Hi, Now i finally get it why all of you propose any inventory software. B/L is not a typical waybill as you imagine. It is not this document that you just fill-in, put on parcel and trace it via website to allocate the product shipped.
It should not travel with the goods. There is just no way this could happen. Shipper has to send the B/L to cnee via post/courier once payment of the goods is received. Or release them electronically. If they are not paid by the time the commodity arrives at port of discharge, cnee cannot take ownership of the commodity due lack of B/L. No one would release the goods if payment is pending. Cnee shall either pay the agreed price or abandon the shipment. Some of you may have watched “Container wars” on TV. This is what happens in many cases. Kind regards, Rosi PS: sorry, John, didn’t reply the correct email. > On 24 Jul 2019, at 23:14, Adrien Monteleone <adrien.montele...@lusfiber.net> > wrote: > > But what you are speaking of here appears to me to be more of a document > management or inventory management feature, not an accounting feature. > > I’d be inclined to agree with John, that is out of scope for GnuCash. > > I understand the industry might have a need for such features, particularly > open source options, but I’m not sure GnuCash is the place for them. > Certainly, you can track inventory ownership in your GnuCash books, but the > details of how you arrive at those transactions are likely best handled by > some other tool. > > Regards, > Adrien > >> On Jul 24, 2019, at 3:08 PM, Rosi Dimova via gnucash-devel >> <gnucash-devel@gnucash.org> 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. :) >> >> Kind regards, >> Rosi >> >> >> >> >> >> >> _______________________________________________ >> gnucash-devel mailing list >> gnucash-devel@gnucash.org >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
