[gnucash-de] WIP-Projekt: Modul "Hausverwaltung"

[Christoph Franzen]

Hallo,

Am Sat, 2 Jul 2022 04:04:36 +0200 schrieb "Frank H. Ellenberger"
<frank.h.ellenberger at gmail.com>:
> Am 01.07.22 um 23:43 schrieb Christoph Franzen:
> > Wenn man jetzt hingeht und Programmfunktionen zur automatischen
> > Aufteilung von irgendwas macht (oder ähnliches), wäre meine Idee
> > dabei, die Konten im Prinzip frei konfigurierbar zu machen, anstatt
> > entweder unflexible „Spezialkonten“ zu erstellen oder die
> > Funktionen fest an die „passendsten“ Konten des aktuellen Stands zu
> > hängen.  
> 
> Naja, die Datev sieht in ihre SKRs in Klasse 9
> "Statistische Konten" vor:

richtig, da sind wir gleich an einem Beispiel, was mich zu einem Exkurs
animiert: GENAU SOLCHE Dinge können nach wie vor in Gnucash nicht
vollkommen korrekt abgebildet werden.

Wegen der traditionell-angelsächsichen Drei-/Fünfteilung
„Assets - Liabilities = Equity + (Income - Expenses)“
mit der Nebenbedingung, daß „Equity“ nichts anderes unter sich haben
kann, lassen sich die hiesigen Kontenrahmen vom „venezianischen“ Typ
schlichtweg nicht richtig umsetzen, sondern nur „praktisch brauchbar“ —
weil man die Konten-Typen in der Praxis einfach mal ignoriert und nicht
beispielweise Berichte davon abhängig macht.

> Verkaufsfläche {m²] Anzahl Verkaufspersonal …
> Die braucht man zwar nicht für Bilanz und GuV nach HGB, aber im BWA,
> welcher der Finanzierung (Kredite & Subventionen) dient. Ich sehe da
> gewisse Analogien zu den Umlageschlüsseln Grundfläche, Köpfe.
> Also Wertpapiere m² und Köpfe oder Personen definieren und jeder
> Einheit ein entsprechendes Konto zuweisen mit einem gemeinsamen
> Gegenkonto "Gesamte Anlage". In den Berichten werden dann jeweils die
> Salden abgefragt. Das hilft auch beim Vorher-Nachher-Vergleich:
> 'Heizmenge gefallen, aber Wasserverbrauch gestiegen' ist plausibel bei
> einem Zugang an Köpfen.

Diese Beispiele kann man um das ergänzen, was ALLE hiesigen
Kontenrahmen haben: Konten für Nettowerte und Umsatzsteuer und dazu ein
„Partnerkonto“ für die Leute, welche das mangels Vorsteuerabzugs nicht
„aufzudröseln“ brauchen.

Darum, daß solche Konten in den Kontenrahmen vorhanden sind, die nach
einer programmatischen, automatischen Behandlung „schreien“, ging es mir
indes gar nicht, vielmehr darum, hier nicht den Fehler zu machen, in
einer zu entwickelnden Gnucash-Erweiterung sowas „hart zu verdrahten“.

Beispiel für „falsch“:
1) Kontenrahmen suchen, der für MEG paßt.
2) „Eindampfen“ auf Kontenplan, der für die Praxis reicht.
3) „Hartcodieren“ der „Komfortfunktionen“ für GENAU DEN Plan.

Vorteil: geht schnell & einfach

Probleme:
A) Paßt für den Autoren, die Nachbar-Gemeinschaft womöglich schon nicht
mehr.
B) Schon klitzekleine Kontenrahmenänderungen wegen Gesetzes-Neu-Kram
machen es kaputt.

Beispiel für „richtig“:
Wie vielfach bei Berichten möglich, die Konten frei wählbar machen,
konfigurierbare Tabellen hinterlegen, möglichst nichts „hart“ im
Programmcode vorgeben, auch keine hinderlichen Vorgaben für Anzahlen
machen („ICH hab' nur EINEN Mieter!“), Häkchen „Unterkonten
einbeziehen“ ermöglichen,…

Die Listen sind nicht vollständig, sondern Beispiele.

> > Zum Thema „Integration in Gnucash“: im IRC-Chat treibt sich
> > „CDB-Man“ herum, der ist Ami UND Buchhalter und kann den anderen
> > Amis sehr gut auf englisch „unsere“ Buchhaltungsbesonderheiten
> > erklären (deutsch kann er aber nicht).
> > https://wiki.gnucash.org/wiki/IRC  
> 
> Soweit ich es überblicke, lebt von den Aktiven lediglich John in den
> USA. CDB-Man ist m.W. Kanadier und der Schwerpunkt scheint sich
> derzeit nach Ozeanien zu verschieben.
> Aber das Englische ist dominierend und während alle
> Kontinental-Europäer die venezianische Terminologie übernommen haben,
> haben die Angelsachsen da was geschludert, ihr eigenes Ding gemacht
> und in jedem Land eigene GAAP entwickelt.
> Um dann die schlimmsten Mißverständnisse zu vermeiden, wird seit
> Jahrzehnten an IAS/IFRS gebastelt.

Dahningehend war ich wohl zu vorschnell und habe hier gleich mal
„angelsächsische Tradition“ mit „Ami“ gleichgesetzt, wollte nur darauf
hinaus, daß es mir mal nicht gelungen war, mit John verständigungsmäßig
„auf einen grünen Zweig“ zu kommen, weil der die weiter oben
beschriebene Aufteilung für DAS „weltweite Naturgesetz der Buchhaltung”
gehalten hat. CDB-Man konnte das binnen Minuten verständlich erklären:
natürlich kann man alles so abbilden, aber es geht eben auch ein wenig
anders, so daß man nicht einfach nur alles 1:1 umbenennen kann.

Es lohnt sich vielleicht, sich mit dem mal dranzusetzen, Gnucash
„europakompatibel“ zu machen.

Viele Grüße, Christoph
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 819 bytes
Beschreibung: Digitale Signatur von OpenPGP
URL         : <http://lists.gnucash.org/pipermail/gnucash-de/attachments/20220703/c62b7966/attachment.sig>