Export der Kassendaten für Statistiken

[jf_stgt]

Hallo zusammen,

wir haben eine Kassensoftware die auch umfangreiche Statistiken und Auswertungen bietet.
Es gibt aber immer wieder Kunden oder auch Händler die eigene Statistiken bauen möchten.
Sei es in einem besonderen Design oder auch Auswertungen die die Allgemeinheit nicht interessieren wie z.B. Umsatz aller Montage zusammen oder so Quatsch.
Dies wollen wir dann natürlich nicht in unsere normale Kassenfunktion übernehmen.

Die Frage ist also. Wie können die Kunden an die Umsatzdaten nach einem Verkauf kommen.

Verschiedene Möglichkeiten stelle ich mir vor:

1. Export des Kassenbons als TXT oder XML Datei mit allen Details wie Bon-Header und Details.
Nachteil: Kunde muss in seiner Anwendung die Datei erst parsen.

2. (Lese)zugriff auf unsere SQL Datenbank.
Dies möchte ich ihm nicht geben.

3. Wir schreiben die Umsatzdaten in eine Excel Datei. Zum Beispiel nach dem Tagesabschluss. Dann kann er (in Excel?) relativ einfach Auswertungen wie Summen etc. bilden.

4. ...

Wer hat so eine Export Funktion schon mal umgesetzt?
Erfahrungen?

Gruß
jf_stgt

[s.h.a.r.k]

Fast jeder etwas erfahrene Programmierer wird schon mal eine CSV-Datei geschrieben habe, die dann ganz einfach via jedem anderem Programm eingelesen werden kann, u.a. eben Excel. Wenn die Benutzer an die Daten wollen und spezielle Auswertungen, so müssen die halt auch einen gewissen Aufwand betreiben, um die Daten in ihr System zu bekommen. Von dem her ist das CSV-Format vollkommen ausreichend, imho.

Ist die Frage nun eigentlich, was ein sinnvolles Format ist, oder wie man eine entsprechende Datei aus den bestehenden Daten erzeugt?

[Lemmy]

HI Jürgen,

Zugriff auf die DB wäre über Views und entsprechende Zugriffsrechte (eigener Benutzer der nur auf die Views zugreifen kann) auch einfach machbar, aber was soll er damit? Dann muss ja noch ein ODBC Treiber oder ähnliches her, damit er auch wirklich von anderen Programmen auf die Daten zugreifen kann.

Export in Excel bringt nur was, wenn der Kunde Excel auch installiert hat, wobei COM auch so seine Probleme hat. Direktes schreiben von Excel-Format halte ich nichts, das führt viel zu oft zu Problemen.

Deshalb: CSV-Export ist das einfachste Mittel, der Kunde kann die Daten dann bel. auswerten (Excel, OpenOffice Calc, Lotus oder eingene DB + Auswertungssoftware).

Grüße

[jf_stgt]

Danke für eure Infos.

Zitat:

Zitat von s.h.a.r.k (Beitrag 1161564)

Ist die Frage nun eigentlich, was ein sinnvolles Format ist, oder wie man eine entsprechende Datei aus den bestehenden Daten erzeugt?

Die Frage ist was das beste Format ist. Die Erzeugung bekomme ich hin.

Danke lemmy, ich denke auch extra Views sind zu komplex (für den Kunden).

Ich denke auch an XML oder CSV.
XML haben natürlich deutlich mehr Dateioverhead.
Dafür sind in CSV Kassendaten schwierig zu halten oder?
Also man bedenke auf einem Kassenbon steht Kunde, Geschlecht, Datum, Gesamtsumme (...) und dann z.B. 10 Einzelpositionen mit 10 x Einzelpreis, Artikelname, Preis versteht ihr?

[Bummi]

Welche Datenbank liegt dahinter und welche Zugriffskomponenten verwendest Du?
Manches lässt sich gegf. auch schnell aus GUI-Komponenten mit Exportern wie cxGrid oder Fastreport abfackeln.
CSV und Excelexporter würde ich beide anbieten, letztlich ist es eine Prozedur die unterschiedlichen Parametern gefahren wird.
XML-Export wären bei Ado neben Plain auch über eine ShapeConnection mehrdimensional schnell umgesetzt ....

[s.h.a.r.k]

Ich würde zu einer CSV oder XML tendieren. Wenn ich wählen müsste, dann eher noch zu einer CSV, da z.B. Excel das sehr einfach einlesen kann.

Beim Export entsteht dann halt für jede Position auf einem Beleg eine Zeile in der CSV, d.h. es werden dann halt so "Bon-globale" Daten, wie Uhrzeit oder Kasse, mehrfach aufgeführt, pro Position eben ein Mal. Aber dafür gibt es sehr viele Programme, die CSV verstehen und einfach importieren können.

