[GNC-dev] [off-topic] Re: Adding module to make GnuCash more valuable

Tue Jul 30 06:44:58 EDT 2019

David,

So many of you tried to open my eyes and I appreciate that.
Especially for the purposes of this topic I prepared a small document-flow attached hereto. It’s good to know that actually few of you are familiar with this subject :)

Here it is explained:
1. Everything is controlled or changed at Origin, no matter what happens. If payment of goods is not received, HBL is not sent to cnee. No payment -> no goods. This is controlled by the trading parties until legislative provisions come into force (confiscation of goods, return to origin, destroy the commodity or re-export to other location). Most of these cases I’ve actually had in my experience + strikes + implementation of new software at ports or customs. I know how complicated it is, when a single failure makes me to communicate with Customs and Port Authorities, shipping lines, brokers and actual customer. Trust me, I know it and could support anything with an example. You don’t need to know :)

2. You think of B/L as a regular road or air waybill. And it is not. It is issued *after* vessel’s departure and contains the only date, that matters. Because it is provided and supported by Customs Agency and feeder/vessel’s operators. This is the exact point of starting the carrier’s responsibility. Other clauses as “Received for shipment” just specify when the FF or shipping line took over the goods in order to comply with bank requirements. You have problems with banks to implement the connection? I have had many troubles to explain them why they cannot ask me as an issuer of document title to put something that is not true; like “Clean on board”. Because it will extend my responsibility outside my area of control. Yet, customers tend to ask for it after it is possible to meet the requirements of this clause. ;-) Banks even tend to be arrogant and imperative. But FF take the actual responsibility over the goods, you can sue them for improper release of your cargo and no one will support them. 

3. All of you are focusing on problems with simple solution or that are out scope.For example:
- confirmed bank transfer. Not necessary. FF follow-up the commodity movement and the status of HBL only. Payment of freight is watched by whoever has access to bank transactions in the company. If they haven’t received the payment, they do not issue the originals or don’t send them to trading parties. If they already did, but customer is not playing fair, they just instruct the delivery agent not to release the cargo to cnee until further instruction. And it is working, I had more than enough of it. Including as a controlling agent, who is not mentioned on the HBL at all. 

- tracing of goods: nothing more simple than that. Most specialists focus on container or waybill numbers. They implement complex systems, manage them, force their customers to use these super-ultra-safe modern websites. I’ve been using more that 10 shipping lines sites and it is a complete nightmare, because of different implementation of VGM submission or rate quotes, or shipping instructions, etc. At least Maersk gave-up on browser’s certificates.
Instead, customers shall only type the name of the mother vessel given on HBL in any search engine and will find all the whereabouts of their cargo at the moment. There are couple of free of charge websites that provide gps-location of commercial ships. Peace of cake. This will enable trading parties to understand that commercial ships are not taxicabs, serving two ports only.

- place of B/L in double-entry book-keeping: simple solution via transaction reminders. If originals are issued, the FF shall only check if they are received at destination with delivery agent. Or with shipper - if he already sent them to his overseas partner. If yes, a new transaction will mark it as completed operation and will also provide information when it happened. It’s actually a new feature - I’ve never used software that asked me that and kept record of my reply. I only marked the bills of lading in green on my spreadsheet, because the professional software didn’t think about it. Except AS400, may be, but with a work-around. If no originals are issued and express release instead, it is even more simple: date of issue matches date of release.

- secure handling of HBL: the bill is usually sent by shipper with other commercial documents like commercial invoices, packing lists, certificate of origin/conformity/FormA/T2L/whatever. There is no need to implement extra functions in GnuCash because of that. Regular post or courier service will do.

I know what is it do a voluntary job and almost no one would appreciate that. This is why I shared these things in the off-topic. It took me couple of years to submit 100% translation per once. And yet many of you hear about me for the first time :-)
What you also don’t know is I was actually working as a translator for 8 years, part-time job. But in another language pair, because my English is not good enough. So, I know how much time and money I’ve invested in it.

Also I’m aware that some of you don’t like the presentation because it uses commercial fonts on proprietary software. But as an old lady with shoulder pain I prefer to abandon mouse for sometime and use a pen instead. This is why you see these non-serious and non-business oriented funny creatures.

Can we make a deal? I volunteer to do some simple tasks for you in exchange of these two templates. They are ready, but I have to find out how to add them.
For example, you might need a help with F.A.Q. Or may be there are other simple things you find useful and no big experience is needed.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Video.MOV
Type: video/quicktime
Size: 1050150 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20190730/1dd93a33/attachment-0001.mov>
-------------- next part --------------

Kind regards,
Rosi

> On 30 Jul 2019, at 6:05, David Cousens <davidcousens at bigpond.com> wrote:
> 
> Rosi,
> 
> I think you really need to consider approaching a commercial software
> developer. Software is available with this functionality, maybe not in the
> form you propose, but there are commercial solutions out there:
> https://www.linbis.com
> https://lp.descartes.com/aljex-c-v1
> https://www.logitudeworld.com
> https://allotrac.com.au
> http://smartfreight.com
> https://www.magaya.com
> 
> It is not that what you propose may not be useful or meet a need in the
> market for free software, but that the development team for GnuCash is
> largely part time, have other jobs, retired etc. There are many core issues
> in GnuCash which need addressing to keep it viable with the functionality it
> currently has and barely enough people with the expertise and experience
> necessary to do that let alone undertake a major development project on top
> of that.
> Your comment:
> "Tell me if I'm wrong: the biggest problem software or web developers 
> meet is the proper definition of the processes they have to implement. 
> Projects are assigned by owners and managers, who are focused on 
> different things - business flow and not the actual operations flow. "
> 
> pretty well explains the need for a systems analysis team to engage with the
> FF industry in researching and defining those processes to develop the
> appropriate digital solutions, particularly when coping with international
> operations where legal jurisdictional problems can be complex. Gnucash might
> have individuals with the necessary systems analysis capability but they are
> most likely already committed. GnuCash is doable because the core of
> accounting is well developed and doesn't change much and has well developed
> international standards that most countries are pretty close to even if the
> haven't adopted those standards and GnuCash addresses that core requirement.
> It doesn't tackle customisation for individual requirements except by
> remaining flexible enough that those requirements could be met outside
> GnuCash.
> 
> The other problem you mention is "interest". If one of the GnuCash
> contributors was sufficiently interested, generally because they are
> involved in the industry, you might strike it lucky. There is certainly no
> harm in canvassing the forum to see if that interest does exist. It may not
> necessarily exist.
> 
> "accounting software is made to do the _book-keeping_" Accounting software
> is designed to do the *financial* bookkeeping i.e. track where they money
> goes to and comes from.  It is not designed to track the location of goods,
> via  a variety of shipping methods and routes, their departure and arrival
> and whether payment has or has not been made and whether their release
> should ro should not be authorized. That requires custom purpose made
> software with appropriate authorization methodologies incorporated into it.
> Gnucash has no methodology for external notification that a payment has been
> received which is about the only part of the operations you have described
> which falls within the accounting functionality of GnuCash. With a database
> backend version one could externally query the GnuCash database to obtain
> such verification but that would require a consistent defined methodology
> for ensuring tagging the payments recorded into GnuCash with references
> which can be tracked to the appropriate B/L. Good luck with getting banks to
> necessarily incorporate the additional information you need in their
> records.
> 
> As others have commented I would think what you describe would be best
> implemented as an external program which can communicate the requisite
> financial information to GnuCash rather than within GnuCash itself. It is
> not the value of what you propose that we disgaree with in saying it is out
> of scope, but the capacity to implement what you propose with the existing
> available resouces.
> 
> David Cousens
> 
> 
> 
> -----
> David Cousens
> --
> Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel