GNOME Bugzilla – Bug 767032
Bad invoices from importing "posted" needing currency conversion
Last modified: 2018-06-29 23:49:20 UTC
Created attachment 328753 [details] Contains GnuCash with accounts, customer; invoices to import; screenshot of import. I'm loading an invoice history to GnuCash 2.6.12, and have found a less-than-awesome handling of invoices with "foreign" customers if they are being imported as "posted" to accounts with "domestic" currencies. Enclosed is a sample file with most accounts in USD, and one customer CUS-007GBP who is invoiced in and pays in GBP. There's also a sample "inv-test.csv" importing invoices for the customer. The invoices import with the correct fields, and all in the customer's correct currency. An invoice report will show a posting date for those invoices which are posted. => But if I open the invoice in a tab, it shows as un-posted. Clicking "Post" asks for a currency conversion to USD, and I give it, and there's no error, and yet it doesn't post. Importing invoices as "posted" that need currency conversion creates un-postable invoices. <= This is for a very small business that has some sales to international customers who are billed in their own currencies, thanks to the web-based marketplace it sells on. For completeness, the inv-test.csv has every combination of attribution and posting accounts for the alternate-currency customer. Open the "Import Bills & Invoices" dialog, click "Invoice" and "Comma" radio buttons, to see it behave as below. * Unposted imports * 1. US-Attr : USD Attribution account 2. GB-Attr : GBP Attribution account * Posted imports * 3. US-PostUS: USD Attribution account, USD A/R 4. US-PostGB: USD Attribution account, GBP A/R 5. GB-PostUS: GBP Attribution account, USD A/R 6. GB-All : GBP Attribution account, GBP A/R * Results * | Inv # | Due Date OK | Posted Date OK | Paid flag | Can Post & Unpost | |-----------+-------------+----------------+-----------+-------------------| | US-Attr | Yes (blank) | Yes (blank) | | Yes | | GB-Attr | Yes (blank) | Yes (blank) | | Yes | | US-PostUS | NO (blank) | Yes Apr 4 | | NO | | US-PostGB | NO (blank) | Yes Apr 4 | | NO | | GB-PostUS | Yes May 5 | Yes Apr 4 | Yes | Yes | | GB-All | NO (blank) | NO (blank) | | Yes | * Notes * The main bug are that "US-PostUS" and "US-PostGB" are broken, neither can be posted or unposted. They have date for posting, yet still show the "Post" button. Clicking the "Post" button asks for an exchange rate but does not actually post those invoices. I expected "GB-All" to "just work" and import as already-posted, since the currency matches for customer, attribution account, and posting account. I expected importing it to add £8 to "Product Sales GBP" and also to "A/R GBP". Immediately after importing inv-test.csv, "Product Sales GBP" shows £4.00, and all other sales & A/R accounts remain at 0. Thus "GB-PostUS" is the only invoice which had any transactions associated with it. Yet even though it shows as posted, and can be un-posted, importing it had no influence on any A/R account. GB-PostUS imports as "Paid," I'm not sure if that's correct or not. I didn't think one could import payments with invoices. I tried changing the "accumulate splits" flag, it didn't change the described behavior. I have no strong opinion on what should happen when the customer currency doesn't match the currency for an account, other than a desire for consistency. It would be good to try the same with bills, perhaps by creating a GBP vendor also called "CUS-007GBP" and using this same test file.
Sorry about taking so long to look at this and thank you for the comprehensive bug report. I can confirm this behaviour and I see CRIT <gnc.pricedb> [gnc_price_get_value()] price NULL. errors when importing and posting. I'll look into this as soon as I have some time. Mike
It also gets the posted date wrong for auto posted invoices.
(In reply to Mike Evans from comment #2) > It also gets the posted date wrong for auto posted invoices. Oops, it doesn't if the locale is set correctly.
I *think* that invoices with other currencies should never auto-post because; GnuCash normally pops up a currency dialog when manually posting giving the user the opportunity to get and check the exchange rate. I don't think exchange exchange rates should be automatically applied during the import and I don't think popping up this dialog repeatedly during import is satisfactory either. The importer should just import, but not post any invoices involving other currencies thus leaving the user to manually process these post-import. Maybe the auto-posting feature should not be implemented at all as it may lead to users not examining the imported invoices and missing possible errors.
>Maybe the auto-posting feature should not be implemented at all >as it may lead to users not examining the imported invoices and >missing possible errors. This cropped up during a bulk import from another system; auto-posting on import was helpful when converting those records. And the majority of the records were all in the same default currency, it was great having posting taken care of. If the feature must be disabled, please consider doing so only for cross-currency transactions. Thanks!
OK What I have done so far: Only auto-post if: The posted_to account name is valid. There's no currency conversion. The invoice customer's currency matches the A/R account currency. Using your sample csv the debugging output now looks like: Invoice US-Attr is NOT marked for posting Invoice GB-Attr is NOT marked for posting Invoice US-PostUS NOT posted because it requires currency conversion Invoice US-PostGB NOT posted because it requires currency conversion. Invoice GB-PostUS NOT posted because currencies don't match Invoice GB-All posted A/R GBP has £8 in it after import. Regarding Invoice GB-PostUS, if you manually post it you do not get the option to post to Assets:Accounts Receivable:Accounts Receivable-Trade because the account currency is USD. Not sure why your dates are wrong though. However, the date format in preference has to match the format in the csv file.
That is a sane way of handling the situation, thanks for thinking it through and implementing the fix.
Thank you Yary for a comprehensive bug report which made fixing this a much easier experience. If only all bug reports were as good. Pushed to git as commit 9c39d0e597 This will be in the next release, which is planned for 2017-03-26
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=767032. Please update any external references or bookmarks.