> On Jul 23, 2019, at 11:59 AM, Rosi Dimova <poc...@icloud.com> wrote: > > Hello, > > >> On 23 Jul 2019, at 20:18, John Ralls <jra...@ceridwen.us> wrote: >> >> That would be *way* out of scope for GnuCash. The only effect on accounting >> is when the change in ownership of the inventory is booked. Deciding that is >> completely external to GnuCash, which doesn't even do cost accounting for >> WIP inventory. It might be in scope for an ERP program like odoo >> (https://www.odoo.com/) that does do cost accounting, but even that's >> doubtful and most of an ERP suite wouldn't be useful to a freight forwarder. >> (I used to be the production control manager at an integrated circuit >> manufacturer so I have a small understanding of international shipping.) > > The focus here is not on inventory - it is just not mandatory thing for the > freight forwarders. Many of them use warehouses of their partners. There are > many ERP-systems, so it is not a point of interest now. > > Instead, this is the ocean bill of lading that transfers the ownership of the > commodity shipped. There is no reliable solution on the market yet. It has > more to do with “smart contracts” or whatever is the correct term for using > the means of version control system. And I believe you, guys, know pretty > well how it works. > > >> You might invert the problem, though, and use GnuCash as the accounting >> backend for a stand-alone shipping management program. >> >> Regards, >> John Ralls >> > > That might be a nice workaround actually. > Let me explain the idea: > The thing is many people, including trading companies with many years > expertise and actually successful international business, do not completely > understand the concept “document of title” and what does mean that the B/L is > “transferable”. That caused many troubles in my experience. Maritime business > just lacks of modern solutions. > > This is why I’m here - if you are interested, I can explain how it works, > where are the weak points, possible solutions, which points of control cannot > and shouldn’t be replaced by robots. This is a main issue with recent systems > - bots are introduced where human force is required and human do things, that > will be easier for software. > > With bills of lading you cannot afford that. Ocean freight forwarders are > responsible for delivery of goods against surrendered B/L. And robots are > not. Many companies are trying to implement electronic B/L using blockchain. > But I’m afraid a possible failure of any of them (or any crypto-currency) > might lead to a blind alley and mistrust. This is why my suggestion is > GnuCash + electronic B/L. Both on the backend. It looks a way out of scope. > On second thought they might seem closer than you think. > > It’s just something to consider. I’m trying to connect the dots only and > introduce another use of GnuCash.
If you're just here on a recruiting effort, looking for software engineers to write your app for you, OK. I'm not interested, but others here might be. Your app isn't going to be something that bolts on to GnuCash, though. That just won't fit. The other way around might, but get the conceptual design worked out without any preconceptions about what might or might not contribute. Once you have a good conceptual design you can start to look at what existing products might match the requirements of the design. Regards, John Ralls _______________________________________________ gnucash-devel mailing list email@example.com https://lists.gnucash.org/mailman/listinfo/gnucash-devel