> On 25 Jul 2019, at 0:45, John Ralls <jra...@ceridwen.us> wrote:
>> On Jul 24, 2019, at 1:08 PM, Rosi Dimova <poc...@icloud.com> wrote:
>> Hi Frank,
>>> On 24 Jul 2019, at 17:47, Frank H. Ellenberger 
>>> <frank.h.ellenber...@gmail.com> wrote:
>>> Hi Rosi,
>>>> Am 24.07.19 um 09:12 schrieb Rosi Dimova via gnucash-devel:
>>>> :
>>>> I never understood this decision to make translators part of dev-team.
>>> you are our ambassador to all Bulgarian speaking people. :-)
>>> Translators find many issues in the GUI: Missing context, bad plural
>>> forms, bad concatenation for right-to-left writing,  ...
>> I like that - an ambassador. Works for me. :-) 
>> You have a point, I never considered these things. But can recall being 
>> stuck at 33% of translation for months, because I didn’t understand one 
>> single word. If it wasn’t for Mila, who explained me our legislation lacks 
>> the concept of orphan account, Bulgarian translation wouldn’t become real 
>> for many years. At least, not from me.
>>> I like your idea. But considering our small resources, I believe it
>>> would better fit as a module into ERP software:
>>> https://en.wikipedia.org/wiki/List_of_ERP_software_packages
>> Thank you!  :) I’m not good at explanations, but will give it another try 
>> and will stop disturbing your discussions. :) 
>> You and John are thinking big, but not small or not big enough. And you are 
>> underestimating yourselves. Or may be I wasn’t clear enough. Here it is why:
>> Technically, issuing ocean bill of lading is nothing much different that 
>> printing out a document on a letterhead. Forwarders and shipping lines use 
>> various tools. Small companies use spreadsheets or pdf templates to print it 
>> on paper. Big companies use SAP or other solutions. SAP-based solutions use 
>> browser+pdf again in the common case. I used to work on AS400 for almost 2 
>> years. Can you imagine that? It’s older than me! 
>> So, I’m talking about nothing more than two additional templates - one for 
>> originals and another for electronic (express or telex) release. But it is 
>> tricky, especially the latter. For originals: the margins of the templates 
>> should be adjustable to fit on their own forms. Also additional fields as 
>> per local legislation might be required (like SCAC code).
>> The good practice says originals should be printed out from fewer computers. 
>> Also two or max. three persons in charge shall sign them. A specimen of any 
>> written signature is kept to prove the validity of the B/L. But it is 
>> problem of the issuing party, not of the software. Most small companies do 
>> not follow this rule strictly.
>> For express release: same rules shall be kept by using electronic means. 
>> Basically it should include additionally three programmable fields:
>> - consecutive number of the document itself, not the B/L number 
>> - identity of the signing party (digital signature or some kind of security 
>> token)
>> - valid time stamp, supported by Electronic data interchange (EDI) for 
>> vessel’s sailing date. 
>> Date of departure is as important as the identity. Especially for L/C.
>> The two templates are needed, because in some countries originals are the 
>> only valid B/L. Others require the B/L’s to mention the ocean rate 
>> (freighted B/L).
>> This is the idea and I think GNC can actually do that or supports the 
>> features to implement it. Please let me know if I’m right. :)
> We used an AS400 for production management at the integrated circuit company 
> where I was the production control manager 20+ years ago. It was an 
> interesting system to work with.
> There's nothing there about money, and GnuCash is about managing money. For 
> what you've described a simple LibreOffice plugin would do the job better 
> than GnuCash would.
> Regards,
> John Ralls

This thread becomes more interesting than I thought. Four of GNC developers 
said it is out of scope. And not a single one says it cannot be done. :)

LibreOffice is not in applicable, because it doesn’t keep track on 
transactions, invoices and money flow (via aqbanking). ERP’s are not suitable, 
because they serve other purposes. Implementing B/L in ERP will be easy, but it 
would inherit the flaws of the ERP/CRM/etc.

Here it is why:
- B/L actually acts as a security. Theoretically, it doesn’t serve as a 
document of ownership (as per popular readings on the Internet). Practically, 
it is just like that! It’s a very special document of title. It transfers 
ownership while the commodity of any value is on the move - on board or at any 
other point of shipment. And GNC supports securities - I can recall it from the 
translation 9y ago, even if I have no idea how it works

- Afaik, there is no such product on the market. Believe it or not, both 
commodity and money flow work fine even without it, yet... There is no 
commercial or free software solution for freight-forwarders since 40+ years. 
Shipping lines have it, but it is easy for them, because they act as 
Principal-Agent which is basically server-client relationship. 

My recent research showed there are many efforts to implement Etherium. Only 
one of them shows the understanding of B/L. Others are still kept in secret, so 
I have no opinion. 
But this solution is done incorrectly. Developers assume all involved parties 
are equal to each other and yet they are not. 

If I have to present the basic movements of the goods and not the B/L itself, 
it is like that:

client(shipper)->peer->server at origin->other servers->server at 

HBL movement is:
peer (origin) - peer (destination) once shipper and consignee clear the payment.

Aggregation of these parties with distributed cryptographic software looks 
sweet and fancy, and cutting edge. Even revolutionary. But it is more like 
putting predators, pray, armed guards, visitors and food&water in the same cage 
of the zoo. 

Guys, I’m not here to recruit any of you for my idea, but to tell me why GNC is 
not suitable. If you want to get rid off me, just say: GNC‘s features do not 
allow to keep track on consecutive documents (as invoices) or don’t support 
software for digital signature. Or EDI-standard could not be implemented. And 
I’ll give up or put it on hold and just live my life :) 

Kind regards,

gnucash-devel mailing list

Reply via email to