Created attachment 238560 [details]
Replacement taxinvoice.scm file, with sensible defaults to suit Australia

Created attachment 238561 [details]
A replacement taxinvoice.eguile.scm file, with sensible defaults to suit Australia

Created attachment 238562 [details]
Replacement taxinvoice.css. Minor cosmetic changes.

Created attachment 238563 [details]
Sample tax invoice after this patch has been applied, using default options.

Please accept this patch to provide a working AU Tax Invoice without having to change several defaults. The result from Bug 67008 still requires work to produce a legally valid invoice for Australia, and we do need this to "work out of the box" for ordinary Australian users.

Thank you for your patches. I appreciate the effort you have spent to bring
this all together.

Unfortunately I can't just apply them for a couple of reasons.

1. To start, GnuCash has two separate series of code (called "branches" in our
technical jargon) that are currently actively maintained: a stable branch,
which results in stable releases (2.4.11 being the last one so far) and a
development branch. We haven't made any release from the development branch yet
since the start of the 2.4 series.

GnuCash has a fairly strict policy regarding which patches can be applied to
which branch. You can read the full details on this in [1]. Basically all
development happens on the development branch and under certain conditions
bugfixes are backported (copied over) to the stable branch.

The patches you have assembled were all applied on the development branch. They
were clearly intended as an enhancement of the currently existing
functionality, not a bugfix. For this reason these patches were never
considered for the stable branch, and hence were not present in version 2.4.11
when it was released. Contrary to what you seem to have understood, they
shouldn't have been either.

2. The patches are not in a patch format. Instead these are full files. This
makes it harder for a developer to see what has changed. In itself this would
not be a reason to block the patches though. Especially not in this case,
because the patches are already known and applied. But then there is

3. Apart from the assembled patches, you have made some additional changes to
prefer the Australian defaults in all cases. Given issue 2, it's pretty
difficult to filter out what exactly you changed for this. But regardless, I
can't accept that change anyway. This is not a solution or even a workaround
for the general problem with the report or GnuCash as a whole (lack of a way to
deal with country or region-local features). Your patches push the
inconvenience from Australian users onto the rest of the world.

I will also add this reply on the mailing list, and ask for feedback from the
other developers on this particular case.

[1] http://wiki.gnucash.org/wiki/Subversion#Backport_Rules

Thanks for submitting your tax invoice improvements.  Unfortunately there are a couple of issues that prevent them being included in the code.

Most seriously is that GnuCash crashes on start when your invoice is used in trunk.

