Verkaufs- Kassensoftware in python

Alles, was nicht direkt mit Python-Problemen zu tun hat. Dies ist auch der perfekte Platz für Jobangebote.
pyStyler
User
Beiträge: 311
Registriert: Montag 12. Juni 2006, 14:24

Freitag 8. Juni 2007, 21:24

Hallo,

kennt zufällig einer von euch eine Verkaufs- oder Kassensoftware
geschrieben in Python?

Für einen Link oder Tip wäre ich sehr dankbar.

Danke und Gruss
pyStyler
Benutzeravatar
Mr_Snede
User
Beiträge: 387
Registriert: Sonntag 8. Februar 2004, 16:02
Wohnort: D-Dorf, Bo

Freitag 8. Juni 2007, 22:16

Schau dem Gerold mal in die Signatur --> sw3.
(ich denke mir mal, dass das in Python geschrieben wurde)
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Samstag 9. Juni 2007, 08:12

Mr_Snede hat geschrieben:Schau dem Gerold mal in die Signatur --> sw3.
(ich denke mir mal, dass das in Python geschrieben wurde)
...leider noch in Visual Basic 6. :(
SW3 hat schon über acht Jahre auf dem Buckel. Damals war ich noch eingefleischter MCP und wusste noch nichts von Python.

lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
EnTeQuAk
User
Beiträge: 986
Registriert: Freitag 21. Juli 2006, 15:03
Wohnort: Berlin
Kontaktdaten:

Samstag 9. Juni 2007, 09:09

@gerold: Na dann habt ihr ja was zu tun :)

@pyStyler: Mir fällt auf anhieb nicht wirklich was ein. Ansonsten einfach mal auf Sourceforge.net suchen.

Aber...
Wozu brauchst du unbedingt eine in Python geschriebene Kassenverwaltung?

MfG EnTeQuAk
pyStyler
User
Beiträge: 311
Registriert: Montag 12. Juni 2006, 14:24

Samstag 9. Juni 2007, 11:30

Hallo,
also die Software ist nicht für mich, sondern für einen guten Freund von mir.
Die Software von Gerold scheint genau die richtige für ihn zu sein, halt aber nicht Kostenlos ( ist aber auch klar bei so ne Profi Software).

Ich werde jetzt noch bei Sourceforge vorbeischauen vielleicht werde ich dort fündig.

MfG
pyStyler
Benutzeravatar
Mr_Snede
User
Beiträge: 387
Registriert: Sonntag 8. Februar 2004, 16:02
Wohnort: D-Dorf, Bo

Dienstag 12. Juni 2007, 13:19

Nur so als Suchbegriff: point of sale oder kurz POS
Ich meine auch bei ProLinux ist mir sowas in den Programm-News schon untergekommen. Aber ich glaube Suchen macht der dort keinen Spass.
pyStyler
User
Beiträge: 311
Registriert: Montag 12. Juni 2006, 14:24

Dienstag 12. Juni 2007, 21:12

dank sourceforge haben wir jetzt einige Kassensysteme(POS) finden und testen können.
Leider waren mit unter keine richtig lauffähige in Python geschriebenen Kassensysteme dabei.

Ich habe gedacht, wenn ich etwas mehr Zeit habe, werde ich versuchen als "Projekt" ein Kassensystem in Python zu programmieren. :D
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Dienstag 12. Juni 2007, 21:20

pyStyler hat geschrieben:Ich habe gedacht, wenn ich etwas mehr Zeit habe, werde ich versuchen als "Projekt" ein Kassensystem in Python zu programmieren. :D
Hallo pyStyler!

Da könnte ich, bei Interesse, als Berater fungieren. Ich selber darf im Moment kein Kassenprogramm und keine Warenwirtschaft schreiben. Das verbietet mir mein Partnerschaftsvertrag. Aber ich kann dir sagen, was die Probleme waren; auf was ich am Anfang keine Rücksicht genommen habe, was sich aber später als Problem herausgestellt hat; Sinnvolle Datenstrukturen; Auswahl des Datenbanksystems mit Begründung; usw.

mfg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
pyStyler
User
Beiträge: 311
Registriert: Montag 12. Juni 2006, 14:24

Dienstag 12. Juni 2007, 21:36

gerold hat geschrieben:
pyStyler hat geschrieben:Ich habe gedacht, wenn ich etwas mehr Zeit habe, werde ich versuchen als "Projekt" ein Kassensystem in Python zu programmieren. :D
Hallo pyStyler!

