After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 544152 - German tax report does not sum by tax key
German tax report does not sum by tax key
Status: RESOLVED INCOMPLETE
Product: GnuCash
Classification: Other
Component: Reports
git-master
Other Linux
: Normal normal
: ---
Assigned To: gnucash-reports-maint
gnucash-reports-maint
Depends on:
Blocks: 473506
 
 
Reported: 2008-07-22 12:11 UTC by Rolf Leggewie
Modified: 2018-06-29 22:07 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Rolf Leggewie 2008-07-22 12:11:30 UTC
For the german tax report to be really useful it needs to sum accounts by tax code.  The txf implementation for the US apparently does not need that and it even looks like it would be inappropriate there for two accounts to have have the same tax code.

I am really starting to get the feeling that trying to beat the work already done on the tax stuff to fit with what we need in .de is actually more cumbersome and error-prone than starting afresh.
Comment 1 Christian Stimming 2008-09-27 13:06:04 UTC
Just as a note for the archive: I think the whole "German tax report" issue doesn't really fit into the txf.scm report framework. Instead, the newly added python bindings  http://lists.gnucash.org/pipermail/gnucash-devel/2008-July/023431.html should be used to program this task as a new, stand-alone python script that collects all the necessary data for export.

The German taxtxf-de_DE.scm should probably removed sooner or later because the improvements in taxtxf.scm by http://svn.gnucash.org/trac/changeset/17602 haven't been back-ported to the German version and I definitely won't have time for that.
Comment 2 Rolf Leggewie 2008-11-14 21:57:57 UTC
Now that we have the SQL backend that opens a whole slew of new possibilities for reporting.  I am already trying them out.  I think this bug should eventually be wontfixed.  I leave it open for now for two reasons.

1) the SQL backend is not yet stable
2) the nonworking stuff already in trunk should probably be removed

I should probably write somewhere about what I have done with the SQL backend once my work has been stabilized a bit, as well.
Comment 3 Christian Stimming 2008-11-15 21:55:53 UTC
> I think this bug should eventually be wontfixed.

I'm all for this solution. Also, I agree to this:

> 2) the nonworking stuff already in trunk should probably be removed

If this concerns any of the "taxtxf-de_DE" stuff, please give me a clear advice about which pieces don't work and should be removed.

If the "German business features" are indeed not continued any longer inside the gnucash codebase, the following bugs should be closed as WONTFIX: bug#542648 bug#539302 bug#538913. If they are still relevant, we should maybe add a new bug component "German business", because in the component "General" they seem like a bug list pollution to me.
Comment 4 Rolf Leggewie 2008-11-16 09:37:09 UTC
(In reply to comment #3)
> > 2) the nonworking stuff already in trunk should probably be removed
> 
> If this concerns any of the "taxtxf-de_DE" stuff, please give me a clear advice
> about which pieces don't work and should be removed.

Without looking more closely now, I'd say the whole taxtxf-de_DE stuff will not work correctly without some major changes to a lot of parts in gnucash.  This kind of reporting will be much easier to accomplish from SQL.

./src/report/locale-specific/us/taxtxf-de_DE.scm
./src/report/locale-specific/us/de_DE.scm
./src/tax/us/txf-help-de_DE.scm
./src/tax/us/txf-de_DE.scm
./src/tax/us/de_DE.scm

are candidates for closer inspection.  Quite possibly, there are others, but others know their way around the gnucash code better than me.

> If the "German business features" are indeed not continued any longer inside
> the gnucash codebase, the following bugs should be closed as WONTFIX:
> bug#542648 bug#539302 bug#538913.

This bug is about reporting.  By now, it's become quite clear to me that gnucash will not be the right tool here.  Above bugs concern the SKR and data entry.  Data entry will most likely remain inside gnucash (without even that, what would be left for gnucash?).  As far as maintaining the SKR, I am undecided at the moment.  SQL offers more powerful manipulation tools, including ways to alter for example the chart of acounts after it has been created.  But, accessing data read-only for reporting is a completely different animal from actually writing data into the SQL repo.  The devs are quite clear they don't support tools directly accessing the SQL backend.  This is yet too early to call IMHO.
Comment 5 Carsten Rinke 2013-04-24 13:47:59 UTC
To the reporters:

Is this still any issue, or can this bug be closed?
Comment 6 Geert Janssens 2014-09-23 15:51:46 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!
Comment 7 John Ralls 2018-06-29 22:07:52 UTC
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=544152. Please update any external references or bookmarks.