Backtrace:
In unknown file:
   ?:  90* [load-file #<primitive-procedure primitive-load> ...]
   ?:  91* [save-module-excursion #<procedure #f ()>]
   ?:  92  (let (# #) (dynamic-wind # thunk #))
   ?:  93  [dynamic-wind #<procedure #f ()> #<procedure #f ()> #<procedure #f ()>]
   ?:  94* [#<procedure #f ()>]
   ?:  95* [primitive-load "/home/mikee/progs/gnucash-taxinvoice/share/gnucash/guile-modules/gnucash/report/taxinvoice.scm"]
In /home/mikee/progs/gnucash-taxinvoice/share/gnucash/guile-modules/gnucash/report/taxinvoice.scm:
  28:  96* (use-modules (gnucash business-utils))
  28:  97  (eval-case (# # *unspecified*) (else #))
  28:  98  (begin (process-use-modules (list (list #))) *unspecified*)
In unknown file:
   ?:  99* [process-use-modules (((gnucash business-utils)))]
   ?: 100  (let* ((interfaces #)) (call-with-deferred-observers (lambda () #)))
   ?: 101* [map #<procedure #f (mif-args)> (((gnucash business-utils)))]
   ?: 102* [#<procedure #f (mif-args)> ((gnucash business-utils))]
   ?: 103* (or (apply resolve-interface mif-args) (error "no such module" mif-args))
   ?: 104* [apply #<procedure resolve-interface (name . args)> (#)]
   ?: 105  [resolve-interface (gnucash business-utils)]
     ...
   ?: 106  (let* (# # # # ...) (and # #) (if # public-i #))
   ?: 107* (and (or (not module) (not public-i)) (error "no code for module" name))
   ?: 108  [error "no code for module" (gnucash business-utils)]
     ...
   ?: 109  [scm-error misc-error #f ...]

Runs fine with 2.4 though, but see the cuple of issues below regarding wrapping and column mis-alignment.

Also you appear to have re-introduced a couple of minor bugs that were fixed in trunk with bug 670008 relating to wrapping in the date column.

Plus a table mis-alignment issue has re-appeared.  Test it with all the checkboxes checked in the Elements options.  The sub-total line is mis-aligned.

Saying that, it is a good looking invoice.  As it is though, mainly because of the crashing, this unfortunately cannot be applied to the development trunk without further work.  As a Linux user I cannot give detailed advice concerning obtaining and compiling trunk sources on a Mac.  The development trunk sources already have Dmitry's changes in, so it may be relatively easy to add your improvements there.

These may of help.
http://wiki.gnucash.org/wiki/Building
http://wiki.gnucash.org/wiki/MacOSX/Quartz

(In reply to comment #5)
> Please accept this patch to provide a working AU Tax Invoice without having to
> change several defaults. The result from Bug 67008 still requires work to
> produce a legally valid invoice for Australia, and we do need this to "work out
> of the box" for ordinary Australian users.

Would you want me to apply a patch that makes GnuCash "work out of the box" for
Australian users, but then require the rest of the world to change several
defaults each time ?

I think we need a broader solution that suits everyone.

See also my previous comment for other reasons this wasn't added in the 2.4
branch.

Can I make a suggestion? Perhaps what we need is a "Remember these values" (or equivalent) button when configuring invoice options.

(In reply to comment #9)
> Can I make a suggestion? Perhaps what we need is a "Remember these values" (or
> equivalent) button when configuring invoice options.

The closest we have to this is the custom reports feature in the reports menu. You can open a report and modify it to your likings. Be sure to change the name as well. Then you can save the report using the "Save Report" feature (fourth button from the right on the toolbar).

For future invoices, you would select Reports->Custom reports, double click your saved report and start from there instead of the standard tax invoice.

Not a perfect solution, but a fair workaround.

Okay, so I've finally had a chance to go through all of the comments. Thank you all for looking into this. Before I go into my responses, please understand that what I'm saying here is in the spirit of this statement, from the GnuCash wiki:

"What this thing needs is some normal human beings using it and saying "you know what, it's NOT acceptable that window A obscures window B and freezes while window B is waiting for input from me." It needs, I am sorry to say, Quicken or MS Money users, who say "It was really easy to do X, Y, and Z, but here, I can't even figure out if it's possible."

Geert:
1. GnuCash is a fantastic product, and there is a very real demand for GnuCash to be used in Australia and other countries with similar laws (eg, NZ). I can see that invoice generation has been curse of GnuCash since the very beginning. Yes, I can tell it's been rewritten, and I applaud the contributors for this. However, we have to achieve a balance between perceived stability and getting minor enhancements (like this) out to the public, especially for something like a book-keeping/accounting package, which is obligated to comply with government regulations etc. 

If we don't get the balance right, like so many other projects in the past, GnuCash will inevitably get forked, and the original will eventually become... irrelevant. I don't believe that going 8 months without an update is "getting the balance right". I also think that, unless a version 2.5 or a 3 is imminent, minor, backward compatible enhancements should make it into the production branch for 2.4. Whilst there's nothing "wrong" with the current tax invoice template, there's the argument that there probably isn't much "right" about it either.

2. The patch was uploaded with the original bug report. Here's a link. http://bugzilla-attachments.gnome.org/attachment.cgi?id=238559 . I uploaded the full files for the benefit of people who were using 2.4.11 and just want a working, bug-free invoice template for Australia. Putting it here meant I didn't have to host it myself.

3. Perhaps you're right, maybe the defaults should have everything selected. It's quite trivial to fix this.

4. I just tried out the custom reports feature, and yeah, that does seem like a reasonable workaround, thanks for pointing this out.

Mike:
1. Yep, I'm not surprised that it doesn't work on the latest dev branch version.

2. I can't seem to reproduce any misalignment or wrapping bugs. I've tried over a dozen combinations and they all appear fine. I'll attach a bunch of variations in a zip file so you can see what I mean.

Created attachment 238784 [details]
A range of sample invoices with proposed taxinvoice.scm template, no wrapping/alignment bugs found.

(In reply to comment #8)
> (In reply to comment #5)
> > Please accept this patch to provide a working AU Tax Invoice without having to
> > change several defaults. The result from Bug 67008 still requires work to
> > produce a legally valid invoice for Australia, and we do need this to "work out
> > of the box" for ordinary Australian users.
> 
> Would you want me to apply a patch that makes GnuCash "work out of the box" for
> Australian users, but then require the rest of the world to change several
> defaults each time ?
> 
> I think we need a broader solution that suits everyone.
> 
> See also my previous comment for other reasons this wasn't added in the 2.4
> branch.

On a previous bug report I submitted the concept (and scm) for an *additional* invoice "Tax Invoice AU". I have not asked for others to have to change, but if we have an additional Invoice specifically for AU we can all be satisfied.

(In reply to comment #13)
> (In reply to comment #8)
> > (In reply to comment #5)
> > > Please accept this patch to provide a working AU Tax Invoice without having to
> > > change several defaults. The result from Bug 67008 still requires work to
> > > produce a legally valid invoice for Australia, and we do need this to "work out
> > > of the box" for ordinary Australian users.
> > 
> > Would you want me to apply a patch that makes GnuCash "work out of the box" for
> > Australian users, but then require the rest of the world to change several
> > defaults each time ?
> > 
> > I think we need a broader solution that suits everyone.
> > 
> > See also my previous comment for other reasons this wasn't added in the 2.4
> > branch.
> 
> On a previous bug report I submitted the concept (and scm) for an *additional*
> invoice "Tax Invoice AU". I have not asked for others to have to change, but if
> we have an additional Invoice specifically for AU we can all be satisfied.

That is one approach, but that might open the flood gates for every user from every country to have their own "Tax Invoice", so I agree with the developers that perhaps that's not the right approach either.

If the existing tax invoice report could be configured via the GUI to generate a valid tax invoice for Australia (and assuming it isn't completely hideous either), I think that's a reasonable middle ground. And I think that was the intention all along, but unfortunately it misses the mark, and the only way to generate a valid tax invoice for use in Australia is to manually modify scm files. 

The requirements aren't unreasonable either. Other than the normal items you'd expect to find on an invoice, it's gotta say "Tax Invoice", must state the company name and ABN (ie, the ID) of the company, and it must specify the GST amount included in the total (even if its zero, and in this case it must provide an explanation, eg, not registered for GST, or exempt, etc), must use the label "GST" and not "Tax".

If we can't update the 2.4 branch with this fix, then what if we develop an add-on package (perhaps called "Tax Invoice enhancement add-on for 2.4.11") and update the FAQ with more detail on how to  use this add-on to generate Tax Invoices for Australia. I remember reading in a changelog somewhere that there was a feature implemented to allow the user to configure which report the default "Invoice" and "Print Invoice" used, but I haven't been able to find that feature in the app. If that feature also missed out on being backported, perhaps we could include that in the tax invoice enhancement add-on as well.

And as for saving defaults, using the Custom Reports feature will meet the need imho.

Thoughts?

* On release plans: currently the next major release (2.6) is planned for the end of the year. We're only waiting for two features to complete (or at least be mostly complete) before we start releasing development snapshots for beta testing. So the invoice improvements so far are expected to reach a larger audience by the end of the year (8-9 months from now).

That's still fairly long imo to not have another stable release (2.4.12) in between. There are a number of bugfixes ready waiting to be released. So I expect at least a 2.4.12 release relatively soon (though it's not formally planned yet).

* The invoice issue: alphamega: thank you for summarizing the required changes again. As you say those are reasonable. That is, if you look at this problem in isolation and not consider that the same problem (difficult to add customized features per country) in a wider scope.

A universal solution (ie adding the ability to have country dependent addons) is too intrusive for a 2.4 branch and imo we're also too far in the 2.6 development cycle to add it there still.

I have no problems with adding a solution specific for the Australian tax invoice in short term though. And I'll focus the remainder of my reply on this option.

Ideally the current tax invoice is customizable enough that it can work for every country. That would mean we only need to maintain one invoice. It seems we can do this and we're pretty close. Let's call this invoice the "Generic tax invoice".

With only this invoice, for each country that wants to, we can add another menu entry that calls the same invoice code, but with different presets. This shouldn't be too hard to accomplish. We do similar things in other parts of GnuCash, like in the aging report. There's only one report (aging.scm) but it's used for displaying both the payable aging and receivable aging.

It may even be possible to hide customization options for the country specific invoices that have to be fixed by law anyway (like the "Tax Invoice" vs "Invoice" caption, "GST" vs "Tax" for the Australian tax invoice). I don't know off-hand if this is possible straight away or needs more coding. It may already be part of a longer term solution.

[Sidenote: regarding Tax Invoice vs Invoice and GST vs Tax - I'm not even sure this should be done via options instead of making proper use of the gettext translation system, but that's again something to consider for a long-term solution only]

I think that's all we need to deal with the immediate issue at hand while keeping a clean code base.

* Regarding timing: The work should be done against the trunk branch and only backported to 2.4 when considered stable. Unfortunately I don't expect the backporting to be trivial, as Mike already suggested in comment 7. The manual change required is probably small though (trunk doesn't have a business-utils module anymore, IIRC its functionality has been merged into gnome-utils, should have to look this up).

On the other hand code changes are very local (only the invoice report is affected). So I think we can make a backporting exception to make the improvements available in 2.4.12 on condition it is thoroughly tested (with many different combinations of options).

That's my idea. Can you agree with this plan ?

(Note: I don't have time to implement this myself unfortunately, but perhaps one of you has and is motivated enough to go for it)

Created attachment 238868 [details]
Shows column mis-alignment

(In reply to comment #11)
SNIP
> Mike:
> 1. Yep, I'm not surprised that it doesn't work on the latest dev branch
> version.
> 
> 2. I can't seem to reproduce any misalignment or wrapping bugs. I've tried over
> a dozen combinations and they all appear fine. I'll attach a bunch of
> variations in a zip file so you can see what I mean.
Try creating an invoice that has no taxes applied at all.  I know in Au you have to but I don't charge UK VAT. See comment 24 in bug 670008.

(In reply to comment #14)

> 
> That is one approach, but that might open the flood gates for every user from
> every country to have their own "Tax Invoice", 

Is there any evidence of any other user group wanting a specific invoice? I know there are groups who have asked about taxation features, but I am not aware of any other geographical group wanting a special invoice.


> 
> And as for saving defaults, using the Custom Reports feature will meet the need
> imho.
> 
> Thoughts?

A custom report approach does not help the new user. A person looking for the correct invoice would search the menus to find one.
Automatically setting the default invoice after setting the country in the preferences menu would be the stuff of dreams.

(In reply to comment #17)
> (In reply to comment #14)
> > 
> > And as for saving defaults, using the Custom Reports feature will meet the need
> > imho.
> > 
> > Thoughts?
> 
> A custom report approach does not help the new user. A person looking for the
> correct invoice would search the menus to find one.
> Automatically setting the default invoice after setting the country in the
> preferences menu would be the stuff of dreams.

That's exactly what I envision as the long term proper solution.

Comment on attachment 238559 [details] [review]
A patch that can be applied to the taxinvoice.scm / taxinvoice.eguile.scm / taxinvoice.css files (as found in gnucash 2.4.11)

This patch has been sitting in my face for long enough now. I have gone over the changes myself and picked the Australian specific preset options to generate a second report called "Australian Tax Invoice", which actually uses the same code as the normal "Tax Invoice" but with differently set preferences.

This should take care of the immediate needs of our Australian friends. The longer term solution of picking good defaults based on a country (or jurisdiction) preference is much more work and will not happen any time soon I'm afraid. I have added a new enhancement request to remind us of this potential improvement (bug 737489).

There is a bug introduced in commit 7015cf9edf312069aaab0028a1d9ac217cb8b43f that prevents this report from working completely correctly unfortunately. That issue is however tracked in a separate bug.

With that I believe this bug is completely handled. I will close it now.

Oh, if other aspects of the invoice need fixing specifically for the Australian market, please feel free to open new bug requests for that.

Reassign version to 2.4.x so that individual 2.4 versions can be retired.

GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=695610. Please update any external references or bookmarks.