Seite 1 von 2

Verkaufs- Kassensoftware in python

Verfasst: Freitag 8. Juni 2007, 21:24
von pyStyler
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

Verfasst: Freitag 8. Juni 2007, 22:16
von Mr_Snede
Schau dem Gerold mal in die Signatur --> sw3.
(ich denke mir mal, dass das in Python geschrieben wurde)

Verfasst: Samstag 9. Juni 2007, 08:12
von gerold
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
:-)

Verfasst: Samstag 9. Juni 2007, 09:09
von EnTeQuAk
@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

Verfasst: Samstag 9. Juni 2007, 11:30
von pyStyler
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

Verfasst: Dienstag 12. Juni 2007, 13:19
von Mr_Snede
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.

Verfasst: Dienstag 12. Juni 2007, 21:12
von pyStyler
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

Verfasst: Dienstag 12. Juni 2007, 21:20
von gerold
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
:-)

Verfasst: Dienstag 12. Juni 2007, 21:36
von pyStyler
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

Verfasst: Freitag 15. Juni 2007, 01:15
von thelittlebug
Mich würden da ja auch einige Details brennend interessieren da ich ja noch immer am planen der Shopsoftware "hänge" :)

lgherby

Verfasst: Montag 18. Juni 2007, 07:03
von gerold
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
:-)

Verfasst: Montag 18. Juni 2007, 09:35
von jens
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*

Verfasst: Montag 18. Juni 2007, 10:41
von thelittlebug
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

Verfasst: Montag 18. Juni 2007, 16:27
von gerold
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...

Verfasst: Montag 18. Juni 2007, 17:30
von Sr4l
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.

Verfasst: Montag 18. Juni 2007, 19:04
von pyStyler
Hallo Gerold,

ersteinmal ein dickes dankeschön für die ganze infos, die du für uns übrig hast.

Jezte werde ich deine postings detaillierter analysieren und hoffe, mir fällt eine frage dazu ein. :D

Sr4l hat geschrieben:PS: Gerold behalt ein paar Betriebsgeheimnisse noch für dich Man muss ja immer soviel lesen.
Das sind doch keine Betriebsgeheimnisse. :wink:
Ich denke es ist so - ein extrem erfahrener Programmierer versucht uns klar zu machen, wo die schwierikeiten beim Programmieren eines Kassensytems sind.

Danke und Gruss
pyStyler


p.s @Sr4l ich weiss wie du das gemeint hast. :D

Verfasst: Montag 18. Juni 2007, 22:14
von pyStyler
Hallo,
ein Paar Gedanken von mir,

**Internationalisierung

da das Kassensystem vollkommen von der Gui abgetrennt wird, werde
ich eine englische Gui mit allem drum und dran mitgeben. Ich denke, das
ist einfacher als mit gettext zu arbeiten ?

**Netto nicht Brutto

Frage: das heisst, in der Datenbank muss ich meinen tatsächlichen
Gewinn nach Abgaben der Steuern speichern ?

**Zahlmittel
Was mache ich, wenn einer mit der Karte zahlen will ?
gibt es dafür externe Opensource Programme ?

**Fremdwährung

reicht datum + Kassenbonnummer ?

**Touchscreen oder doch nicht?
also es ist einfach so, dass ich mich mit Tkinter "Gut" auskenne, deshalb
wird die Windows Version in Tkinter sein.
( sieht unter Windows Gut aus finde ich. Auf Wunsch gibt es einen Screen )
Frage: Gerold weisst du ob man Tkinter mit einem Touchscreen bedienen
kann ( ich weiss, ist ein bisschen lolig :D )
wahrscheinlich muss der Fokus über alle Widgets sein?

**Authentifizierung und Rechtevergabe

das wird echt mal schwierig denke ich!
eventuell hat einer eine Idee, wie ich es am besten lösen kann.

**Branchenunterschiede
das ist echt mal komisch. Wie soll man da eine anständige Lagerführung
betreiben können?

**Rabatte und Kundenkarten
am überlegen bin.

**Die richtige Datenbank
das ist echt mal ein grosses Problem was ich im Moment habe.
ich muss noch ein paar Nächte drüber schlafen.

Gruss
pyStyler

Verfasst: Dienstag 19. Juni 2007, 09:52
von gerold
Hallo pyStyler!
pyStyler hat geschrieben:**Internationalisierung
da das Kassensystem vollkommen von der Gui abgetrennt wird, werde ich eine englische Gui mit allem drum und dran mitgeben. Ich denke, das ist einfacher als mit gettext zu arbeiten?
Eine Trennung ist teuer. Die kostet dich "geschätzt" 1/5 deiner Arbeitszeit. Aber sie ist vernünftig, wenn du ein erweiterbares Programm schreiben möchtest.

Gettext ermöglicht es anderen, dein Programm zu übersetzen. Aber wenn du dein Programm eh in englisch schreibst, dann lässt sich das später auch noch einbauen. --> http://www.python-forum.de/topic-10711.html