Da könnte ich, bei Interesse, als Berater fungieren. Ich selber darf im Moment kein Kassenprogramm und keine Warenwirtschaft schreiben. Das verbietet mir mein Partnerschaftsvertrag. Aber ich kann dir sagen, was die Probleme waren; auf was ich am Anfang keine Rücksicht genommen habe, was sich aber später als Problem herausgestellt hat; Sinnvolle Datenstrukturen; Auswahl des Datenbanksystems mit Begründung; usw.

mfg
Gerold
:-)
:shock: Wenn das mal kein Angebot ist? Wie sagt man - das ist ein angebot was ich nicht ablehnen kann :D.
Ich werde auf jeden fall auf dich zu kommen.

MfG
pyStyler
thelittlebug
User
Beiträge: 188
Registriert: Donnerstag 20. Juli 2006, 20:46
Wohnort: Wien
Kontaktdaten:

Freitag 15. Juni 2007, 01:15

Mich würden da ja auch einige Details brennend interessieren da ich ja noch immer am planen der Shopsoftware "hänge" :)

lgherby
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Montag 18. Juni 2007, 07:03

thelittlebug hat geschrieben:Mich würden da ja auch einige Details brennend interessieren
Hallo Herby!

Also hier ein paar Punkte, die man beachten sollte oder die einem später das Leben leichter machen.

Internationalisierung
Schon von Anfang an daran denken, dass nur ein kleiner Teil der Welt "deutsch" spricht. Für Python empfiehlt sich das Modul "gettext".

Mehrwertsteuer
Es gibt viele Länder, in denen nicht nur ein MwSt-Satz für einen Artikel verwendet werden muss. Es gibt sogar Länder, die mehrere Steuern auf einen Artikel drauf schlagen und diese Steuern müssen auf den Rechnungen explizit aufgeschlagen werden. Also muss nicht nur der MwSt-Satz pro Rechnungszeile, sondern auch noch eine andere Steuer angezeigt werden.

Netto nicht Brutto
Die Artikelpreise sollten in der Datenbank immer "Netto" gespeichert werden. Niemals "Brutto". Warum? Weil ein Artikel je nach Verwendung mit verschiedenen MwSt-Sätzen belegt werden kann. Wenn man den Brutto-Preis in der Datenbank speichert, dann hat man Probleme.

Zahlmittel
Es gibt nicht nur Bargeld oder Kreditkarte. Es gibt "Gutscheine mit Geldwert", "Gutscheine mit Warenwert" z.B. im Wert eines T-Shirts (in verschiedenen Größen), ...
Man sollte also Zahlmittel nicht "fest" ins Programm einbauen, sondern diese dynamisch aus der Datenbank laden.

Fremdwährung
Man muss bei der Verwendung von Fremdwährung den Kurs zum Zeitpunkt der Verwendung mitspeichern. Kurse ändern sich ständig.

Touchscreen oder doch nicht?
Eine Kassen-Arbeitsstation muss entweder mit der Tastatur oder mit Hilfe eines Touchscreens bedient werden können. Es ist nicht ideal, wenn ein Tagesabschluss nur mit Tastatur bedient werden kann, wenn der Kassencomputer nur mit Touchscreen augestattet ist.
Es ist aber ebenfalls nicht ideal, wenn man zum Bedienen der Kassenoberfläche eine Maus braucht.
Alle Dinge, die zum Bonieren wichtig sind, müssen also einmal nur mit Tastatur und einmal nur mit der Maus/Touchscreen bedienbar sein.

Authentifizierung und Rechtevergabe
Was bei einem einfachen Kassensystem, das nie mit anderen Arbeitsstationen oder Servern zusammenarbeiten wird, kein Problem ist, ist im Falle einer Vernetzung doppelt wichtig.

Man muss sicher stellen, dass ein Mitarbeiter nicht, unabsichtlich oder böswillig, einem anderen Mitarbeiter Artikel hinzufügen oder stornieren kann.

Man muss sicher stellen, dass die Mitarbeiter einer Filiale keine Daten von anderen Filialen abfragen können.

Man muss sicher stellen, dass nur privilegierte Mitarbeiter Einstellungen ändern können.

Man muss sicher stellen, dass nur privilegierte Mitarbeiter einen Bon stornieren dürfen. Das kann z.B. der Store-Leiter sein.

Idealerweise überlässt man die Authentifizierung dem Datenbanksystem. Es ist nicht ideal, wenn man diese selber in die Hand nimmt. Das habe ich persönlich erst zu spät gemerkt.

Mitarbeiterauthentifizierung auf verschiedene Arten ermöglichen: Keine Authentifizierung, einfache Auswahl eines Namens, Auswahl eines Namens und Eingabe eines Passwortes, Mitarbeiterkarte, Kellner-Steckschlüssel, ...

