Want to contribute modified US "Tax Report & TXF Export" report - questions

[Christian Stimming]

Dear Alex,

thanks a lot for your exhaustive work on the taxtxf report issues. That's a 
big improvement and I'll try to give you enough hints below to prepare an 
actual patch, which we'll gladly submit into SVN.

> In doing this, I discovered some minor limitations/errors in the existing
> report which the revised report corrects:

That's good. In fact, the existing taxtxf.scm has been sitting around almost 
unchanged since the file was first committed in r5144, August 2001 (uh oh), 
apart from some minor bugfixes. Hence, there might still be plenty of bugs or 
conceptional flaws in there. I'm glad if you were able to hunt down many of 
them while still keep the old funtionality working - it might have been very 
well possible that you concluded to throw away the old structure completely.

> 1. The existing report does not handle more than one account being
> assigned to some of the tax codes. 

Surely a bug. Thanks for fixing this.

> 2. The existing report double-counts amounts in a case where
> transactions are posted to detail and summary level accounts in the
> hierarchy and both are referenced to tax codes

Surely a bug. Thanks for fixing this.

> 3. The existing report does not handle accounts in more than one
> currency

And again a bug.

> Although I initially only planned to add an option for more detail to
> the existing report and then changed my mind to have a second,
> companion report (that would have the same totals but in a different
> sort and with more detail), it turns out that because of these
> discrepancies the two reports shouldn't/couldn't co-exist in gnucash.
> If they are both in the system and run on the same data, they  can
> come out with inconsistent results. So I've had to go back and add-in
> to my report the TXF exporting logic from the existing report, which I
> have now done. 

Correct. We'll gladly put your version instead of the old one into SVN.

> My questions to the developer are:
>
> 1. The way I handle currencies for each transaction is as follows:
> 	- if the account commodity & tran-currency both = default currency,
> 		use split-amount (no conversion required)
> 	- if the account commodity = default currency but tran-currency doesn't,
> 		use split-amount (conversion = split value @ 1/share price)
> 	- if the tran-currency = default currency but account commodity doesn't,
> 		use split-value (conversion = split amount @ share price)
> 	- if both account commodity & tran-currency do not = default currency,
> 		use pricedb-nearest function to convert split-amnt; report option
> 		specifies date (tran-date or report end-date) to use
> 		(conversion = split amount @ lookup rate)
> Does this logic seem correct? any comments or suggested changes?

Seems correct to me, but others should comment on this as well.

> 2. When in the TXF output mode, the existing report (and mine as well)
> outputs all amounts with a '$' prefix, as required by the TXF
> standard. But it doesn't actually ever check that USD is the default
> or report currency. Should a check for this be added before executing
> the export code, or, is it safe to assume that, since this is a
> locale-specific report, it always will be a USD default? It seems that
> if a user installed a US locale (and therefore had access to the
> report) but selected a non-USD default currency in gnucash preferences
> (say, someone living in Europe but having to prepare US tax returns),
> the report would display in the non-USD currency and then blindly
> output the non-USD amounts in the TXF file with a '$' inserted in
> front. Should I add a check for this (easy to do)?

A check with some user feedback would be good, yes. However, I have no idea 
what the output should do if either the default or the report currency are, 
say, EUR. Should it refuse to work unless the report currency is USD? Or 
should it only give a warning along the lines of "The numbers will be in EUR, 
but they will be prepended by a $"? I don't know.

> 3. Since I don't personally use any tax preparation software and don't
> have access to any, the only testing I can do is to compare the output
> files between the two reports and make sure they are the same (except,
> obviously, for the intentional differences). Is this
> sufficient/acceptable? 

Sounds sufficient to me.

> 4. In my development and testing, I simply added my new
> taxschedule.scm file (which was a renamed and modified copy of
> taxtxf.scm) to the same directory where taxtxf.scm was
> (/usr/share/gnucash/guile-modules/gnucash/report on my Fedora system)
> and added a line ('(use-modules (gnucash report taxschedule))') to the
> standard-reports.scm file, (...) Since these reports are
> locale-specific I suspect that they are handled differently but I'm
> confused about how it's supposed to work for them. How does taxtxf.scm
> get on the menu and known to the system? 

It's put into the menu in the C code in the shared library module made of 
src/report/locale-specific/us/gncmod-locale-reports-us.c 

> Presumably, my report should 
> work just like it? It should show up in US locales but not in non-US
> locales?

Yes, it should work just like it. No, it shows up not only in US locales but 
in any locale except for the de_DE locale, which has its own report (which is 
even more unfinished and broken, but that's another issue).

> 5. If these changes are made for the US tax report, are there
> implications for work needing to be done for the German tax report? Or
> is that completely separate (my assumption)?

The same work should be done for the taxtxf-de_DE.scm file. However, as I 
already said, the de_DE version is unfinished and broken anyway. I submitted 
it in 2004 as a proof-of-concept for the de_DE tax reporting, together with 
the call for (German) testers who would actually need the feature, so that 
they supposedly would tell me which changes are still necessary. This never 
really happened, although apparently some Germans seem to be using this 
report (but I have no idea what they are doing with the output). I think the 
diff of "taxtxf.scm old" -> "taxtxf.scm new" should be applied to 
taxtxf-de_DE.scm, i.e. all of your changes should go into the de_DE form as 
well, if possible.

> 6. After doing the development and testing on my rpm-based system, I
> set up a development directory and checked out gnucash/trunk from svn
> and built it in /opt. This built-from-svn system works fine and I can
> add my report there just like I did for the copy in /usr/share/... but
> how & where do I put my report in the source tree and get a re-build
> to generate a gnucash that includes the new report in place of the old
> one? 

If you replace taxtxf.scm with your new version, just copy your new version 
into src/report/locale-specific/us and that's it.

If you add a new taxtxf2.scm (or whatever name), do the following:
- Copy it into the locale-specific/us directory
- Add code to gncmod-locale-reports-us.c so that it is loaded by 
scm_c_eval_string("(use-modules (gnucash report taxtxf2)")
- Add it in src/report/locale-specific/us/Makefile.am into the line defining 
the variable gncscmothermod_DATA. This will have it installed upon "make 
install" and also put into the tarball upon "make dist"

> And then how do I generate a diff file to send to you guys?  

Run 

  svn diff

and send the output as attachment here to gnucash-devel. (gzip is necessary 
only if the diff is larger than 100KB)

> How do I make those changes in my copy of the svn check out
> sources, rebuild from source to test gnucash, test the build to make
> sure nothing I do breaks it, then generate my patch to submit? 

If you really want to test "everything" (and have a lot of CPU cycles to 
spare), modify your development tree as explained above, run "make" and "make 
install" to see whether it works as expected, and then run "make distcheck" 
to see whether your files will be included in the tarball correctly. We don't 
require any more testing than this.

> but I'd like to know the answers to these questions anyway since I
> plan to do more work and submit other patches in the future.

That's great to hear! (And just a side note: If your patches look good and are 
helpful, we consider granting direct SVN access quite quickly these days.)
We are looking forward to receiving your patches. Way to go!

Christian