pyStyler hat geschrieben:**Netto nicht Brutto
Frage: das heisst, in der Datenbank muss ich meinen tatsächlichen Gewinn nach Abgaben der Steuern speichern?
Nein. Ich meinte damit, dass du nirgends den Brutto-Verkaufswert der Ware speichern sollst. Rechne erst beim Verkauf den Brutto-Verkaufswert der Ware aus. Bei Verkäufe an Endkunden arbeitest du mit dem Brutto-VKP. Bei Verkäufen an gewerbliche Inlandskunden arbeitest du mit Netto-VKP und rechnest zum Schluß die MwSt dazu. Bei Verkäufen an gewerbliche Auslandskunden mit gültiger UID arbeitest du mit Netto-VKP ohne die MwSt dazuzurechnen. Dafür muss dann aber auch auf der Rechnung drauf stehen, dass es sich um so einen Kunden handelt.

Es ist, schlicht einfacher, wenn du in der Datenbank (bei den Artikeldaten) den NETTO-VKP stehen hast. Z.B. in der Schweiz haben manche Artikel unterschiedliche MwSt-Sätze, je nachdem, ob die Ware im Lokal genossen wird, oder ob sie mitgenommen wird.

Wo wir dann bei den MwSt-Sätzen sind. Ich würde die MwSt-Sätze eines Artikels NICHT in die Artikel-Tabelle schreiben. Ich würde die MwSt-Sätze in eine eigene Tabelle schreiben. So, dass ein Artikel mehrere MwSt-Sätze besitzen kann. Und dann muss noch eine Regel aufgestellt werden, die dem Programm bekannt gibt, welcher MwSt-Satz zu verwenden ist. Idealerweise nimmt man einen "Action"-Artikel für so etwas. Also ein Artikel, der zwar an der Kasse gebucht werden kann, aber nichts anderes zu tun hat, als dem System als Schalter zu dienen. --> Wenn dieser Artikel nicht in der Detailliste auftaucht, dann wird bei jedem Artikel der erste MwSt-Satz verwendet. Taucht dieser Artikel in der Detailliste auf, dann werden alle Artikel der Detailliste noch einmal durchlaufen und geprüft ob jetzt der zweite oder dritte MwSt-Satz verwendet werden soll.

Code: Alles auswählen

vat_groups
===================================
id | group_id | percent | condition
===================================
1  |    1     |   14    |   NULL
-----------------------------------
2  |    1     |   7     |   A1234
-----------------------------------
3  |    2     |   10    |   NULL
-----------------------------------
4  |    3     |   20    |   NULL
-----------------------------------

articles
=============================================
article_nr | name         | vat_group | ...
=============================================
L13        | Bio-Joghurt  |     1     |
---------------------------------------------
E234       | Radio        |     3     |
---------------------------------------------
S667       | Wiener Schn. |     2     |
---------------------------------------------
G567       | Sachertorte  |     1     |
---------------------------------------------
Bei dieser Art der MwSt-Zuweisung, ist es möglich, einem Artikel mehrere MwSt-Sätze zuzuweisen. Und das Kassenprogram sucht sich dann den richtigen Satz aus der Tabelle raus. Wenn der Artikel "A1234" nicht in der Liste mit den Verkaufsdetails enthalten ist, dann wird der Artikel "G567" mit 14% verkauft. Ist der Artikel "A1234" allerdings in der Liste mit den Verkaufsdetails, dann wird der Artikel "G567" mit 7% verkauft. Dieser ominöse Artikel "A1234" könnte den Namen "Ware wird mitgenommen" haben. Somit weiß das System, dass die Ware nicht im Lokal gegessen, sondern mitgenommen wird und kann darauf reagieren. Ob dieser Artikel dann auch auf dem Bon steht oder nicht, ist dann nicht mehr wichtig.
Wichtig ist nur, dass dadurch der richtige MwSt-Satz verwendet wurde und dass ich später exakt auswerten kann, wieviel im Lokal verzehrt wurde und wieviel die Kunden mitgenommen haben.

So kannst du schon mal ziemlich viele Länder abdecken und kannst auch flexibel auf Steueränderungen reagieren.

pyStyler hat geschrieben:**Zahlmittel
Was mache ich, wenn einer mit der Karte zahlen will ?
gibt es dafür externe Opensource Programme ?
Fast alle Anbieter von Kreditkarten-Terminals können das Terminal so einstellen, dass es unabhängig vom Kassenprogramm arbeitet. Der Kassier muss dann den Betrag direkt in das Terminal eingeben.

Wenn du dein Kassenprogramm mit so einem Terminal verbinden möchtest, dann musst du mit einer dieser Karten-Terminal-Anbieter zusammenarbeiten. In Österreich musst du dich sogar zertifizieren lassen, sonst lassen die dich nicht an die Bankomat-Terminals ran. In Österreich ist z.B. die Firma Europay oder besser deren Partner First Data Austria GmbH zuständig. Bei FDI kann man sich die Schnittstellenbeschreibung besorgen und sich zertifizieren lassen. In Deutschland ist es, glaube ich, einfacher.