Jede Aktivität muss mitgeloggt werden
Ein Löschen einer Datenzeile gibt es nicht. Es gibt nur Stornos. (Detailstornos, Bonstornos,...)

Reporting
- Renner oder Penner
- Wer storniert sehr oft?
- Umsätze
- ...
Berichte müssen ausgedruckt werden können und sollten auch irgendwie abgespeichert werden können. (z.B. als PDF)

Bondruck
Lass den Kunden kontrollieren. Kein Verkauf ohne ausgedruckten Bon. So kann vermieden werden, dass nur zum Schein etwas in die Kassa eingegeben wird, aber nie zur Verrechnung kommt. Gemeinsam mit einer Übersicht über die Bonstornos und die Detailstornos, wird dadurch ein Bescheißen durch Mitarbeiter erschwert.

Laufende Nummern
Laufende Nummern für Bons müssen irgendwann mal wieder auf 0 gestellt werden. Entweder monatlich, jährlich, oder manuell.

Frei definierbare Felder
Jeder Kaufmann hat andere Informationen, die er/sie zu einem Artikel hinzuschreiben möchte.

Branchenunterschiede
Es gibt Branchen, die für einen Artikel, der sich nur durch Farbe oder Größe unterscheidet, nur einen einzigen Barcode vergeben. Das ist zwar blöd, muss aber auch irgendwie gehandelt werden.
Bei Schuhen oder bei Kleidung z.B. muss man in diesem Fall nach dem Einscannen des Barcodes, nach Farbe oder Größe fragen. Bei unterschiedlichien Farben bleibt der Preis meist gleich. Aber bei unterschiedlichen Größen ändert sich dadurch auch der Preis einer Ware.

Rabatte und Kundenkarten
Kunden können Rabatte bekommen. Diese sollten automatisch vom Programm aktiviert werden. Es gibt Mengenrabatte, Naturalrabatte, "Nimm 3 zahl 2"-Rabatte, usw.
Es genügt nicht, nur einen einzelnen Artikel beim Eingeben zu analysieren. Man muss immer auch alle anderen Bondetails durchsuchen um die exakte Menge für die Rabatte herauszufinden.
Ein Artikel kann von mehreren Rabatten betroffen sein. (Feiertagsrabatt, Ausverkaufsrabatt, einfacher Mengenrabatt, spezieller Kundenrabat, usw) Es muss immer der für den Kunden günstigste Rabatt heran gezogen werden. Rabatte dürfen nicht aufsummiert werden.

Man muss auch darauf achten, dass es verschieden hohe Rabatte gibt. Nicht nur einen Rabatt vorsehen. Mehrere Rabattarten in der Datenbank speichern lassen. Vergebene Rabattart mit dem Bon oder mit dem Bondetail mitspeichern.
Rabatte auf den ganzen Bon (Pauschalrabatte) müssen sich proportional mindernd auf die MwSt-Beträge auswirken.
Es darf also nicht sein, dass ich etwas um 10 Euro verkaufe, aber für 100 Euro Steurn zahle.

Rückgabe von Artikeln
Die Rückgabe von Artikeln muss geregelt werden. Warum hat der Kunde den Artikel zurück gegeben? Bekommt er dafür einen Gutschein? Wird ihm das Geld zurück erstattet?
Einfache Oberfläche für Rückgaben erstellen. Mit einer Buchung eines Artikels mit Minusmenge geben sich größere Händler nicht zufrieden.

Es gibt noch viele Dinge, die man beachten muss, aber jetzt muss ich mich um meine Arbeit kümmern.

lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
jens
Moderator
Beiträge: 8482
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Montag 18. Juni 2007, 09:35

Ich war gestern auf einem Konzert. Da haben die vielleicht ein bescheuertes Kassensystem gehabt.
Die hatten ganz tolle, hochmoderne Kassen gehabt. Klein und handlich mit Touchscreen.

Das bescheuerte daran: Sie mussten sich immer mit einer Telefonkarten große Karte Authentifizieren. (seitlich einschieben)
Ist im Prinzip ja nicht so schlimm. Allerdings mussten die nach *jedem* Kunden die Karte aus der Kasse wieder raus ziehen und beim nächsten Kunden wieder einstecken. Total bescheuert.

Natürlich waren auch promt welche dabei, bei denen der Kartenleser schon schlapp gemacht hat. Der Typ von der Kasse wollte die Karte wieder sauber machen, in der Hoffnung das es wieder klappt. Rubbelte diese hastig am T-Shirt rum und so... Naja, die Schlange wurde immer länger, die Laune der Kunden immer schlechter...

