Kasse [POS] in Python plus Warenwirtschaft und Onlineshop

Alles, was nicht direkt mit Python-Problemen zu tun hat. Dies ist auch der perfekte Platz für Jobangebote.
Benutzeravatar
pillmuncher
User
Beiträge: 1482
Registriert: Samstag 21. März 2009, 22:59
Wohnort: Pfaffenwinkel

Py-Paul hat geschrieben:...Kundenkonten, in denen die jeweiligen Guthabenbeträge stehen. Das ist notwendigerweise aus Platzgründen unvollständig...
Sobald es um Geldkonten geht, ist das alleinige Speichern des aktuellen Guthabens zu wenig. Man will ja wissen, wie es zu diesem Guthaben gekommen ist. Was würdest du davon halten, wenn deine Bank dir am Monatsende eine Nachricht schickt, in der lediglich steht "Ihr Guthabenstand ist so-und-so" aber nicht die Kontobewegungen? Für Lagebestände gilt übrigens dasselbe. Ein zu googlendes Stichwort wäre Event Sourcing.
In specifications, Murphy's Law supersedes Ohm's.
Py-Paul
User
Beiträge: 26
Registriert: Freitag 30. August 2013, 11:55

snafu hat geschrieben:Der übliche Weg bei solchen großen Vorhaben ist halt, sich bestehende Software (z.B. Odoo) zu nehmen und diese anzupassen.
Das hatte ich auch lange Zeit vor..... eben mit Odoo. Aber auch da gibt es eben nicht nur Licht.... Der ganze Haufen von Code, bei dem kaum noch jemand durchblickt usw. Ich beschrieb das ja schon weiter oben...

Ich schaue mir gerade die Kasse von Odoo 11 an.

snafu hat geschrieben:Du hast also Bedenken, dass ein jahrelang gepflegtes und von der Community angenommenes Produkt schlechter ist als etwas in Eigenregie innerhalb weniger Monate aus dem Boden gestampftes? Mkay...
Zu Odoo hatte ich ja schon oben was geschrieben. Vieles galt als buggy und nicht gerade schlank programmiert. Ich sehe schon die Vorteile von OpenSource und funktionierenden Communities- man sollte aber auf der anderen Seite so realistisch sein, darin nicht die Gewähr für ein gut gestaltetes und programmiertes System zu sehen ("optimal" habe ich nicht geschrieben!). Das ergibt sich aus vielen "Metarecherchen" zu Odoo und weil ich zufällig einen Odoo Entwickler kenne. Im Umkehrschluss muss Odoo nicht schlecht sein. Was Preise angeht, zu denen ich mich nicht äußere, kann man jedenfalls feststellen, dass der belgische Hersteller (oder wie nennt man das bei OpenSource Projekten?) jetzt verstärkt in die Monetarisierungsphase geht- was er wiederum mit Gegenwerten aufwiegen möchte. Allerdings sind dabei einige Details aus meiner bescheidenen Sicht zweifelhaft: die kostenfreie Communityversion lässt sich nicht auf mobilen Geräten darstellen, die kostenpflichtige Enterpriseversion dagegen schon. Betrachtet man das echte Leben, würde die Communityversion damit von vornherein wegfallen. Das neue Odoo 11 soll aber viel besser als alle Odoos zuvor sein.

snafu hat geschrieben:Im Übrigen hattest du eingangs noch die Lagerhaltung und ein WaWi-System erwähnt. Das ist jetzt plötzlich nicht mehr relevant? Selbst wenn Du "nur" die Schnittstellen zu bestehenden Lösungen meintest, so ist auch hier der Aufwand nicht zu unterschätzen.
Ja, das hängt später natürlich alles zusammen. Die Produktauflistung mit Bestand für die Kasse wäre dazu ja schon ein Anfang.

__deets__ hat geschrieben: Du unterschaetzt das. Wirklich. Massiv. Ich habe an einem Webshop gearbeitet, das sind dutzende Mannjahre, die da drin versenkt wurden. Es waere schlimmer in Java gewesen (siehe unten), aber es war trotzdem richtig viel Arbeit, und bleibt es auch. Unsere Webabteilung mit ~6 Entwicklern tut nahezu nur das. Und das ist "nur" das Frontend, die Datenbank, das Lizenzvergabe und Preisberechnungssystem. Der Anschluss ans Accounting erfolgt durch eine Schnittstelle zu Drittanbietern.
Ich habe auch das Gefühl, dass ich das unterschätze. Irgendwann muss ich aber mal versuchen die Sachen zu finden, die ich immer übersehe. Wenn man die Berichte über Webshops liest, dann wird einem ganz anders... :cry:

__deets__ hat geschrieben:
Py-Paul hat geschrieben: Was mir aber gar nicht klar ist, ist die "Pflege" des Systems. Was soll da wie gepflegt werden? Außer Ergänzung von Produkten und Preisänderungen, was aber ja für mich keine "Pflege" ist.... (OK, man sagt, glaube ich, "Preise / Produkte einpflegen").
Pflege bedeutet neue Funktionalitaet. Die kann in diesem Zusammenhang von dir gewuenscht sein, viel wichtiger aber in diesem Bereich durch gesetzliche Vorgaben vorgeschrieben werden - du *musst* also reagieren.
Ja, ok, dazu schrieb ich ja schon was.
A propos "gesetzliche Vorgaben": Jetzt fällt mir gerade einer der wichtigsten Gründe ein (habe ich AFAIR hier noch nicht erwähnt). Bei allen bestehenden Systemen, die ich dann entsprechend modifiziere, hätte ich nie ein ausreichend sichers Gefühl (von "wissen" gar nicht die Rede), dass diese tatsächlich diese Normen erfüllen. Nur bei einer selbst kontrollierten Neuentwicklung hätte ich eine gewisse, hoffentlich hinreichende Sicherheit.
Das gilt dann also für Odoo und alle, zB die weiter unten verlinkten, Entwicklungen. Schon das $-Zeichen bei den Beträgen deutet darauf hin, dass eine Software zumindest nicht ursprünglich für den deutschen Markt entwicklet wurde.


__deets__ hat geschrieben:
Py-Paul hat geschrieben: Das ist hier ein interessanter Punkt: Wie kommt es dabei zur häufigen Benutztung von Java? Ist das für solche Anwendungen irgendwie prädestiniert?
Nicht an sich, aber Java wird von boesen Zungen als das Cobol der 90er bezeichnet. Banken und Co verwenden es oft, und das ist halt eine business-affine Umgebung. Oder auch "enterprisey", wie man so schoen sagt.

Allerdings ist es auch ein ziemlich aetzendes Umfeld, wo immer die grossen Raeder gedreht werden, wenn es auch ein kleines taete.

OK, dass das in speziellen professionellen Bereichen gern genommen wird, ahbe ich auch schonmal gehört. Allerdings sind die Kassen, die ich meine, alles OpenSource Entwicklungen- darum wunderte mich das besonders. Siehe zB hier: https://blog.capterra.com/the-top-6-fre ... solutions/
Py-Paul
User
Beiträge: 26
Registriert: Freitag 30. August 2013, 11:55

pillmuncher hat geschrieben:
Py-Paul hat geschrieben:...Kundenkonten, in denen die jeweiligen Guthabenbeträge stehen. Das ist notwendigerweise aus Platzgründen unvollständig...
Sobald es um Geldkonten geht, ist das alleinige Speichern des aktuellen Guthabens zu wenig. Man will ja wissen, wie es zu diesem Guthaben gekommen ist. Was würdest du davon halten, wenn deine Bank dir am Monatsende eine Nachricht schickt, in der lediglich steht "Ihr Guthabenstand ist so-und-so" aber nicht die Kontobewegungen? Für Lagebestände gilt übrigens dasselbe. Ein zu googlendes Stichwort wäre Event Sourcing.
Interessanter Hinweis, Danke.

Dass es Bewegungsrichtungen diesbezüglich gibt, war mir klar. Den Fachausdruck Event Sourcing kannte ich noch nicht. Ich hatte das aus der buchhalterischen Sicht mit Buchungssätzen gesehen. Insofern würde vermerkt werden, dass Bargeld eingezahlt und ein bestimmtes Guthabenkonto entsprechend aufgefüllt wurde- also buchhalterisch ein "Zahlungsmitteltausch", bilanz- und USt-neutral.
Benutzeravatar
kbr
User
Beiträge: 1487
Registriert: Mittwoch 15. Oktober 2008, 09:27

Py-Paul hat geschrieben:Bei allen bestehenden Systemen, die ich dann entsprechend modifiziere, hätte ich nie ein ausreichend sichers Gefühl (von "wissen" gar nicht die Rede), dass diese tatsächlich diese Normen erfüllen. Nur bei einer selbst kontrollierten Neuentwicklung hätte ich eine gewisse, hoffentlich hinreichende Sicherheit.
Das ist das "Not Invented Here"-Syndrom, das oftmals Ursache, oder zumindest teilweise, für verspätete, fehlerhafte, finanziell aus dem Ruder gelaufene oder gar gescheiterte Projekte ist.
Py-Paul
User
Beiträge: 26
Registriert: Freitag 30. August 2013, 11:55

kbr hat geschrieben:
Py-Paul hat geschrieben:Bei allen bestehenden Systemen, die ich dann entsprechend modifiziere, hätte ich nie ein ausreichend sichers Gefühl (von "wissen" gar nicht die Rede), dass diese tatsächlich diese Normen erfüllen. Nur bei einer selbst kontrollierten Neuentwicklung hätte ich eine gewisse, hoffentlich hinreichende Sicherheit.
Das ist das "Not Invented Here"-Syndrom, das oftmals Ursache, oder zumindest teilweise, für verspätete, fehlerhafte, finanziell aus dem Ruder gelaufene oder gar gescheiterte Projekte ist.
Hehe..., ja da hast Du aus dieser Sicht sicherlich auch recht...

Du musst aber zugeben, dass die Abwägung schwer ist: Bei bestehenden Systemen mit einer Menge Datenmüll und kryptischem Code- egal ob Open Source oder proprietär- anzuknüpfen, birgt schon Risiken- besonders dann, wenn man bedenkt, dass das Finanzamt die Kassenführung über 10 Jahre rückwirkend verwerfen und dann (nach oben) schätzen darf. Womit wir wieder bei dem sind, was ich anfangs hervorgehoben hatte, die beiden Communities.... :wink:
DasIch
User
Beiträge: 2718
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

Py-Paul hat geschrieben:Es scheint ein Naturgesetz zu sein, dass auf Meinungen zu Preisen, auch wenn diese Meinungen schlüssig sind, oft heftig reagiert wird. Eine dauerhafte Rentenzahlung (finanztechnisch) i.H.v. mindestens 49 € ist schon einiges, schon absolut für sich genommen. In Relation zum Produkt, so, wie es sich für mich darstellt, ist das ziemlich viel.
49 € kann man schon alleine für Hosting, Backups usw. ausgeben. Jährliche Entwicklungskosten in mindestens 6-stelliger Summe kommen da noch dazu. Außerdem haben Software Projekte eine unschöne Tendenz haben schief zu gehen. Du solltest also bereit sein soviel auch ggfs. in den Sand zu setzen und am Ende bei Orderbird o.ä. zu stehen.
Benutzeravatar
kbr
User
Beiträge: 1487
Registriert: Mittwoch 15. Oktober 2008, 09:27

@Py-Paul: Wenn Du bestehenden Softwarelösungen nicht vertraust, kannst Du das Thema auf eine einfache Betrachtung reduzieren. Du schreibst es selbst, oder gibst es in Auftrag. Ersteres kannst Du nicht (und falls doch, so brauchst Du Zeit und hast kalkulatorische Kosten), letzteres wird teuer.
Und da es sich um eine unternehmenskritische Anwendung handelt, ist auch der sichere Betrieb mit Kosten verbunden.
Py-Paul
User
Beiträge: 26
Registriert: Freitag 30. August 2013, 11:55