[BUG]

Was will der Kunde denn damit machen?

Wenn er es in Excel bearbeiten möchte, würde ich bei CVS bleiben und eventuell verschiedene Tabellen anbieten (mit Schlüsseln wo es sich anbietet, also zB. vom Kassenbon zu den Einzelpositionen, aber den Artikelnamen und die Nummer direkt rauschreiben). Zusätzlich aber dann auch die Variante von s.h.a.r.k..
Mit etwas Mühe könnte man die Spalten vom User auswählen lassen.

Wenn er eh einen Programmierer anheuert, wäre ein nettes View vielleicht doch nicht verkehrt.

[p80286]

Da ich auf der "Kunden Seite" sitze, was spricht gegen einen View?
Soo viel Aufwand ist es ja auch nicht einen View zu erstellen, und was gerne vergessen wird,
wem "gehören" eigentlich die Daten?

Gruß
K-H

[Lemmy]

Zitat:

Zitat von p80286 (Beitrag 1161602)

Da ich auf der "Kunden Seite" sitze, was spricht gegen einen View?

ODBC-Treiber die nicht funktionieren bzw. die in Zusammenspiel mit der Super-Auswertungssoftware von dir (die absolute Spitzenklasse ist, absolut fehlerfrei programmiert ist und bisher mit ALLEM funktioniert hat) schlicht nicht funktionieren? Die dem Entwickler/Supporter Stunden an Einrichtung kosten (die natürlich keiner bezahlt)? ;-)

Grüße

[p80286]

Da kommen mir aber gleich die Tränen.
Wenn ich versuche auf eine existierende DB zu kommen, ist das ja wohl mein Problem.
Etwas anderes ist es wenn ein Superstarverkäufer zwar erzählt, das es eine Auswertungsschnittstelle gibt, diese aber unbedingt die XYZ-Treiber des Mongolischen Sofwarehauses WannixMoon in der Version 556.78.0005A-78 benötigt.
Komm, nun lassen wir mal die Kirche im Dorf. Wenn beide Seiten wissen um was es geht und die Zuständigkeiten abgeklärt sind, wo ist das Problem?

Gruß
K-H

[Sir Rufo]

Wer mehr Statistik benötigt (als Kunde) als die Software beinhaltet und der Softwarehersteller implementieren möchte, sollte sich darauf einstellen eine separate DB für dieses Vorhaben zu bemühen.

Eine MegaMonsterAuswertung auf ein Produktiv-System loszulassen kommt dem digitalen Selbstmord gleich.

Nicht umsonst gibt es Software a la QlikView die genau zu diesem Zweck geschaffen wurde.
Und für diese Art von Software würde ich Schnittstellen anbieten.

[Furtbichler]

Nun ja. Es wird doch möglich sein, für die Datenbank einen Treiber auf dem System des Kunden zu installieren. Was daran so schlimm sein soll, erschließt sich mir nicht.

Und dann zeigt man ihm, wie man über EXCEL an die Daten rankommt. Fertig.

Geld verdient ihr damit, das ihr dem Kunden die Views zur Verfügung stellt, die seinen Vorstellungen entsprechen.

Bei einer Kassensoftware sollte es aber reichen, z.B. die Tagesergebnisse als CSV-Datei zur Verfügung zu stellen. So viele Daten sind das ja nicht, weder an Zeilen noch an Spalten.

Wir erzeugen z.B. Logdateien im CSV-Format. Der Dateiname ist dabei das Tagesdatum. Der Kunde kann jederzeit auf die letzten N (default = 30) Tage zugreifen. Wenn er sie längerfristig speichern will, bitte sehr. Nichts spricht dagegen, das er sich eine Access-oder-wie-auch-immer-DB bastelt und die Daten dort einbläst. Benötigt er Unterstützung? Klar, machen wir.

[s.h.a.r.k]

Wobei ich hier Sir Rufo schon Recht geben muss. Bietet man Views an, so werden alle Queries auf dem Produktiv-System ausgeführt. Jetzt lasst mal so einen Pfuscher auf dem System arbeiten, der non-stop die DB pollt und es halt einfach nicht besser weiß. Wollt ihr wirklich Support für die Fehler anderer spielen? Klar, wenn dafür extra Geld rausspringt wäre das noch unter Umständen okay, aber von dieser Fehlerquelle würde ich definitiv Abstand nehmen und die Daten einfach regelmäßig exportieren. Als Hersteller der Software muss man doch sicherstellen, dass die Funktionalität der Software nicht durch Spielereien gefährdet wird. Ob das genannte Beispiel übertrieben ist, darf jeder für sich entscheiden, nur habe ich echt schon viel zu viel gesehen, als dass ich das für gut heißen würde.