Super Konzept *kopfschüttel*

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
thelittlebug
User
Beiträge: 188
Registriert: Donnerstag 20. Juli 2006, 20:46
Wohnort: Wien
Kontaktdaten:

Montag 18. Juni 2007, 10:41

Da ich ja noch immer über meinen Shop grüble danke ich dir für deine Erfahrung die du uns hier bereitwillig zur Verfügung stellst.
Einige Punkte sind nicht neu für mich da ich ja in meiner Firma für die WaWi zuständig war. Zusätzlich waren wir noch in der Textilbranche, die Hölle, sag ich dir. ;)

lgherby
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Montag 18. Juni 2007, 16:27

Es geht weiter... :-)

Programm-Modell
Hier kommt es darauf an, für wen man das Kassensystem programmiert. Soll es schnell fertig sein und hautpsächlich **einen** Kunden zufriedenstellen, dann muss man sich keine große Sorgen um Portabilität machen. Dann schreibt man ein Kassenprogramm, ohne sich um irgendwelche Anbindung an Internetserver oder Ähnliches Gedanken zu machen.

Meistens ist es ziemlich umständlich, die gleichen Daten wie das Warenwirtschaftssystem zu verwenden. Einfacher und leichert zu handhaben ist ein gezielter Datenimport und -export. Was sinnvoller ist, das muss von Situation zu Situation entschieden werden.

Bei kleinen Programmen und wenn man kaum Zeit dafür hat, dann sollte man auf eine große Verteilung der Logik verzichten und ein Programm in einem Guss machen. Damit meine ich jetzt ein Modul für das Hauptprogramm und eines für die GUI sollte genügen. Das ist jetzt meine persönliche Meinung. Darüber kann man streiten. Aber ziemlich oft, bei kleinen Programmen, verlangsamt eine verteilte Entwicklung den Prozess erheblich. Oft ist es nicht einmal wichtig, dass die Einstellungen in einer INI-Datei oder in der Datenbank stehen. Wenn man die Einstellungen nicht in die Programmdatei selber schreiben möchte, dann kann man diese immer noch in eine eigene Python-Datei (als Python-Code) auslagern. Aber auch das rentiert sich nur dann, wenn das Programm verteilt werden soll und es nicht nur ein kleines Programm für eine(n) werden soll.
Außerdem lässt sich die Einstellungsverwaltung später immer noch auslagern. Das ist keine Hexerei.

Wenn das Programm verteilt werden soll oder sogar im Verbund mit anderen Arbeitsstationen und Server(n) laufen soll, dann sieht die Sache gleich wieder ganz anders aus. Lokale Einstellungen in INI-Dateien. Die lassen sich einfach verteilen und können sogar kaskadiert werden. INI-Dateien können sich teilweise überschreiben. Superideal, ehrlich! :-) Globale Einstellungen müssen natürlich in die Datenbank.

Die richtige Datenbank
Wenn es *nur* ein kleines Kassenprogramm werden soll, das über einen Touchscreen bedient werden soll, dann könnte es noch evt. mit Shelve oder Textdateien funktionieren. Aber die sinnvollen Grenzen sind klein.

Wenn ein Artikel gesucht werden soll, oder wenn ein Artikel nicht nur nach Artikelnummer gefunden werden soll, sondern auch nach Barcode-ID oder anhand eines Kurztasten-Codes, dann ist eine Datenbank die BESTE Wahl. Man will später sicher auch noch eine Auswertung der Daten. Es gibt Programme, die direkt auf Datenbanken (z.B. per ODBC) zugreifen können. Aber es gibt keine Programme, die auf Textdateien oder Shelve-Dateien zugreifen können um damit Auswertungen anzuzeigen. SQLite ist die Wahl für kleine Programme, die keine Authentifizierung brauchen. Schlicht, einfach und sauschnell.

Eigentlich muss ich sogar zugeben, dass ich SQLite sogar für alle Desktop-Systeme verwenden würde. Auch dann, wenn es eine Hauptdatenbank gibt, mit der die Daten abgeglichen werden, dann wäre bei mir PostgreSQL für die Hauptdatenbank und SQLite für die lokalen Daten zuständig. Lokal werden ja sowiso nur Daten gespeichert, die für die lokale Kasse wichtig sind und zur Hauptdatenbank muss sich das System mit einem gültigen Benutzernamen und Passwort verbinden.