DasIch hat geschrieben: 49 € kann man schon alleine für Hosting, Backups usw. ausgeben. [...]
Dieses Orderbird entspricht aber eben nicht meinen persönlichen Preferenzen. Und meine bescheidene persönliche Meinung ist, dass ich für solch eine Gastrokasse, auch mit Fernbonnierung, mindestens 49 € im Monat als teuer empfinde, denn es sind ja regelmäßige Zahlungen und das System ist nicht für zB 1000 € gekauft (mit folgenden kostenfreien Sicherheitsupdates und Bugfixes und kostenpflichtigen Verbesserungen bzw. Erweiterungen).
Die 49 € oder mehr stehen ja gar nicht zur Debatte- die würde ich für passende Software schon monatlich bezahlen- allerdings ist mir das Kaufmodell (mit Updates) lieber als das SAAS-Modell. Das wäre aber wieder ein eigenes Diskussionsthema.
kbr hat geschrieben:@Py-Paul: Wenn Du bestehenden Softwarelösungen nicht vertraust, kannst Du das Thema auf eine einfache Betrachtung reduzieren. Du schreibst es selbst, oder gibst es in Auftrag. Ersteres kannst Du nicht (und falls doch, so brauchst Du Zeit und hast kalkulatorische Kosten), letzteres wird teuer.
Und da es sich um eine unternehmenskritische Anwendung handelt, ist auch der sichere Betrieb mit Kosten verbunden.
Jaja, ich muss Dir ja -leider- schon wieder recht geben. Ich habe einfach den Umfang der Arbeiten nicht so groß eingeschätzt. Ich weiß ja immer noch nicht wieviel das ist und inwieweit man das mit einem Webshop vergleichen kann.
Selbstmachen würde mich zwar reizen, aber es ist einfach illusorisch. Also schaue ich mich weiter um :K
Odoo könnte -vielleicht- doch was werden.Ich würde aber schon gern wissen, wie das mit den GOBD dort realisiert ist- und da habe ich wieder ein ungutes Gefühl.
bfm
User
Beiträge: 88
Registriert: Donnerstag 14. März 2013, 09:42

Hallo zusammen,

ich bin gerade dabei, mein etwas in die Jahre gekommenes Haushaltsbuch für den reinen Privatgebrauch (ab 1990 in Basic geschrieben) neu in Python umzusetzen.

Moderne Programmiersprachen und Datenbanken bieten halt ziemlich viele Möglichkeiten. Wenn ich nur daran denken, wie lange ich am Datenbankdesign rumüberlegt habe. Und das ist heute sicher nicht perfekt. Da wird sich sicher mit der Zeit auch noch etwas ändern, weil ganz einfach Erfahrung hinzu kommt. Mit der GUI oder der "Geschäftslogik" drunter ist es genau das Gleiche. Insbesondere wenn man erst dabei ist, die Programmiersprache zu lernen. Da gibt es auch Code von vor einem Jahr, den ich heute anders schreiben würde. Bei meinem nächsten Projekt werde ich mir mit Sicherheit auch einfacher tun, weil ich halt zwischenzeitlich Erfahrung gesammelt habe.

Dazu muss ich noch sagen, dass ich beruflich Anwender in einer Lohnsoftware schule, berate, Module einrichte, Fehler suche usw. Soll heißen, ich schaue das Auto nicht nur von außen an, sondern ich mache auch mal die Motorhaube auf, schraube den Ventildeckel runter, der Kollege gibt Gas und dann schauen wir mal was passiert. Ich gehe dann durchaus auch mal mit SQL auf die Datenbank und bereinige Datenschiefstände, die die Software durch fehlerhafte Programmierung produziert hat (soviel zum Thema GOB :lol: ). Ich bin in dem Thema Programmierung, Datenbanken usw. also nicht ganz jungfräulich.

