[GNC-dev] Make of 3.3-181

[John Ralls]

> On Dec 24, 2018, at 3:23 PM, Frank H. Ellenberger <frank.h.ellenberger at gmail.com> wrote:
> 
> 
> 
> Am 24.12.18 um 22:10 schrieb John Ralls:
>> 
>> 
>>> On Dec 24, 2018, at 9:44 AM, Frank H. Ellenberger <frank.h.ellenberger at gmail.com> wrote:
>>> 
>>> 
>>> 
>>> Am 24.12.18 um 18:30 schrieb John Ralls:
>>>> Agreed in principle, but in this case ISTM it would make more sense to just remove them.
>>> 
>>> Then all books based on SKR04 will crash. That was the reason, it became
>>> default.
>> 
>> Well, we have another long-standing action item to separate the account templates from the current locale selection. We'd need to bring txfde_DE.scm along with that.
> 
> Right, and like the account templates all locales should be build.
> 
>>>> de_DE.scm hasn’t been substantively maintained since it was first committed in 2005. taxtxf-de_DE.scm was last updated in 2011. The US versions get annual updates. Add to that that few if any users even have access to them because they require that the user build from source in the de_DE locale.
>>> 
>>> The implemented part is for the monthly VAT declaration and the VAT rate
>>> does not change so often.
>> 
>> Since the TXF report is for exporting one's income tax information to US Income Tax software like Turbotax this seems a mis-application.
> 
> Why? The german government prefers from private and requires from
> business users to use its interface ElStEr. Both groups have to file at
> the end of the year the income statement, most business users also the
> VAT statement, special branches also other taxes. Like Taxbird for the
> US there are third party tools for DE. The difference might be the
> monthly predeclaration and payment of VAT. But because this is the most
> annoying part, it was implemented first.

So begin with TXF is for personal tax return software, not for business returns. 

(Taxbird for the US (https://www.taxbird.com/ <https://www.taxbird.com/>) is completely unrelated to the German one (http://www.taxbird.de/ <http://www.taxbird.de/>) and doesn’t have anything to do with TXF import. Software that uses TXF includes Intuit’s TurboTax (https://turbotax.intuit.com/ <https://turbotax.intuit.com/>) and H&R Block’s Tax Software (https://www.hrblock.com/tax-software/ <https://www.hrblock.com/tax-software/>).)

So the German tax extraction module and corresponding report shouldn’t be called “txf”. If the format they export is called ElStEr then that’s what they should be called. They also shouldn’t be in tax/us and locale-specific/us.

For completeness in case someone decides to take on cleaning this up, there are two more puzzle pieces: gnc_ui_account_get_tax_info_string in libgnucash/app-utils/gnc-ui-utils.c and gnucash/gnome/dialog-tax-info.c.

It turns out that everything gets built regardless of locale. de-DE.go, txf-de_DE.go, and the rest are all in my build directory using the C locale. Not that that matters, they’re pure Scheme and guile would build them on the fly if it needed to.

What’s different between Cmake and autotools is that under autotools we used recursive build to ensure that dependencies (in this case libgnucash/tax/us) were built before what depends on them (gnucash/report/locale-specific/us). Cmake doesn’t work that way, it has a single build and needs to be told explicitly about dependencies so that it can correctly order the build. That dependency information is missing from gnucash/report/locale-specific/us/CMakeLists.txt, creating the opportunity for the warning that Steve noticed.

It’s not a real problem, just noise: It’s just byte-compiling, not linking, so there’s no real need for the gnucash/tax/de_DE module at build time and it does get built and installed before the tests run. 

Regards,
John Ralls