[gnucash-de] GoB und Buchungen nicht mehr veränderbar machen

[Mario Goppold]

Frank Nagel schrieb:
> Manfred Usselmann schrieb:
>   
>> Hi Micha,
>>
>> On Thu, 31 Jan 2008 11:12:30 +0100
>> Micha Lenk <micha at lenk.info> wrote:
>>
>>     
>>> Manfred Usselmann schrieb:
>>>       
>>>> Aber vielleicht waere es ein Ansatz, wenn die ZIP-Verschluesselung
>>>> passtwortgeschuetzt erfolgen wuerde...
>>>>         
>>> Das ist doch bloß Augenwischerei: Gnucash ist Open Source, d.h. das
>>> Passwort wäre dann ja im Quellcode enthalten. Jemand, der unbedingt
>>> eine Buchung ohne Hilfe von Gnucash verändern will, findet das
>>> Passwort also ohne große Probleme.
>>>       
>> Klar, Passwort im Quelltext ist Unfug, das ist mir auch klar. Das
>> muesste man schon anders machen, deswegen sprach ich auch nur von
>> Ansatz. Eine fertige Loesung habe ich auch nicht anzubieten. Evtl. ein
>> Admin-Kennwort bei der Installation abfragen und mit diesem Kennwort
>> kann man dann das Datei-Passwort vorgeben. Vielleicht hat ja jemand
>> noch eine Idee, wie es gehen koennte...
>>     
>
>
> Sorry, aber eine nicht veränderbare Datei gibt es genauso wenig, wie
> eine nur einmal lesbare Datei. Alles kann kopiert/verändert werden!
>
> Einzigste Möglichkeit ein Datei-Inhalt(!) vor Veränderungen zu schützen
> ist die Verwendung von Verschlüsselung, aber mindestens der
> Schlüsselinhaber kann dann wieder manipulieren.
>
> Weiter darf nicht die DB sondern muss zwingend *jeder* Datensatz
> (zusammengehörende Buchung) *einzeln* verschüsselt/gesichert werden, am
> besten mit einem Key den nur das FA kennt. (Ob man das will diskutiere
> ich hier nicht)
>
> Insgesamt ist die Forderung der "Nichtveränderbarkeit von
> Daten/Inhalten" NICHT(!) - im Sinne von Niemals - zu erfüllen.
>
> Die Forderungen des FA in der GoB sind somit eh nur 'Augenscheinlich',
> als im Sinne wenn der Buchhalter die Buchung nicht mehr im Frontend
> ändern kann, zu sehen. Sie Resultieren noch aus der Zeit der
> ausschliesslichen Papierbuchungen, und auch dort konnte bereits niemand
> die Neuausfertigung eines einzelnen Blattes verhindern.
>
>
> Bleibt als wichtigstes Kriterium für GoB Konformität nur die ordentliche
> Zulassung von GC durch das FA/FIN.
>
> Und genau das ist der Knackpunkt! Wer kann eine OS-Software beim FA
> einreichen, wenn da:
>
>   a) dauernd dran geändert wird
>   b) jeder (Dank OSS) dran' rumfummeln' kann
>   c) eigenlich niemand die Gemeinschaft der Programmierer vertreten kann
>   d) ein Haftungsanspruch gegenüber ?Wem? nicht durchgesetzt werden kann
>
>
> (Siehe auch: http://de.wikibooks.org/wiki/OpenSource_im_Unternehmen )
>
> Vielleicht kann hierbei ein Kontakt zu der FOSS-Vertretung (Namen
> vergessen) oder dem CCC hilfreich sein. Anfragen an das FA, wobei die
> verschiedenen Ergebnisse und Aussagen im Wiki zu konsolidieren wären,
> wären auch hilfreich.
>
>
> Schlage vor: Eine GC-Wiki-Seite zum Thema GoB/FA aufzumachen wo alle
> hier mitlesenden Geschäftsleute mal die Infos Ihrer/s 'gelöcherten'
> FAs/StBs hinterlegen.
> Wenn dann noch jemand aus der Liste Kontakt zur FreeSoftwareFoundation
> (oder wie die heissen) oder dem CCC herstellen kann, um die auch mal zu
> Wort kommen zu lassen, ist GC schon ein ganzes Stück weiter.
>
>
>
> Mit genügend Kapital würde ich eine/n Firma/Gesellschaft/Verein gründen,
> welcher die Interessen von GC gegenüber der/dem
> FA/Öffentlichkeit/Gewerbetreibenden vertritt.
>
>
> Aber Leider...
>
>
>
> Tschö
> Frank
>   

Hallo Frank,

zu Punkt a)  und b)  kann man sich auch Versionsstände  vorstellen die
dann eben nicht verändert werden oder nur in "großen" Abständen.

Oder  ich kann mir auch eine Verfahrens- und Anwendungsbeschreibung
incl. Testfälle vorstellen die dann "zertifiziert" werden. Das geht bei
anderer Software auch. Ich denke viele zertifizierte Software lebt
weiter (Fehlerbehebung, neue äußere Bedingungen die es zu erfüllen gilt)
solange Sie die entsprechende Testscenarien besteht. Wurde jedes
Programm nach Einbau der iTan-Fähigkeit erneut geprüft?

Wie schon gesagt erscheint mir wichtig Ziele zu vereinbaren (auf die
Steuerberater mit offenen Ohren reagieren) und Testscenarien zu
entwickeln die die Qualität der Software anhand der gesteckten Ziele
sicherstellt.

Viele Grüße,
Mario