Aus dem Grund schätze ich dein Projekt als nicht gerade einfach ein. Selbst ein geübter Programmierer ist da nicht in vier Wochen damit fertig.

mfg
Py-Paul
User
Beiträge: 26
Registriert: Freitag 30. August 2013, 11:55

bfm hat geschrieben: ich bin gerade dabei, mein etwas in die Jahre gekommenes Haushaltsbuch für den reinen Privatgebrauch (ab 1990 in Basic geschrieben) neu in Python umzusetzen.
Dann brauchst Du ja nicht so sehr auf die geltenden Normen achten. Du hättest aber dafür auch fertige günstige / kostenfreie Alternativen.... Als Hobbyprojekt aber sicher interessant.

bfm hat geschrieben: Ich gehe dann durchaus auch mal mit SQL auf die Datenbank und bereinige Datenschiefstände, die die Software durch fehlerhafte Programmierung produziert hat (soviel zum Thema GOB :lol: ).
Das bezieht sich ja auf die Lohnbuchhaltung.... Grundsätzlich werden die GoBD auch hier gelten (und die GOB sowieso)- die relevanten Daten der Lohnbuchhaltung (Meldungen, Beitragsnachweise) werden aber ja direkt an die jeweilige Einzugsstelle übermittelt und dann ausgedruckt (sei es auf Papier oder virtuell als PDF). Daneben noch die Zahlungen der entsprechenden Beträge. Da würde man nachträglich, glaube ich mal, nichts wirklich manipuliert bekommen.

Die Manipulationssicherheit ist aber natürlich ein wichtiges Thema. Wie das konkret bewerkstelligt wird, würde mich mal interesieren. Logdateien spielen wohl eien Rolle- die hätten vielleicht in Deinem Fall den Zugriff auf die Datenbank geloggt, vielleicht auch die konkreten Änderugen aufgezeichnet. Dann müsste nur noch diese Logdatei geschützt werden...
Ich habe neulich das hier entdeckt: http://www.secumem.com/- ein "USB Speicher zur veränderungsgeschützten Archivierung [...]" Es gibt also auch Schutz auf Hardwareebene.

bfm hat geschrieben:Aus dem Grund schätze ich dein Projekt als nicht gerade einfach ein. Selbst ein geübter Programmierer ist da nicht in vier Wochen damit fertig.
Ja, ich fürchte, das wird wohl so sein...
Die Entwickler, die ich hier so kenne (und die nie Zeit haben außer ab und zu mal Kaffee trinken...), raten mir auch ständig ab (nee, stimmt nicht, einer sagt: "einfach anfangen"). Mich würde immer noch interessieren, wo meine Denkfehler liegen, wo der Aufwand eigentlich liegt... :roll:
__deets__
User
Beiträge: 14493
Registriert: Mittwoch 14. Oktober 2015, 14:29

Die meisten Systeme kommen ohne so eine spezielle Hardware daher. Da regiert letztlich der Glaube daran (und eher nicht zu unrecht) das es zu aufwändig ist, lückenlos zu fälschen. Das ist ja nicht anders als mit Papier. Ich könnte auch tausende Briefköpfe gestalten, ausdrucken und abheften. Wird nur anstrengend. Und wenn wer wirklich guckt, ist ein Fehler tödlich.

Was deine Fehleinschätzung angeht - Dunning Kruger ;) Das ist natürlich salopp gemeint. Nur ist der Kern halt einfach: du weißt gar nicht, was du alles nicht weißt. Versuch programmieren zu lernen.
__deets__
User
Beiträge: 14493
Registriert: Mittwoch 14. Oktober 2015, 14:29

Nachdem ich find, das mein "lern programmieren" nicht so richtig hilfreich war, hier noch ein paar mehr Gedanken:

Wir arbeiten zur Zeit an einem komplett neuen Produkt. Das ist etwas ungewoehnlicher, weil es auch bedeutet, das es Risiken gibt, die wir sonst so nicht haben. Trotzdem wollen wir natuerlich eine Vorstellung davon haben, wie kompliziert das ganze ist, wann ungefaehr wir mit einem Release rechnen koennen, etc.

Ich kann jetzt hier nicht die gesamte Theorie der agilen Entwicklung reproduzieren, aber vielleicht ein paar Hinweise geben, wie man das angehen kann. Daran kannst du dich versuchen, und ggf. selbst entsprechende Literatur fuer die Projekt-Leitungs-Seite des ganzen durcharbeiten.

Wie so oft im leben ist das ganze hierarchisch durchstrukturiert: es gibt eine Reihe von top-level Artefakten, wie zB eine Produktvision (was macht das Produkt aus, wie grenzt es sich von den Mitbewerbern ab.

Dann gibt es eine daraus erstellte "User-Story-Map". Das ist in unserem Fall ein wirklich physikalisch vorhandenes, riesiges Whiteboard (ca 1.5m * 5m). Darauf stehen von links nach rechts grobe Aktionen, welche der User mit dem Produkt taetigt. Ich kann aus naheliegenden Gruenden nicht sagen, wie die bei uns aussehen, aber ich versuche das mal fuer dein Produkt runterzubrechen:

- Benutzer meldet sich an
- Benutzer sucht nach Warengruppe
- Benutzer sucht nach Tisch/anderer Kunden-Identifizierung
- Benutzer bongt x von Produkt y fuer Kunde z

Solche und andere Interaktionen (anlegen eines neuen Kunden, erstellen eines Reports, etc) kannst du alle aufschreiben.

Vertikal unter jeder dieser groben Stories stehen konkreter beschriebene. Nehmen wir mal "sucht nach Warengruppe"

Dann sind da zB zu finden:

- sucht per Produktnummer (funktional vollstaendig, aber aetzend in der Bedienung)
- die 10 populaerstene Produkte sind per Schnell-Zugriff zu erreichen (bedeutet natuerlich auch eine Admin-Oberflaeche genau dafuer)
- es gibt eine Produktsuche, die durch hierarchischen Kategorien funktioniert

Etc.

Diese Stories sind wiederum fuer uns Grundlage fuer sogenannte Meilenstein-Planung (ein MS ist im Moment 6 Wochen). Und da werden die *nochmal* runtergebrochen, auf ein Niveau wo ein Entwickler sagt "ok, das ist konkret und ohne nachfragen kann ich das implementieren".

Da wirst du dann mit ein paar hundert von enden, und wenn dann jedes nen halben Tag kostet, dann hast du einen Gesamtaufwand. Natuerlich ist das nicht 100%ig, aber es gibt dem Bauchgefuehl noch mal ein bisschen mehr Fundament.
bfm
User
Beiträge: 88
Registriert: Donnerstag 14. März 2013, 09:42

Py-Paul hat geschrieben: Dann brauchst Du ja nicht so sehr auf die geltenden Normen achten. Du hättest aber dafür auch fertige günstige / kostenfreie Alternativen.... Als Hobbyprojekt aber sicher interessant.
Genau. Gesetzliche Anforderungen interessieren mich nicht. Ich mache es aus Spaß und wenn ich es selber mache, dann kann ich es so machen, wie ich es will und wie es für mich am einfachsten ist.
z. B Banklastschriften als Dauerbuchungen im Haushaltsbuch. EC-Kartenbelege mit einfacher Eingabemaske zum schnell Runtertippen. Kontoauszug einlesen, mit Betrag Bankbuchung und Dauerbuchung/EC-Karte matchen lassen. Monatskontoauszug mit 20-30 Buchungen ist so in zwei Minuten gebucht. Basta!
Py-Paul hat geschrieben: Die Manipulationssicherheit ist aber natürlich ein wichtiges Thema. Wie das konkret bewerkstelligt wird, würde mich mal interesieren. Logdateien spielen wohl eien Rolle- die hätten vielleicht in Deinem Fall den Zugriff auf die Datenbank geloggt, vielleicht auch die konkreten Änderugen aufgezeichnet. Dann müsste nur noch diese Logdatei geschützt werden...
Das geht eigentlich ganz einfach: berechne aus den Feldinhalten eines Datensatzes mit einem geheimen Algorithmus einen Hashwert und speichere ihn geschickterweise in dem betroffenen Datensatz. Wird ein Feld nun z. B. mit SQL manipuliert, dann wird ein anderer Hashwert berechnet und die Manipulation fällt auf.
Py-Paul hat geschrieben: Ja, ich fürchte, das wird wohl so sein...
Die Entwickler, die ich hier so kenne (und die nie Zeit haben außer ab und zu mal Kaffee trinken...), raten mir auch ständig ab (nee, stimmt nicht, einer sagt: "einfach anfangen"). Mich würde immer noch interessieren, wo meine Denkfehler liegen, wo der Aufwand eigentlich liegt... :roll:
Oder einfach mal anfangen. Stück für Stück gibt es dann auch irgendwann mal ein Ganzes :)
Sirius3
User
Beiträge: 17711
Registriert: Sonntag 21. Oktober 2012, 17:20