Fazit: das einfachste ist es alles regelmäßg in eine CSV zu klopfen. Ansonsten kann man sich überlegen, ob man nicht noch eine SQLite-DB füttert. Aber diese externe Auswertung hat im eigentlichen System nicht viel zu suchen, wenn ein fremder User darauf zugreifen soll. Jedenfalls wäre ich auch sehr vorsichtig damit.

Und zu dieser Treibergeschichte: bietet man eine ordentliche Schnittstelle à la CSV, Access-DB, SQLite, MySQL an, so wird es wohl für den Kunden kein Problem sein einen entsprechenden Treiber oder dergleichen zu installieren. Das sollte dann definitiv nicht das Problem des Herstellers sein.

[jf_stgt]

Guten Morgen zusammen,

Danke für eure echt guten Antworten.
Also ich fasse mal zusammen und ergänze meine persönliche Meinung dazu.

Views möchte ich ungern anbieten. Erstmal muss der Kunde spezielle Datenbanktreiber haben und zweites müssen wir da noch aufpassen dass der Kunde nicht die DB crasht durch polling etc..
Außerdem wird er über Änderungen nicht so informiert falls es neue Kassendaten gibt.

Ich stelle mir mehrere Exports vor.
1. Export der Kassendaten in Kopfdaten, Detaildaten und eine gemeinsame Datei direkt nach dem Kassiervorgang.
2. Export der Tagesabrechnung die dann die Umsätze zusammen enthält.

Alles als CSV Datei mit dem Datum als Dateinamen damit die einzelne Datei nicht zu voll wird. Plattenplatz spielt eine untergeordnete Rolle.
Der Kunde kann dann diese Datei parsen und in eine eigene DB schreiben oder direkt in Excel etc. verarbeiten.

Ich denke damit ist das Thema ausreichend erörtert, oder?

Viele Grüße,
Jürgen

[s.h.a.r.k]

Zitat:

Zitat von jf_stgt (Beitrag 1161661)

Views möchte ich ungern anbieten. Erstmal muss der Kunde spezielle Datenbanktreiber haben und zweites müssen wir da noch aufpassen dass der Kunde nicht die DB crasht durch polling etc..
Außerdem wird er über Änderungen nicht so informiert falls es neue Kassendaten gibt.

Hatte ich mich falsch ausgedrückt? Die DB crasht doch nicht. Es geht evtl. nur die Performance des DBMS runter. Und sowas auf einem Produktiv-System wäre einfach nicht wünschenswert. Der sichere und störungsfreie Betrieb muss ja gewährleistet werden. Aber das passiert halt auch nur unter gewissen Umständen und hier ist einfach Vorsicht geboten, denn der Kunde schimpft dann auf deine Software und nicht unbedingt auf das evtl. dumm programmierte Auswertsystem.

Das Problem mit dem Treiber ist doch eigentlich kein Problem, da man doch eigentlich keine speziellen Treiber verwendet, oder? Man verwendet nur eine entsprechende Version, die doch überall installierbar ist. und das in einer Doku zu erwähnen ist doch kein Problem. Oder passt ihr Treiber für den DB-Zugriff an, dass kein anderer das nutzen kann? Hm...

Zitat:

Zitat von jf_stgt (Beitrag 1161661)

Ich stelle mir mehrere Exports vor.
1. Export der Kassendaten in Kopfdaten, Detaildaten und eine gemeinsame Datei direkt nach dem Kassiervorgang.
2. Export der Tagesabrechnung die dann die Umsätze zusammen enthält.

Warum so kompliziert? Alles in eine Datei rein klatschen, eine Doku dazu schreiben, wie diese Datei aufgebaut ist und dem Kunden so ausliefern. Man muss es sich extra für den Kunden doch nicht schwerer machen, als es sein muss. Zudem weiß man eh nicht genau, was der Kunde später dann aus den Daten machen will, d.h. einfach eine Maximaldatei liefern und alles ist erledigt. Selbst anpassbar würde ich diese Export nicht machen, da die Daten später ja immer noch vom Kunden gefiltert werden können -- lieber zu viel, als zu wenig liefern.

Zitat:

Zitat von jf_stgt (Beitrag 1161661)

Alles als CSV Datei mit dem Datum als Dateinamen damit die einzelne Datei nicht zu voll wird. Plattenplatz spielt eine untergeordnete Rolle.
Der Kunde kann dann diese Datei parsen und in eine eigene DB schreiben oder direkt in Excel etc. verarbeiten.

Das Verhalten kannst du ja mit dem Kunden abklären. Wobei ich da nicht zu viel Aufwand rein stecken würde. Will er nur die letzten x Tage in einem Verzeichnis stehen haben, so kann er sich ja einen CronJob basteln. Deine Anwendung liefert halt Tag für Tag alle Daten in ein Verzeichnis. Alles andere ist imho nice-to-have.