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

[J. Alex Aycinena]

Christian,

Thanks for your feedback. My comments, below:

On Sun, Jun 29, 2008 at 11:41 AM, Christian Stimming <stimming at tuhh.de> wrote:
> Dear Alex,
>
>
>> 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.
>

What I will do for this, then. is add logic to check what the default
currency is and use the conversion logic to convert everything to USD,
if necessary. The heading will say 'All amounts in USD' and the report
will show how all amounts were converted. Then the export won't be a
problem. I'll have to set up a non-USD file to test.

>> 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.
>

When I've made all other changes, I will ask on the user list if
anyone wants to volunteer to help me test the export. If I get no
takers, I'll just submit the report with my testing.

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

I'll look at that to understand how it works but if I don't change the
name of the report, I guess no changes to it will be required.

>> 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.
>

While I kept big chunks of the original code, the main structure is
quite different so I'm sceptical about what that diff would look like.
I'll leave it for you or others to determine what to do with the de
version.

>> 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.
>

This is the easy way and what I'll do.

> 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"
>

Thanks for the information.

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

If I keep the same name, should I just attach the whole new taxtxf.scm
file or do the diff between the new and old and attach the diff?

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

I'll make my final changes, clean up the code and do my final testing
in the next several days. Then I'll ask on the user list about export
testing and submit it based on the response there.

Thanks,

Alex