ubuntuusers.de

Xell schrieb:

Die bei der Software interessante Richtlinie nennt sich Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme.

Nö. Ein P(oint)O(f)S(ales) ist kein Buchführungssystem. Es ist nur eine Kasse. 😉

DeJe schrieb:

Dr. E Bian schrieb:

Und @DeJe: ich war der Meinung es ginge um OpenPOS, weil das in dem Kommentar stand den ich zuletzt gelesen hatte.

Doch, es geht um OpenPOS. 😉 Genau genommen um OpenBravo POS. 😀 Die andere Schiene wäre OpenERP bzw. OpenBravo ERP. Ja, ist etwas verwirrend. Zumal es auch noch OpenPOS (in CS) gibt, das mit Openbravo POS nicht viel gemeinsam hat.

OK, danke ☺ dem hätte ich jetzt nur noch hinzuzufügen, dass Java für dei Ausführung üblicherweise auch nicht im Quelltext, sondern als kompilierter Bytecode vorliegt. Es unterscheidet sich in dieser Hinsicht also nicht von kompilierten Sprachen.

Das ändert aber nichts an meinem Kommentar, der war Software-unabhängig. Es interessiert das FA schlicht nicht, wie und mit welcher SW du deine Abrechnungen bewerkstelligst. Die interessiert auch nicht, ob diese manipulationssicher ist. Das ist DEIN Problem. 😉

Im ursprünglichen Artikel wurde aber gerade behauptet, dass es eine Anforderung an Kasssensoftware gäbe, die Manipulationssicherheit verlangt. Ich denke allerdings, dass sich eine solche Anforderung nur auf die im Kassenterminal installierte Software beziehen kann und nicht auf die Software im Allgemeinen, denn letztere ließe sich gar nicht erfüllen.

DeJe schrieb:

Xell schrieb:

Die bei der Software interessante Richtlinie nennt sich Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme.

Nö. Ein P(oint)O(f)S(ales) ist kein Buchführungssystem. Es ist nur eine Kasse. 😉

Na ja, es hat aber sicherlich eine Schnittstelle zur "Buchführung".

Die von Xell oben genannte Richtlinie ist schon passend, denn auch eine "Kassensoftware" muss die Grundsätze der ordnungsgemäßen Buchhaltung gemäß HGB erfüllen.

Closed Source heißt aber nicht, dass der Quellcode des Programms nicht vorliegt, sondern nur, dass Du das Programm, wenn Du es änderst, nicht mit Deinen Änderungen weitergeben darfst.

Die Lizenzunterschiede bestehen v.a. in der Weitergabe veränderter Versionen - auch wenn man bei Nicht-Open-Source fast nie den Quellcode mit dazubekommt - außer bei Officemakros und Javascript.

Da bedeutet die Sichtbarkeit und Änderbarkeit des Quellcodes meist kein Recht veränderte Versionen in Umlauf zu bringen.

Wesentlich für das Arbeiten mit Buchungen ist aber nicht die Änderbarkeit des Programms, sondern der Daten, und digitale Daten könnte man nur vor Änderung schützen, wenn man sie live an einen unabhängigen Prüfer schicken würde, der spätere Manipulationen dann jederzeit beweisen könnte. Das macht aber auch keine CS-Software.

Wenn es da wirklich Vorschriften in diese Richtung gäbe würde mich das dennoch nicht wundern, weil die Interessenvertreter da Informationstechnische Analphabeten 'beraten'.

user unknown schrieb:

Wesentlich für das Arbeiten mit Buchungen ist aber nicht die Änderbarkeit des Programms, sondern der Daten, ...

Genau. Und deshalb gibt es auch keine solche Anforderung. Die Software an sich ist vollkommen Banane. 😉

user unknown schrieb:

Wenn es da wirklich Vorschriften in diese Richtung gäbe würde mich das dennoch nicht wundern, weil die Interessenvertreter da Informationstechnische Analphabeten 'beraten'.

Da hast du schon recht. Aber in dieser Beziehung sind sie zum Glück noch nicht komplett durchgeknallt. 😀

Es ist im Ergebnis tatsächlich so, wie es harmatan, agschaal und Glori beschreiben. Das Kassensystem darf durch den Anwender nicht manipulierbar, getätigte Buchungen müssen unveränderbar sein.

Sie dürfen allenfalls durch Stornierung oder Korrekturbuchungen neutralisiert werden. Das Einrichten und Löschen von Bedienern, von Stammdaten wie Preis, Ust-Satz,... muss nachvollziehbar sein. (Log-Datei o.Ä.)

Der Anwender soll nicht in der Lage sein, Manipulationen vorzunehmen. Die Personen, die die Software programmieren, bzw diejenigen, die das System einrichten , werden wohl immer in der Lage sein, nicht oder für einen Prüfer nur schwer nachvollziehbare Änderungen vorzunehmen.

Ob Open Source verwendet wird oder nicht, ist dabei völlig egal.

Mittlerweile gibt es für sehr viele gängigen „Nicht-Open Source“-Kassensysteme „Spielzeug“, mit denen es „interessierten Anwendern“ gelingt, Kassendaten beinahe spurlos zu manipulieren.

Vom Finanzamt wird man wohl keine konkrete Antwort bekommen. Weiß ich, dort arbeite ich. Mit dem Thema plag´ ich mich in der Praxis oft rum. Es wird wahrscheinlichbei einem Hinweis auf die GoBS bleiben. (vgl Link im Beitrag von Xell v.16.9.11).

Das Finanzamt kann auch keinen allgemeinen Persilschein ausstellen. Es ist immer der Einzelfall maßgebend. Ist blöd, aber verständlich. Die Markierung „gelöst“ --zumindest zufriedenstellend gelöst--wird wohl schwer zu setzen sein. Sorry