> On 24 Jul 2019, at 7:32, John Ralls <jra...@ceridwen.us> wrote: > > > >> 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.
Actually, there are already software engineers who found the idea interesting and would like to participate. But they are not enthusiastic about me sharing the idea in public. I don’t understand what they are afraid of - many people are working to find a solution of the same problem. Someday someone will succeed. One presentation doesn’t change a thing, because it shows the basics many experts are aware of. There is nothing new about it. Also, a friend of mine gave a good idea of funding it, so I’m not here to take your time or money for. :) The problem is I prefer this app to be under GNU GPL. Many reasons for it: the industry is growing and the big companies swallow and merge with smaller. There are shipping lines, that just disappeared the last ten years: Hamburg Sued, UASC, Maruba, CSCL and so on. The three Japanese carriers MOL, K-Line and NYK formed ONE. Merging is a global trend and don’t want to argue if that is a good or bad thing. This solution might bring the balance back to small freight-forwarding companies, but it also might make the big companies stronger. Of course, it might be a complete failure. But there is only one way to find out. :) And you are the only people with long expertise I “know”, who can share opinion and advice and I will take it seriously. Besides, when personal interests of actual developers step in, GPL might be a tough task to keep. As already told you, I’m no software developer and the only experience in my life is this translation. Yet it is far away from actual development. I never understood this decision to make translators part of dev-team. > Your app isn't going to be something that bolts on to GnuCash, though. That > just won't fit. This is exactly what I wanted to know. If developers cannot find a good connection, whatever the reasons might be, than that is the wrong place for contribution. > 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. This should happen anyway. Recently I got in a contact with a company that is interested and can prepare the conceptual design. The rest is already explained. Thank you for you attention and pointing out possible solutions! Take care (-: Kind regards, Rosi _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
