3rd Party eSolution Entwicklung
Der Status aus eigener Perspektive dienst der Abstimmung der Erwartung. Wenn dort ein perfekt steht, geht Hypersoft davon aus, dass die Funktion in Hypersoft stark ist und in der Schnittstelle perfekt unterstützt wird, so dass eine 3rd Party damit alle Anforderungen für diesen Bereich lösen kann. Dies und anderes dient Ihnen somit als Orientierung.
Best Practice Beispiel zum Bezahlen vorhandener Vorgänge
Bei allen Funktionen die einen Parameter Company und SerialNumber verlangen, bitte immer die Vorgaben verwenden, die Sie von Hypersoft genannt bekommen haben.
Erste Schritte zum Bezahlen vorhandener Vorgänge (Tische)...
Es stehen folgende Methoden für den Workflow einer Bezahlung des Tisches zur Verfügung:
Liste aller Buchungen...
Mit der Methode „GetOpenTable“ erhalten sie eine Liste aller Buchungen aus allen offenen Vorgängen.
Lister aller Buchungen eines Vorgangs...
Mit der Methode „GetOpenTableBySelection“ erhalten sie die gleichen Daten wie bei „GetOpenTable“, jedoch dann nur für den Tisch, den sie in dem Parameter SelectionTable übergeben haben, z.B. „2“ für den Tisch 2.
Wir gehen davon aus, dass ihrer APP (über den QR-Code) die Tischnummer bekannt ist und somit nur mit der Methode „GetOpenTableBySelection“ gearbeitet wird.
Vorgangssumme berechnen...
Die Aufsummierung von „Menge“ * „Preis“ jedes Artikels, ergibt die Vorgangssumme.
Vorgang bezahlen...
Mit der Methode „BookTransaction“ oder „BookTransactionStr“ kann dieser offener Tischvorgang als bezahlt übergeben werden, z.B.:
BookTransactionStr(„MyCompany“, „MySerialNumber“, „TNR:2|ZA:47=MyPayment“)
Wenn die Summe unter MyPayment der Vorgangssumme entspricht, wird der Vorgang vom POS System abgerechnet. Bei einer Überzahlung (mehr Payment als Vorgangssumme) wird die Differenz als Trinkgeld verbucht (das Trinkgeld wird in Hypersoft dem Bediener mit Vorgangsverantwortung zugewiesen). Jede Zahlung die kleiner ist, als die Vorgangssumme wird als Zwischenzahlung in den Vorgang gespeichert und der Vorgang mit dem Restbetrag bleibt offen (so können Sie Teilzahlungen vornehmen, die keinen bestimmten Artikelbuchungen zugewiesen sind).
Rechnungsinformationen...
In der Rückmeldung erhalten sie die DeliveryID mit der sie dann ggfls. die Rechnungsinformationen abrufen können. Hierzu verwenden sie dann bitte die Methode „GetDeliveryInfo“.
Die ID 47 aus dem Beispiel ist für die Zahlungsart intern fest auf „Pay per App“ verknüpft. Diese Zahlungsart kann immer dann verwendet werden, wenn eine Separierung der tatsächlichen Zahlungsart nicht gewünscht ist. Andernfalls können mittels Methode „GetMyPaymentMethod“ die verfügbaren Zahlungsarten aus dem POS-System ermittelt werden.
Z.B. 20 = ec, 25 = VISA, 26 = Mastercard, 49 = Sofortüberweisung usw.
Innerhalb des Hypersoftsystems wird Ihr Programm als Channel integriert, über diesen Channel werden die Buchungen als >„Ihre Lösung“ Payment< ausgewertet.
Den Datenaufbau der Parameter sowie der Rückmeldungen aller verfügbaren Methoden entnehmen sie bitte der Dokumentation.
Artikel und Vorgänge mit 3rd Parties
Artikeltexte und Informationen
Die Artikeltexte werden in unterschiedlichem Umfang bereitgestellt, der Standard Artikelname ist der Bontext 1. Es gibt eine Methode für weitere Sprachen bezüglich des Kurztextes und einen HTML formatierten Detailtext. Die weiteren Informationen wie Allergene, Inhaltsstoffe und Energiewerte können ebenso abgerufen werden.
Ein weitere wesentlicher Punkt sind die Anpassungen eines Artikels beim Bestellen (Modifier). Diese können in Form von Abfragen (Zwangsabfragen) oder am POS und mPOS auch durch freie Anhänge gebucht werden. Abfragen haben enorme Auswirkungen auf die Stammdaten eines Artikels.
Struktur und IDs der Artikeldaten...
Ein Steak mit Salat oder Knoblauchbrot kann kein fester Artikel sein, sondern besteht aus dem Steak und der getroffenen Auswahl und somit aus zwei von drei Artikeln. Der Salat wird ein einziges Mal in den Stammdaten auf der Ebene des Steaks angelegt und wenn dieser Salat einzeln verkauft werden soll, so ist dies seine ID (ProductID). Wenn es mehrere Artikel gibt, die als Auswahl Salat haben, so erhält der Salat für jede Zuordnung eine weitere eindeutige ID (RezID), die genau für diese Zuordnung gültig ist. Der Salat zum Entrecôte hat somit eine andere eindeutige ID (RezID) als der gleiche Salat zum Filet Mignon. Diese Methode ermöglicht nicht nur die historischen Auswertung der Stammdatenveränderung (in Deutschland durch GDPdU erforderlich), sondern repräsentiert auch die Möglichkeit die Beilagen und Abfragen für das Stock Management pro möglicher Artikelkombination und unterschiedlicher Im-Haus und Außer-Haus Rezepturen anpassen zu können.
Grundsätzlich sind alle verkaufsfähigen Artikel in der Tabelle SYS_Artikel und dort mit der ProductID hinterlegt aufzufinden. In dieser Tabelle gibt es jeden Artikel (jede ProductID) nur einmal. Zusätzlich sind die Artikel in ihrer entsprechenden Tabelle der Gruppe ebenfalls aufgeführt. Die Toppings/Beilagen/Abfragen finden sie in den Tabellen SYS_Abfragen und SYS_ArtikelAbfragenNoVK dort finden sie mit der Link_ProductID die zugehörigen Abfragen/Beilagen. Die RezID aus diesen Tabellen ist dann zum Buchen notwendig.
Sehen Sie im Bereich Interne IDs Drucken wie Sie sich die Stammdaten mit den IDs ausdrucken können.

