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. :) Kind regards, Rosi _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