pyStyler hat geschrieben:**Fremdwährung
reicht datum + Kassenbonnummer ?
Wenn beim Bezahlen des Bons **in Deutschland** "Britische Pfund", "Amerikanische Dollar" und "Euro" verwendet wurden, dann musst du mindestens den dafür verwendeten Wechselkurs für "Britische Pfund" und "Amerikanische Dollar" abspeichern. Natürlich mit Bezug zum Bon. Bezug zu einem Datum funktioniert nicht, da der Kurs sich auch im Laufe des Tages ändern kann.

Idealerweise speicherst du mit, wie und mit welcher Währung der Kunde bezahlt hat. Dann kannst du beim Tagesabschluss auch auflisten, was eigentlich in der Kassenschublade drinnen sein sollte. Wieviel Euro, wieviel Dollar und wieviel Pfund.

Fremdwährungen sind in Europa für den Einzelhandel nicht mehr so wichtig wie vor der Euro-Einführung. Aber wenn dein Programm auch in anderen Ländern Verwendung finden soll, dann kommst du um Fremdwährungen nicht herum.

pyStyler hat geschrieben:**Touchscreen oder doch nicht?
also es ist einfach so, dass ich mich mit Tkinter "Gut" auskenne, deshalb wird die Windows Version in Tkinter sein.
( sieht unter Windows Gut aus finde ich. Auf Wunsch gibt es einen Screen ) Frage: Gerold weisst du ob man Tkinter mit einem Touchscreen bedienen kann
Die meisten Touchscreen-Monitore simulieren einfache Mausklicks. Wenn dein Programm ohne Tastatur, nur mit der Maus bedienbar ist und die Buttons nicht zu klein gehalten werden, dann ist dein Programm mit einem TS bedienbar.

Viele Händler wollen TS-Lösungen. Weil sie einfach aussehen und hip sind. Händler, die darüber nachdenken und wollen, dass die Waren die Kassen schnell passieren, arbeiten mit programmierbaren Tastaturen und mit Barcodescannern. Das ist viel, viel schneller als TS-Lösungen. Aber auch eine Kombination aus Barcodescanner und Touchscreen kann schnell sein. Es kommt immer auch auf den Anwendungsfall an.

Z.B. bei McDonalds und Co würde ich niemals eine reine Tastaturlösung verwenden. Die haben exakt angepasste TS-Lösungen. Diese stehen dem Kassier zur Seite und weisen auf Menükombinationen und Angebote hin. Außerdem kann die Oberfläche auf neue Anforderungen angepasst werden.

Im Gastgewerbe haben sich TS-Lösungen auch bewährt. Erstens ist der Bildschirm hell, so dass auch in dunklen Lokalen alles gesehen werden kann. Zweitens gibt es im Gastgewerbe viele Kombinationen von Artikeln, die man über einen TS recht schnell auswählen kann.

Aber im Handel, oder z.B. bei Schellbedienungsrestaurants bin ich klar gegen den Einsatz von Touchscreens. Da ist ein geschulter Mitarbeiter mit einer programmierbaren Tastatur um Welten schneller.

pyStyler hat geschrieben:**Authentifizierung und Rechtevergabe
das wird echt mal schwierig denke ich!
eventuell hat einer eine Idee, wie ich es am besten lösen kann.
Bei PostgreSQL hast du ein Berechtigungssystem mit dabei, das du auch für dich verwenden kannst. Du kannst Rollen anlegen und Datenbankbenutzer diesen Rollen zuweisen. Später kannst du abfragen, welche Rollen einem Benutzer zugewiesen wurden.

http://www.postgresql.org/docs/8.2/stat ... manag.html

Und damit findest du z.B. raus, an welche Rollen der aktuell angemeldete Benutzer gebunden ist:
http://www.postgresql.org/docs/8.2/stat ... roles.html

Mit Rollen kannst du also erstens den Zugriff auf die Datenbank regeln und zweitens auch an Berechtigungen in deinem Kassensystem binden. Du musst nur irgendwo definieren, welche Rolle was tun darf. Das ist aber nur ein Beispiel. Es gibt auch andere Möglichkeiten.

pyStyler hat geschrieben:**Die richtige Datenbank
das ist echt mal ein grosses Problem was ich im Moment habe.
ich muss noch ein paar Nächte drüber schlafen.
Kassenprogramme sind typtische Datenbank-Programme. Ich habe oft überlegt, ob ich die Daten nicht irgendwie in das Dateisystem legen könnte, aber es spricht nichts dafür. Irgendwie muss man sich da alles selber programmieren. Jede kleine Suche oder ein Datenabgeleich endet dann in einer Programmier-Orgie.


lg
Gerold
:-)

Verfasst: Mittwoch 23. April 2008, 11:38
von ete
Hallo Gerold!

Ich möchte für eine Freundin eine minimal Version einer Kassensoftware machen. Deine Tips haben mir schon grossartig weitergeholfen.
Kennst du vielleicht eine Demo von einer guten Kassensoftware, das man sich das ganze mal anschauen kann?

Liebe Grüsse
Stefanie

Verfasst: Mittwoch 23. April 2008, 13:08
von gerold
ete hat geschrieben:Kennst du vielleicht eine Demo
Hallo Stefanie!

Nein, leider.

lg
Gerold
:-)