[gnucash-de] Beerdigung des SKR3

Andreas Fromm Andreas.Fromm at physik.uni-erlangen.de
Mit Feb 2 03:22:09 EST 2005


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Andreas Schenk wrote:
| Hallo Jens,
|
| Am Dienstag, 1. Februar 2005 11:59 schrieb Jens Falk:
|
|>Hallo,
|>
|>
|>>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.)
|>
|>nach über einer Woche intensiver Arbeit mit GnuCash und den Versuch eine
|>Anpassung an ein kleines Unternehmen vorzunehmen, muß ich dem leider
|>zustimmen. Einige noch gar nicht auf der Liste erwähnte Probleme (ich habe
|>zumindest nichts gefunden) ist eine eventuelle Betriebsprüfung ,
|>Betriebsprüfer-Export (gemäß § 147 AO) und der Steuerberatungsexport
|>(DATEV).
|>
|
|
| Diese Punkte sind mir nicht fremd. Ich kann jedenfalls bei dem aktuellen
| Zustand der Anwendung niemandem anraten, GnuCash zur professionellen
| Betriebsbuchhaltung zu verwenden. (Evtl. sollte ich sogar soweit gehen
und
| davon abraten?) Vielleicht wird sich die Anwendung niemals bis zu diesem
| Punkt entwickeln. Bei meiner Beschäftigung mit dem SKR3 wollte ich nur
einmal
| austesten, wie weit man mit GnuCash kommt. Ich denke, daß eine ganze
Reihe
| von Grenzen aufgezeigt worden ist. Das ist immerhin der erste Schritt für
| eine Weiterentwicklung. Die "Defizite" erklären sich (wie diskutiert)
aus der
| Entwicklungsgeschichte von GnuCash und meine Aussage soll kein
abwertendes
| Urteil sein -- vielmehr ein Ansporn.

Ich denke auch dass der erste schritt für eine Weiterentwicklung schon
mal getan ist, indem die anforderungen formuliert werden. Jedoch sollten
dann aber auch die Antowrten der Entwickler berücksichtigt werden.
Christian hat ja geschildert was nötig wäre um einen SKR3 Kontenplan
aufsetzten zu können. Die paar Stunden Arbeit sollten es nicht sein an
denen das Projekt scheitert. Wenn jemand interesse daran hat, sollte er
sich überlegen ob er sich ein komerzielles programm kaufen will, oder ob
er nicht das Geld jemandem zukommen lässt der die nötigen Funktionalität
in GnuCash implementiert. Ich denke es ist ein allgemeines
missverständnis zu meinem Open Source software muss immer Kostenlos
sein. Wenn man etwas braucht, kann man immer jemand dafür bezahlen der
das macht, und das Ergebniss immer noch als Open Source freigeben, wovon
dann alle wiederum profitieren.

|
| Der Schritt in Richtung professionelle Buchhaltungssoftware hat ein paar
| gewichtige Hürden:
|
| Es gibt neben den GoB (Grundsätze ordnungsgemäßer Buchführung) auch
noch die
| GoSB (Grundsätze ordnungsgemäßer Speicherbuchführung), die bei der
| Buchführung zu beachten sind. Ich kenne diese Grundsätze nicht, würde
aber
| erwarten, daß sie z.B. auch die nachträgliche Änderung von Belegen
verbieten.
| Bei GnuCash kann ich mit jedem Texteditor die Datei fälschen,
unabhängig von
| den Flags, die ein Ändern aus der Anwendung heraus verbieten --
| wahrscheinlich ein absoluter Killer.

Es gibt keine Wirklich lösung für dieses Problem auf Computerebene,
solange man an eienm Rechner sitzt an dem man root-Rechte hat. Man
könnte natürlich jede Buchung, oder auch die gesamte datei über einen
Hash-Key vor veränderung schützen, aber solange man nicht sicherstellen
kann, dass dieser Key nicht modifiziert wird, hilft das nicht viel. Das
geht eben nur, indem das programm an irgend einer unbekannten stelle den
key abspeichert, aber solange man als root alles auf dem Rechner machen
kann, kann man das nicht wirklich schützen. Eine colsed source -lösung,
bei der man einfach nicht weiß wo die Schlüssel hinterlegt werden, ist
übrigends auch keine wirklich bessere lösung, da man eigentlich
unerlaubte modifizierungen ebensowenig ausschliessen kann wie erlaubte.
Die einzige lösung die ich kenne, existiert aber nur auf Großrechnern,
ist dass man da benutzer anlegen kann, deren Daten nicht einmal von root
eingesehen werden können. In so einem Fall könnte man einen Benutzer für
GC anlegen, unter dessen Kennung dann die Schlüssel der Transaktionen
abgespeichert werden. Wie gesagt, ist aber so eine Lösung auch nicht
unter anderen gängigen Betriebssysteme möglich.

