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.
__deets__
User
Beiträge: 14494
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: 14494
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