Im Hypersoftsystem können Artikel durch Abfragen modifiziert werden. Informativ "ohne Salz", "Medium" oder bezüglich der gesamten Konfiguration und des Preises "mit Salat -> Dressing-Auswahl" +4,-. Somit erhalten Artikel im Artikelstamm vorkonfigurierte Abfragen.
Die Tabelle SYS_Query enthält die Abfragen, die zu einem Artikel erscheinen. Zum Beispiel erscheint bei einem Steak die Abfrage "rare / medium / well done" .
Die Abfragen zu einem Artikel aus der Tabelle ART_XXX sind über die Spalte Link_Artikel_Nr verknüpft. Beim Buchen eines Artikels aus der Tabelle ART_XXX muss also geprüft werden, ob in der Tabelle SYS_Query Datensätze mit dem entsprechenden Link_Artikel_NR vorhanden sind.
Die Spalte Sort ist die vom Kunden gewünschte Anzeigereihenfolge der Abfragen.
Eine Abfrage auf Hypersoft ist "16-stufig", so dass bis zu 16 Abfragen hintereinander erscheinen können. Dies wird durch die Spalten "AB1" bis "AB16" realisiert. Es werden zunächst alle Artikel angezeigt, die in "AB1" eine "1" haben. Wurde ein Artikel ausgewählt, erfolgt erst die Anzeige aller Artikel der zweiten Ebene "AB2" usw. Hier gibt es eine Besonderheit:
Wenn ein Artikel nur einen einzigen Artikel in einer Abfrageebene hat ("AB1-16"), dann wird dieser Artikel automatisch gebucht (ohne Abfrage).
Weiterführende Dokumentation:
Basiswissen 4: Bestandteile und Abfragen
Sub-Abfragen und Sub-Bestandteile
Abfrageüberschriften verwenden.
Code Beispiel:
DataSet Typ1: Tabellenname SYS_Abfragen:

Im Artikelstamm gibt es einen integrierten Text Editor für die App Beschreibung. Der Text am Standort im RTF Format gespeichert.
Über das eSolutions Interface erhalten Sie den Text automatisch in das HTML Format konvertiert.
Weiterführende Dokumentation: Bereich App Beschreibungen

Für Artikel stehen (maximal 64) Zusatzfelder zur Verfügung, die optional auch in der Artikelschnittstelle verwendet werden können. Hierfür dienen die Typen Schnittstelle1 bis Schnittstelle10. Eine Unterscheidung zwischen 1 und 10 wird derzeit nicht vorgenommen.
Weiterführende Dokumentation: Bereich Besonderheiten.

Die Artikelbezeichnungen können unterschiedliche maximale Längen und Funktionen haben. Bontext 1 ist der wichtigste Text für die Artikel am POS System. Sehen Sie im Artikelstamm unter Artikelbezeichnung und Artikelbontexte.

In der Hypersoft Suite gibt es mehrere Möglichkeiten Artikel unter bestimmten Bedingen nicht zu verkaufen, sehen Sie hierzu Artikel bedingt anbieten.
Die eSolutions Schnittstelle stellt die Liste der gesperrten Artikel zur Verfügung (Blacklist).
Der Partner kann vor dem Buchen eines dieser Artikel prüfen, ob er auf der Sperrliste steht und gegebenenfalls einen Hinweis ausgeben. Sollte ein Artikel der auf der Sperrliste steht über die eSolutions Schnittstelle eintreffen, wird er trotzdem gebucht.
Die eSolutions Schnittstelle stellt in den Artikeldaten die Zeitpunkte Eingeschränkt buchbar aus dem Artikelstamm zur Verfügung. Der Partner kann somit vor dem Buchen eines Artikels den Zeitpunkt prüfen und berücksichtigen. Sollte dennoch ein Artikel zu einen eingeschränkten Zeitpunkt als Buchung über die eSolutions Schnittstelle eintreffen, wird er trotzdem gebucht.
Die eSolutions Schnittstelle stellt eine Liste der Verfügbarkeitsartikel inkl. der aktuellen Bestände zur Verfügung (Verfügbarkeitsmanager). Auch kann der Bestand eines oder mehrere Artikel abgerufen werden. Der Partner kann somit vor dem Buchen eines dieser Artikel den aktuellen Bestand abrufen um gegebenenfalls einen Hinweis auszugeben. Sollte einer dieser Artikel als Buchung über die eSolutions Schnittstelle eintreffen und der Bestand nicht ausreichen, wird er trotzdem gebucht.
Code Beispiel Funktion zum Abruf aller Verfügbarkeitsartikel..
Weiterführende Dokumentation:

Um mit Lagerbeständen der Basisartikel arbeiten zu können ist die Lizenz für den Controller erforderlich.
Bevor Sie hier mit den Beständen arbeiten müssen Sie die Bedeutung von Lagerbeständen und anderem bedingten Anbieten von Artikeln verstanden haben. Hierfür lesen Sie und die entsprechenden verweise in dem Kapitel Artikel bedingt anbieten. Wenn Sie sich allerdings sicher sind, dass Sie tatsächlich mit "reinen Lagerbeständen der Basisartikel" arbeiten wollen lesen Sie hier weiter:
Sie können die Lagerorte der Basisartikel abrufen, die aktuellen Lagermengen erfahren, sowie die Lagermengen aktualisieren.
Code Beispiel Funktion zum Abruf des Bestands.
Code Beispiel Funktion zum Abruf des Bestands als JSON String.
Code Beispiel SetProdStock Vorerst ist diese Funktion aus Sicherheitsgründen deaktiviert.
Code Beispiel Funktion zum Abruf des Bestands
Weiterführende Dokumentation: Die optimale Bestandsführung wählen.

Da einen typische "Größenverwaltung" für Artikel (Pizza klein / mittel / groß), die Möglichkeiten des Rezepturmanagements überschreiten würde und auch von Anwendern nur sehr unübersichtlich gepflegt werden könnt, biete Hypersoft eine Alternative an.
Hypersoft bietet hierfür 3 Artikeltexte ("Artikelname", "Bontext1" und "Bontext2")
Mehrere Größen eines Artikels werden durch einen gleichen Artikelnamen gekennzeichnet.
Der Bontext2 stellt die Größenvariante dar.
Beispiel:
Product Name: Pizza Hawaii Bontext1: Pizza Hawaii small Bontext2: small, 24 cm
Product Name: Pizza Hawaii Bontext1: Pizza Hawaii medium Bontext2: medium, 36 cm
Product Name: Pizza Hawaii Bontext1: Pizza Hawaii big Bontext2: large, 48 cm
Die Gruppierung der Artikel erfolgt hier über den Artikelnamen. Weitere Informationen zu Artikelbezeichnungen für 3rd Parties.

Das Hypersoftsystem stellt den Status Außer Haus zur Verfügung. Dieser muss vom eSolutions Partner (ECP) genutzt werden.
Im Standard können für den Full-Service Tischnummern übergeben und abgerufen werden.
Weiterführende Dokumentation: Webservice Initialisieren
Wenn Sie mit Quick-Service, Digital Service (auch Limited Service) oder Takeaway arbeiten, können Sie auch eine Pagernummern oder Bestellnummer übergeben. Hierfür werden die folgenden Regeln verwendet:
Sie verwenden für die erste Vorgangsnummer 10000, für die zweite 11000, dann 12000 und beginnen spätestens nach 99000 wieder mit 10000
Wenn mit Pagernummern oder anderen Belegnummern gearbeitet wird verwenden Sie hierfür die letzten drei Stellen. Beispiel Pager 25 beim ersten Vorgang 10025.
Die Vorgangsnummer wird auf dem Orderbon und auf den Kitchen Displays angezeigt und auch auf dem Servicebeleg des Kitchen Monitors ausgedruckt. Ebenfalls die Information für Außer Haus (optional auch Im Haus).

Beispiel anhand einer Bestellung über Online Order: Die interne eindeutig ID, die auch schon Bestandteil der Artikelstammdaten beim Hochladen (zum Beispiel an Deliverect) ist, ist auch Bestandteil jeder einzelnen Buchung die wir mit der Bestellung übergeben bekommen. Anhand dieser eindeutigen ID wird geprüft, ob der Artikel im Kassensystem bekannt ist.
Sollte der Artikel nicht bekannt sein, bekommt er einen Status als unbekannter Artikel und der Online Order übergebene Artikelname wird für die Anzeige des Bestellvorganges an der Kasse verwendet (farblicher von den bekannten Artikeln unterschieden, siehe zum Beispiel Deliverect).
Sollte der Artikel bekannt sein und der Preis nicht übereinstimmen, bekommt er den Status Preis unbekannt (ebenfalls farblicher unterschieden, siehe zum Beispiel Deliverect).
Sollte ein Artikel bekannt sein, wird immer der aktuellen Artikeltext aus der Kasse vorrangig verwendet.

Artikel können im Hypersoftsystem auch anhand der frei wählbaren Artikelnummer sortiert werden (da diese Nummer heutzutage kaum noch am POS verwendet wird).
Ein 3rd Party Anbieter kann diese Nummer zum Sortieren verwenden.
Im Hypersoftsystem gibt unterschiedliche Methoden um auf Kunden zu buchen.
-
Sie können einen Kunden aus der Kundendatenbank als Kunden aufrufen und auf diesen wie auf einen Vorgang buchen. Sie buchen "auf diesen Kunden". Der Kunde tritt hier anstelle einer möglichen Tischnummer, so dass es keine zusätzliche Tischnummer geben könnte.
-
Sie können einem Vorgang einfach Kundendaten hinzufügen - auch wenn dieser Kunde in der Kundendatenbank vorhanden wäre, buchen Sie aus Sicht der Datenbank so nicht auf diesen Kunden. EIne Tischnummer kann hier zusätzlich verwendet werden.
-
Es gibt weitere Möglichkeiten.

Beispiel aus Deliverect, als auch aus Third Party Bestellungen (eSolutions): Von Deliverect und anderen Online Order Systemen erhalten wir Kundeninformationen bestehend aus Kundenname, Firmenname, Telefonnummer und Mailadresse, optional zusätzlich Straße, Hausnummer, PLZ und Stadt.
Anhand dieser Daten wird in folgender Reihenfolge geprüft, ob der Kunde bereits in Hypersoft Kundenstamm ermittelbar ist:
Es wird als erstes anhand der Telefonnummer geprüft und wenn diese nicht bekannt ist, dann anhand der eMailadresse.
Sollte beides nicht bekannt sein, wird ein neuer Kundendatensatz mit den übergebenen Daten angelegt.
Hierbei werden die unterschiedlichen Versionen des Hypersoft Kundenstamm berücksichtigt(Offline Kundenstamm, Kundenstamm 1.0 oder Kundenstamm 2.0 ).
Kunden aus dem Webshop 1.0 und Webshop 2.0:
Beim Einsatz von Webshop 1.0 oder auch 2.0 ist der Offline Kundenstamm nicht möglich, somit wird der Kunde bereits im Shop (Kundenstamm 1.0 oder 2.0) angelegt und die eindeutige KundenID an die eSolutions Schnittstelle mit der Bestellung übergeben. Eine Erfassung der Kunden ist somit hier nicht notwendig. Der Kundendatensatz wird hierbei von der eSolutions Schnittstelle über die mitgelieferte ID vom Portal abgerufen und der Bestellung zugeordnet.
DeliveryID
Die DeliveryID ist der eindeutige Vorgang im Zusammenhang mit dem Online Order System und allen optionalen Integrationen.
Wir bitten Sie dringend die Möglichkeit Bilder aus dem Artikelstamm für die Artikeldaten zu verwenden und davon abzusehen Bilddaten extern beizusteuern oder statisch in Ihrer Anbindung zu verankern, da dies nachteilig in der Bearbeitung ist und zu weiteren Problem (z.B. bei Prüfungen) führen kann. Sehen Sie hierzu 3rd Party eSolution Fiskalanforderungen.
Sollte ihre Nutzung besondere Formate benötigen können diese in der Regel in einem der verfügbaren Kanäle des Artikelstamms eingepflegt werden.
Die Übermittlung der Kanäle 2-9 kann bei Bedarf manuell im Sub-Channel des Online Order Connectors aktiviert werden.
Der Artikelstamm hat mehrere Bildkanäle. Alle Bildkanäle können in der eSolutions Schnittstelle abgerufen werden. Sehen Sie hierzu ds Kapitel Bildverarbeitung mit eSolutions.
Bitte beachten Sie gerade bei Ressourcen wie Bildern, dass Sie durch zu große oder zu häufige Abfragen das Kundensystem oder auch die Hypersoft Server unnötig belasten können. Die Verantwortung das System nicht negativ zu beeinflussen tragen Sie als 3rd Party. Sollten wir dies feststellen kommen wir auf Sie zu. Wir behalten uns in diesem Zusammenhang vor Ihnen bei wiederholt auftretenden Problemen den Zugriff ohne weitere Ankündigung zu sperren.
Sollten Sie aus anderen Bereichen als dem Artikelstamm Mediadaten benötigen, prüfen wir gern auf Anfrage die Möglichkeiten.
NoCOO digitales Rechnungverzeichnis für 3rd Parties
NoCOO (no Co²) steht für ein digitales Rechnungverzeichnis, dass von Hypersoftkunden optional gebucht werden kann. Sollen digitale Belege an die 3rd Party übermittelt werden ist NoCOO hierfür die Lösung. Sehen Sie die Programmbeschreibung unter NoCOO - Digital Billing. Über die Schnittstelle wird der Zugang und PIN übermittelt.
Preisebenen haben in Hypersoft mehrere wichtige Funktionen und steuern neben unterschiedlichen Preisen Pro Artikel auch MwSt. Sätze und den Status Im Haus / Außer Haus, hierzu gibt es auch das Thema Außer-Haus-Serviceruf. Ein Artikel kann im Hypersoft System übrigens mehr als einen festen MwSt. Satz besitzen.
Hypersoft hat ein umfangreiches Rabattsystem. Für 3rd Parties können aus den Artikeldaten diese Informationen verwendet werden:
-
Artikel darf rabattiert werden oder nicht
-
Minimalpreis des Artikels (dieser darf auch dann nicht unterschritten werden wenn der prozentuale Rabatt dies rechnerisch ergeben würde.
Wir empfehlen Ihnen bei Bedarf die eingestellten Rundungsparameter abzurufen und anzuwenden.
Sehen Sie alles zu Rabatten ab Rabatte anwenden .
Bitte verwenden Sie in Kürze nicht mehr die Alte Methode: Weitere Sprache für Artikel. Verwenden Sie bitte Sprachen: Hypersoft Mehrsprachfähigkeit.
Multiobjekt-Vorgänge mit eCOm API
Wenn die Option Multiobjekt Vorgang aktiv ist, werden alle Online Order Vorgänge mit Platznummern und Platzinformationen abgespeichert. Somit wird hierbei (wie auch im Hypersoftsystem üblich) die erste freie Platznummer verwendet und als Objektinformation zum Beispiel der Vorname und Name des Kunden abgespeichert.
Kassenterminal Zuständigkeit und Einrichtung
In der Regel übernimmt die Kassenstation die Bearbeitung der Buchungen und Vorgänge, auf der notwendige Hypersoft eSolutions Webservice eingerichtet wurde. Alternativ kann eine 3rd Party Anbindung eine Kassennummer (Stationsnummer) übermitteln, die dann für die Buchungen und Vorgänge zuständig ist. Dies ist auch dann indiziert wenn mehrere eSolutions Anbindungen gleichzeitig an einem Kassensystem laufen und eventuell unterschiedlich eingerichtet werden sollen (Webshop, Order App etc). Allein durch die unterschiedlichen Überschriften auf Orderbons oder Formularen können sie Hinweise zu dem Channel der Order geben.
Auf einer Kassenstation kann hierfür ein (oder mehrere) Kassen Subsystem(e) eingerichtet werden, um individuelle Einstellungen für die eintreffenden Buchungen und Vorgänge anzuwenden. Auf einem Server oder einem Gerät ohne Hypersoft POS Kassiermodus kann hierfür eine Kasseninstanz ohne Kassiermodus eingerichtete werden (wie für Orderman Steuerungssysteme) und optional weitere Subsysteme.
Das angesprochene Kassenterminal bzw.- Subsystem verarbeitet die Buchungen und erstellt die Orderbons und Rechnungen/Formulare gemäß seinen Einstellungen.
Häufig wird im Zusammenhang mit dem eSolutions Interface auch ein sogenannter Übersichtsbon eingerichtet. Für komplexe Zubereitungsaufgaben empfiehlt Hypersoft die Kombination mit dem Kitchen Monitor System.
Auch 3rd Party Stationen, sofern Sie Bestandteil des Systems sind sollten als solche am Standort des jeweiligen Systems eingerichtet werden.
Im Hypersoftsystem ist ein ausgeprägtes Storno Management enthalten, mit dem wir unseren Kunden zahlreichen Möglichkeiten anbieten und diese sich die für sie passenden Möglichkeiten heraussuchen. Beschrieben wird dies im Bereich Storno- und Verlustmanagement und den dazugehörigen Kapiteln wie zum Beispiel Storni mit integrierten eSolutions. Für die unterschiedlichen internationalen Einsatzorte des POS Systems stellt Hypersoft ein sicheres Werkzeug zur Verfügung, um im Fall von Prüfungen korrekten Buchungen, Berichte und Exporte bereitzustellen. Hiervon profitieren auch die 3rd Party Partner in der täglichen Zusammenarbeit. Wir konnten feststellen, dass es in der bisherigen Zusammenarbeit nicht notwendig war eine Funktion zum Stornieren per eSolutions Interface zur Verfügung zu stellen und können daher weitgehend auch System mit aktiver 3rd Party eSolutions Anbindung bei Prüfungen beurteilen. Gleiches erwarten wir sodann von Betriebsprüfern, die das Gesamtsystem beurteilen.
Somit bitten wir die 3rd Parties und unsere Kunden die vorhanden Stornofunktionen des Gesamtsystems zu nutzen und auf eine Stornomöglichkeit im 3rd Party eSolutions Bereich weiterhin zu verzichten. Bisher konnten alle hiermit einen sehr guten Workflow konzipieren und sich gleichzeitig die Sicherheit der Hypersoft Welt stützen. Wir danken Ihnen für Ihr Verständnis.
In der Hypersoft Suite ist ein ausgeklügeltes System für den Tageswechsel vorhanden. Nutzen Sie den Zeitpunkt des so genannten /TTA Der Theoretische Tagesabschluss (TTA) wendet den kalendarischen Tageswechsel zu einer von Ihnen festgelegten Uhrzeit an (Standardeinstellung 6:00 Uhr). Das Programm kann zu diesem Zeitpunkt automatisch Abschlüsse, Aktualisierungen und Wartungen durchführen. Danach beginnt mit der ersten POS-Buchung des Tages ein neuer Verkaufstag. , um gegebenenfalls Dinge in ihrem System zurückzusetzen, verwaiste Warenkörbe zu leeren oder den Tag zu wechseln. Sehen sie hier den Bereich Tagesabschluss, Tageswechsel und TTA.
Einzelnen Artikelbuchungen können von unterschiedlichen Bedienern erfolgen. Hypersoft arbeitet mit der Vorgangsverantwortung, die immer einem speziellen Bediener zugewiesen ist (zum Beispiel der erste Bediener der einen Tisch öffnete). Das Trinkgeld wird von Hypersoft automatisch diesem Bediener zugewiesen. Sie müssen sich nicht darum kümmern.
Wenn Sie als 3rd Party Vorgänge anlegen und das System entsprechend eingerichtet ist können Sie als virtueller Bediener die Vorgangsverantwortung erhalten und das Trinkgeld könnte dann weiter behandelt oder verteilt werden. Sehen Sie alle Hinweise zum Thema Trinkgeld buchen.
Zwei Methoden um Trinkgeldbuchungen auszulösen
-
Sie können einen Artikel mit dem entsprechenden Betrag buchen, der im Hypersoftsystem als Trinkgeldartikel definiert ist.
-
Sie können den Zahlungsbetrag des Vorgangs erhöhen, Hypersoft bucht die Überzahlung als Trinkgeld.
Konfiguration zur Behandlung von Überzahlungen...
Mit dem Optionsschalter Bei Überzahlung TRINKGELD buchen können Sie für die API ein Verhalten speziell für Ihren Channel festlegen. Damit entscheiden Sie, ob bei einer Überzahlung in Verbindung mit einem Vorgangsabschluss der Überschuss als Trinkgeld oder als Rückgeld verbucht wird. Ist der Schalter aus und eine höhere Zahlungssumme wird mit dem Vorgangsabschluss übergeben, behandelt das POS die "Überzahlung" als Rückgeld. Dieser Teil wird somit nicht in den Geldbestand einbezogen und auch nicht als Trinkgeld in der Bedienerabrechnung aufgeführt.
Steuerliche Behandlung von Trinkgeld...
Überzahlungen werden im Standard als steuerfreies Trinkgeld gebucht. Bei Trinkgeldartikel kann die Versteuerung durch Einstellungen definiert werden.
In Deutschland ist Trinkgeld nicht generell steuerfrei. Viele 3rd Parties verursachen generell oder im Zusammenhang mit nicht abgestimmten Workflows die Steuerpflicht von Trinkgeldern. Buchen Sie daher im Zweifel immer steuerpflichtiges Trinkgeld.
Hypersoft hat ein dreistufiges Warengruppenkonzept.
Weiterführende Dokumentation:
Sortieren - Reihenfolge der Artikel.
Weiterführende Dokumentation:
eSolution 3rd Party API Übersetzungen
Zurück zur übergeordneten Seite: 3rd Party eSolution API