Hallo allerseits,
ich bin gerade dabei, OrderSprinter wieder kompatibel mit der RKSV zu machen (per Anbindung an Fiskaly Sign-At). Dabei haben sich einige Fragen ergeben, bei denen es wunderbar wäre, wenn sich jemand im Forum damit auskennen würde und mich etwas coachen könnte. Konkret dreht es sich um das DEP131 (umfangreiches Kassenjournal) und Fragen zur Behandlung von Trinkgeld.
Gruß,
Stefan
Unterstützung bei Implementation österreichische RKSV gesucht
-
- Administrator
- Beiträge: 1380
- Registriert: So 13. Sep 2015, 19:48
- Wohnort: Hamburg
- Kontaktdaten:
Unterstützung bei Implementation österreichische RKSV gesucht
Stefan Pichel
Entwickler der Kassensoftware OrderSprinter (http://www.ordersprinter.de)
Entwickler der Kassensoftware OrderSprinter (http://www.ordersprinter.de)
-
- Beiträge: 2
- Registriert: Sa 20. Apr 2024, 22:11
Re: Unterstützung bei Implementation österreichische RKSV gesucht
Sehr geehrter Herr Pichel,
Lieber Stefan,
ich gratuliere dir zu deiner beeindruckenden Arbeit mit Ordersprinter. Sehr gerne möchte ich dich unterstützen, Ordersprinter nach Österreich zu bringen und hier zu verbreiten. Dafür schlage ich vor, ein persönliches Gespräch telefonisch zu führen.
Ich habe Ordersprinter vor ein paar Wochen (wieder-) entdeckt und mehr als sechs Installationen in VirtualBox mit LinuxMint (immer frische Images) durchgeführt. Dabei habe ich jedes Mal, beabsichtigt oder auch unbeabsichtigt, Fehler gemacht, um mich mit allen möglichen Problemen zu konfrontieren. Nun melde ich mich, um meine Erfahrungen mitzuteilen und einige Anmerkungen, Vorschläge und Fragen zu äußern.
Die folgenden Punkte müssen nicht unbedingt gerechtfertigt sein; ich könnte trotz gründlichem Studium des Handbuchs und des Forums etwas übersehen haben.
Hier sind meine Eindrücke, Anmerkungen und Vorschläge:
Speisekarten/Artikel einfügen:
Speisekarten sollten einmalig eingerichtet werden müssen. Bei der Einrichtung der Artikel sollte es folgende Kästchen geben:
1. Artikel zum Abholen
2. Artikel zum Liefern.
In diesen Kästchen sollte zusätzlich der Steuersatz definierbar sein (7 % oder 19 %). Im Restaurant gilt bei Gerichten der allgemeine Steuersatz von 19 %, während bei Abholung oder Lieferung der Steuersatz von 7 % für Lebensmittel/Gerichte gilt. Auf der Kundenwebseite/Showroom sollten dann unter „Speisekarte zur Abholung“ oder „Speisekarte zur Lieferung“ nur die entsprechenden Artikel angezeigt werden.
E-Bon:
Der E-Bon sollte als PDF-Datei gespeichert werden können, idealerweise mit Vorschau. Diese Datei kann der Gast dann auf seinen Geräten speichern oder verwalten (z.B. über DMS) oder weiterleiten. Gleichzeitig sollte unterhalb des E-Bons der Bewirtungsbeleg ausgefüllt als PDF-Datei zur Verfügung gestellt werden.
(Virtuelle) Drucker – für E-Bons, Bewirtungsbelege, Statistiken, Tagesabschlüsse usw.:
Unter Linux und CUPS gibt es die Möglichkeit, einen virtuellen PDF-Drucker einzurichten (siehe https://wiki.ubuntuusers.de/CUPS-PDF/ und https://www.cups-pdf.de/). So könnte man theoretisch jeweils eine Instanz für E-Bons und Bewirtungsbelege sowie für Tagesabschlüsse und Statistiken einrichten. Jeder Druckauftrag erhält eine eigene ID, und je nach Dokumentenart kann ein eigener Speicherordner zugewiesen werden. So kann der entsprechende Druckauftrag dem Gast zur Verfügung gestellt werden.
„Außer-Haus-Verkauf“ und „Lieferung“:
Es sollten zwei virtuelle Räume mit leicht unterschiedlichen Workflows eingerichtet werden:
1. Außer-Haus-Verkauf (bzw. „Gassenverkauf“ in Österreich): Der Kunde kommt ins Geschäft, gibt eine Bestellung auf, erhält einen Abholbon und wartet, bis er aufgerufen wird oder auf einem Monitor über der Theke sieht, dass seine Bestellung fertig ist. Er holt seine Bestellung von der Theke mit Seinem Bon ab. Seine persönlichen Daten werden hier nicht benötigt.
2. Lieferungen: Der Kunde gibt seine Bestellung telefonisch oder per E-Mail auf. Der Mitarbeiter trägt die Kundendaten (Name, Adresse usw.) in eine Maske ein, und die Daten werden automatisch in einer Kundendatenbank gespeichert. In Zukunft können die Daten per Eingabe der Telefonnummer oder E-Mail abgerufen werden, um die Kundenhistorie zu überprüfen. Wenn die Bestellung fertig ist, wird sie dem Zusteller zusammen mit dem Zahlungsbon übergeben, auf dem der Zahlungsweg (in Österreich „Zahlungsart“) und eventuelle Bemerkungen (z.B. „2 Mal läuten, 3. Stock“) vermerkt sind. Wenn der Zusteller zum Betrieb gehört, kann er ein mobiles Terminal, Kartenleser und tragbaren Bondrucker mitführen und die Zahlung direkt beim Kunden abwickeln. In diesem Fall sollte der Zusteller Zugang zu den Anweisungen haben, entweder auf einem mobilen Gerät oder auf einem extra Bon.
Ich habe einige Bestellungen zur Lieferung durchgeführt, jedoch nie eine Bestätigungs-E-Mail erhalten, obwohl die entsprechenden Einstellungen vorgenommen und getestet wurden.
Kundenwebseite/Showroom:
Es wäre hilfreich, wenn mehr technische Daten und Informationen, wie z.B. Platzhalter, zur Verfügung stünden, sodass auch Laien ihre Speise- und Getränkekarte sowie Bildgalerien nach ihren Vorstellungen gestalten können. Zum Beispiel bevorzuge ich Karten in Tabellen nach Kategorien wie Vorspeisen, Suppen, Spezialitäten, Biere, Weine usw. Bei der Bildgalerie hätte ich gerne alle verfügbaren Bilder in Spalten und Reihen in Miniaturansicht, die beim Anklicken vergrößert angezeigt werden.
Workflow im Restaurant – wie ich es mir vorstelle und wie es jetzt ist:
1. Kunde setzt sich hin.
2. Bedienung nimmt die Bestellung auf.
3. Arbeitsbons werden auf den Druckern der Küche und der Bar ausgedruckt und/oder die Bestellung erscheint auf den Touchscreens der Küche und der Bar.
4. Bar und Küche bereiten die Bestellung vor und klicken auf ihren Touchscreens, sodass die Bedienung die Bestellung abholen kann.
5. Die Bedienung kann die Artikel auf ihrem mobilen Gerät als Symbole/Bilder sehen. Wenn Küche und Bar auf „Bestellung/Artikel vorbereitet“ klicken, sollte die Anzeige der Artikel auf dem mobilen Gerät der Bedienung sich ändern und/oder ein Warnton ausgegeben werden.
6. Artikel werden am Tisch serviert, und die Bedienung markiert den jeweiligen Artikel als „serviert“. Ein entsprechender Hinweis erscheint dann auf dem jeweiligen Artikel des Tisches.
7. Gast zahlt die Rechnung, die Bedienung übergibt den Bon und/oder zeigt den QR-Code. Der Gast kann dann den Link öffnen, wo er den Bon sowie den Bewirtungsbeleg als PDF-Dateien herunterladen kann.
(Wahrscheinlich ist dies bereits der bestehende Workflow des Systems, und ich habe die Software nicht richtig bedient. Ich bin für jeden Hinweis dankbar.)
Das sind alle Punkte, die mir momentan einfallen und bei denen ich Hilfe benötige.
Derzeit habe ich einen Kunden in Bayern, den ich davon überzeugt habe, Ordersprinter einzusetzen. Ich werde daher mit Sicherheit deine Hilfe, lieber Stefan, bei der Realisierung dieses (für mich) Pilotprojekts benötigen. Zudem suche ich jemanden, der bereit ist, den Kunden zukünftig zu betreuen und bei technischen Schwierigkeiten Unterstützung zu leisten (entgeltlich, versteht sich). Gerne höre ich von jedem, der daran Interesse hat. Bitte schickt mir eine PN.
Sollte dieses Projekt zufriedenstellend abgeschlossen werden, möchte ich sehr gerne Ordersprinter nach Österreich bringen, nachdem wir alle relevanten Punkte geklärt haben. Aus diesem Grund freue ich mich auf ein persönliches Gespräch mit dir, Stefan.
Schöne Grüße aus Tirol
Konstantin
Lieber Stefan,
ich gratuliere dir zu deiner beeindruckenden Arbeit mit Ordersprinter. Sehr gerne möchte ich dich unterstützen, Ordersprinter nach Österreich zu bringen und hier zu verbreiten. Dafür schlage ich vor, ein persönliches Gespräch telefonisch zu führen.
Ich habe Ordersprinter vor ein paar Wochen (wieder-) entdeckt und mehr als sechs Installationen in VirtualBox mit LinuxMint (immer frische Images) durchgeführt. Dabei habe ich jedes Mal, beabsichtigt oder auch unbeabsichtigt, Fehler gemacht, um mich mit allen möglichen Problemen zu konfrontieren. Nun melde ich mich, um meine Erfahrungen mitzuteilen und einige Anmerkungen, Vorschläge und Fragen zu äußern.
Die folgenden Punkte müssen nicht unbedingt gerechtfertigt sein; ich könnte trotz gründlichem Studium des Handbuchs und des Forums etwas übersehen haben.
Hier sind meine Eindrücke, Anmerkungen und Vorschläge:
Speisekarten/Artikel einfügen:
Speisekarten sollten einmalig eingerichtet werden müssen. Bei der Einrichtung der Artikel sollte es folgende Kästchen geben:
1. Artikel zum Abholen
2. Artikel zum Liefern.
In diesen Kästchen sollte zusätzlich der Steuersatz definierbar sein (7 % oder 19 %). Im Restaurant gilt bei Gerichten der allgemeine Steuersatz von 19 %, während bei Abholung oder Lieferung der Steuersatz von 7 % für Lebensmittel/Gerichte gilt. Auf der Kundenwebseite/Showroom sollten dann unter „Speisekarte zur Abholung“ oder „Speisekarte zur Lieferung“ nur die entsprechenden Artikel angezeigt werden.
E-Bon:
Der E-Bon sollte als PDF-Datei gespeichert werden können, idealerweise mit Vorschau. Diese Datei kann der Gast dann auf seinen Geräten speichern oder verwalten (z.B. über DMS) oder weiterleiten. Gleichzeitig sollte unterhalb des E-Bons der Bewirtungsbeleg ausgefüllt als PDF-Datei zur Verfügung gestellt werden.
(Virtuelle) Drucker – für E-Bons, Bewirtungsbelege, Statistiken, Tagesabschlüsse usw.:
Unter Linux und CUPS gibt es die Möglichkeit, einen virtuellen PDF-Drucker einzurichten (siehe https://wiki.ubuntuusers.de/CUPS-PDF/ und https://www.cups-pdf.de/). So könnte man theoretisch jeweils eine Instanz für E-Bons und Bewirtungsbelege sowie für Tagesabschlüsse und Statistiken einrichten. Jeder Druckauftrag erhält eine eigene ID, und je nach Dokumentenart kann ein eigener Speicherordner zugewiesen werden. So kann der entsprechende Druckauftrag dem Gast zur Verfügung gestellt werden.
„Außer-Haus-Verkauf“ und „Lieferung“:
Es sollten zwei virtuelle Räume mit leicht unterschiedlichen Workflows eingerichtet werden:
1. Außer-Haus-Verkauf (bzw. „Gassenverkauf“ in Österreich): Der Kunde kommt ins Geschäft, gibt eine Bestellung auf, erhält einen Abholbon und wartet, bis er aufgerufen wird oder auf einem Monitor über der Theke sieht, dass seine Bestellung fertig ist. Er holt seine Bestellung von der Theke mit Seinem Bon ab. Seine persönlichen Daten werden hier nicht benötigt.
2. Lieferungen: Der Kunde gibt seine Bestellung telefonisch oder per E-Mail auf. Der Mitarbeiter trägt die Kundendaten (Name, Adresse usw.) in eine Maske ein, und die Daten werden automatisch in einer Kundendatenbank gespeichert. In Zukunft können die Daten per Eingabe der Telefonnummer oder E-Mail abgerufen werden, um die Kundenhistorie zu überprüfen. Wenn die Bestellung fertig ist, wird sie dem Zusteller zusammen mit dem Zahlungsbon übergeben, auf dem der Zahlungsweg (in Österreich „Zahlungsart“) und eventuelle Bemerkungen (z.B. „2 Mal läuten, 3. Stock“) vermerkt sind. Wenn der Zusteller zum Betrieb gehört, kann er ein mobiles Terminal, Kartenleser und tragbaren Bondrucker mitführen und die Zahlung direkt beim Kunden abwickeln. In diesem Fall sollte der Zusteller Zugang zu den Anweisungen haben, entweder auf einem mobilen Gerät oder auf einem extra Bon.
Ich habe einige Bestellungen zur Lieferung durchgeführt, jedoch nie eine Bestätigungs-E-Mail erhalten, obwohl die entsprechenden Einstellungen vorgenommen und getestet wurden.
Kundenwebseite/Showroom:
Es wäre hilfreich, wenn mehr technische Daten und Informationen, wie z.B. Platzhalter, zur Verfügung stünden, sodass auch Laien ihre Speise- und Getränkekarte sowie Bildgalerien nach ihren Vorstellungen gestalten können. Zum Beispiel bevorzuge ich Karten in Tabellen nach Kategorien wie Vorspeisen, Suppen, Spezialitäten, Biere, Weine usw. Bei der Bildgalerie hätte ich gerne alle verfügbaren Bilder in Spalten und Reihen in Miniaturansicht, die beim Anklicken vergrößert angezeigt werden.
Workflow im Restaurant – wie ich es mir vorstelle und wie es jetzt ist:
1. Kunde setzt sich hin.
2. Bedienung nimmt die Bestellung auf.
3. Arbeitsbons werden auf den Druckern der Küche und der Bar ausgedruckt und/oder die Bestellung erscheint auf den Touchscreens der Küche und der Bar.
4. Bar und Küche bereiten die Bestellung vor und klicken auf ihren Touchscreens, sodass die Bedienung die Bestellung abholen kann.
5. Die Bedienung kann die Artikel auf ihrem mobilen Gerät als Symbole/Bilder sehen. Wenn Küche und Bar auf „Bestellung/Artikel vorbereitet“ klicken, sollte die Anzeige der Artikel auf dem mobilen Gerät der Bedienung sich ändern und/oder ein Warnton ausgegeben werden.
6. Artikel werden am Tisch serviert, und die Bedienung markiert den jeweiligen Artikel als „serviert“. Ein entsprechender Hinweis erscheint dann auf dem jeweiligen Artikel des Tisches.
7. Gast zahlt die Rechnung, die Bedienung übergibt den Bon und/oder zeigt den QR-Code. Der Gast kann dann den Link öffnen, wo er den Bon sowie den Bewirtungsbeleg als PDF-Dateien herunterladen kann.
(Wahrscheinlich ist dies bereits der bestehende Workflow des Systems, und ich habe die Software nicht richtig bedient. Ich bin für jeden Hinweis dankbar.)
Das sind alle Punkte, die mir momentan einfallen und bei denen ich Hilfe benötige.
Derzeit habe ich einen Kunden in Bayern, den ich davon überzeugt habe, Ordersprinter einzusetzen. Ich werde daher mit Sicherheit deine Hilfe, lieber Stefan, bei der Realisierung dieses (für mich) Pilotprojekts benötigen. Zudem suche ich jemanden, der bereit ist, den Kunden zukünftig zu betreuen und bei technischen Schwierigkeiten Unterstützung zu leisten (entgeltlich, versteht sich). Gerne höre ich von jedem, der daran Interesse hat. Bitte schickt mir eine PN.
Sollte dieses Projekt zufriedenstellend abgeschlossen werden, möchte ich sehr gerne Ordersprinter nach Österreich bringen, nachdem wir alle relevanten Punkte geklärt haben. Aus diesem Grund freue ich mich auf ein persönliches Gespräch mit dir, Stefan.
Schöne Grüße aus Tirol
Konstantin
-
- Administrator
- Beiträge: 1380
- Registriert: So 13. Sep 2015, 19:48
- Wohnort: Hamburg
- Kontaktdaten:
Re: Unterstützung bei Implementation österreichische RKSV gesucht
Hallo Konstantin,
danke für deinen ausführlichen Beitrag.
Speisekarte/Artikel:
OrderSprinter sieht vor, dass Artikel sowohl für In-House als auch To-go bestellt werden können, so dass es hierzu in der Speisekarte keine Einschränk gibt. Die Unterscheidung ist in Deutschland ganz wichtig, weil das steuerlich einen Unterschied macht und zwar in Abhängigkeit vom Typ des Artikels. Natürlich kann man sich überlegen, bestimmte Artikel nur für einen Außer-Haus-Verkauf oder nur für die Verköstigung am Tisch vorzusehen, aber eine entsprechende Deklaration gibt es in OrderSprinter noch nicht. Ich habe das aber mal in die riesige Todo-Liste eingetragen, vielleicht setze ich das mal um.
E-Bon:
Aktuell kann sich der Benutzer den Bon über die entsprechenden Funktionen seines Computers/Browsers/Smartphones speichern oder drucken. Ich möchte da aktuell keine Arbeit reinstecken, denn ich sehe den Mehrwert von PDF nicht.
CUPS:
OrderSprinter druckt auch per CUPS die Daten entsprechend des ESC/POS-Protokolls, d.h. ein PDF-Druck, wenn es denn überhaupt den Druckjob einigermaßen sinnvoll rendern könnte, würde niemals den Bon ganz richtig in PDF darstellen. Bondrucker werden grundsätzlich ganz anders angesteuert als GDI oder PDF-Drucker.
Zwei virtuelle Räume mit unterschiedlichen Workflows:
Man kann die Workflows aktuell nur für Produktgruppen einstellen. Wenn man in der Artikelansicht die Kategorieinstellungen aufklappt, kann man festlegen, ob die Artikel die Küche/Bar- und Bereitstellungsansicht durchlaufen sollen. Du könntest also eine Produktgruppe 'Außer-Haus-Artikel' anlegen, in der du das einträgst.
Showroom:
Vielleicht ein Henne-Ei-Problem, aber solange ich nicht genügend Showroom-Instanzen im Internet finde, ist das Interesse daran offenbar so gering, dass sich auch für mich nicht sinnvoll anfühlt, da noch viel mehr Arbeit reinzustecken.
Workflow im Restaurant:
Aber das ist doch jetzt bereits der Standard-Workflow. Welchen Schritt vermisst du?
Österreich-Support:
Wenn du Interesse an einem Support für Österreich hast, wäre es warscheinlich am besten, zunächst mit der Firma Fiskaly zu reden und zu sehen, ob eure Vorstellungen zusammenpassen. Denn vor allem ist es da ja die Einbindung der Fiskaly Sign-AT-Lösung für die Umsetzung der RKSV wichtig.
Gruß,
Stefan
danke für deinen ausführlichen Beitrag.
Speisekarte/Artikel:
OrderSprinter sieht vor, dass Artikel sowohl für In-House als auch To-go bestellt werden können, so dass es hierzu in der Speisekarte keine Einschränk gibt. Die Unterscheidung ist in Deutschland ganz wichtig, weil das steuerlich einen Unterschied macht und zwar in Abhängigkeit vom Typ des Artikels. Natürlich kann man sich überlegen, bestimmte Artikel nur für einen Außer-Haus-Verkauf oder nur für die Verköstigung am Tisch vorzusehen, aber eine entsprechende Deklaration gibt es in OrderSprinter noch nicht. Ich habe das aber mal in die riesige Todo-Liste eingetragen, vielleicht setze ich das mal um.
E-Bon:
Aktuell kann sich der Benutzer den Bon über die entsprechenden Funktionen seines Computers/Browsers/Smartphones speichern oder drucken. Ich möchte da aktuell keine Arbeit reinstecken, denn ich sehe den Mehrwert von PDF nicht.
CUPS:
OrderSprinter druckt auch per CUPS die Daten entsprechend des ESC/POS-Protokolls, d.h. ein PDF-Druck, wenn es denn überhaupt den Druckjob einigermaßen sinnvoll rendern könnte, würde niemals den Bon ganz richtig in PDF darstellen. Bondrucker werden grundsätzlich ganz anders angesteuert als GDI oder PDF-Drucker.
Zwei virtuelle Räume mit unterschiedlichen Workflows:
Man kann die Workflows aktuell nur für Produktgruppen einstellen. Wenn man in der Artikelansicht die Kategorieinstellungen aufklappt, kann man festlegen, ob die Artikel die Küche/Bar- und Bereitstellungsansicht durchlaufen sollen. Du könntest also eine Produktgruppe 'Außer-Haus-Artikel' anlegen, in der du das einträgst.
Showroom:
Vielleicht ein Henne-Ei-Problem, aber solange ich nicht genügend Showroom-Instanzen im Internet finde, ist das Interesse daran offenbar so gering, dass sich auch für mich nicht sinnvoll anfühlt, da noch viel mehr Arbeit reinzustecken.
Workflow im Restaurant:
Aber das ist doch jetzt bereits der Standard-Workflow. Welchen Schritt vermisst du?
Österreich-Support:
Wenn du Interesse an einem Support für Österreich hast, wäre es warscheinlich am besten, zunächst mit der Firma Fiskaly zu reden und zu sehen, ob eure Vorstellungen zusammenpassen. Denn vor allem ist es da ja die Einbindung der Fiskaly Sign-AT-Lösung für die Umsetzung der RKSV wichtig.
Gruß,
Stefan
Stefan Pichel
Entwickler der Kassensoftware OrderSprinter (http://www.ordersprinter.de)
Entwickler der Kassensoftware OrderSprinter (http://www.ordersprinter.de)