| Sodann gibt es länderspezifische Besonderheiten. Eine Anwendung, die in
| verschiedenen Ländern im professionellen Einsatz sein soll, muß die
| jeweiligen Anforderungen an die Buchhaltung erfüllen. Um dies für jedes
| "unterstützte" Land zu erreichen, muß die Anwendung wahrscheinlich
| entsprechend Modular aufgebaut werden und umfangreiche Möglichkeiten der
| Konfiguration bieten. Damit könnte man dann länderspezifische Varianten
| anbieten, die sich in der Software nicht unterscheiden.

In der Tat wäre ein solcher Modulares Dessign nötig. Hab aber keine
ahnung in wie weit so was in GC möglich ist. Wie aber Christian zum SKR3
beschrieben hat, ist es wohl pronzipiell möglich verschieden
Kontenverwaltungen zu implementieren.

| Das Risiko der 10 Jahre: Bestimmte Daten müssen 10 Jahre aufbewahrt
werden.
| Bei einem Open-Source Projekt besteht aber immer die Gefahr, daß es
nach ein
| oder zwei Jahren stirbt oder bei der Weiterentwicklung die
| Rückwärtskompatibilität aufgibt. Dadurch könnte es zwangsweise zu einem
| Datenverlust und / oder zu der einen oder anderen Verletzung gesetzlicher
| Vorschriften kommen. Man muß sich also wahrscheinlich mit einem
Hybridmodell
| begnügen: man verwendet eine Open-Source Anwendung für die Buchführung,
| exportiert die Daten aber regelmäßig an einen Profi, z.B. DATEV (wenn
die so
| etwas anbieten), zur Sicherung. Da dadurch ein standardisiertes
| Austauschformat unterstützt wird (werden muß), könnte man mit
möglicherweise
| geringem Aufwand jeder Zeit auf eine andere Anwendung wechseln, und
die Daten
| vom Profi zurück in die neue Anwendung importieren. Ich kann mir im
Moment
| nicht vorstellen, daß man mit GnuCash je über so ein Hybridmodell
| hinauskommen kann -- aber der Weg dahin ist noch weit. Ich denke, daß Du
| diesen Punkt mit dem "Steuerberaterexport" meintest?

Das ist ein Problem was gerade bei Open-Source anwendungen weitaus
geringer ist als bei komerziellen anwendungen, zu mindest wenn das
Dateiformat nicht komplett offengelegt wurde. Bei einem Open Source
progranmm reicht es föllig aus, einfach eine Version des Programms mit
abzuspeichern, und schon kann man immer auf die Daten zugreifen. Sollt
man irgend wann die Plattform wechseln, speichert man den Quellcode des
Programms und damit kann man immer nachvollziehen wie die Daten
eizulesen sind. Bei einem komerziellen anbieter ist genau das nicht
gegeben. Es ist zwar wahrscheinlich, dass wenn es den herstellert noch
gibt, dass er irgend eine import-möglichkeit anbieten wird, aber wenn
der hersteller eben mal konkurs gegangen ist, steht man vor einem viel
größern Problem, es sei denn mann kennt zufällig den Programierer der
den Datenexport damals für den Hersteller geschrieben hat...

| Diese Liste ist sicher nicht vollständig. Mal sehen, wohin die Reise
geht....

Mal sehen, aber denkt daran, dass jeder die Richtung mitbestimmen kann.
Wer selbst nicht programmiert, kann auf jeden Fall jemand damit beauftragen.

| Viele Grüße
|
| Andreas Schenk


- --
Grüße,

Andreas Fromm

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCAI2wUmBtSMq5cGURAgn4AKDKTz3H6v4n7qcWsjEDzeh9YCbLRQCgmCDu
9iZhDQtsUaXR2oJV2AM0Ew8=
=XjJl
-----END PGP SIGNATURE-----