[gnucash-de] Beerdigung des SKR3

Andreas Schenk dr.andreas.schenk at gmx.net
Sam Jan 29 13:53:37 EST 2005


Hallo Christian,

Nachtrag inline:

>
> Das ist allerdings nicht die Implementierung in Gnucash. Die Zuordnung
> eines Kontos zur Haben- oder Sollseite ist dort unabhängig vom
> tatsächlichen Saldo. Die Zuordnung, *wo* im momentan vorhandenen
> Bilanz-Bericht ein Konto erscheint, hängt *nur* ab vom Kontentyp des
> jeweiligen obersten top-level Konto, von dem das betrachtete Konto ein
> Unterkonto ist. D.h., um mit dem momentanen Bilanz-Bericht ein brauchbares
> Ergebnis zu bekommen, müssen alle Konten der Aktiva-Seite unterhalb eines
> (oder mehreren) top-level Konten des Type ASSET eingeordnet werden.
> Passiva-Konten müssen unterhalb eines toplevel Kontos des Type LIABILITY
> eingeordnet sein, und Eigenkapital-Konten (also aus meiner Sicht die
> Übertrags-Salden) unterhalb eines Kontos des Types EQUITY.

Leider sehe ich es erst jetzt: Damit ist die ganze Sache mit dem SKR3 
gestorben. Hier zeigt sich nun deutlich, dass Kontenplaene und eine Bilanz 
zueinander inkompatible Ordnungen haben. Wenn man einen Kontenplan nach 
seiner beabsichtigten Ordnung strukturiert, so kann man nicht alle Konten von 
einem Toplevelkonto mit eindeutigen Typ ableiten.

Beipsiel: Kontenklassse 0 im SKR3, d.h. "Anlage und Kapitalkonten". Darunter 
fallen Konten sowohl der Aktiv- als auch der Passivseite, inklusive der 
Kapitalkonten.

Wenn man also die Ordnung des Kontenplanes beibehaelt, so haette man minimal 
folgende Struktur:

Hauptbuch:
   Anlage und Kapitalkonten
      0001 Ingangsetzungs- und Erweiterungsaufwand (ASSET)
      ......
      0595 LV-Rückdeckungsansprüche z.lfr.Verbl. (ASSET)
      0600 Anleihen, nicht konvertibel (LIABILITY)
      ......
      0800 Gezeichnetes Kapitel (EQUITY)
      ......

Anleihen sind hier begebene Anleihen, nicht erworbene. 

Den Toplevelknoten Hauptbuch kann man o.B.d.A. weglassen, seine Anwesenheit 
hat keinen Einfluss auf das Problem. Wir haben hier also gleich drei 
GnuCash-Kontotypen innerhalb einer Kontenklasse.

Damit sieht es sehr boese aus. GnuCash erzwingt die Einordnung der Konten in 
eine Hierarchie, aus der die Bilanz abgeleitet wird. Diese feste Zuordnung 
ist im Ansatz sowieso untauglich, da -- wie vorher angesprochen -- diese 
Zuordnung (dynamisch) vom Vorzeichen der Salden fast aller Konten abhaengt.

Einen Kontenplan koennen wir nun auch nicht nach seiner Ordnung strukturieren, 
da dies ebenfalls mit der durch GnuCash geforderten Struktur unvertraeglich 
ist.

Es macht auch keinen Sinn, den Knoten "Anlage- und Kapitalkonten" (und ggf. 
weitere) wegzulassen. Man wuerde dadurch die Kontenklassenstruktur des SKR3 
ausblenden. Das Ergebnis waere sehr unuebersichtlich (und in meinen Augen 
unpraktikabel).

Was nun? Jetzt habe ich keine Idee mehr, mit den Rahmenbedingungen von GnuCash 
vernuenftig umzugehen. Damit kommen wir zurueck zu Deinem Ziel, Christian: 
den "onlinefähigen privaten Finanzmanager". Alles andere scheint ein 
groesseres Redesign zu erfordern. (Schade.)

Falls doch noch jemand eine Idee hat...... oder einen Vorschlag fuer das 
weitere Vorgehen......

Viele Gruesse

Andreas Schenk