Re: [GNC-dev] Adding module to make GnuCash more valuable
> On 24 Jul 2019, at 7:32, John Ralls wrote: > > > >> On Jul 23, 2019, at 11:59 AM, Rosi Dimova wrote: >> >> Hello, >> >> >>> On 23 Jul 2019, at 20:18, John Ralls 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 r
Re: [GNC-dev] [GNC] UK VAT and "Making Tax Digital"
Hi Christopher, I've just submitted the first MTD VAT return using GC and the report you very kindly wrote. The only glitch discovered in actual production use is that the dates exported by the report in to the CSV file and hence read by the bridging spreadsheet need to have a 4-digit year, the export is presently only 2 digits. I had no EU transactions this quarter but otherwise, no problems, the numbers all matched up to my old custom reports. so thank you very much for the time to make this work. best regards, Maf. On Wednesday, 12 June 2019 15:30:15 BST Christopher Lam wrote: > Hi > > I think it'll be reasonable for now to merge some infrastructure work in > the transaction-report engine to allow CSV export. > > uk-vat-report.scm would be a custom-report, added onto standard-reports or > possibly config-user.scm on request, with caveat that the > accounts-selection is not yet set in stone. > > Ultimately it may be an idea to add onto the Tax-Info dialog to tag > accounts, but I don't know how to do that. > > C > > On Wed, 12 Jun 2019 at 11:07, Maf. King wrote: > > Hi Christopher, > > > > thanks for the gentle prod. I've been very busy for the last couple of > > weeks, > > and I apologise for not getting back to you sooner. > > > > so far, the VAT report seems to work for me, I haven't spotted any glaring > > problems, although I appreciate the limitations on the account selections > > that > > you mention, and I haven't explored deeply with anything other than my > > normal > > files. > > > > it seems that MTD hasn't gone away (unfortunately) and would be a shame to > > miss the release bundle, although I accept that this is still code which > > is > > beta-ish in nature, and I don't know the GC policy on including code which > > may > > still need some polish in a finished release. However, I would also > > counter > > that the first real complete test of the workflow has to wait for July and > > the > > first return being prepared. > > > > best regards, > > Maf. > > > > On Sunday, 9 June 2019 15:53:26 BST Christopher Lam wrote: > > > Any final views on enabling CSV export of subtotals and VAT report? 3.6 > > > will be in preparation soon... > > > > > > The VAT report is rather UK-specific regarding EC sales and I don't know > > > rules for other EC countries. It'll be a shame to limit it to UK only, > > > which means any other EC VAT report will need to duplicate and amend the > > > report. > > > > > > And while the selection of Sales/Purchases/VAT accounts is IMHO > > > satisfactory, the tagging of EC accounts via account-description is > > > > rather > > > > > hackish, but possibly the easiest one available so far, unless we reuse > > > > the > > > > > Tax-Info dialog. > > > > > > Unless the above questions are not finalised I wouldn't think it's > > > appropriate to merge VAT-report. > > > > -- > > Maf. King > > PGP Key fingerprint = 8D68 A91F 733B 2C1F 43B7 2B7C E591 E8E1 0DE7 C542 -- Maf. King PGP Key fingerprint = 8D68 A91F 733B 2C1F 43B7 2B7C E591 E8E1 0DE7 C542 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] [GNC] UK VAT and "Making Tax Digital"
Hi Maf, you're welcome; thanks for letting me know. The dates are printed via gnucash's date-printer and will probably obey the locale or general preferences setting. Try Preferences/Date&Time. I'm still considering how to incorporate the UK rules into the current merged report; I now know the sales/purchases accounts selection via Income/Expense account-type is a design mishap; perhaps the next 4.x series will request the sales/purchase acocunts separately. This means the UK-VAT report (including the EC rules and the EC account tagging hacks) could then be an optional switch in the GST Report. On Wed, 24 Jul 2019 at 10:39, Maf. King wrote: > Hi Christopher, > > I've just submitted the first MTD VAT return using GC and the report you > very > kindly wrote. > > The only glitch discovered in actual production use is that the dates > exported > by the report in to the CSV file and hence read by the bridging > spreadsheet > need to have a 4-digit year, the export is presently only 2 digits. > > I had no EU transactions this quarter > > but otherwise, no problems, the numbers all matched up to my old custom > reports. > > so thank you very much for the time to make this work. > > best regards, > Maf. > > > > > On Wednesday, 12 June 2019 15:30:15 BST Christopher Lam wrote: > > Hi > > > > I think it'll be reasonable for now to merge some infrastructure work in > > the transaction-report engine to allow CSV export. > > > > uk-vat-report.scm would be a custom-report, added onto standard-reports > or > > possibly config-user.scm on request, with caveat that the > > accounts-selection is not yet set in stone. > > > > Ultimately it may be an idea to add onto the Tax-Info dialog to tag > > accounts, but I don't know how to do that. > > > > C > > > > On Wed, 12 Jun 2019 at 11:07, Maf. King wrote: > > > Hi Christopher, > > > > > > thanks for the gentle prod. I've been very busy for the last couple of > > > weeks, > > > and I apologise for not getting back to you sooner. > > > > > > so far, the VAT report seems to work for me, I haven't spotted any > glaring > > > problems, although I appreciate the limitations on the account > selections > > > that > > > you mention, and I haven't explored deeply with anything other than my > > > normal > > > files. > > > > > > it seems that MTD hasn't gone away (unfortunately) and would be a > shame to > > > miss the release bundle, although I accept that this is still code > which > > > is > > > beta-ish in nature, and I don't know the GC policy on including code > which > > > may > > > still need some polish in a finished release. However, I would also > > > counter > > > that the first real complete test of the workflow has to wait for July > and > > > the > > > first return being prepared. > > > > > > best regards, > > > Maf. > > > > > > On Sunday, 9 June 2019 15:53:26 BST Christopher Lam wrote: > > > > Any final views on enabling CSV export of subtotals and VAT report? > 3.6 > > > > will be in preparation soon... > > > > > > > > The VAT report is rather UK-specific regarding EC sales and I don't > know > > > > rules for other EC countries. It'll be a shame to limit it to UK > only, > > > > which means any other EC VAT report will need to duplicate and amend > the > > > > report. > > > > > > > > And while the selection of Sales/Purchases/VAT accounts is IMHO > > > > satisfactory, the tagging of EC accounts via account-description is > > > > > > rather > > > > > > > hackish, but possibly the easiest one available so far, unless we > reuse > > > > > > the > > > > > > > Tax-Info dialog. > > > > > > > > Unless the above questions are not finalised I wouldn't think it's > > > > appropriate to merge VAT-report. > > > > > > -- > > > Maf. King > > > PGP Key fingerprint = 8D68 A91F 733B 2C1F 43B7 2B7C E591 E8E1 0DE7 > C542 > > > -- > Maf. King > PGP Key fingerprint = 8D68 A91F 733B 2C1F 43B7 2B7C E591 E8E1 0DE7 C542 > > > > > > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Adding module to make GnuCash more valuable
Hi Rosi, Am 24.07.19 um 09:12 schrieb Rosi Dimova via gnucash-devel: : > 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. 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, ... > >> 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. > 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 Regards Frank ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Adding module to make GnuCash more valuable
Hi Frank, > On 24 Jul 2019, at 17:47, Frank H. Ellenberger > 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
Re: [GNC-dev] Adding module to make GnuCash more valuable
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 > wrote: > > Hi Frank, > >> On 24 Jul 2019, at 17:47, Frank H. Ellenberger >> 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
Re: [GNC-dev] Adding module to make GnuCash more valuable
> On Jul 24, 2019, at 1:08 PM, Rosi Dimova wrote: > > Hi Frank, > >> On 24 Jul 2019, at 17:47, Frank H. Ellenberger >> 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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
