Erarbeitung eines "POS-Kassenbuchs"
Moderator: Moderatoren
Forumsregeln
Dieses Unterforum versteht sich als Plattform zur Diskussion/Bearbeitung komplexerer Anfragen bzw. konkret verabredeter Projekte. Das können Dinge sein wie eine komplexere Calc-Datei oder auch die gemeinsame Programmierung eines größeren Makros, wichtig ist immer die Absicht ein Thema über längere Zeit (z.B. 3 Monate) fortlaufend zu besprechen.
Dieses Unterforum versteht sich als Plattform zur Diskussion/Bearbeitung komplexerer Anfragen bzw. konkret verabredeter Projekte. Das können Dinge sein wie eine komplexere Calc-Datei oder auch die gemeinsame Programmierung eines größeren Makros, wichtig ist immer die Absicht ein Thema über längere Zeit (z.B. 3 Monate) fortlaufend zu besprechen.
Erarbeitung eines "POS-Kassenbuchs"
In diesem Thread erarbeite ich mit freundlicher Forumsunterstützung ein „Point-of-Sale-Kassenbuch“ (Point-of-Sale = POS).
Die ersten Schritte bis hierher habe ich mit balu gemacht, der sich zudem angeboten hat, das Projekt weiter zu begleiten. An dieser Stelle noch einmal ganz lieben Dank an dich!
Um ehrlich zu sein, ist die Bezeichnung „POS-Kassenbuch“ nicht ganz korrekt oder zumindest gibt es das Wort nicht offiziell.
Korrekterweise müsste der Thread wohl heißen „Erarbeitung eines Calc-Dokuments mit Benutzeroberfläche für die Kneipen-Gastronomie zur nachvollziehbaren Einzelauflistung der verkauften Produkte“.
Zum Einen ist das ziemlich lang, zum Anderen erhoffe ich mir durch die verkürzte Bezeichnung, dass jeder, der nach einem solchen Tool sucht, es hier auch finden kann.
Gängig ist heutzutage eine GDPdU-zertifizierte POS-Kasse mit Software, Touchscreen und einem Rechner dahinter, der für kleine Gastronomiebetriebe im Normalfall überdimensioniert ist. Man kann für ein solches System gut und gerne 3.000 € auf den Tisch legen. Hinzu kommen Wartungskosten, die anfallen, wenn einmal etwas nicht funktioniert.
Zum Glück hat man von dem Vorhaben abgelassen, ab 2017 allen Betrieben eine solche GDPdU-konforme Aufzeichnungspflicht aufzuerlegen.
Pflicht ist aber weiterhin eine gut nachvollziehbare Einzelauflistung aller verkauften Produkte. So soll das hier auszufeilende Calc-Dokument eine praktikable Eingabe dieser Einzelauflistung ermöglichen.
Für wen ist das Dokument geeignet?
Geeignet ist das Dokument in seiner Grundstruktur für all diejenigen, die ihre Geschäfte mit einer „offenen Ladenkasse“ - also einer Geldkassette - betreiben.
Hardware/Software
Unser Kneipenrechner ist ein Raspberry Pi 3 Modell B, der mit Kabelage und Gehäuse für ca. 80 € erhältlich ist (Bildschirm, Tastatur, Maus exkl.). Monitor: 19" mit Auflösung 1280 x 1024. Als Betriebssystem verwenden wir Ubuntu Mate. Libre Office 5.1.6.2 läuft darunter einwandfrei.
Allgemeine Erläuterungen
Da wir so gut wie keine Produkte verkaufen, die bei Außerhausverkauf dem verminderten Steuersatz unterliegen, ist keine Spalte für den Steuersatz vorgesehen – dieser ist immer 19%.
Der Steueranteil wird erst später in unserer Buchhaltungssoftware ausgewiesen.
Grundlegend werden alle Werte über die Eingabe von Artikelnummern und die verkaufte Anzahl des Produkts in die Tabelle eingetragen. Die Vergabe von Rabatten in % ist auch vorgesehen (1.a-d).
Es gibt Sonderfälle, in denen der rabattierte VK-Preis (Spalte im Dokument „Einzelpreis nach Rabatt“) nicht über einen Rabatt festgelegt wird, sondern andersherum der Rabatt über eine Preiseingabe errechnet wird (1.e + 2.).
Neben der einfachen Artikelauflistung soll die „Kasse“ folgendes können:
1. Eingabe mit Rabatt für die Fälle
a) Mitarbeiter-Rabatt (50%)
b) Sonstige Rabatte (variable%)
c) kostenfreie Abgabe + Schwund* (100%)
d) evtl. Sachentnahme/Eigenverbrauch (>50%)
e) Verkauf ganzer Flaschen bzw. Kästen über Preiseingabe – Rabatt wird errechnet
2. Bei Verkauf ganzer Kästen außer Haus (in unserem Fall nur das Flaschenbier Astra) wird der Pfandwert auf den rabattierten Verkaufspreis aufgeschlagen.** Hierfür gibt es ein Auswahlfeld „außer Haus“. Dies bedeutet jedoch nicht einen verminderten Außerhaus-Steuersatz.
3. Löschen der zuletzt eingegebenen Zeile
4. Korrektur einzelner Zeilen über ID-Eingabe (derzeit beim Überschreiben keine Sonderfälle s.o. möglich)
5. Kumulieren der durch Rabatte entgangenen Einnahmen = Mindereinnahmen
6. Gesonderter Ausweis des Schwunds in €.*
*noch nicht vorhanden
**Das Pfand wird bei uns nicht einzeln ausgewiesen sondern der Astra-Einnahme hinzugerechnet. Das machen wir nur deshalb so, weil dieser Fall so gut wie nie eintritt und es für uns auch kein Pfand im klassischen Sinne ist, da die Kisten bei uns nicht wieder abgegeben werden. Wer diesen Fall häufiger hat, sollte für das Pfand eine extra Artikelnummer anlegen.
So, jetzt kann´s losgehen. Wer hierzu Fragen oder Anregungen hat, darf diese gerne hier posten. Ich freu mich auf ein kreatives Arbeiten! Denn, wie Wilhelm Busch sagte: „Ein jeder Wunsch, wenn er erfüllt, kriegt augenblicklich Junge.“
Grüße Julia
Hinweis: Ich bin kein Steuerprofi und habe selbst noch nicht zu allen hier angeschnittenen steuerrechtlich relevanten Themen mit dem Steuerberater Rücksprache gehalten --> alle Angaben ohne Gewähr!!!
Die ersten Schritte bis hierher habe ich mit balu gemacht, der sich zudem angeboten hat, das Projekt weiter zu begleiten. An dieser Stelle noch einmal ganz lieben Dank an dich!
Um ehrlich zu sein, ist die Bezeichnung „POS-Kassenbuch“ nicht ganz korrekt oder zumindest gibt es das Wort nicht offiziell.
Korrekterweise müsste der Thread wohl heißen „Erarbeitung eines Calc-Dokuments mit Benutzeroberfläche für die Kneipen-Gastronomie zur nachvollziehbaren Einzelauflistung der verkauften Produkte“.
Zum Einen ist das ziemlich lang, zum Anderen erhoffe ich mir durch die verkürzte Bezeichnung, dass jeder, der nach einem solchen Tool sucht, es hier auch finden kann.
Gängig ist heutzutage eine GDPdU-zertifizierte POS-Kasse mit Software, Touchscreen und einem Rechner dahinter, der für kleine Gastronomiebetriebe im Normalfall überdimensioniert ist. Man kann für ein solches System gut und gerne 3.000 € auf den Tisch legen. Hinzu kommen Wartungskosten, die anfallen, wenn einmal etwas nicht funktioniert.
Zum Glück hat man von dem Vorhaben abgelassen, ab 2017 allen Betrieben eine solche GDPdU-konforme Aufzeichnungspflicht aufzuerlegen.
Pflicht ist aber weiterhin eine gut nachvollziehbare Einzelauflistung aller verkauften Produkte. So soll das hier auszufeilende Calc-Dokument eine praktikable Eingabe dieser Einzelauflistung ermöglichen.
Für wen ist das Dokument geeignet?
Geeignet ist das Dokument in seiner Grundstruktur für all diejenigen, die ihre Geschäfte mit einer „offenen Ladenkasse“ - also einer Geldkassette - betreiben.
Hardware/Software
Unser Kneipenrechner ist ein Raspberry Pi 3 Modell B, der mit Kabelage und Gehäuse für ca. 80 € erhältlich ist (Bildschirm, Tastatur, Maus exkl.). Monitor: 19" mit Auflösung 1280 x 1024. Als Betriebssystem verwenden wir Ubuntu Mate. Libre Office 5.1.6.2 läuft darunter einwandfrei.
Allgemeine Erläuterungen
Da wir so gut wie keine Produkte verkaufen, die bei Außerhausverkauf dem verminderten Steuersatz unterliegen, ist keine Spalte für den Steuersatz vorgesehen – dieser ist immer 19%.
Der Steueranteil wird erst später in unserer Buchhaltungssoftware ausgewiesen.
Grundlegend werden alle Werte über die Eingabe von Artikelnummern und die verkaufte Anzahl des Produkts in die Tabelle eingetragen. Die Vergabe von Rabatten in % ist auch vorgesehen (1.a-d).
Es gibt Sonderfälle, in denen der rabattierte VK-Preis (Spalte im Dokument „Einzelpreis nach Rabatt“) nicht über einen Rabatt festgelegt wird, sondern andersherum der Rabatt über eine Preiseingabe errechnet wird (1.e + 2.).
Neben der einfachen Artikelauflistung soll die „Kasse“ folgendes können:
1. Eingabe mit Rabatt für die Fälle
a) Mitarbeiter-Rabatt (50%)
b) Sonstige Rabatte (variable%)
c) kostenfreie Abgabe + Schwund* (100%)
d) evtl. Sachentnahme/Eigenverbrauch (>50%)
e) Verkauf ganzer Flaschen bzw. Kästen über Preiseingabe – Rabatt wird errechnet
2. Bei Verkauf ganzer Kästen außer Haus (in unserem Fall nur das Flaschenbier Astra) wird der Pfandwert auf den rabattierten Verkaufspreis aufgeschlagen.** Hierfür gibt es ein Auswahlfeld „außer Haus“. Dies bedeutet jedoch nicht einen verminderten Außerhaus-Steuersatz.
3. Löschen der zuletzt eingegebenen Zeile
4. Korrektur einzelner Zeilen über ID-Eingabe (derzeit beim Überschreiben keine Sonderfälle s.o. möglich)
5. Kumulieren der durch Rabatte entgangenen Einnahmen = Mindereinnahmen
6. Gesonderter Ausweis des Schwunds in €.*
*noch nicht vorhanden
**Das Pfand wird bei uns nicht einzeln ausgewiesen sondern der Astra-Einnahme hinzugerechnet. Das machen wir nur deshalb so, weil dieser Fall so gut wie nie eintritt und es für uns auch kein Pfand im klassischen Sinne ist, da die Kisten bei uns nicht wieder abgegeben werden. Wer diesen Fall häufiger hat, sollte für das Pfand eine extra Artikelnummer anlegen.
So, jetzt kann´s losgehen. Wer hierzu Fragen oder Anregungen hat, darf diese gerne hier posten. Ich freu mich auf ein kreatives Arbeiten! Denn, wie Wilhelm Busch sagte: „Ein jeder Wunsch, wenn er erfüllt, kriegt augenblicklich Junge.“
Grüße Julia
Hinweis: Ich bin kein Steuerprofi und habe selbst noch nicht zu allen hier angeschnittenen steuerrechtlich relevanten Themen mit dem Steuerberater Rücksprache gehalten --> alle Angaben ohne Gewähr!!!
- Dateianhänge
-
- POS_Kassenbuch_Forum_4.ods
- (42.2 KiB) 677-mal heruntergeladen
Zuletzt geändert von Julia NuN am Di, 13.12.2016 09:16, insgesamt 3-mal geändert.
Wilhelm Busch: "Ein jeder Wunsch, wenn er erfüllt, kriegt augenblicklich Junge."
... ich glaub, der wär heutzutage Programmierer und nicht Schriftsteller.
... ich glaub, der wär heutzutage Programmierer und nicht Schriftsteller.
Re: Erarbeitung eines "POS-Kassenbuchs"
Eigentlich will ich nur Danke sagen für das interessante Projekt.
Sei möglicherweise nicht enttäuscht wenn es, über Balu hinaus, nicht allzuviel Resonanz gibt, leider beteiligen sich meist nur wenige aktiv an solchen Dingen.
Anregung? Stelle doch vielleicht mal ein paar Bilder (RasPi in Nahaufnahme (verkabelt), Gesamtsystem (RasPi, Monitor, Tastatur), Screenshot von Desktop) ein.
Gruß
Stephan
Sei möglicherweise nicht enttäuscht wenn es, über Balu hinaus, nicht allzuviel Resonanz gibt, leider beteiligen sich meist nur wenige aktiv an solchen Dingen.
Anregung? Stelle doch vielleicht mal ein paar Bilder (RasPi in Nahaufnahme (verkabelt), Gesamtsystem (RasPi, Monitor, Tastatur), Screenshot von Desktop) ein.
Gruß
Stephan
Re: Erarbeitung eines "POS-Kassenbuchs"
Hallo Julia,
Raspberry Pi ist mir wohl nicht ganz unbekannt, wollte mir auch schon mal so was zulegen, aber andere Dinge haben höhere Priorität. Und vor allem war ich mir nicht sicher ob das was Du da jetzt gemacht hast überhaupt funktionieren könnte. In dieser hinsicht hast Du so gesehen Pioniersarbeit geleistet. Klasse.
Und damit sind wir schon bei einem doch nicht ganz unwichtigen Punkt, den wir unbedingt besprechen sollten, der sich sehr stark auf das weitere vorgehen des Kassenbuches niderschlägt.
Mir geht es um die Größe des Bildschirms und was für eine Auflösung Du da fährst. Bitte nenne diese Daten.
Das ist nämlich ein Punkt der mir in deiner bisherigen Beispieldatei nicht so sonderlich gefällt, weil nämlich die Dialoge sehr klein geraten sind. Ich könnte es ja noch verstehen wenn der angeschlossene Bildschirm Hochkant stehen würde und dadurch die Dialoge dann in ein anderes Licht "gerückt werden". Sollte das aber nicht der Fall sein, das mit Hochkant, dann hätten wir eine ganz andere Gestaltungsmöglichkeit der Dialoge.
Und außerdem sollten diese Punkte (Monitor Auflösung, Hoch- oder Querkant) dann auch noch in die "Hardware" Beschreibung mit einfließen. Aber immer eins nach dem anderen, jetzt gehts erstmal um Größe und Auflösung.
Auf ein gutes gelingen.![Smile :-)](./images/smilies/icon_smile.gif)
Gruß
balu
Bin doch erstaunt: Raspberry Pi 3 & LO!Unser Kneipenrechner ist ein Raspberry Pi 3 Modell B, der mit Kabelage und Gehäuse für ca. 80 € erhältlich ist (Bildschirm, Tastatur, Maus exkl.). Als Betriebssystem verwenden wir Ubuntu Mate. Libre Office 5.1.6.2 läuft darunter einwandfrei.
![Shocked :shock:](./images/smilies/icon_eek.gif)
Raspberry Pi ist mir wohl nicht ganz unbekannt, wollte mir auch schon mal so was zulegen, aber andere Dinge haben höhere Priorität. Und vor allem war ich mir nicht sicher ob das was Du da jetzt gemacht hast überhaupt funktionieren könnte. In dieser hinsicht hast Du so gesehen Pioniersarbeit geleistet. Klasse.
![Smile :)](./images/smilies/icon_smile.gif)
Und damit sind wir schon bei einem doch nicht ganz unwichtigen Punkt, den wir unbedingt besprechen sollten, der sich sehr stark auf das weitere vorgehen des Kassenbuches niderschlägt.
Mir geht es um die Größe des Bildschirms und was für eine Auflösung Du da fährst. Bitte nenne diese Daten.
Das ist nämlich ein Punkt der mir in deiner bisherigen Beispieldatei nicht so sonderlich gefällt, weil nämlich die Dialoge sehr klein geraten sind. Ich könnte es ja noch verstehen wenn der angeschlossene Bildschirm Hochkant stehen würde und dadurch die Dialoge dann in ein anderes Licht "gerückt werden". Sollte das aber nicht der Fall sein, das mit Hochkant, dann hätten wir eine ganz andere Gestaltungsmöglichkeit der Dialoge.
Und außerdem sollten diese Punkte (Monitor Auflösung, Hoch- oder Querkant) dann auch noch in die "Hardware" Beschreibung mit einfließen. Aber immer eins nach dem anderen, jetzt gehts erstmal um Größe und Auflösung.
Auf ein gutes gelingen.
![Smile :-)](./images/smilies/icon_smile.gif)
Gruß
balu
Sei öfter mal ein Faultier, sag öfter mal "Ach was!" Dann kriegst du keinen Herzinfarkt, und hast ne menge Spass.
wehr rächtschraipfähler findet khan si behalden![Very Happy :D](./images/smilies/icon_biggrin.gif)
wehr rächtschraipfähler findet khan si behalden
![Very Happy :D](./images/smilies/icon_biggrin.gif)
Re: Erarbeitung eines "POS-Kassenbuchs"
Hallo balu,
![Cool 8)](./images/smilies/icon_cool.gif)
Dann gehe ich jetzt mal näher darauf ein - das wollte ich nämlich eh noch machen.
Nachdem unser Shuttle-PC vor kurzem das Zeitliche gesegnet hatte, habe ich nach einer preisgünstigen Alternative gesucht. Es musste ein kleiner Rechner sein, weil wir nicht viel Platz haben. So bin ich auf den Raspberry gestoßen. Davon hatte ich zuvor nichts gehört. Aber es hat mich doch ziemlich in den Fingern gejuckt, den auszuprobieren. Das war wahrscheinlich ähnlich wie bei dir.
Auf jeden Fall läuft auf dem Raspberry 3 Modell B Libre Office mit allen Funktionen, die sonst auch zur Verfügung stehen.
Man kann einwandfrei Musik über den Klinkenausgang abspielen.
Speichervorgänge und das Laden von Ordner- und Festplatteninhalten dauern etwas länger, als auf einem "richtigen" PC.
Zurzeit schicken wir unsere Tabellen immer noch mit W-Lan per E-Mail an unser Büro zum Ausdruck. D.h. W-Lan funktioniert super, nur kann ich nicht sagen, ob ein Drucker direkt angeschlossen auch funktioniert. Ich hoffe doch, weil das nämlich geplant ist.
Unser "Kleiner" ist bei den Bildschirmen weit rumgekommen - er hatte schon 6 und es gab mit keinem einzigen Probleme. Ich finde, das spricht für sich.
Filme (avi, mp4) abspielen von Festplatte geht überhaupt nicht gut. Aber es kann sein, dass man da einfach etwas einstellen muss, was wir nicht ausprobiert haben. Für uns ist das nicht wichtig, deshalb habe ich das nicht weiter verfolgt. Online-Filme sind kein Problem, soweit keine Plugins wie z.B. FlashPlayer benötigt werden.
Gleichzeitig den Fotoordner durchstöbern und Musik laufen lassen packt er nicht.
Externe Festplatten laufen sogar ohne eigene Stromversorgung (ich hatte gelesen, dass dies nicht möglich sei - stimmt aber nicht). Hierbei ist allerdings zu beachten, dass man am besten den originalen Netzwerkadapter von RaspPi für den Raspberry verwendet, ansonsten kann es sein, dass das ganze System schwächelt. Wir haben erst einen anderen ausprobiert und das war überhaupt nicht gut.
Ich würde auch nicht bei der SD-Karte sparen, auf der dann das Betriebssystem installiert wird. Da kann ich nicht die aus dem RaspPiShop empfehlen, auch wenn sie von Samsung ist und Class10 hat. Ich weiß jetzt grad nicht, welche wir stattdessen haben - aber der Fotohändler um die Ecke kann bestimmt sagen, was gerade High End ist insbesondere bezüglich Geschwindigkeit. Die würde ich dann nehmen. Es reichen 16GB Speicher, wenn Ubuntu Mate drauf ist. Dann kann man solche Tabellen wie mein Kassenbuch auch noch darauf speichern.
Zum Betriebssystem:
Gefühlt würde ich sagen, dass raspbian als Betriebssystem etwas schneller ist, weil schlanker. Das habe ich nämlich zuerst ausprobiert.
Aber das ist keine gute Idee, wenn daran Minijobber arbeiten müssen, die Windows 10 gewohnt sind.
Ubuntu Mate ist dann doch viel benutzerfreundlicher und - wenn überhaupt - nur marginal langsamer.
Das ist soweit glaube ich alles, was ich bislang dazu sagen kann.
Da ich mir ja immer alles selbst beibringe, wusste ich überhaupt nicht, dass die unterschiedliche Darstellung der Dialoge etwas mit der Bildschirmauflösung zu tun hat. Hätte ich mir ja denken können...
Ich kann schonmal sagen, dass unser Bildschirm nicht hochkant steht und alles normal aussieht.
Ich muss aber erstmal nachprüfen, wie da die Einstellungen sind und was für einen Bildschirm wir da überhaupt haben. Das schicke ich dann, wenn ich die Fotos hochlade, wie Stephan angefragt hatte.
Erstmal - ich meld mich nach meinen Hausaufgaben.![Very Happy :-D](./images/smilies/icon_biggrin.gif)
LG Julia
Huch, also das wusste ich gar nicht.Bin doch erstaunt: Raspberry Pi 3 & LO!
... In dieser hinsicht hast Du so gesehen Pioniersarbeit geleistet. Klasse.![]()
![Cool 8)](./images/smilies/icon_cool.gif)
Dann gehe ich jetzt mal näher darauf ein - das wollte ich nämlich eh noch machen.
Nachdem unser Shuttle-PC vor kurzem das Zeitliche gesegnet hatte, habe ich nach einer preisgünstigen Alternative gesucht. Es musste ein kleiner Rechner sein, weil wir nicht viel Platz haben. So bin ich auf den Raspberry gestoßen. Davon hatte ich zuvor nichts gehört. Aber es hat mich doch ziemlich in den Fingern gejuckt, den auszuprobieren. Das war wahrscheinlich ähnlich wie bei dir.
Auf jeden Fall läuft auf dem Raspberry 3 Modell B Libre Office mit allen Funktionen, die sonst auch zur Verfügung stehen.
Man kann einwandfrei Musik über den Klinkenausgang abspielen.
Speichervorgänge und das Laden von Ordner- und Festplatteninhalten dauern etwas länger, als auf einem "richtigen" PC.
Zurzeit schicken wir unsere Tabellen immer noch mit W-Lan per E-Mail an unser Büro zum Ausdruck. D.h. W-Lan funktioniert super, nur kann ich nicht sagen, ob ein Drucker direkt angeschlossen auch funktioniert. Ich hoffe doch, weil das nämlich geplant ist.
Unser "Kleiner" ist bei den Bildschirmen weit rumgekommen - er hatte schon 6 und es gab mit keinem einzigen Probleme. Ich finde, das spricht für sich.
Filme (avi, mp4) abspielen von Festplatte geht überhaupt nicht gut. Aber es kann sein, dass man da einfach etwas einstellen muss, was wir nicht ausprobiert haben. Für uns ist das nicht wichtig, deshalb habe ich das nicht weiter verfolgt. Online-Filme sind kein Problem, soweit keine Plugins wie z.B. FlashPlayer benötigt werden.
Gleichzeitig den Fotoordner durchstöbern und Musik laufen lassen packt er nicht.
Externe Festplatten laufen sogar ohne eigene Stromversorgung (ich hatte gelesen, dass dies nicht möglich sei - stimmt aber nicht). Hierbei ist allerdings zu beachten, dass man am besten den originalen Netzwerkadapter von RaspPi für den Raspberry verwendet, ansonsten kann es sein, dass das ganze System schwächelt. Wir haben erst einen anderen ausprobiert und das war überhaupt nicht gut.
Ich würde auch nicht bei der SD-Karte sparen, auf der dann das Betriebssystem installiert wird. Da kann ich nicht die aus dem RaspPiShop empfehlen, auch wenn sie von Samsung ist und Class10 hat. Ich weiß jetzt grad nicht, welche wir stattdessen haben - aber der Fotohändler um die Ecke kann bestimmt sagen, was gerade High End ist insbesondere bezüglich Geschwindigkeit. Die würde ich dann nehmen. Es reichen 16GB Speicher, wenn Ubuntu Mate drauf ist. Dann kann man solche Tabellen wie mein Kassenbuch auch noch darauf speichern.
Zum Betriebssystem:
Gefühlt würde ich sagen, dass raspbian als Betriebssystem etwas schneller ist, weil schlanker. Das habe ich nämlich zuerst ausprobiert.
Aber das ist keine gute Idee, wenn daran Minijobber arbeiten müssen, die Windows 10 gewohnt sind.
Ubuntu Mate ist dann doch viel benutzerfreundlicher und - wenn überhaupt - nur marginal langsamer.
Das ist soweit glaube ich alles, was ich bislang dazu sagen kann.
Da ich mir ja immer alles selbst beibringe, wusste ich überhaupt nicht, dass die unterschiedliche Darstellung der Dialoge etwas mit der Bildschirmauflösung zu tun hat. Hätte ich mir ja denken können...
Ich kann schonmal sagen, dass unser Bildschirm nicht hochkant steht und alles normal aussieht.
Ich muss aber erstmal nachprüfen, wie da die Einstellungen sind und was für einen Bildschirm wir da überhaupt haben. Das schicke ich dann, wenn ich die Fotos hochlade, wie Stephan angefragt hatte.
Erstmal - ich meld mich nach meinen Hausaufgaben.
![Very Happy :-D](./images/smilies/icon_biggrin.gif)
LG Julia
Wilhelm Busch: "Ein jeder Wunsch, wenn er erfüllt, kriegt augenblicklich Junge."
... ich glaub, der wär heutzutage Programmierer und nicht Schriftsteller.
... ich glaub, der wär heutzutage Programmierer und nicht Schriftsteller.
Re: Erarbeitung eines "POS-Kassenbuchs"
Hallo schon wieder,
hier kommen Fotos und Screenshots wie versprochen.
Und so sieht der Dialog bei uns aus. Das ist eine ältere Version, aber die neueste läuft auch.
LG Julia
hier kommen Fotos und Screenshots wie versprochen.
Und so sieht der Dialog bei uns aus. Das ist eine ältere Version, aber die neueste läuft auch.
LG Julia
Wilhelm Busch: "Ein jeder Wunsch, wenn er erfüllt, kriegt augenblicklich Junge."
... ich glaub, der wär heutzutage Programmierer und nicht Schriftsteller.
... ich glaub, der wär heutzutage Programmierer und nicht Schriftsteller.
Re: Erarbeitung eines "POS-Kassenbuchs"
Hallo Julia,
also wirklich, ganz ehrlich, was Du hier jetzt so alles an Infos abgeliefert hast, ist schon sehr beeindruckend. Dafür hast Du schon mal meinen Räschbäckt![Smile :-)](./images/smilies/icon_smile.gif)
Es sei schon mal so viel gesagt, Unterschiedliche Betriebssysteme stellen die Dialoge anders in der Größe dar. Aber wie gesagt, das tut jetzt noch nicht so sehr not.
Ein "Taschenmonitor" ist ja so ungefähr nur 5" (5 Zoll) groß, welcher ja auch z.B. in Autos in Kopfstützen eingebaut wird. Und da ist die darzustellende Schrift ja schon verhältnismäßg klein.
Und ein "normal" großer Monitor ist da ja schon ein anderes Kaliber, was da Schrift und dergleichen anbelangt.
Also das mit den Fotos versteh ich jetzt nicht. Ich dachte Du arbeitest an einer Bar, wo Getränke ausgeschenkt werden, und nicht an einer Salatbar (Kabelsalat).![Laughing :lol:](./images/smilies/icon_lol.gif)
Das Bild von LO mit dem Dialog ist natürlich auch interessant. Da ich dort unter anderem sehe das wohl anscheind die Schrift Arial existiert. Auch das ist ein Punkt der in die Kategorie "Gut zu wissen" gehört.
Heute nicht mehr, aber ich denke mir ab morgen werden wir uns um das naheliegendste Thema "Makro" kümmern, Dialog folgt anschließend.
Gruß
balu
also wirklich, ganz ehrlich, was Du hier jetzt so alles an Infos abgeliefert hast, ist schon sehr beeindruckend. Dafür hast Du schon mal meinen Räschbäckt
![Smile :-)](./images/smilies/icon_smile.gif)
Nun, ganz so einfach ist das nun wiederum auch nicht wie Du denkst. Das ist nämlich ein eigenes Thema für sich selbst, welches im moment noch nicht so tragisch für dich ist. Wir werden uns jetzt erstmal nur auf deine Situation und deine "Arbeitsumgebung" konzentrieren. Damit meine ich, dein Ubuntu und dein LO. Obwohl ich (wir) irgendwann mal zwischendurch auf dies Thema schon eingehen werden.Da ich mir ja immer alles selbst beibringe, wusste ich überhaupt nicht, dass die unterschiedliche Darstellung der Dialoge etwas mit der Bildschirmauflösung zu tun hat. Hätte ich mir ja denken können...
Es sei schon mal so viel gesagt, Unterschiedliche Betriebssysteme stellen die Dialoge anders in der Größe dar. Aber wie gesagt, das tut jetzt noch nicht so sehr not.
Da fällt mir echt ein ganz dicker Stein vom Herzen. *puuuh-glück-gehabt*Ich kann schonmal sagen, dass unser Bildschirm nicht hochkant steht und alles normal aussieht.
Meine Anfrage der Bildschirmgröße bezog sich mehr auf; "Taschenmonitor" (also so groß wie ne Hosentasche), oder schon einer der aufm Schreibtisch sich gut macht.Ich muss aber erstmal nachprüfen, wie da die Einstellungen sind und was für einen Bildschirm wir da überhaupt haben.
Ein "Taschenmonitor" ist ja so ungefähr nur 5" (5 Zoll) groß, welcher ja auch z.B. in Autos in Kopfstützen eingebaut wird. Und da ist die darzustellende Schrift ja schon verhältnismäßg klein.
Und ein "normal" großer Monitor ist da ja schon ein anderes Kaliber, was da Schrift und dergleichen anbelangt.
Also das mit den Fotos versteh ich jetzt nicht. Ich dachte Du arbeitest an einer Bar, wo Getränke ausgeschenkt werden, und nicht an einer Salatbar (Kabelsalat).
![Laughing :lol:](./images/smilies/icon_lol.gif)
Das Bild von LO mit dem Dialog ist natürlich auch interessant. Da ich dort unter anderem sehe das wohl anscheind die Schrift Arial existiert. Auch das ist ein Punkt der in die Kategorie "Gut zu wissen" gehört.
Heute nicht mehr, aber ich denke mir ab morgen werden wir uns um das naheliegendste Thema "Makro" kümmern, Dialog folgt anschließend.
Gruß
balu
Sei öfter mal ein Faultier, sag öfter mal "Ach was!" Dann kriegst du keinen Herzinfarkt, und hast ne menge Spass.
wehr rächtschraipfähler findet khan si behalden![Very Happy :D](./images/smilies/icon_biggrin.gif)
wehr rächtschraipfähler findet khan si behalden
![Very Happy :D](./images/smilies/icon_biggrin.gif)
Re: Erarbeitung eines "POS-Kassenbuchs"
Das Dein Dialog hochkant ist finde ich nicht störend, allgemein ist das aber mit der Darstellung von Dialogen etwas schwierig denn es geht nicht nur um die Größe sondern auch das Seitenverhältnis ändert sich, abhängig vom konkreten Rechner ggf. denn die Darstellung von Dialogen in OO/LO richtet sich nach dem jeweiligen sog., Systemfont und dessen Eigenschaften.Da ich mir ja immer alles selbst beibringe, wusste ich überhaupt nicht, dass die unterschiedliche Darstellung der Dialoge etwas mit der Bildschirmauflösung zu tun hat. Hätte ich mir ja denken können...
Details erspare ich mir, zum Einem weil ich mich da auch nur 90% auskenne und weil es zweitens ein praktisch undurchführbares Unternehmen ist bei OO/LO Dialoge so zu programmieren das sie quasi systemneutral funktionieren würden, sondern in Praxis kann man höchstens 'mit Augenmaß' die Dialoge so machen das sie mutmaßlich universell funktionieren werden, d.h. zum Beispiel das man Schaltflächen vermeiden sollte deren Beschriftung gerade noch so passt sondern darauf achten sollte das genügend Platz ist.
Best Practice ist somit immer für ein vorgegebenes konkretes System zu programmieren, wenn die genau richtige Darstellung wirklich wichtig ist. "genau richtige Darstellung" trifft hier auch den Kern, denn es geht natürlich nur um Feinheiten und nicht darum das die Dialoge im Normalfall bei verschiedenen Systemen völlig anders aussähen.
Das ist wohlgemerkt Praxiserfahrung und die diesbezügliche Einsicht vieler (aufwendiger) Versuche diese Probleme programmiertechnisch zuverlässig zu lösen. Ich lasse mich gerne vom Gegenteil überzeugen zumal eine wirklich universelle Lösung von hoher Praxisrelevanz wäre.
Jenseits des gerade Gesagten, wäre meine Anregung aber doch darüber nachzudenken, das gesamte Programm/Makro über einen Dialog zu steuern und das Tabellenblatt auszublenden, weil ich vermuten würde das es in der normalen Hektik des Geschäfts doch darauf ankommt große, eindeutige Schaltflächen zu haben, wo man sich möglichst nicht 'verklicken' kann.
Wahrscheinlich wäre hier für das konkrete Projekt auch ein Touchscreen optimal, ich weiß aber nichts über Touchscreenbenutzung in OO/LO-Makros bzw. auch generell nichts über Touchscreen-Programmierung.
GRuß
Stephan
Re: Erarbeitung eines "POS-Kassenbuchs"
Hallo Stephan,
a) Unsere Gäste bewegen sich zwar so frei wie in einer Disco, bezahlen aber nicht direkt wie in einer Disco
b) Unsere Gäste sitzen zwar wie in einem Restaurant an Tischen, diese verlassen sie aber andauernd, um sich woanders dazu setzen ("andauernd" ist nicht übertrieben - das Umbuchen der Tische bzw. einzelner Getränke von Tischen ist unmöglich zu leisten)
c) Eine Nummernvergabe pro Gast/Gruppe kann schon mal die Zahl 50 überschreiten. Wir haben in diesem Zusammenhang gescherzt, dass wir bei Einführung einer solchen Kasse ab sofort jedem seine Nummer auf die Stirn schreiben...
Also läuft es so wie früher:
Da die Getränke wegen der Problematik eh nicht direkt in die Kasse eingetragen werden können, werden die Namen auf Zettel geschrieben und die Getränke mit Nr. notiert.
Wenn dann jemand bezahlt, wird abkassiert, alle seine Getränke werden in das Calc-Dokument eingetragen und auf dem Zettel wird vermerkt, dass das erledigt ist. Ist keine Zeit für die Übertragung, wird das zu einem späteren Zeitpunkt gemacht.
Somit ist es gar nicht so hektisch, wie du es dir vorstellst.
Liebe Grüße Julia
PS: Wer also Lust hat: Die passende Kassen-Software für nicht ganz kleine Kneipen mit starker sozialer Komponente wurde meines Wissens noch nicht erfunden! Bei uns gibt es eine ähnlich geartete Kneipe mit 3.000 €-Kassensystem, und die machen es genau wie wir, weil es offenbar bislang nicht anders geht. (Übrigens ist das einer der Hauptgründe, weshalb es dieses Projekt jetzt gibt. Es ist halt nicht einzusehen, wieso man so viel Geld für ein System ausgeben soll, das überhaupt nicht praktikabel ist.)
Hhm, darauf bin ich tatsächlich noch nicht gekomen. Aber ich glaube, wir brauchen keinen Touchscreen. Dazu muss man etwas über die Arbeitsweise bzw. zu einer grundlegenden Problematik im Kneipengeschäft wissen. Verkürzt kann man sagen, dass es kein praktikables System für Kneipen unserer Größe gibt, weil in diesen Systemen die Gäste entweder direkt bezahlen (a) oder auf einen Tisch (b) oder eine Nummer gebucht (c) werden:Jenseits des gerade Gesagten, wäre meine Anregung aber doch darüber nachzudenken, das gesamte Programm/Makro über einen Dialog zu steuern und das Tabellenblatt auszublenden, weil ich vermuten würde das es in der normalen Hektik des Geschäfts doch darauf ankommt große, eindeutige Schaltflächen zu haben, wo man sich möglichst nicht 'verklicken' kann.
Wahrscheinlich wäre hier für das konkrete Projekt auch ein Touchscreen optimal,...
a) Unsere Gäste bewegen sich zwar so frei wie in einer Disco, bezahlen aber nicht direkt wie in einer Disco
b) Unsere Gäste sitzen zwar wie in einem Restaurant an Tischen, diese verlassen sie aber andauernd, um sich woanders dazu setzen ("andauernd" ist nicht übertrieben - das Umbuchen der Tische bzw. einzelner Getränke von Tischen ist unmöglich zu leisten)
c) Eine Nummernvergabe pro Gast/Gruppe kann schon mal die Zahl 50 überschreiten. Wir haben in diesem Zusammenhang gescherzt, dass wir bei Einführung einer solchen Kasse ab sofort jedem seine Nummer auf die Stirn schreiben...
Also läuft es so wie früher:
Da die Getränke wegen der Problematik eh nicht direkt in die Kasse eingetragen werden können, werden die Namen auf Zettel geschrieben und die Getränke mit Nr. notiert.
Wenn dann jemand bezahlt, wird abkassiert, alle seine Getränke werden in das Calc-Dokument eingetragen und auf dem Zettel wird vermerkt, dass das erledigt ist. Ist keine Zeit für die Übertragung, wird das zu einem späteren Zeitpunkt gemacht.
Somit ist es gar nicht so hektisch, wie du es dir vorstellst.
Liebe Grüße Julia
PS: Wer also Lust hat: Die passende Kassen-Software für nicht ganz kleine Kneipen mit starker sozialer Komponente wurde meines Wissens noch nicht erfunden! Bei uns gibt es eine ähnlich geartete Kneipe mit 3.000 €-Kassensystem, und die machen es genau wie wir, weil es offenbar bislang nicht anders geht. (Übrigens ist das einer der Hauptgründe, weshalb es dieses Projekt jetzt gibt. Es ist halt nicht einzusehen, wieso man so viel Geld für ein System ausgeben soll, das überhaupt nicht praktikabel ist.)
Zuletzt geändert von Julia NuN am Di, 13.12.2016 16:55, insgesamt 1-mal geändert.
Wilhelm Busch: "Ein jeder Wunsch, wenn er erfüllt, kriegt augenblicklich Junge."
... ich glaub, der wär heutzutage Programmierer und nicht Schriftsteller.
... ich glaub, der wär heutzutage Programmierer und nicht Schriftsteller.
Re: Erarbeitung eines "POS-Kassenbuchs"
Also mein (vielleicht naiver) Gedanke war eher das eine Maus in eine Kneipe schon deshalb ungünstig wäre weil man teils nasse oder fettige Hände hat. (z.B. weiß ich aus Praxiserfahrung bei einigen Kunden das eine 'normale' Laptop-Tastatur in einer Kfz-Werkstatt eher ein Problem ist, weil die häufig so verschmutzt das sie nicht mehr richtig geht - wohlgemerkt in der Werkstatt nicht im Büro)Hhm, darauf bin ich tatsächlich noch nicht gekomen. Aber ich glaube, wir brauchen keinen Touchscreen. Dazu muss man etwas über die Arbeitsweise bzw. zu einer grundlegenden Problematik im Kneipengeschäft wissen. Verkürzt kann man sagen, dass es kein praktikables System für Kneipen unserer Größe gibt, weil in diesen Systemen die Gäste entweder direkt bezahlen (a) oder auf einen Tisch (b) oder eine Nummer gebucht (c) werden:
a) Unsere Gäste bewegen sich zwar so frei wie in einer Disco, bezahlen aber nicht direkt wie in einer Disco
b) Unsere Gäste sitzen zwar wie in einem Restaurant an Tischen, diese verlassen sie aber andauernd, um sich woanders dazu setzen ("andauernd" ist nicht übertrieben - das Umbuchen der Tische bzw. einzelner Getränke von Tischen ist unmöglich zu leisten)
c) Eine Nummernvergabe pro Gast/Gruppe kann schon mal die Zahl 50 überschreiten. Wir haben in diesem Zusammenhang gescherzt, dass wir bei Einführung einer solchen Kasse ab sofort jedem seine Nummer auf die Stirn schreiben...
Also läuft es so wie früher:
Da die Getränke wegen der Problematik eh nicht direkt in die Kasse eingetragen werden können, werden die Namen auf Zettel geschrieben und die Getränke mit Nr. notiert.
Wenn dann jemand bezahlt, wird abkassiert, alle seine Getränke werden in das Calc-Dokument eingetragen und auf dem Zettel wird vermerkt, dass das erledigt ist. Ist keine Zeit für die Übertragung, wird das zu einem späteren Zeitpunkt gemacht.
Somit ist es gar nicht so hektisch, wie du es dir vorstellst.
das die Kosten ein Problem sind, hatte ich schon in Deinem ersten Post aufgeschnappt und es war durchaus ein Grund über Deine Datei nachzudenken, denn ich verdiene mein Geld beruflich mit solcherlei OO/LO-Programmierung. Einzig kenne ich mich natürlich mit dem Bereich Kassensysteme überhaupt nicht aus.PS: Wer also Lust hat: Die passende Kassen-Software für nicht ganz kleine Kneipen mit starker sozialer Komponente wurde meines Wissens noch nicht erfunden! Bei uns gibt es eine ähnlich geartete Kneipe mit 3.000 €-Kassensystem, und die machen es genau wie wir, weil es offenbar bislang nicht anders geht.
Gruß
Stephan
Re: Erarbeitung eines "POS-Kassenbuchs"
Hallo,
bevor wir überhaupt so richtig loslegen, muss ein extrem wichtiger Punkt abgehandelt und besprochen werden, der sich dann auch schon direkt im Makro widerspiegelt. Alles andere ist erstmal uninteressant.
Die fertige Datei ist ja wohl nicht für den privaten Hausgebrauch vorgesehen, sondern sie ist wohl ein Teil einer gesetzlichen Vorgabe die z.B. das Finanzamt interessiert. Sorry das ich jetzt nicht weiß wie ich es genauer ausdrücken soll.
Julia hat ja schon gleich zu Anfang etwas mittgeteit, was jetzt genauer besprochen werden muss.
a)
Wie handhabt ihr das bei Preisänderungen, egal ob Erhöhung oder Reduzierung? Wird dann die aktuelle Datei unter einem anderen Namen mit einem bestimmten Vermerk gespeichert und "weggeschlossen"?
b)
Wie sieht das Erfahrungsgemäß aus, wann können Preisänderungen stattfinden beziehungsweise wann werden sie vollzogen; irgendwann im laufenden Monat oder zum Monatswechsel?
c)
Auch ohne Preisänderung, wie wird mit der Datei umgegangen wenn ein Monat zu Ende ist, irgendwo seperat speichern "wegschließen", oder was genau?
Punkt a) und b) machen sich direkt im Makro bemerkbar da dann einiges umgeschrieben werden muss. Stichwort dazu ist: SVERWEIS.
Bin auf die Antworten gespannt![Smile :)](./images/smilies/icon_smile.gif)
Gruß
balu
bevor wir überhaupt so richtig loslegen, muss ein extrem wichtiger Punkt abgehandelt und besprochen werden, der sich dann auch schon direkt im Makro widerspiegelt. Alles andere ist erstmal uninteressant.
Die fertige Datei ist ja wohl nicht für den privaten Hausgebrauch vorgesehen, sondern sie ist wohl ein Teil einer gesetzlichen Vorgabe die z.B. das Finanzamt interessiert. Sorry das ich jetzt nicht weiß wie ich es genauer ausdrücken soll.
Julia hat ja schon gleich zu Anfang etwas mittgeteit, was jetzt genauer besprochen werden muss.
Meine Fragen dazu lauten wie folgt:JuliaNN hat geschrieben: ... zur nachvollziehbaren Einzelauflistung der verkauften Produkte.
a)
Wie handhabt ihr das bei Preisänderungen, egal ob Erhöhung oder Reduzierung? Wird dann die aktuelle Datei unter einem anderen Namen mit einem bestimmten Vermerk gespeichert und "weggeschlossen"?
b)
Wie sieht das Erfahrungsgemäß aus, wann können Preisänderungen stattfinden beziehungsweise wann werden sie vollzogen; irgendwann im laufenden Monat oder zum Monatswechsel?
c)
Auch ohne Preisänderung, wie wird mit der Datei umgegangen wenn ein Monat zu Ende ist, irgendwo seperat speichern "wegschließen", oder was genau?
Punkt a) und b) machen sich direkt im Makro bemerkbar da dann einiges umgeschrieben werden muss. Stichwort dazu ist: SVERWEIS.
Bin auf die Antworten gespannt
![Smile :)](./images/smilies/icon_smile.gif)
Gruß
balu
Sei öfter mal ein Faultier, sag öfter mal "Ach was!" Dann kriegst du keinen Herzinfarkt, und hast ne menge Spass.
wehr rächtschraipfähler findet khan si behalden![Very Happy :D](./images/smilies/icon_biggrin.gif)
wehr rächtschraipfähler findet khan si behalden
![Very Happy :D](./images/smilies/icon_biggrin.gif)
Re: Erarbeitung eines "POS-Kassenbuchs"
Hey Stephan,
LG Julia
Im Grunde sind für uns noch nicht einmal die Kosten das größte Problem, sondern eher das, was ich grad noch ergänzt habe:das die Kosten ein Problem sind, hatte ich schon in Deinem ersten Post aufgeschnappt und es war durchaus ein Grund über Deine Datei nachzudenken, denn ich verdiene mein Geld beruflich mit solcherlei OO/LO-Programmierung. Einzig kenne ich mich natürlich mit dem Bereich Kassensysteme überhaupt nicht aus.
Ich berate dich gerne, wenn du dich da ransetzen möchtest. Die einzige Möglichkeit ist glaube ich mit einer Namensvergabe für Kunden zu arbeiten, die supereasy von dem Kassensystem angenommen wird. So etwas gibt es zwar schon - aber nicht in supereasy. Das müsste halt so schnell gehen, wie wenn man den Namen auf einen Zettel schreibt.Es ist halt nicht einzusehen, wieso man so viel Geld für ein System ausgeben soll, das überhaupt nicht praktikabel ist.
LG Julia
Wilhelm Busch: "Ein jeder Wunsch, wenn er erfüllt, kriegt augenblicklich Junge."
... ich glaub, der wär heutzutage Programmierer und nicht Schriftsteller.
... ich glaub, der wär heutzutage Programmierer und nicht Schriftsteller.
Re: Erarbeitung eines "POS-Kassenbuchs"
Ich berate dich gerne, wenn du dich da ransetzen möchtest.
Also so konkret war meine 'Ansage' nicht, zumal das ja auch ein finanzielles Risiko für mich ist, wenn ich jetzt anfinge eine Art Kassensystem zu programmieren.
Frage:Die einzige Möglichkeit ist glaube ich mit einer Namensvergabe für Kunden zu arbeiten, die supereasy von dem Kassensystem angenommen wird. So etwas gibt es zwar schon - aber nicht in supereasy. Das müsste halt so schnell gehen, wie wenn man den Namen auf einen Zettel schreibt.
wenn ihr heutzutage den/die Zettel führt, wie beschrieben, ist das doch aber auch Kopfkoordination, d,h. ihr müsst wissen welcher Kunde zu welchem Zettel gehört? Vielleicht macht ihr auf jeden Zettel ein Zeichen, das ihr gedanklich mit dem Kunden verbindet oder schreibt dort einen Phantasienamen hin?
Wenn das so wäre verstehe ich nicht welches Problem die Umsetzung in Software macht. Ich würde das z.B. so machen das ich auf einen Dialog mehrere Textfelder/Rechtecke lege und Bedienung wie folgt:
-klick auf ein noch unbeschriftetes Rechteck --> Eingabedialog übernimmt Eingabe als Name bzw. 'Markierung'
-klick auf ein Rechteck mit Namen -->Eingabedialog wertet Eingabe als Produkt
Alles was ich als Problem sehe ist das man schauen müsste was in Praxis ergonomisch ist, z.B. könnte man die 'Namenseigabe' beschleunigen wenn man garkeine Namen hat sondern jeder Bediener sich 20 Symbole merkt und diese immer wieder neu zuordnet, wenn die Kunden wechseln.
Ebenso wäre eine optimal schnelle Produkteingabe wohl am besten als 'Mischmasch' zwischen Auswahl und manueller Eingabe zu lösen, zum Einen Per Listenfeld oder Combobox, zum Anderen wohl auch mittels Dialog der Bilder der häufigsten Produkte zum direkten Draufklicken hat.
Du musst bei solchen Ergonomiefragen auch immer das Gesamtergebnis sehen, z.B. könntest Du sagen 'nee Symbole lerne ich nicht' anderseits liegt in solchen Dingen dann eine Einsparung wenn Du gleiche Bedienschritte immer wieder brauchst. Ebenso kommt der Kostenaspekt hinzu, denn für eine Computerlösung musst Du Mitarbeiter immer zumindest ein bisschen anlernen.
aber ich denke nur laut nach ... ich hatte beruflich noch nie mit der Gastronomiebranche zu tun.
Gruß
Stephan
Re: Erarbeitung eines "POS-Kassenbuchs"
Hallo balu,
ich schieb mal was vorneweg. Ich hatte ja ganz zu Anfang etwas von GDPdU-konform geschrieben und dass das unseren Betrieb jetzt doch nicht betrifft.
Was das ganz genau im Einzelnen bedeutet, würde hier den Rahmen sprengen (hab ich eh nicht alles verstanden).
Jedoch sind da 2 Punkte, die vielleicht deine Fragen beantworten. Diese Dinge müssen wir jetzt also doch nicht:
1. Eine nicht manipulierbare Software betreiben.
2. Eine Software betreiben, die in ihrer Struktur so aufgebaut ist, dass alle Daten direkt ins Finanzamt eingespeist werden können (ich glaub Schnittstelle ist für euch Profis das richtige Wort).
Die Dateien bewahren wir zwar auf - sie werden nicht monatlich überschrieben, wenn du das meinst -, aber "weggeschlossen" werden sie nicht. --> Du meinst, ob die Daten irgendwie digital unmanipulierbar gemacht werden? Nee, nur durch den täglichen Ausdruck mit Datum und Unterschrift.
Soweit ich weiß, genügt es dem Finanzamt, wenn es eine schlüssige Einzelauflistung hat. Das ist dann dieser Ausdruck mit Unterschrift, der als Beleg aufbewahrt wird zusammen mit den Zetteln für den Fall einer Prüfung.
Im Zweifelsfall können sie aber natürlich Einsicht in die Digitalen Daten verlangen.
In unserer Buchhaltungssoftware werden nur die Tagesumsätze ausgewiesen und gehen dann als Monatsumsatz ans Finanzamt.
Praktisch, nä?
Es gibt eine Datei mit allen Preislisten, und in ausgedruckter Form sind sie auch abgeheftet.
Die aktuelle besteht seit 2015, im Dokument, Sheet "Preise", D2, vermerkt.
Ich bin jetzt nicht ganz sicher, ob ich damit alle deine Fragen beantwortet habe.
Ansonsten müsstest du nochmal nachhaken.
LG Julia
ich schieb mal was vorneweg. Ich hatte ja ganz zu Anfang etwas von GDPdU-konform geschrieben und dass das unseren Betrieb jetzt doch nicht betrifft.
Was das ganz genau im Einzelnen bedeutet, würde hier den Rahmen sprengen (hab ich eh nicht alles verstanden).
Jedoch sind da 2 Punkte, die vielleicht deine Fragen beantworten. Diese Dinge müssen wir jetzt also doch nicht:
1. Eine nicht manipulierbare Software betreiben.
2. Eine Software betreiben, die in ihrer Struktur so aufgebaut ist, dass alle Daten direkt ins Finanzamt eingespeist werden können (ich glaub Schnittstelle ist für euch Profis das richtige Wort).
Die Dateien bewahren wir zwar auf - sie werden nicht monatlich überschrieben, wenn du das meinst -, aber "weggeschlossen" werden sie nicht. --> Du meinst, ob die Daten irgendwie digital unmanipulierbar gemacht werden? Nee, nur durch den täglichen Ausdruck mit Datum und Unterschrift.
Soweit ich weiß, genügt es dem Finanzamt, wenn es eine schlüssige Einzelauflistung hat. Das ist dann dieser Ausdruck mit Unterschrift, der als Beleg aufbewahrt wird zusammen mit den Zetteln für den Fall einer Prüfung.
Im Zweifelsfall können sie aber natürlich Einsicht in die Digitalen Daten verlangen.
In unserer Buchhaltungssoftware werden nur die Tagesumsätze ausgewiesen und gehen dann als Monatsumsatz ans Finanzamt.
Wir haben uns darauf geeinigt, dass wir der Einfachheit halber nur Preisänderungen vornehmen, wenn ein neues Kalenderjahr beginnt. Also 01.01.b)
Wie sieht das Erfahrungsgemäß aus, wann können Preisänderungen stattfinden beziehungsweise wann werden sie vollzogen; irgendwann im laufenden Monat oder zum Monatswechsel?
Praktisch, nä?
Es gibt eine Datei mit allen Preislisten, und in ausgedruckter Form sind sie auch abgeheftet.
Die aktuelle besteht seit 2015, im Dokument, Sheet "Preise", D2, vermerkt.
Ich bin jetzt nicht ganz sicher, ob ich damit alle deine Fragen beantwortet habe.
Ansonsten müsstest du nochmal nachhaken.
LG Julia
Wilhelm Busch: "Ein jeder Wunsch, wenn er erfüllt, kriegt augenblicklich Junge."
... ich glaub, der wär heutzutage Programmierer und nicht Schriftsteller.
... ich glaub, der wär heutzutage Programmierer und nicht Schriftsteller.
Re: Erarbeitung eines "POS-Kassenbuchs"
Hallo Julia,
Da Du sicherlich nicht so recht den Zusammenhang zwischen meinen Fragen und dem Stichwort SVERWEIS verstehst, will ich das jetzt mal verdeutlichen. Auch wenn es jetzt eigentlich so nicht mehr von nöten ist.
Angenommen es hätte während eines laufenden Monats Preisänderungen gegeben, was ja bedeutet das das Tabellenblatt "Preise" dementsprechend geändert wird, so würden dann alle schon getätigten Buchungen in den einzelnen Tagen zuvor durch die geänderten Werte überschrieben.
So würde dann z.B. bei einer Preisänderung beim Alsterwasser von 2,20 € auf 2,50€ sich folgendes Bild ergeben.
Vor Änderung am 16.2.17:
Vom 1.2.17 bis 15.2.17
Alsterwasser 5 mal verkauft gleich 11,00€
So wurde alles verbucht und abgeheftet.
Nach Änderung am 16.2.17:
Vom 1.2.17 bis 15.2.17
Alsterwasser 5 mal verkauft gleich 12,50€
Das abgeheftete und verbuchte stimmt nicht mehr mit dem überein was in der Datei steht.
Verstehst Du jetzt worauf ich hinaus wollte?
Weil in der Datei mit SVERWEIS gearbeitet wird, schlagen sich Änderungen in der Preisliste sofort auch auf schon gemachte Buchungen in der Datei nieder.
ABER!
Da ja nur einmal im Jahr eine Preisänderung stattfinden kann/wird, ist erstmal ein Problem weniger. *na-gott-sei-dank*
.
Und ich bin beruhigt.
Gruß
balu
Das ist natürlich sehr gut.Wir haben uns darauf geeinigt, dass wir der Einfachheit halber nur Preisänderungen vornehmen, wenn ein neues Kalenderjahr beginnt. Also 01.01.
Praktisch, nä?
Da Du sicherlich nicht so recht den Zusammenhang zwischen meinen Fragen und dem Stichwort SVERWEIS verstehst, will ich das jetzt mal verdeutlichen. Auch wenn es jetzt eigentlich so nicht mehr von nöten ist.
Angenommen es hätte während eines laufenden Monats Preisänderungen gegeben, was ja bedeutet das das Tabellenblatt "Preise" dementsprechend geändert wird, so würden dann alle schon getätigten Buchungen in den einzelnen Tagen zuvor durch die geänderten Werte überschrieben.
So würde dann z.B. bei einer Preisänderung beim Alsterwasser von 2,20 € auf 2,50€ sich folgendes Bild ergeben.
Vor Änderung am 16.2.17:
Vom 1.2.17 bis 15.2.17
Alsterwasser 5 mal verkauft gleich 11,00€
So wurde alles verbucht und abgeheftet.
Nach Änderung am 16.2.17:
Vom 1.2.17 bis 15.2.17
Alsterwasser 5 mal verkauft gleich 12,50€
Das abgeheftete und verbuchte stimmt nicht mehr mit dem überein was in der Datei steht.
Verstehst Du jetzt worauf ich hinaus wollte?
Weil in der Datei mit SVERWEIS gearbeitet wird, schlagen sich Änderungen in der Preisliste sofort auch auf schon gemachte Buchungen in der Datei nieder.
Und da würde dann bei Einsicht in diese Datei eine Unstimmigkeit festgestellt werden.Im Zweifelsfall können sie aber natürlich Einsicht in die Digitalen Daten verlangen.
ABER!
Da ja nur einmal im Jahr eine Preisänderung stattfinden kann/wird, ist erstmal ein Problem weniger. *na-gott-sei-dank*
![Smile :)](./images/smilies/icon_smile.gif)
Und ich bin beruhigt.
Gruß
balu
Sei öfter mal ein Faultier, sag öfter mal "Ach was!" Dann kriegst du keinen Herzinfarkt, und hast ne menge Spass.
wehr rächtschraipfähler findet khan si behalden![Very Happy :D](./images/smilies/icon_biggrin.gif)
wehr rächtschraipfähler findet khan si behalden
![Very Happy :D](./images/smilies/icon_biggrin.gif)
Re: Erarbeitung eines "POS-Kassenbuchs"
Hallo Stephan,
![Wink ;-)](./images/smilies/icon_wink.gif)
Natürlich habe ich versucht, allen, die am Tresen arbeiten, eine solche Lösung schmackhaft zu machen. Man hat mir aber so lange verklickert, dass das nicht praktisch sei, bis ich mich hier im Forum wiedergefunden habe.
Aber es gab noch einen anderen Grund: Man zahlt immer für Features mit, die man nicht braucht, und es fehlen andere Dinge, die man gerne hätte:
Z.B. gibt es glaube ich keine Kasse, bei der man unbezahlte Getränke vor der Endabrechnung für später als unbezahlten Deckel auslagern kann. Es liegt nämlich in der Natur einer solchen Kneipe, dass die Gäste mehr trinken, als sie Geld dabei haben; das kommt täglich vor. Dann beginnt vor der Endabrechnug das Stornieren und es wird wieder ein Deckel auf einem Zettel gemacht.
Ein EC-Cash wäre eine Lösung. Auch eine Lösung wäre ein System, bei dem Kunden sich ein positives Konto durch Vorab-Einzahlung anlegen können, das gibt es.
Dies ist aber nicht das einzige Feature, was ein Kassensystem bei der schon genannten Summe haben sollte, und die beiden genannten Lösungen finden wir nicht optimal.
Letzten Endes läuft es darauf hinaus, dass wir wohl den Anspruch haben, dass unser Kassensystem explizit auf unsere Wünsche zugeschnitten sein soll und dass es das natürlich nicht gibt, außer man macht es selbst.
![Very Happy :-D](./images/smilies/icon_biggrin.gif)
LG Julia
Hehe, manchmal heißt jemand "Brille" oder "Nase" - und das ist nicht böse gemeint.Frage:
wenn ihr heutzutage den/die Zettel führt, wie beschrieben, ist das doch aber auch Kopfkoordination, d,h. ihr müsst wissen welcher Kunde zu welchem Zettel gehört? Vielleicht macht ihr auf jeden Zettel ein Zeichen, das ihr gedanklich mit dem Kunden verbindet oder schreibt dort einen Phantasienamen hin?
Das ist wahr. Jetzt muss ich mal sagen, dass ich gar nicht an dem Tresen arbeite. Ich bin natürlich Frau Büro. Ich kann mir nur dann die Nächte um die Ohren schlagen, wenn ich einen Bildschirm vor der Nase habe.Du musst bei solchen Ergonomiefragen auch immer das Gesamtergebnis sehen, z.B. könntest Du sagen 'nee Symbole lerne ich nicht' anderseits liegt in solchen Dingen dann eine Einsparung wenn Du gleiche Bedienschritte immer wieder brauchst.
![Wink ;-)](./images/smilies/icon_wink.gif)
Natürlich habe ich versucht, allen, die am Tresen arbeiten, eine solche Lösung schmackhaft zu machen. Man hat mir aber so lange verklickert, dass das nicht praktisch sei, bis ich mich hier im Forum wiedergefunden habe.
Aber es gab noch einen anderen Grund: Man zahlt immer für Features mit, die man nicht braucht, und es fehlen andere Dinge, die man gerne hätte:
Z.B. gibt es glaube ich keine Kasse, bei der man unbezahlte Getränke vor der Endabrechnung für später als unbezahlten Deckel auslagern kann. Es liegt nämlich in der Natur einer solchen Kneipe, dass die Gäste mehr trinken, als sie Geld dabei haben; das kommt täglich vor. Dann beginnt vor der Endabrechnug das Stornieren und es wird wieder ein Deckel auf einem Zettel gemacht.
Ein EC-Cash wäre eine Lösung. Auch eine Lösung wäre ein System, bei dem Kunden sich ein positives Konto durch Vorab-Einzahlung anlegen können, das gibt es.
Dies ist aber nicht das einzige Feature, was ein Kassensystem bei der schon genannten Summe haben sollte, und die beiden genannten Lösungen finden wir nicht optimal.
Letzten Endes läuft es darauf hinaus, dass wir wohl den Anspruch haben, dass unser Kassensystem explizit auf unsere Wünsche zugeschnitten sein soll und dass es das natürlich nicht gibt, außer man macht es selbst.
Das klingt ganz gut - vielleicht werde ich so etwas für unsere Deckel-Tabelle verwenden.-klick auf ein noch unbeschriftetes Rechteck --> Eingabedialog übernimmt Eingabe als Name bzw. 'Markierung'
-klick auf ein Rechteck mit Namen -->Eingabedialog wertet Eingabe als Produkt
![Very Happy :-D](./images/smilies/icon_biggrin.gif)
LG Julia
Wilhelm Busch: "Ein jeder Wunsch, wenn er erfüllt, kriegt augenblicklich Junge."
... ich glaub, der wär heutzutage Programmierer und nicht Schriftsteller.
... ich glaub, der wär heutzutage Programmierer und nicht Schriftsteller.