bfm hat geschrieben: Das geht eigentlich ganz einfach: berechne aus den Feldinhalten eines Datensatzes mit einem geheimen Algorithmus einen Hashwert und speichere ihn geschickterweise in dem betroffenen Datensatz. Wird ein Feld nun z. B. mit SQL manipuliert, dann wird ein anderer Hashwert berechnet und die Manipulation fällt auf.
Das ist Quatsch. Ein geheimer Algorithmus sagt nur, „ich glaube nicht, dass der Algorithmus was taugt“ und das ist auch garantiert richtig. Niemand hindert Dich daran, genau den Algorithmus zu nehmen und einen neuen Hashwert zu berechnen und zu speichern. Nichts was in Software geschrieben ist, ist manipulationssicher.
Py-Paul
User
Beiträge: 26
Registriert: Freitag 30. August 2013, 11:55

@_deets_: Danke für Deine Ausführungen

Ja, das mit den User Stories hatte ich auch schonmal gehört. Erscheint ja auch sinnvoll, da man von den gewünschten Funktionalitäten ausgeht und diese übersichtlich darstellt.

Was die Implementierungs-Standards all der Normen wie GoBD, etc. angeht, so wage ich den Tip: nachdem es einen Haufen von Gerichtsprozessen gegeben hat, die dann zu Konkretisierungen zwingen. Die Normen werden sicher auch immer mehr und immer weitreichender. Es geht dann auch nicht nur um die konkret vorliegenden Daten, sondern auch um die "Vorsysteme"- also alles, was zu diesen Daten geführt hat. Die Daten müssen dann, so tatsächlich die Forderung, "unveränderbar" sein. Wie immer das IT-technisch realisiert werden kann...

Ich fürchte, dass es bei vielen Softwareproduzenten hier eine "Happy-Go-Lucky"-Mentalität gibt- allein schon aus dem Grund, dass diese nicht oder kaum haftbar gemacht werden können. Wenn ich es jetzt richtig sehe, ist Software wohl das einzige Produkt, für das keine Haftung übernommen werden braucht (außer vielleicht grobe Fahrlässigkeit). Ist der User zB Unternehmer, so kann er dann evtl. mit bösen Überraschungen rechnen: Verwerfen der Kasse über die letzten 10 Jahre, damit der Buchhaltung und Schätzung...

Es mag an dieser Stelle vermessen klingen, aber ein Grund für die Idee einer von Grund auf neu programmierten Kasse lag darin, diese so gut zu machen, dass später kein Unheil droht. Aber der Aufwand ist wohl zu groß...

Ich wage aber die Prognose, dass es mit vielen elektronischen Kassen noch böse Überraschungen geben wird.
loopedodge
User
Beiträge: 2
Registriert: Montag 27. September 2021, 13:18

ich habe dir eine PN geschickt.
Antworten