SQLite verzichtet auf Verbindungen zwischen Tabellen und referenzieller Integrität. Außerdem kennt es nur ein paar Basis-Datentypen und hat nichts mit Benutzerauthentifizierung und Berechtigungen am Hut. Aber dafür ist es schnell und unkompliziert. Es muss nicht installiert werden -- und das ist schon ein rießiger Vorteil bei Desktopsystemen. Die Datensicherung ist ein einfaches Kopieren der Datendatei. Und im Gegensatz zu vielen anderen kleinen Datenbanksystemen für Python, können die Daten indiziert werden.

PostgreSQL für die Hauptdatenbank. Aber nur für den Fall, dass man mehrere Kassen zusammenschließen möchte. Gemeinsame Artikelverwaltung, gemeinsame Kundenverwaltung, zentrale Auswertung, usw.
Warum PostgreSQL? Ich komme von der Microsoft-Schiene und habe viele Jahre lang zuerst mit MS Excel, dann mit MS Access und später mit MS-SQL-Server gearbeitet. Eigentlich finde ich den MS-SQL-Server toll. Auch die Tools zum Erstellen der Datenbanken und zum erstellen der Views, Prozeduren, Funktionen, Sichten usw. sind toll. Aber Microsoft zieht dich immer mehr in die totale Abhängigkeit. Für jede Kleinigkeit musst du zahlen und das nicht zu wenig. Deshalb und aus anderen unwichtigen Gründen, habe ich lange nach einer geeigneten Alternative gesucht und diese in PostgreSQL gefunden.

Ich will keine PostgreSQL contra MySQL Diskussion auslösen. Wer MySQL nehmen will, soll MySQL nehmen.

PostgreSQL hat für mich den Vorteil, dass es inzwischen ein ausgeklügeltes Berechtigungssystem hat. Prozeduren schon seit jeher kennt und in C, Java, Python usw. programmierbar ist. Damit meine ich jetzt nicht nur, dass man PostgreSQL von diesen Sprachen aus als Server ansprechen kann. Damit meine ich, dass man Prozeduren und Co. direkt in diesen Sprachen programmieren kann. Damit kann man ziemlich viel direkt im Datenbanksystem machen. Man kann die Datenintegrität sicher stellen. Man kann aber auch komplexe Abfragen vorbereiten und eigentlich schon die komplette Middleware im Datenbanksystem herrichten. Auch darüber lässt sich wieder wunderbar streiten. Die einen sagen so, die anderen so.
Ich weiß nur, dass man von sehr vielen Programmiersprachen aus auf eine PostgreSQL-Datenbank zugreifen kann und man sich die aufwändige Middleware sparen kann. Auch dann, wenn man später mal vom Internet aus und mit einer anderen GUI auf die Daten zugreifen möchte. Man muss ja nicht alles selber programmieren. Man kann ruhig die Datenbank einiges an Arbeit abnehmen lassen. (Authentifizierung, Berechtigungen, Einstellungen, Benachrichtigen von Clients, usw.)

Auswertungen
Jedes Kassenprogramm braucht irgendeine Ausgabe der Daten, irgendeine Auflistung der Verkäufe, eine Liste für den Steuerberater, ...
Ich habe den "Report Manager" http://reportman.sourceforge.net/ gefunden. Damit können Berichte recht einfach zusammengeklickt werden. Damit kann man sich zu einer Datenbank verbinden und Abfragen als Basis für Berichte erstellen. Seitennummerierung, Gruppierungen, Gruppensummen, usw.
Der ReportManager hat seine Ecken und Kanten und man muss sich ein bischen einarbeiten. Aber nach einem Tag weiß man wie der Hase läuft und kann so ziemlich jeden Bericht damit erstellen.
Schon deshalb ist es wichtig, dass man eine Datenbank als Basis hat.

Beim nächsten Mal mehr...

lg
Gerold
:-)

PS: Dass ich es nicht vergesse: Ich möchte noch Barcodescanner und Bondruck ansprechen...
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
Sr4l
User
Beiträge: 1091
Registriert: Donnerstag 28. Dezember 2006, 20:02
Wohnort: Kassel
Kontaktdaten:

Montag 18. Juni 2007, 17:30

Es gibt ja verschiedene Varianten von Scannern USB, Seriel und PS/2 und die Scanner decodieren doch schon die Daten?
Du musst sie also nur noch auslesen. An Seriellen Anschlüssen kannst du ja horchen. PS/2 kann man das wie mit einem Keylogger per `msvcrt` auslesen?

Wäre auf jedenfall wünschens Wert diese Funktion. Ich habe leider kein Scanner das fehlt mir noch ebenso wie ein DB-Lautstärkenmessgerät ;-)

PS: Gerold behalt ein paar Betriebsgeheimnisse noch für dich :-) Man muss ja immer soviel lesen.
Antworten