GNOME Bugzilla – Bug 670008
taxinvoice lacks flexibility necessary to produce legally valid Australian Tax Invoice
Last modified: 2018-06-29 23:06:28 UTC
Created attachment 207477 [details] [review] taxi-presentation_options(first).patch Due to invoice limitations, Gnucash is not yet ready for small business use in Australia. Lack of customisation options in taxinvoice do not allow to change its presentation for compliance with legal requirements. Worse, current FAQ entry http://wiki.gnucash.org/wiki/FAQ#Q:_How_do_I_change_.22Invoice.22_to_.22Tax_Invoice.22_as_required_in_Australia.3F is misleading because it suggest to edit template installed by the native package in GNU/Linux distributions like Debian. Apart from unrealistic expectations regarding user's capabilities to edit templates in Schema, it implies users to have administrative rights, and recommend to edit files which will be overwritten upon package upgrade. In the attached patches I greatly extend customisation options for taxinvoice by introducing new dialog options allowing to enable/disable tables' columns (with dynamic adjustments to table layout, etc); Hard-coded text messages in English are moved to corresponding options with defaults closely following original taxinvoice to introduce minimum disturbance while bringing many improvements thoroughly documented in patch headers. Those patches make taxinvoice practically useful for invoicing. They accommodate weeks of labour so I hope you might consider integrating this work. First patch introducing few changes to allow easy adjustments to report presentation. Second patch (need to be applied over first one) bring all the important options regarding taxinvoice flexibility. Also it would be nice to ship the attached README-AU.txt file to give Australian business users some clues how to customise invoice to produce something like the attached PDF file etc. Please let me know this work is suitable for Gnucash or if any change is required to make it suitable. Thank you sincerely for all your hard work on Gnucash. Regards, Dmitry.
Created attachment 207478 [details] [review] taxi-customization_improvements(second).patch
Created attachment 207479 [details] README-AU.txt Sample text (markdown) describing possible taxinvoice settings for Australian GST invoicing.
Created attachment 207480 [details] Sample tax invoice This is sample invoice only, it doesn't give overview of introduced options, but only demonstrate a possible outcome.
Created attachment 207481 [details] README-AU.txt
Thank you for contributing this report patch, unfortunately I can't get your patches to apply cleanly in either latest 2.4 or trunk. Can you create/test your patch against latest svn version? Regarding the FAQ entry, can you submit a separate bug report, or better yet edit the wiki yourself.
Created attachment 207730 [details] [review] taxi-presentation_options(first).patch
Created attachment 207731 [details] [review] taxi-customization_improvements(second).patch
Hello Mike, Apologies for delay and thank you for your work. Indeed something has changed in trunk so I have patches updated and tested. It took me hours to build trunk version because most recent trunk is broken - it fails to build with error ../../../src/engine/.libs/libgncmod-engine.so: undefined reference to `gnc_features_set_used' So I had to build r22009 (less than a week old) to check if my changes are working. All good, you're welcome to have a look. Surely I will be happy to update FAQ (sorry for ranting) but those improvements of mine are critical for information to put in the FAQ. Before my patch invoice was impossible to customise in a useful way for Australia using GUI so it was pretty much hopeless. I'd like to change it for better, with your help. All the best, Dmitry.
Any feedback? Perhaps it would be nice if you could try this patch before trunk will diverge to a state when patch will not be possible to apply clean.... Thank you.
correcting version from 2.4.10 to trunk since patches were updated for SVN; setting severity to 'minor' as this functionality is desperately needed.
Comment on attachment 207730 [details] [review] taxi-presentation_options(first).patch r22102, thanks!
Comment on attachment 207731 [details] [review] taxi-customization_improvements(second).patch r22103, thanks!
As for README-AU.txt: Where should we put it? Maybe on the wiki, but this you can do yourself as well? Somewhere buried in the source tree makes it worthless because nobody will find it. Maybe somewhere in the "gnucash-docs" module? But then it better should be some docbook markup and not just plain text. Feel free to suggest some location. Thanks!
Created attachment 210168 [details] Image showiing wrong column for totals. If there are no taxes applied then the totals box is in the wrong place. Perhaps too, if the unit column is hidden then aren't the quantities meaningless and should be hidden also?
1. If Invoice number next to title " is selected I see: "Invoice Invoice number: XXXXXX" 2. Whenever the options dialog is opened there is also: CRIT <gnc.gui> [gnc_option_set_ui_value_internal()] bad value error. 3. Small typo in elements dialog. /Sjow/Show/ Looks good though!
Thank you Christian, README-AU.txt should certainly go to wiki but not until new release. (Hopefully I'll be able to update it then). It would be nice to make this information available offline, but I don't know docbook markup yet.. Sadly I don't know when I'll be able to spend some time for it but for sure it won't be soon... Sorry. Thanks Mike, I'll try to fix total column (without taxes) soon, hopefully tomorrow unless you guys fix it before me. Quantity is not meaningless if you're invoicing only for goods where unit is an object like car or coffee machine (in which case column 'units' would be unnecessary or even confusing). "Invoice Invoice number: XXXXXX" is absolutely intentional - as described in README-AU.txt this is for overriding "Invoice number text" and therefore make sure invoice name and number is in top-right corner, as in sample tax invoice. I'm not sure where "CRIT <gnc.gui> [gnc_option_set_ui_value_internal()] bad value" is coming from - I primarily use 2.4.10 and I had to do certain adaptation for trunk. I had no such error in trunk version I build for submitting updated patch back then. Thanks for noticing typo. :) Cheers, Dmitry.
Created attachment 210566 [details] [review] 0001-table-layout-fix-for-taxless-invoices.patch patch to correct table layout for taxless items
Apologies for delay - here is the patch for table layout issue with taxless items (reported by Mike E). It is also addresses the similar problem with discount columns. By the way commit r22111 apparently fixed FTBFS with --libdir=/usr/lib/x86_64-linux-gnu/gnucash (the problem I mentioned in comment 8) - thanks. Before r22111 I had to build with --libdir=/usr/lib/gnucash as workaround for the problem. I'm unable to reproduce "CRIT" error with recent trunk. Cheers, Dmitry.
Created attachment 210567 [details] [review] minor spelling patch "Sjow ---> Show"
Thanks Dmitry Did you test it for when taxes ARE taxes applied? Seems to be mis-aligned "Amount Due".
Hi Mike, I tested with all combinations of Taxes/Discounts etc. that I could imagine. It is certainly better as it fixes table misalignment you found as well as few similar ones. I don't know what's "ARE" taxes, but I have a feeling I addressed exactly what you're talking about unless you've managed to try new patch and discover more problems. Thank you.
Created attachment 210576 [details] showing the "Amount Due" column offset. (In reply to comment #21) > > I don't know what's "ARE" taxes, but I have a feeling I addressed exactly what That was a typo by me. Sorry for the misunderstanding. I've attached a screenshot, showing the "Amount Due" column offset. I'll commit the work so far. Thanks very much.
Thank you Mike, Please confirm if the problem you demonstrated in screenshot from comment 22 is with or without patch I provided in comment 17? This was exactly the problem I was addressing with patch and I can't reproduce it any more. If you've taken the screenshot after applying my patch please advise how to reproduce the problem so I could fix it, if the problem is still there. Cheers, Dmitry.
Created attachment 210684 [details] [review] Fix "Amont Due" alignment Hi Dmitry The problem occurs when I have an invoice which has never had tax applied, since I don't charge UK VAT. My customers default to no tax being applied. In this case the alignment issue occurs. If I apply tax in the invoice, for testing purposes, then remove it again the alignment is OK. My "Default Tax Table" is set to "None". Try with a customer tax table set to None, create a new invoice (which should have no taxes) see if you get the same result. Then, try the attached patch. If it works for you then I'll commit. There's a couple of commented apostrophies (;') to make geany colourisation work, ignore those. Mike E
Created attachment 211027 [details] [review] refactoring-table-layout-calculation.patch Hi Mike, You're right, layout problem is still there - it's manifesting in some situations as you described. I tried your patch, it helps a little, but I found more problems when I loaded real data - "Payment received" row is also mis-aligned. I admit the fix was more difficult to implement than I thought so I've decided to try a different approach to control table layout - hopefully more robust and maintainable. The attached patch moves most of the layout calculation logic to rows which I think makes it easier to control. Also it's using less variables. What do you think? Let's see if you'll be able to find any table mis-alignments now. :) I've done a lot more testing with this patch so I hope it will finally let us to close this bug. (You don't need to commit your patch if this one is OK for you). All the best, Dmitry.
Thanks Dmitry, it looks good to me. Thanks for the work! I find most things more difficult to implement than I thought. Committed to trunk@22126
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=670008. Please update any external references or bookmarks.