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

[J. Alex Aycinena]

Hello,

I've modified a report and it got more complicated than I thought. I'm
almost finished but I don't know the last steps to submit a patch for
the developers to consider.

I've taken the existing US "Tax Report & TXF Export" report and
modified it. I initially simply wanted to add the option to show
transaction detail to support the account-level amounts that were
being reported in the existing report but in looking at it in more
detail, decided that a more useful report for me personally (and as it
turned out, actually necessary to get the correct results) would be
sorted (from major to minor) by tax schedule/form, tax code, account
and finally transaction. This is in contrast to the account hierarchy
sort of the existing report. In doing this, I discovered some minor
limitations/errors in the existing report which the revised report
corrects:

1. The existing report does not handle more than one account being
assigned to some of the tax codes. This is because the exported file
can only have those codes included once and since the report is in
account hierarchy sequence, it can't add the amounts in more than one
account (since they may not be next to each other in the hiearchy).
But there is nothing in the GUI that enforces this (and in fact it
would be an unfortunate restraint if there were) so instead, the
report prints a warning if this is encountered. Since the revised
report sorts accounts within tax code, I've modified the export logic
so that this is not a limitation with the new report.

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 or even if transactions
are only posted to the child account but both the child and parent are
'postable' and coded as tax-related. While this may not be a common
occurrence, there is nothing in the system to prevent it and, with no
detail to support the report or the export, the double-counting could
be undetected and easily overlooked, potentially providing erroneous
data to a tax preparation package. The revised report doesn't do this.

3. The existing report does not handle accounts in more than one
currency - if an account with a non-default (non-USD) currency is
referenced to a tax code, it simply takes the account amount and
includes it in the report unconverted and exports it with no comment
or warning (essentially 'adding apples and oranges'). Actually, it
does worse, putting the amount in the export file with a mangled
currency code: for example, '$-UR 10.00' for a deductible EUR 10.00
expense.The revised report converts all non-default currencies at the
transaction level and then adds the converted amounts in totalling and
exporting, with the report serving as an audit trail showing what was
done.

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. This way, if everyone agrees, the new report can
replace the existing one, addressing problems 1 thru 3 above, without
taking away any functionality. With the exception of these three
items, the two reports generate the same TXF files, at least with my
test data.

Also, I checked bugzilla for items related to taxes and txf so I could
take them into account but found none (other than those related to
taxes and invoicing).

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?

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)?

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? If not, any recommendations as to how to test
further. Does someone else out there have access to tax preparation
software that can help me test the new report's output in the next
week or so?

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, right after where all the other reports
were listed, in the same directory. This put the new report in the
gnucash report menu and made it functional. But I see that taxtxf.scm
is not one of the reports listed in standard-reports.scm. Also, many
of the other reports seem to use the "'menu-path" parameter in their
"gnc:define-report" expression to specify where in the menu they
should be shown and report.scm seems to build this. But taxtxf.scm has
this commented out (and so does my report). 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? Presumably, my report should
work just like it? It should show up in US locales but not in non-US
locales?

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)?

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? And then how do I generate a diff file to send to you guys? And
based on question 4, above, what other files do I need to modify
before creating the diff? (For example, since taxtxf.scm is not in
standard-reports.scm I suspect my report shouldn't be either - so that
file shouldn't be in a diff - but some other file should be? - which
one?) 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? I guess
the simplest thing in this case is simply to name my file exactly the
same as the existing report and change nothing else and everything
should work (the diff would be limited to inside the one report file),
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.

Feedback on these items would be welcome. I am eager to submit the patch.

Thanks,

Alex