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

Beitragvon pyStyler » Montag 18. Juni 2007, 19:04

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
pyStyler
User
Beiträge: 311
Registriert: Montag 12. Juni 2006, 14:24

Beitragvon pyStyler » Montag 18. Juni 2007, 22:14

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
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Beitragvon gerold » Dienstag 19. Juni 2007, 09:52

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=]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 |
---------------------------------------------[/code]
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
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
ete
User
Beiträge: 218
Registriert: Montag 19. Februar 2007, 13:19
Kontaktdaten:

Beitragvon ete » Mittwoch 23. April 2008, 11:38

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
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Beitragvon gerold » Mittwoch 23. April 2008, 13:08

ete hat geschrieben:Kennst du vielleicht eine Demo

Hallo Stefanie!

Nein, leider.

lg
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

Beitragvon pyStyler » Freitag 25. April 2008, 18:52

Hallo ete,

du kannst dir mal die Demo von http://www.bonit.eu/asp/download.asp laden und ausgiebig testen......

Gruss
pyStyler
BlackJack

Beitragvon BlackJack » Dienstag 6. Mai 2008, 10:41

Man sollte bei Kassensystemen auf jeden Fall diesen Testfall berücksichtigen: Lidl und der Kassen-Bug. :-D

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder