GNOME Bugzilla – Bug 513000
Patch for german SKR04: introduce some A/R and reduce A/P
Last modified: 2018-06-29 22:00:26 UTC
As in Bug 512985 for SKR03 here are some changes to SKR04, which improve the type of some "Forderungen..." accounts from ASSET to RECEIVABLE. This would allow the users to book invoices. When reviewing the template, I saw also, there are too much accounts of type PAYABLE, which I will fix in a later patch. BTW, should this and 512985 be marked for BP?
Created attachment 104005 [details] [review] accounts/de_DE/acctchrt_skr04.gnucash-xea.diff
Please provide one complete patch with RECEIVABLE and PAYABLE changes then, please :-) WRT BP: I guess r16775, r16913 and the upcoming commit can be backported at once and the skr account templates will be equivalent afterwards, except the encoding change in skr03.
Created attachment 109870 [details] [review] accounts/de_DE/acctchrt_skr04.downgrade_most_A_P.diff Sorry for the delay, but after 1 month of absence I fell ill. In my eyes this "downgrading of most A/P to liability accounts" task is an independend of the previous "enable some A/R accounts"; so I made a separate patch. You should apply both. Now I will not tell you, what I plan next. Otherwise my changes would never be applied. ;-)
(In reply to comment #1) > Created an attachment (id=104005) [edit] > accounts/de_DE/acctchrt_skr04.gnucash-xea.diff Thanks. Committed as 17242. (In reply to comment #3) > Created an attachment (id=109870) [edit] > accounts/de_DE/acctchrt_skr04.downgrade_most_A_P.diff I am not sure all those changes are correct, but I am too lazy to think much about it now. Just one example, Umsatzsteuer is not Fremdkapital. If anything, it is a deferred payable. What real difference does it make?
I assume, as cstim is no frequent user of the business module, there are some not so well fitting translations. You can find my understanding in http://wiki.gnucash.org/wiki/De/Referenz#Offene-Posten-Verwaltung and around. So your example could be read as "should ...MWSt. be selectable as account in process invoice?"
Frank, es tut mir leid, ich verstehe Dich oft einfach nicht. Und ich habe auch nicht die Zeit, seitenweise unspezifisch Texte zu lesen. Geht es hier um bug 432143? Es ist wenig hilfreich alle Probleme mit allen anderen bugs zu vermischen. "one issue, one report". Warum heißt der Patch eigentlich "downgrade"? In den Account-Typen ist doch keine Hierarchie. I am trying to understand what Frank is trying to achieve and how it relates to this other bug reports.
OK, I think I have understood what Frank is trying to say now and I am quite confident that attachment 109870 [details] [review] is there to address bug 432143. It should have been attached there which would have saved me quite some time trying to understand things. Closing this bug as fixed. Let's continue in bug 432143.
Well, to tell you the truth, I am not so sure anymore. I am pulling my hair out trying to understand what it is that you are trying to do. I think it complicates things too much to communicate about these problems specific to German accounting in English, too much information is lost and the possibility for misunderstandings too great. Let's discuss this stuff in German. Frank, Du möchtest die geänderten Konten gerade *nicht* mehr im Business-Modul "Rechnung" aufscheinen lassen, da es sich bei den Konten Deiner Meinung nach um keine typischen Konten für Forderungen aus L+L handelt? Das würde zumindest Sinn machen, aber auch da bin ich mir nicht sicher, ob Du die Umsatzsteuerkonten korrekt behandelst. Allein aus der Beschreibung der jeweiligen Konten läßt sich das noch nicht schließen. Für eine tiefergehende Analyse fehlt mir im Moment sowohl Zeit als auch Interesse/Motivation. Wenn mein jetziges Verständnis richtig ist ist das ohnehin ein rein kosmetisches Problem, was bei attachment 104005 [details] [review] nicht der Fall war. Wo werden die Passivkonten für Payable und Liabilities real unterschiedlich behandelt? Im Businessmodul für Rechnungnen und wo sonst noch?
For the discussion in german, we can use the german mailing list. There are also some guys hanging around with some better/fresher theoretical background. According Comment 2 there was the wish to have this changes together. Patch 109870 is not cosmetic, it is a) a question of usability - having over 100 _wrong_ entries in a drop down list. b) a question of theory - I wish to have this accounting system clean, to avoid further errors - may be by users or us. The accounts, which can be used for VAT, are declared in Business->"Tax Table Editor", and do not have anything special in the hierarchy. Depending on your tax declaration by cash flow (EUeR) or P&L, you should declare different accounts. A/R and A/P appear in the invoices and related customer-, vendor-, employee(?) and aging reports - did you never test them?
(In reply to comment #3) > Created an attachment (id=109870) [edit] > accounts/de_DE/acctchrt_skr04.downgrade_most_A_P.diff > > Sorry for the delay, but after 1 month of absence I fell ill. > In my eyes this "downgrading of most A/P to liability accounts" task is an > independend of the previous "enable some A/R accounts"; so I made a separate > patch. You should apply both. Is this patch still waiting to be applied? Could Rolf also do this, and if yes, why didn't he apply this? If this should go in, I could do that soon.
(In reply to comment #10) > Is this patch still waiting to be applied? Could Rolf also do this, and if yes, > why didn't he apply this? If this should go in, I could do that soon. From my POV, this patch is absolutely not waiting to be applied. I did not apply it on purpose because it actually breaks the SKR by replacing correct values with something broken. I already closed this bug report once as fixed to see it reopened by Frank and I don't mean to get into some kind of fight about this. Frank wants to apply the patch not because this patch corrects some incorrect information in the SKR but because he desperately wants to circumvent the strange problems created by the business module logic in gnucash. I have long given up on the business logic in gnucash. It is too much worked around one person's concept of how the world should spin.
Umm.. Not sure what "strange problems" are "create by the business module logic" here. Could you refer to a bug#? The business logic requires accounts of A/Receivable and A/Payable. I don't see anything wrong with that. I'm also quite sure you're referring me to as the "one person" who's "concept of how the world should spin" requires some workaround. No need to be so circumspect, but whatever.
> From my POV, this patch is absolutely not waiting to be applied. Ok.
(In reply to comment #12) > Umm.. Not sure what "strange problems" are "create by the business module > logic" here. Could you refer to a bug#? I'll give you 2 which I think are closely related to this request. bug 432143 bug 542606 I think there are others. For example, I believe Frank has some problems in efficiently choosing an acount when preparing an invoice. But he'd be more qualified than me to comment on this.
Please, back to the roots: Did anybody of you ever had a look in such an account in GnuCash. Then (s)he could me probably explain, why all transactions should have the following additionally unused fields: T: (-/invoiced/paid) Due Date Ref Vendor/Payee In my eyes this fields are only necessary in one or a few A/P and A/R accounts (de: "Offene Posten") dedicated for invoicing and absolutely superfluous in all other liability accounts. At least I do not know of any other impact of this account types. All the trouble was caused by some not so lucky german translations. So Bettina had choosen the wrong account types and in my first approach, I followed her. It would be really frustrating, if it would not be allowed, to correct them. Re #6: That is, what I tried to show for german users in the small table http://wiki.gnucash.org/wiki/De/Referenz#Einordnung_der_in_GnuCash_definierten_Kontentypen Re #4: Auch abzuführende Umsatzsteuer ist kurzfristiges fremdes Kapital.
For the record, users should never be hand-entering transactions into accounts of type A/Payable or A/Receivable. Those accounts are *ONLY* for use with the Business features, and transactions should only be entered through the Invoicing/Payment-Processing interfaces.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=513000. Please update any external references or bookmarks.