my.apro: Funktionen im Überblick

Zielgruppe: Chef, Büro
Typische Nutzung: Einmalig beim Einrichten, danach bei Modul-Erweiterungen, Hardware-Tausch oder jährlicher Erneuerung
Aufruf: my.apro → Kassenmodule → Administration → Lizenzverwaltung

Zweck

In der Lizenz-Übersicht sieht das Büro auf einen Blick, welche APRO-Module der Betrieb gebucht hat, bis wann sie laufen und welche Kassen (Seriennummern) dafür freigeschaltet sind. Das ist der zentrale Kontrollpunkt für Fragen wie „Haben wir das Hotel-Modul aktiv?", „Wann läuft unsere Lizenz aus?" oder „Warum startet die neue Kasse nicht?".

Ablauf

Lizenz-Status prüfen:

1. my.apro → Kassenmodule → Administration → Lizenzverwaltung öffnen.
2. Übersicht der Module — z.B. Basis-Kasse, Bonierapp, Bestellmanager, Hotel-Schnittstelle, FiBu-Modul, Kiosk, Webshop, Gutscheinsystem.
3. Pro Modul:

• Anzahl gebuchter Lizenzen
• Anzahl aktuell verwendeter Lizenzen (an welcher Kasse / Gerät)
• Laufzeit-Ende

4. Details je Gerät — Seriennummer, Installations-Datum, letzter Lizenz-Check.

Neue Lizenz aktivieren (nach Nachbestellung):

1. APRO-Vertrieb übermittelt einen Lizenzschlüssel (meist als PDF/Datei).
2. Administration → Lizenzverwaltung → Lizenz einspielen — Schlüssel eintragen oder Datei hochladen.
3. Die neue Lizenz steht sofort als frei zur Verfügung.
4. Am gewünschten Gerät nutzen: Am Kassen-Client Verwaltung → Lizenzverwaltung → Lizenz holen.

Lizenz nach Hardware-Tausch übertragen:

1. Alte Kasse startet noch — Am alten Gerät: Verwaltung → Allgemein → Lizenzverwaltung → Lösche Allokierung und Reset Lizenznehmer. Wichtig: Internetverbindung nötig, damit der Server die Freigabe annimmt.
2. Neue Kasse — Lizenz über denselben Lizenzschlüssel abrufen.
3. Alte Kasse startet nicht mehr (Hardware-Defekt) — Lizenz muss am APRO-Lizenzserver manuell zurückgesetzt werden. Support kontaktieren; im Notfall neue Bestellung mit Hinweis im Notizfeld — das wird später gutgeschrieben.

Lizenz-Checker (automatische Prüfung):

• Kassen prüfen regelmäßig im Hintergrund, ob ihre Lizenz noch gültig ist (einmal pro Tag).
• Bei ablaufenden Lizenzen gibt es mehrere Wochen im Voraus eine Warnung in my.apro und am Kassen-Client.
• Bei abgelaufener Lizenz läuft die Kasse weiter, aber mit Einschränkungen (z.B. Sync deaktiviert).

Einstellungen

• Lizenz-Liste — my.apro → Kassenmodule → Administration → Lizenzverwaltung. Zentrale Übersicht.
• Lizenz-Check-Intervall — systemseitig täglich; nicht manuell änderbar, aber im Wartungsfall kurzfristig deaktivierbar.
• Ablauf-Benachrichtigungen — my.apro → User → User → [User] — Büro und Chef können Mail-Warnungen vor Ablauf aktivieren.
• Geräte-Seriennummer — einmal zugewiesen, bleibt die Seriennummer am Gerät. Bei Hardware-Tausch über „Lösche Allokierung" freigeben.
• Multi-Filiale — Lizenzen sind je Filiale und je Kasse zugeordnet. Ein zentrales my.apro sieht alle Lizenzen aller Filialen.
• Basis- vs. Zusatzmodule — Basis-Kasse ist die Voraussetzung; Zusatzmodule (Hotel, FiBu, Kiosk, Gutschein, Bonierapp, Bestellmanager, Webshop, Reservierung, WaWi, Loyalty) werden einzeln lizenziert.

Berechtigungen

Varianten

• Basis-Kasse — Pflicht. Ohne Basis-Lizenz startet die Kasse nicht.
• Bonierapp / Mobile Kasse — Zusätzliche Lizenz pro mobiles Gerät.
• Bestellmanager (Küche) — Eine Lizenz pro Küchen-Display.
• Hotel-Schnittstelle — Eine Lizenz pro verbundenes Hotel-System (Apaleo, Mews, Opera, Sihot, Casablanca, ASA, …).
• FiBu-Modul — Meist eine Lizenz pro Betrieb, unabhängig vom Steuerberater-System.
• Kiosk / Self-Order-Terminal — Eine Lizenz pro SB-Terminal.
• Gutscheinsystem / Gutscheinservice V3 — Eine Lizenz für das Gutschein-Backend; zusätzlich oft Online-Gutschein-Modul.
• Webshop / Online-Bestellsystem — Lizenz für Smorder / Online-Bestellmanager.
• Reservierung, WaWi, Loyalty, Payment-Terminal, Waage, Pager, Pickup-Box — jeweils eigene Zusatz-Lizenzen.
• Whitelabel-Partner / Franchise — Sammellizenzen mit eigener Pool-Verwaltung.

Problembehebung

• „Neue Kasse startet nicht — keine Lizenz" → Prüfen: wurde die Lizenz zugeordnet? Am Kassen-Client Verwaltung → Lizenzverwaltung → Lizenz holen ausführen. Internet nötig.
• „Lizenzierung funktioniert nicht" → Oft Firewall oder fehlende Internetverbindung zum APRO-Lizenzserver. Netzwerk prüfen. Wenn das nicht hilft: Support.
• „Lizenz bei Hardware-Tausch nicht freigegeben — Support nötig?" → Wenn das alte Gerät noch startet: selbst freigeben (siehe Ablauf). Wenn nicht: ja, Support kontaktieren. Im Notfall neue Bestellung mit Hinweis „Hardwaretausch".
• „Fehlermeldung: Automatische Gutscheinnummernvergabe deaktiviert" → Die Gutschein-Lizenz ist abgelaufen oder auf einem anderen Gerät belegt. Lizenz-Übersicht prüfen.
• „Nach Zeitumstellung: Lizenz-Check schlägt fehl" → Bekannter Randfall im Frühjahr/Herbst. Der interne Dienst (BaseDataService) hängt kurz fest. Ein bis zwei Stunden später löst sich das von selbst; der Lizenz-Check ist in diesem Fenster nicht zwingend nötig.
• „Modul ist gebucht, wird in my.apro aber nicht angezeigt" → Rolle des Benutzers prüfen — die Modul-Sichtbarkeit hängt auch an der Rolle. Oder: Lizenz wurde noch nicht vom Vertrieb freigeschaltet — im Zweifel beim APRO-Vertriebspartner nachfragen.
• „Wir haben mehr Kassen als Lizenzen" → Lizenz-Übersicht zeigt die Differenz. Entweder alte Kasse freigeben oder Nachbestellung beim Vertrieb.
• „Wie verlängere ich die Jahreslizenz?" → Meist läuft das über den APRO-Vertriebspartner / die Rechnungsstelle. In my.apro selbst nur einspielen, wenn ein neuer Schlüssel geliefert wurde.

Siehe auch

• userrollen.md — Welche Rolle darf Lizenzen einspielen
• stammdaten-sync-konfig.md — Sync benötigt eine gültige Basis-Lizenz
• online-reports.md — Einige Berichte sind nur bei aktivem Modul sichtbar
• kundenkarte-admin.md — Gutschein-Modul als eigene Lizenz
• Technik-Wiki: „Lizenz übertragen nach Hardwaretausch", „APRO Lizenz ausstellen"

Zielgruppe: Chef, Büro (mit Unterstützung durch APRO bei der Erst-Einrichtung)
Typische Nutzung: Einmalig bei Inbetriebnahme, danach nur bei größeren Umstellungen (neues Lokal, Rebranding, neue Öffnungszeiten-Logik)
Aufruf: my.smorder.at (Administrator-Login) — Hauptmenü „Allgemein", „App", „Payment", „Module"

Zweck

Bevor der Gast die erste Online-Bestellung absetzen kann, muss im Hintergrund eine ganze Reihe an Stammdaten gepflegt sein: das Lokal selbst, die Zahlungsanbindung, die Menükarte, die Workflows zur Kassa, die Identifikation des Gastes, das Design des Webshops und die Verknüpfung zur bestehenden APRO-Kasse. Dieser Artikel beschreibt die empfohlene Reihenfolge und erklärt, was aus Büro-Sicht in welcher Phase vorbereitet werden muss. Er ersetzt keine der Detail-Artikel (Payment, Menükarte, Lieferzonen) — er sortiert sie zeitlich.

Ablauf

Empfohlene Reihenfolge der Einrichtung:

1. Vorab-Abstimmung mit APRO — Lizenz-Lage klären, Services anlegen (Smorder Service, OrderService, BillingService), Payment-Integration (Stripe/PayPal) initial durch APRO anlegen. Dieser Schritt läuft nur einmal für den Betrieb.
2. Lokal anlegen — im Smorder-Backoffice unter „Allgemein → Lokal hinzufügen" das Lokal mit Namen, Anschrift, Kontakt und Hauptsprache erfassen. Bei Filialbetrieben: ein Lokal pro Standort.
3. Lokalinformationen pflegen — Bild/Logo, Öffnungszeiten, Beschreibungstext, angebotene Services (Vor-Ort, Abholung, Lieferung). Diese Informationen erscheinen sowohl im Webshop als auch in der Smorder-App.
4. Zahlungsmittel konfigurieren — Stripe und/oder PayPal aktivieren (siehe stripe-paypal-zahlung.md). Pro Methode die Sichtbarkeit setzen. Bar- oder Kartenzahlung an der Kassa zusätzlich als „Zahlung bei Abholung/Lieferung" aktivieren.
5. Kassenseitige Vorbereitungen — auf der APRO-Kasse Online-Tisch anlegen, Online-Kellner anlegen, Druckerzuordnung für Online-Bestellungen (eigenes Profil), Sammelbestellbon aktivieren (oder nicht), Zahlungsmittel „Smorder Kreditkarte / Smorder PayPal / Smorder Bar" anlegen. Die IDs dieser Zahlungsmittel werden im Smorder-Backoffice beim TPS-User hinterlegt.
6. Menükarten aufbauen — Kategorien, Artikel, Bilder, Beschreibungen, Allergene, Mehrsprachigkeit (siehe menuekarten-management.md). Diesen Schritt nicht unterschätzen — er ist der zeitaufwändigste.
7. Flow(s) auswählen und einrichten — Vor-Ort, Abholung, Lieferung. Pro Flow die Bestellkriterien (Vorbestellzeit, Trinkgeld, Mindestbestellwert) setzen (siehe preorder-takeaway-delivery.md).
8. Lieferzonen pflegen (falls Lieferung) — Zonen, Zeitfenster, Pauschalen, Kapazitäten (siehe lieferzonen-lieferzeiten.md).
9. Gast-Identifikation und Ausgabe-Kanäle — Pager, Abholname oder Bestellnummer? Wo wird ausgedruckt? Bestellbon, Kundenbon, Küchenmonitor?
10. Design und Domain — Hauptfarbe, Logo-Farbvariante, Startbild, optional eigene Domain (z. B. bestellen.eigenesrestaurant.at) als CNAME-Weiterleitung.
11. QR-Aufsteller / QR-Codes erzeugen — über das QR-Modul im Backoffice werden Tischaufsteller-PDFs generiert, die der Gast vor Ort scannt.
12. Gutscheine einbinden (optional) — Online-Verkauf und -Einlösung freischalten (siehe online-gutschein-einloesung.md).
13. Test-Durchlauf — mindestens je ein Durchlauf pro aktivem Flow mit Echt-Zahlung. Der Testbetrag kann anschließend refundiert werden.
14. Live-Schaltung und Kommunikation — Webshop-Link an Gäste kommunizieren (Website, Social Media, Speisekarte, QR-Aufsteller an Tischen).

Einstellungen

Zentrale Bereiche im Smorder-Backoffice und wie sie ineinandergreifen:

• Lokalprofil — Allgemein. Name, Adresse, Kontakt, Öffnungszeiten, Bilder, Beschreibung.
• App-Darstellung — App. Hauptfarbe, Startscreen, Logo, Services, Sichtbarkeit einzelner Funktionen (Warteliste, Pager, Abholname, Trinkgeld).
• Payment — Payment → App-/Web-Payment und Payment → Auszahlungsreports. Pro Methode aktiv/inaktiv, Auszahlungs-E-Mail, Berichts-Intervall.
• Module → Bestellungen — Bestellkriterien pro Flow, Vorbestellzeit, Tage im Voraus, Mindestbestellwert.
• Module → Zustellung — Lieferzonen und Lieferzeiten (falls Flow Delivery aktiv).
• Menükarte — Karten, Kategorien, Artikel, Mehrsprachigkeit, Sichtbarkeit, Wochenmenü.
• App → Workflows — Wohin geht die Bestellung nach Annahme (TPS Quick, Abholbereit/Abgeholt, Bestellmanager).
• User → Bediener und Mitarbeiter — Anlage eines „Online-Kellners" (falls Waiter-UI genutzt wird) und Büro-Administratoren.
• Schnittstellen → TPS-User — Verknüpfung der Smorder-Zahlungsmittel mit den Kassen-Zahlungsmittel-IDs.
• Administration → QR / Design — QR-Aufsteller und Tischcode-PDF-Vorlagen.
• Administration → Logs — zum Nachschauen, wenn eine Bestellung nicht durchkommt; für Büro nützlich bei Support-Fällen.

Verknüpfung my.apro

Smorder und my.apro sind zwei Oberflächen, aber eine Stammdaten-Welt: Artikel, Preise, MwSt und Sparten kommen aus der Kassenstammdatenpflege in my.apro; Online-spezifisches (Bilder, Online-Beschreibung, Sichtbarkeit online, Bestellzeiten, Lieferzonen, Payment) liegt im Smorder-Backoffice. Änderungen an Kassenartikeln wirken nach kurzer Synchronisation auch online. Umgekehrt sieht die Kassa die Online-Bestellung wie eine normale Tischbestellung, weil dahinter ein eigens angelegter Online-Tisch und ein Online-Kellner hängen. Wer die Stammdaten sauber in my.apro pflegt, hat 80 % der Webshop-Einrichtung schon erledigt.

Berechtigungen

Varianten

• Einzelbetrieb — ein Lokal, eine Menükarte, ein Zahlungsvertrag. Einfachster Fall, Setup in 1–2 Tagen nach Stammdaten-Grundlage machbar.
• Filialbetrieb mit gemeinsamer Karte — mehrere Lokale, identische Menükarte, getrennte Stammdaten pro Standort. Zahlungsverträge pro Filiale, Menükarte zentral gepflegt und auf alle Lokale ausgerollt.
• Filialbetrieb mit individueller Karte — jede Filiale pflegt ihre eigene Karte (z. B. bei regionalen Unterschieden).
• Reiner Gutscheinshop — der Webshop dient nur dem Gutscheinverkauf, keine Speisen-Bestellung. Einrichtung mit deaktivierten Bestell-Flows, nur Gutschein-Modul eingebunden (siehe online-gutschein-einloesung.md).
• Kiosk-Setup — Smorder als Self-Order-Terminal im Lokal; Setup umfasst zusätzlich die Kiosk-App auf dem Tablet und das Kiosk-Profil auf der Server-Kasse.
• Hybrid mit Lieferportalen — eigener Smorder-Webshop plus Lieferando/MJAM/Wolt/Foodora parallel. Setup pro Portal separat.

Problembehebung

• „Checkout-Button ist grau" → Kein aktives Zahlungsmittel; entweder Stripe/PayPal noch nicht live oder Lokal hat keinen Flow aktiv.
• „Menükarte leer" → Karte noch nicht aktiviert, Gültigkeit liegt in der Zukunft oder Kategorien sind unsichtbar gestellt.
• „Bestellung kommt nicht in der Kasse an" → Online-Tisch fehlt, Online-Kellner fehlt oder der Smorder-/OrderService-Dienst auf der Server-Kasse ist nicht gestartet.
• „Auszahlung kommt nicht" → Auszahlungs-Report im Payment-Bereich fehlt oder Stripe-Konto ist noch in Prüfung durch Stripe-Compliance.
• „Mail-Bestätigung hat kein Logo" → Logo nicht in den PDF-Mail-Einstellungen hinterlegt.
• „Fehler beim Veröffentlichen der Karte" → mindestens ein Artikel ohne MwSt, ohne Preis oder ohne Sparte. In my.apro prüfen und nachpflegen.
• „Gast sieht den Webshop auf Englisch, obwohl Deutsch Hauptsprache ist" → Hauptsprache des Lokals prüfen; Browser-Sprache überschreibt nur, wenn eine passende Übersetzung existiert.

Siehe auch

• menuekarten-management.md — Aufbau und Pflege der Online-Karten
• preorder-takeaway-delivery.md — Auswahl der Bestell-Flows
• lieferzonen-lieferzeiten.md — Lieferung einrichten
• stripe-paypal-zahlung.md — Zahlungsanbindung
• online-gutschein-einloesung.md — Gutschein im Webshop
• ../myapro/artikelverwaltung.md — Pflege der Kassenartikel, die in die Menükarte einfließen
• ../myapro/stammdaten-sync-konfig.md — Stammdaten-Sync zwischen my.apro und Kasse
• ../myapro/lizenz-uebersicht.md — Lizenzierung der benötigten Module
• ../myapro/online-reports.md — Auswertung der Online-Umsätze
• ../uebergreifend/fibu-ablauf.md — Verbuchung der Online-Umsätze im Monatsabschluss

Zielgruppe: Chef, Büro, Buchhaltung, Controlling
Typische Nutzung: Wenn zwei Berichte unterschiedliche Summen zeigen und geklärt werden muss, warum
Aufruf: my.apro → Reporting (Onlineberichte) bzw. Kassen-Client → Abschlüsse (Kassenberichte)

Zweck

APRO liefert Auswertungen aus drei Quellen: Kassenberichte ([K], z.B. Z-Bericht, Spartenbericht), Onlineberichte ([O], my.apro-Reporting) und externe Berichte ([E], z.B. Terminal oder Hotel). Diese Berichte sind nicht beliebig vergleichbar, weil ihnen unterschiedliche Berechnungslogiken zugrunde liegen: manche zählen abgerechnete Artikel (A), andere bonierte Artikel (B); manche beziehen offene Tische oder nicht verrechenbare Zahlungsmittel ein, andere nicht. Dieser Artikel erklärt, welche Berichte zusammenpassen und warum eine Differenz entsteht.

Grundregel: Onlineberichte sind ein informatives Abbild, nicht für buchhalterische Zwecke. Für FiBu/Finanzamt gilt der Z-Bericht (TagesZ).

Ablauf

Differenz zwischen zwei Berichten klären:

1. Bericht-Typ bestimmen — Kassenbericht [K], Onlinebericht [O] oder extern [E]?
2. Datenbasis bestimmen — zählt der Bericht abgerechnete Artikel (A) oder bonierte Artikel (B)?
3. Vergleichbarkeit prüfen — in der Tabelle unten nachsehen, ob die Kombination „ja / teilweise / nein" ist.
4. Bei „teilweise / nein" — die Begründung beachten (offene Tische, TIP, nicht verrechenbare Zahlungsmittel).
5. TIP herausrechnen — beim TagesZ ist die Trinkgeldsumme immer im Gesamtbetrag inkludiert; für Spartenvergleiche abziehen.

Einstellungen

• Tagesabschlusszeit (virtueller Tag) — Onlineberichte rechnen ab Regel-Tagesabschlusszeit (Standard 05:00). Ein „Tag" ist z.B. 04.07. 05:00 bis 05.07. 05:00.
• Rechnungen aktivieren — Administration → Schnittstellen: Standard-Kellner-ID (z.B. 9999) und Standardbetrieb (1) setzen, sonst fehlen Online-Rechnungen.
• Verrechenbar / nicht verrechenbar — wird über die Zahlungsmittelgruppe gesteuert (siehe zahlungsmittel.md). Bestimmt, ob ein Zahlungsmittel umsatzwirksam in Berichte einfließt.

Vergleichbarkeit der Berichte

[K] Kassenbericht · [O] Onlinebericht · [E] extern · (A) abgerechnet · (B) boniert

TagesZ / Z-Bericht — Aufbau

Der TagesZ gibt alle Umsätze zwischen zwei Z-Berichten aus und setzt sie danach auf 0 zurück. Er ist der Nachweis gegenüber dem Finanzamt.

• Allgemein — Betriebsdaten, fortlaufende Tagesbericht-Nr., erste/letzte Buchung.
• Steuern — Bruttosummen je Steuerklasse, abzuführende Steuer, Nettosummen; danach die steuerlich relevanten (verrechenbaren) Zahlungsmittel. Lieferscheine und Stornobuchungen sind hier NICHT enthalten.
• Sparte — Übersicht aller bebuchten Sparten gruppiert nach Steuersatz; Summe = Brutto-Gesamtumsatz.
• Finanzwege — alle verwendeten Zahlungsmittel (auch nicht verrechenbare); umsatzsteuerrelevant sind nur verrechenbare. Bar unterteilt in Losung (inkl. TIP) und bezahlte AR; danach Lieferscheine (noch nicht umsatzrelevant).
• Zusammenfassung — „Losung" = alle umsatzrelevanten Zahlungswege ohne AR/Lieferschein, minus TIP. TIP ist im Gesamtbetrag immer inkludiert und muss für Vergleichsrechnungen abgezogen werden. Beispiel: Bar 110,- + Gutscheine 8,30 + bezahlte AR 175,80 − TIP 5,40 = 288,70 (= Spartensumme).
• Storno / zurückgeholte Geschäftsfälle, Abrechnungs- und Bonierstatistik je Bediener, Gutscheine (ausgestellt vs. eingelöst) runden den Bericht ab.

Berechtigungen

Varianten

• [K] vs. [O] — Kassenbericht (abgerechnet) gegen Onlinebericht (oft boniert): selten 1:1 vergleichbar.
• [O] vs. [O] — Onlineberichte untereinander: nur bei gleicher Datenbasis (A vs. A) deckungsgleich.
• [E] vs. [K] — Terminalschnitt gegen Kassen-Zahlungsarten: bei Kartenzahlung gut vergleichbar.
• TagesZ als Referenz — der einzige fiskalisch maßgebliche Bericht.

Problembehebung

• „Spartensumme ≠ Losung" → TIP-Summe abziehen; Losung enthält kein TIP, der Gesamtbetrag schon.
• „Online-Übersicht höher als Spartenbericht" → Übersicht enthält offene (bonierte) Tische, Spartenbericht nur abgerechnete.
• „Zahlungsmittel-Bericht ≠ Übersicht" → Zahlungsmittel zählt nur abgerechnet, Übersicht offen+abgerechnet — nicht vergleichbar.
• „Online-Rechnungen fehlen" → In Administration → Schnittstellen Standard-Kellner-ID und Standardbetrieb setzen.
• „Tagesgrenze stimmt nicht" → Onlineberichte rechnen ab 05:00 (virtueller Tag); nicht von 00:00.
• „Lieferschein fehlt im Umsatz" → Lieferscheine sind noch nicht umsatzrelevant und in Steuern/Losung bewusst nicht enthalten.

Siehe auch

• online-reports.md — Definition der einzelnen Onlineberichte und ihrer Datenbasis
• zahlungsmittel.md — Verrechenbar/nicht verrechenbar steuert die Berichtszuordnung
• ../uebergreifend/tagesabschluss.md — Wann und wie der Z-Bericht erstellt wird
• ../uebergreifend/fibu-ablauf.md — Welche Berichte in den FiBu-Export fließen
• stuetzungen.md — Stützungs-Splits als häufige Quelle von Rundungsdifferenzen

Zielgruppe: Chef, Büro, Betriebsleiter
Typische Nutzung: Zeitgesteuerte Sonderpreise (Happy Hour, Aktionsfenster) einstellen
Aufruf: my.apro → Happy Hour

Zweck

Über den Menüpunkt Happy Hour wird ein zeitgesteuertes Aktionsfenster eingestellt, in dem die Kasse automatisch eine andere Preiskategorie verwendet. Man legt Start- und Enddatum sowie die in diesem Zeitraum gültige Preiskategorie fest. Während des Fensters bonieren die Kellner automatisch mit den Aktionspreisen, außerhalb wieder mit dem Normalpreis.

Die Preise je Preiskategorie/Preisebene werden im Artikelstamm gepflegt — siehe ../bonneu/preisebenen.md. Happy Hour ist die zeitliche Steuerung, welche Preiskategorie wann gilt.

Ablauf

Happy Hour einstellen:

1. my.apro → Happy Hour öffnen.
2. Start- und Enddatum (bzw. Zeitfenster) festlegen.
3. Gültige Preiskategorie für das Zeitfenster wählen.
4. Speichern — ab sofort gilt im Fenster automatisch die gewählte Preiskategorie.

Alternativ im Listenmodus:

1. In den Listenmodus wechseln.
2. Einträge übersichtlich in Listenform anlegen/bearbeiten.
3. Speichern.

Einstellungen

• Zeitfenster — my.apro → Happy Hour → Start-/Enddatum.
• Gültige Preiskategorie — Happy Hour → Preiskategorie. Diese Kategorie wird im Fenster automatisch boniert.
• Listenmodus — alternative Listenansicht zum Pflegen mehrerer Einträge.
• Preise je Kategorie — im Artikelstamm (../bonneu/preisebenen.md); ohne Ebenenpreis greift der Grundpreis.

Berechtigungen

Varianten

• Klassische Happy Hour — täglich/wöchentliches Fenster mit reduzierten Getränkepreisen.
• Aktionszeitraum — einmaliges Start-/Enddatum für eine befristete Aktion.
• Mittagstisch — Zeitfenster mit verbilligtem Hauptgang (siehe Preisebenen).
• Listenmodus — mehrere Fenster gesammelt pflegen.

Problembehebung

• „Happy Hour startet nicht pünktlich" → Uhrzeit an Kasse/Server prüfen; bei mehreren Geräten Zeitsynchronisation sicherstellen.
• „Im Fenster gilt trotzdem der Normalpreis" → Hat der Artikel in der gewählten Preiskategorie überhaupt einen Preis? Ohne Ebenenpreis fällt die Kasse auf den Grundpreis zurück.
• „Falsche Preiskategorie" → In den Happy-Hour-Einstellungen die gültige Preiskategorie prüfen.
• „Bericht zeigt weniger Umsatz" → Korrekt — der Aktionspreis ist niedriger; der Umsatz fällt entsprechend geringer aus.

Siehe auch

• ../bonneu/preisebenen.md — Preise je Preiskategorie/Ebene (Mechanik hinter Happy Hour)
• ../bonneu/rabatte.md — Abgrenzung Rabatt (ad hoc) vs. Preisebene (eingestellt)
• artikelverwaltung.md — Preise im Artikelstamm pflegen

Zielgruppe: Chef, Büro, Marketing
Typische Nutzung: Kunden in Gruppen sortieren, Stammkunden/Geschäftskunden pflegen, Rabatte/Preiskategorien je Kunde
Aufruf: my.apro → Kunden (Reiter „Kundengruppen" bzw. „Kunden")

Zweck

Kundengruppen bündeln Kunden in sinnvolle Kategorien (z.B. Stammgäste, Firmenkunden, Vereine), damit sie auf der Kasse und in my.apro besser verwaltet und sortiert werden können. Die eigentlichen Kundendaten — egal ob am Bon-Client oder in my.apro angelegt — werden gemeinsam gepflegt: Anlegen, Ändern und Löschen ist an beiden Stellen möglich. Pro Kunde lassen sich Rabatt, Preiskategorie, Konsumationslimit und FiBu-Konto hinterlegen.

Ablauf

Kundengruppe anlegen:

1. my.apro → Kunden → Kundengruppen öffnen.
2. Neu wählen und Bezeichnung vergeben.
3. Speichern — die der Gruppe zugewiesenen Kunden werden darunter angezeigt.

Kunde anlegen / bearbeiten:

1. ** — bestehende Kunden (auch die am Bon-Client erfassten) erscheinen. (Menüpfad nicht in den my.apro-Navigationsdaten belegt.)
2. Neu wählen oder bestehenden Kunden öffnen.
3. Abschnitte ausfüllen — Allgemein, Kategorisierung, Kontaktdaten, Sonstige Infos.
4. Kundengruppe zuordnen (Abschnitt Kategorisierung).
5. Speichern.

Kunden im Listenmodus bearbeiten:

1. In der Kundenansicht über die Kopfzeile den Listenmodus / Profimodus aufrufen.
2. Kunden übersichtlich bearbeiten, sortieren, ergänzen oder löschen.
3. Optional als CSV-Datei exportieren.

Einstellungen

Felder im Kundenstamm:

• Allgemein — Nr. (automatisch), Anzeigename (auf der Kasse), Anrede/Titel, Vorname/Nachname (Privat), UID-Nr., Firmenname, „zu Handen" (Geschäftskunden).
• Kategorisierung — Kundentyp (Privat/Geschäftlich), Kundengruppe, Rabatt (Standardrabatt), Preiskategorie (Standard-Preisebene des Kunden), Konsumationslimit (max. Konsumation in €, leer = kein Limit).
• Kontaktdaten — E-Mail, Telefon privat/geschäftlich, Straße/Land/Ort/PLZ (wird auf die Rechnung gedruckt).
• Sonstige Infos — Externe Nr., FiBu-Konto (Umsatz des Kunden für FiBu-Export), Abteilung, Kontaktperson.

Berechtigungen

Varianten

• Privatkunde — Anrede/Titel, Vor-/Nachname, private Kontaktdaten.
• Geschäftskunde — Firmenname, UID-Nr., „zu Handen", FiBu-Konto.
• Stammkundengruppe mit Preiskategorie — Gruppe + Standard-Preisebene = automatischer Stammkundenpreis (siehe ../bonneu/preisebenen.md).
• Kunde mit Konsumationslimit — z.B. Mitarbeiter-/Kantinenkunde mit gedeckeltem Verbrauch.
• Kunde mit Standardrabatt — fester Rabatt bei jeder Abrechnung dieses Kunden.
• Bon-Client vs. my.apro — derselbe Kundenstamm, an beiden Stellen pflegbar.

Problembehebung

• „Kunde am Bon angelegt, fehlt in my.apro" → Sync prüfen (siehe ../uebergreifend/sync-kasse-myapro.md); Kunden werden zwischen Kasse und my.apro synchronisiert.
• „Stammkundenpreis greift nicht" → Preiskategorie am Kunden gesetzt? Wurde der Kunde beim Bonieren/Abrechnen ausgewählt?
• „Konsumationslimit wird ignoriert" → Feld leer = kein Limit. Wert eintragen.
• „Rabatt doppelt" → Standardrabatt am Kunden plus manueller Rabatt addieren sich — bewusst prüfen.
• „FiBu bucht Kundenumsatz nicht getrennt" → FiBu-Konto am Kunden hinterlegen.
• „CSV-Export unvollständig" → Filter im Listenmodus prüfen; Export bezieht die aktuelle Filterung mit ein.

Siehe auch

• kundenkarte-admin.md — Guthaben/Kundenkarte zu den Kunden
• ../bonneu/preisebenen.md — Kundenbezogene Preiskategorie
• ../uebergreifend/stuetzungen.md — Kundengruppen als Basis für Stützungen/Mitarbeitertarife
• ../bonneu/abrechnen-kundenkonto.md — Abrechnung auf Kundenkonto
• ../uebergreifend/sync-kasse-myapro.md — Synchronisation des Kundenstamms

Zielgruppe: Büro, Chef
Typische Nutzung: Einmalig beim Einrichten der Gutschein-/Kundenkarten-Welt, danach laufend beim Pflegen einzelner Kunden oder bei Aktionen
Aufruf: my.apro → Kassenmodule → Gutscheine und my.apro → Onlinemodule → Gutscheine / Kundenkarten

Zweck

Gutscheine und Kundenkarten sind zwei Seiten desselben Themas: Kundenbindung und Vorauszahlung. In my.apro legt das Büro fest, welche Gutscheinvorlagen es gibt, wie Online-Gutscheine funktionieren, wer Kundenkarten mit Guthaben betreiben darf und wie viel Guthaben ein einzelner Kunde hat. Der Kellner am Kassen-Client muss dann beim Einlösen nur noch den Code scannen — alles andere läuft automatisch.

Ablauf

Gutschein-Vorlage anlegen (klassisch, am Lokal gekauft):

1. my.apro → Kassenmodule → Gutscheine → Vorlagen → Neu (Voraussetzung: Gutscheinservice ist aktiv und lizenziert).
2. Name (z.B. „Hausgutschein"), Gültigkeitsdauer, Code-Länge.
3. Optional: Design für den gedruckten Gutschein (Logo, Text).
4. Speichern.
5. Am Kassen-Client wird der Gutschein beim Verkauf automatisch mit einer eindeutigen Nummer versehen.

Online-Gutschein-Vorlage einrichten:

1. Vorlage wie oben anlegen, aber Code-Generierung auf „benutzerdefiniert" setzen. Das ist für Online-Gutscheine Pflicht.
2. Name klar trennen (z.B. „Online-Gutschein"), damit gedruckte und Online-Gutscheine in Berichten unterscheidbar sind.
3. Gutschein-Artikel anlegen (Artikeltyp „Gutschein") für den Verkauf im Webshop.
4. Gutschein-Zahlungsmittel an der Kasse einrichten (falls nicht vorhanden).
5. Online-Zahlungsmittel für den Webshop — my.apro → Onlinemodule → Payment.
6. Schnittstelle konfigurieren — `my.apro → Kassenmodule → Administration → Schnittstellen`: Online-Zahlungsmittel, Gutschein-Zahlungsmittel und Gutschein-Vorlage verknüpfen.
7. Online-Gutscheine anlegen / Kategorie pflegen — `my.apro → Onlinemodule → Gutscheine` (Betrag, Motiv, Verkaufsstart).
8. Im App-/Webshop testen, ob der Kauf funktioniert.

Gutschein-Typen:

• Klassischer Gutschein — entsteht erst bei Verkauf.
• Vorabverkauf / Werbung — Gutscheine sind sofort im System, werden als „Werbung" verbucht.
• Vordruck (Wert 0) — Codes werden generiert, aber erst an der Kasse mit Wert aufgeladen.
• Promo-Code — Sofort aktiv, wird auf „Werbung" abgerechnet, bei Teileinlösung läuft ein Rabattartikel.

Kundenkarten-Guthaben pflegen:

1. my.apro → Kassenmodule → Benutzer → Kunden — einzelnen Kunden öffnen oder neu anlegen.
2. Karten-ID mit dem Kunden verknüpfen (oft ein Barcode / NFC-Tag).
3. Guthaben aufladen — Betrag manuell eintragen oder durch Verkauf an der Kasse (Aufbuch-Artikel).
4. Guthaben abfragen — im Kunden-Datensatz sichtbar; an der Kasse zeigt der Kassen-Client das Guthaben beim Scannen der Karte.
5. Korrektur-Buchung — manuell erhöhen/reduzieren in my.apro (z.B. Kulanz, Stornierung).

Online-Gutschein einlösen:

1. Der Kellner scannt oder tippt den Code am Kassen-Client beim Abrechnen ein.
2. Das Gutschein-System prüft: gültig? Wie hoch der Restwert?
3. Betrag wird vom Rechnungsbetrag abgezogen; der Rest zahlt der Gast in bar, Karte oder anderem Zahlungsmittel.
4. Teileinlösungen werden beim Code vermerkt, damit beim nächsten Einsatz der Restwert stimmt.

Einstellungen

• Gutscheinservice (Backend) — muss laufen. Status unter `my.apro → Kassenmodule → Administration → Dienste`.
• Benutzerdefinierter Gutscheincode — Pflicht für Online-Gutscheine, damit extern erzeugte Codes angenommen werden. In der Vorlage aktivieren.
• Gutschein als Zahlungsmittel — `my.apro → Kassenmodule → Payment → Zahlungsmittel`. Braucht ein FiBu-Konto.
• Online-Gutschein-Einbindung — my.apro → Onlinemodule → App-/Webshop für die Kunden-Oberfläche; my.apro → Kassenmodule → Administration → Schnittstellen für die Verknüpfung.
• Gutscheinprüfung (Onlinerolle) — Für Partner oder Callcenter: Rolle „Gutscheinprüfung" erlaubt reine Abfrage eines Codes ohne weiteres my.apro-Recht.
• Kundenkarten-Guthaben — direkt im Kundenstamm; externe Systeme können per Schnittstelle Guthaben abfragen und verändern.
• Gutschein-Vorlage für Aktionen — mehrere Vorlagen parallel (Haus, Weihnachten, Mitarbeiter, Sponsoren). Jede Vorlage hat eigene Abrechnungslogik.

Berechtigungen

Varianten

• Nur Haus-Gutscheine — Einfachster Fall: eine Vorlage, Verkauf nur an der Kasse. Kein Webshop nötig.
• Online-Gutscheine zusätzlich — Eigene Vorlage mit benutzerdefiniertem Code, Verkauf im Webshop, Einlösung sowohl online als auch im Lokal.
• Werbe-/Promo-Code-Aktion — Marketing-Kampagne mit vielen gleichartigen Codes (z.B. „10€ willkommen"). Über Promo-Code-Vorlage.
• Externes Gutschein-System (z.B. Incert) — Andere Plattform erzeugt die Codes; my.apro fragt via Schnittstelle ab, ob Code gültig ist.
• Kundenkarten ohne Guthaben — Nur zur Identifikation (Stammgast, Mitarbeiter), um Kundengruppen-Preise oder Stützungen auszulösen.
• Kundenkarten mit Guthaben — Vorausbezahltes System (z.B. Kantine, Stadionkarte, Mitarbeiterkonto).
• Mehrbetriebs-Gutschein — Ein Gutschein ist in mehreren Filialen einlösbar. Setzt zentrales Gutscheinsystem voraus.
• Migration alter Gutschein-Bestände — Wenn ein Betrieb von einem Alt-System auf das aktuelle Gutscheinsystem wechselt, lassen sich Bestände übernehmen (Support-begleitet).

Problembehebung

• „Online-Gutschein wird an der Kasse nicht gefunden" → Prüfen: ist der Vorlagentyp in Administration → Schnittstellen hinterlegt? Läuft der Gutscheinservice? Ist die Code-Generierung auf „benutzerdefiniert" gestellt?
• „Gutschein wurde online storniert, Kasse zeigt ihn noch als gültig" → Online-Stornos laufen nicht automatisch zurück auf die Kasse. Ein online stornierter Gutschein muss auf der Kasse mit sich selbst abgerechnet werden, um den Bestand zu korrigieren.
• „Teileinlösung funktioniert nicht — Gutschein ist nach 10€ verbraucht" → Bei Promo-Codes wird bei Teileinlösung oft ein Rabattartikel gebucht statt Restwert. In der Vorlage prüfen, ob Teileinlösung explizit erlaubt ist.
• „Guthaben einer Kundenkarte wird am Terminal nicht angezeigt" → Karten-ID am Kunden nicht verknüpft oder Karte gesperrt. my.apro → Kunden → [Kunde] öffnen.
• „Kunde behauptet, Guthaben fehlt — in my.apro ist weniger" → Historie des Kunden prüfen: letzte Aufbuchung, letzte Abbuchung, Tagesdatum. Bei echtem Fehler Kulanzbuchung + Notiz.
• „Fehlermeldung: Automatische Gutscheinnummernvergabe deaktiviert" → Gutschein-Lizenz nicht aktiv oder Gutscheinservice gestoppt. Siehe lizenz-uebersicht.md bzw. Support.
• „Online-Gutschein-Mail kommt beim Kunden nicht an" → Spam-Ordner, Mail-Adresse beim Kauf korrekt, Smorder-/Webshop-Versand aktiv. Notfalls im my.apro-Bestell-Detail den Code manuell nachsenden.
• „Mitarbeiter hat Kundenkarten-Guthaben eines Ex-Kollegen" → Karte im Kundenstamm auf den neuen Mitarbeiter umschreiben oder alte Karte sperren und neue ausgeben. Guthaben per Korrekturbuchung übertragen.

Siehe auch

• artikelverwaltung.md — Gutschein- und Aufbuch-Artikel anlegen
• stuetzungen.md — Kundenkarte als Auslöser für Kundengruppen-Preise
• online-reports.md — Gutscheinsaldo und offene Gutschein-Bestände
• lizenz-uebersicht.md — Gutschein- und Online-Module als eigene Lizenzen
• stammdaten-sync-konfig.md — Kundendaten und Gutschein-Vorlagen werden synchronisiert
• ../uebergreifend/fibu-ablauf.md — FiBu-Konten für Gutschein- und Stützungs-Zahlungsmittel

Zielgruppe: Chef, Büro, Wareneinkauf
Typische Nutzung: Sollbestände und Schwellenwerte pflegen, Bestandskontrolle, Bestellvorschläge
Aufruf: my.apro → Kassenmodule → Lagerverwaltung → Lagerverwaltung

Zweck

Die Lagerverwaltung in der Onlineverwaltung gibt einen Überblick über alle angelegten Lagerorte und die ihnen zugewiesenen Artikel. Das Büro kontrolliert hier die Lagereinstellungen, pflegt Sollbestände (Mindestmengen) und Schwellenwerte und steuert, ab wann ein Artikel als nachzubestellen gilt. So bleibt der Wareneinsatz planbar, und auslaufende Bestände fallen früh auf.

Wichtig: Das Anlegen von Lagerorten und die Grundeinstellungen des Lagers erfolgen aktuell in der APRO-Suite. In my.apro werden diese Einstellungen kontrolliert und Sollbestände/Schwellenwerte angepasst.

Ablauf

Sollbestände und Schwellenwerte pflegen:

1. my.apro → Lager → Lagerverwaltung öffnen.
2. Lagerort wählen — im linken Bereich sind alle angelegten Lagerorte gelistet.
3. Einstellungen prüfen — in der Mitte erscheinen die Einstellungen zum gewählten Lagerort.
4. Zugewiesene Artikel ansehen — der untere Bereich zeigt alle dem Lager zugewiesenen Artikel.
5. Pro Artikel Mindestmenge (Sollmenge) und Schwellenwert eintragen.
6. Nachfasslager definieren und Bestellvorschlag aktivieren (optional).
7. Änderungen speichern.

Lagerliste exportieren:

1. In der Lagerverwaltung Export wählen.
2. Selektion treffen — alle Lager oder nur ausgewählte. Bei „alle Lager" landet jedes Lager in einem eigenen Reiter der Excel-Datei.
3. Excel-Datei speichern und außerhalb bearbeiten.

Lagerliste importieren:

1. Die zuvor von APRO exportierte Excel-Liste bearbeiten (nur diese darf re-importiert werden).
2. In der Lagerverwaltung Import wählen und Datei hochladen.
3. Achtung: Importierte Mengen werden überschrieben, nicht ergänzt.

Einstellungen

• Lagerort anlegen / Grundeinstellungen — aktuell in der APRO-Suite (nicht in my.apro änderbar).
• Mindestmenge (Sollmenge) — Lagerverwaltung → [Lagerort] → [Artikel]. Untergrenze für die Bestandsplanung.
• Schwellenwert — Lagerverwaltung → [Lagerort] → [Artikel]. Ab diesem Wert gilt der Artikel als kritisch.
• Nachfasslager — Lagerort, aus dem nachgefüllt wird.
• Bestellvorschlag — Aktiviert automatische Bestellvorschläge anhand Soll/Schwellenwert.
• Import-Regel — Nur eine von APRO exportierte Liste re-importieren; Mengen werden überschrieben.

Berechtigungen

Varianten

• Mehrere Lagerorte — Küche, Bar, Keller getrennt geführt; jeder Lagerort hat eigene Sollbestände.
• Nachfasslager — Zentrallager liefert an Schanklager; Nachfüllung wird logisch abgebildet.
• Bestellvorschlag aktiv — System schlägt Nachbestellmengen vor, sobald Schwellenwert unterschritten ist.
• Export aller Lager — Sammel-Excel mit einem Reiter pro Lagerort für die Inventur.
• Selektiver Export — nur einzelne Lagerorte für eine Teil-Inventur.

Problembehebung

• „Grundeinstellung lässt sich in my.apro nicht ändern" → Korrektes Verhalten. Lagerorte/Grundeinstellungen werden in der APRO-Suite gepflegt; in my.apro nur Sollbestände/Schwellenwerte.
• „Import überschreibt meine Mengen" → So gewollt: Der Import setzt die Mengen, er ergänzt sie nicht. Vor dem Import die exportierte Liste vollständig befüllen.
• „Import schlägt fehl / Spalten passen nicht" → Es wurde keine von APRO exportierte Liste verwendet. Erst exportieren, diese Datei bearbeiten, dann re-importieren.
• „Bestellvorschlag bleibt leer" → Schwellenwert/Sollmenge pro Artikel gesetzt? Ohne Werte gibt es keinen Vorschlag.
• „Artikel fehlt im Lager" → Artikel ist dem Lagerort nicht zugewiesen — Zuweisung in der Suite prüfen.

Siehe auch

• artikelverwaltung.md — Artikelstamm als Basis der Lagerartikel
• lieferanten.md — Lieferanten für Einkauf und Bestellvorschläge
• ../bonneu/funktionsbuttons-uebersicht.md — Funktionstasten „Lager" / „Lagerort" öffnen die Suite-Lagereinstellungen
• online-reports.md — Auswertungen zum Warenverbrauch

Zielgruppe: Chef, Büro, Wareneinkauf, Buchhaltung
Typische Nutzung: Lieferantenstamm pflegen, Lieferantenabschläge erstellen, Anbindung an Lager/Faktura
Aufruf: my.apro → Kassenmodule → Lieferanten

Zweck

Im Lieferantenmodul werden die Lieferanten des Betriebs verwaltet. Der Lieferantenstamm liefert die Adress-, Kontakt- und Bankdaten für Bestellungen und Lieferantenrechnungen, das FiBu-Konto für den Buchhaltungsexport und die Verknüpfung zu den Artikeln im Lager. Außerdem ist der Lieferant die Basis für den Lieferantenabschlag im Reporting (Abrechnung gelieferter/abgeholter Ware in einem Zeitraum).

Ablauf

Lieferant anlegen / bearbeiten:

1. my.apro → Kassenmodule → Lieferanten öffnen — die Lieferanten erscheinen als Tabelle.
2. Neu wählen oder einen bestehenden Lieferanten zum Bearbeiten öffnen.
3. Stammdaten erfassen — Name, Nummer, Kontaktperson, Adresse (Straße, PLZ, Ort), E-Mail.
4. Buchhaltungsdaten — FiBu-Konto, UID, IBAN, BIC.
5. Speichern.

Lieferantenabschlag erstellen:

1. Im Lieferantenmodul (oder über Reporting → Abschlüsse → Lieferantenabschläge) den Abschlag-Dialog öffnen.
2. Lieferant und Zeitpunkt/Zeitraum wählen (Standard: Monatsbeginn ab virtuellem Tagesstart, z.B. 05:00).
3. Vorschau aktiviert lassen, um den Abschlag vor dem endgültigen Erstellen zu prüfen.
4. Abschlag erstellen bzw. erneut ausgeben; bei Bedarf einen bestehenden Abschlag wieder aufheben.

Einstellungen

• Lieferantenstamm — my.apro → Kassenmodule → Lieferanten. Felder: Nr., Name, FiBu-Konto, E-Mail, Kontaktperson, Adresse, PLZ, Ort, UID, IBAN, BIC.
• Automatische Lieferantenrechnung — my.apro → Kassenmodule → Administration → Betriebsdaten → autom. Lieferantenrechnung.
• Lieferanten-Umsatzartikel — Betriebsdaten → Lieferanten Umsatzartikel. Artikel, auf den der Lieferantenumsatz gebucht wird.
• Lieferanten-Provisionsartikel — Betriebsdaten → Lieferanten Provisionsartikel. Artikel für die Provisionsabrechnung.
• Lieferanten-Artikel-Zuordnung — Verknüpfung von Lieferanten zu Lagerartikeln (Inventory) als Basis für Bestellvorschläge.
• Virtueller Tagesstart — bestimmt die Standard-Zeitgrenze des Lieferantenabschlags (Betriebsdaten).

Berechtigungen

Varianten

• Reiner Stammdaten-Lieferant — nur Adresse/Bankdaten für Lieferantenrechnungen.
• Lager-Lieferant — mit Artikelzuordnung; speist Bestellvorschläge der Lagerverwaltung.
• Provisions-/Kommissionslieferant — Abrechnung über Umsatz-/Provisionsartikel (z.B. Konsignationsware).
• Lieferantenabschlag mit Vorschau — Abschlag erst als Vorschau prüfen, dann fix erstellen.
• Automatische Lieferantenrechnung — System erzeugt die Rechnung selbsttätig nach Betriebsdaten-Einstellung.

Problembehebung

• „Menüpunkt Lieferanten fehlt" → Modul-/Rollenfreigabe prüfen; ggf. APRO-Support kontaktieren.
• „Lieferant fehlt in der Artikelzuordnung" → Lieferant erst im Stamm anlegen, dann der Artikel-/Lagerzuordnung hinzufügen.
• „FiBu-Export bucht Lieferantenumsatz falsch" → FiBu-Konto am Lieferanten und Lieferanten-Umsatzartikel in den Betriebsdaten prüfen.
• „Lieferantenabschlag zeigt anderen Zeitraum" → Der Standardzeitpunkt richtet sich nach dem virtuellen Tagesstart (z.B. 05:00). Zeitpunkt im Dialog manuell anpassen.
• „Abschlag versehentlich erstellt" → Abschlag im Reporting wieder aufheben und neu erstellen.

Siehe auch

• lagerverwaltung.md — Lager und Bestellvorschläge nutzen die Lieferantenzuordnung
• ../uebergreifend/fibu-ablauf.md — FiBu-Konto und Lieferantenumsatz im Export
• online-reports.md — Lieferantenabschläge unter Reporting → Abschlüsse
• ../bonneu/funktionsbuttons-uebersicht.md — „Abschlüsse" enthält den Lieferantenabschlag am Kassen-Client

Zielgruppe: Chef, Büro
Typische Nutzung: Einmalig beim Einrichten des Lieferbetriebs, danach gelegentlich bei Anpassungen (Zone erweitern, Pauschale ändern, neue Öffnungszeiten)
Aufruf: my.smorder.at → Module → Zustellung (bzw. Delivery)

Zweck

Wer Lieferung anbietet, muss für jeden Gast vor dem Bestellen klar sein: Liefert der Betrieb überhaupt zu dieser Adresse? Wie teuer wird es? Wie lange dauert es? Ab welcher Bestellsumme liefert er? Lieferzonen und Lieferzeiten in Smorder sind die Antwort auf genau diese vier Fragen — gepflegt im Büro, automatisch wirksam im Webshop-Checkout. Der Gast gibt seine Adresse ein und sieht sofort, ob und unter welchen Bedingungen geliefert wird.

Ablauf Einrichtung

Typischer Ablauf „Lieferbetrieb scharfstellen":

1. Liefergebiet grob überlegen — Stadt-/Ortsteile, Umkreis in Kilometern, maximale Fahrzeit. Danach richtet sich, ob mit Postleitzahlen, Radius oder einer Kombination gearbeitet wird.
2. Basis-Lieferzeitfenster definieren — Pro Wochentag die Zeiten, in denen überhaupt zugestellt wird (z. B. Mo–Fr 17:00–22:00, Sa/So 11:30–22:00).
3. Zonen anlegen — entweder nach Postleitzahl (eine oder mehrere je Zone) oder nach Kilometer-Radius vom Lokal aus. Pro Zone werden Lieferpauschale, Mindestbestellwert und — falls nötig — ein abweichendes Zeitfenster hinterlegt.
4. Karten-/Adress-Prüfung konfigurieren — der Gast gibt im Checkout die Straße + Hausnummer + PLZ ein; das System prüft gegen die Zonen und zeigt entweder die Bedingungen oder eine Meldung „Leider liefern wir nicht in Ihr Gebiet".
5. Zuschläge einrichten — z. B. Wochenendzuschlag, Feiertagszuschlag, Nachtzuschlag ab 21:30, Mindestbestellwert für abgelegene Zonen.
6. Zustellzeitfenster pro Artikel — auf Menükartenebene lässt sich festlegen, ob ein Artikel überhaupt zugestellt werden darf (z. B. Eisgerichte nur bis Umkreis 3 km).
7. Fahrer- und Übergabe-Workflow — wie die Bestellung im Betrieb landet: eigener Lieferschein-Bon, Fahrer-Liste im Bestellmanager, optional Statusänderungen „In Zustellung"/„Zugestellt" über die Waiter-UI.
8. Test mit Realadressen — drei bis fünf Testadressen aus unterschiedlichen Zonen durchspielen, bevor live geschaltet wird.

Einstellungen

• Zonentyp — Postleitzahlen, Radius (Kilometer vom Betrieb), manuelle Polygon-Definition (wenn verfügbar). Typisch: kleines Stadtgebiet mit PLZ, größere Umkreise mit Radius.
• Lieferpauschale pro Zone — fixer Betrag, wird zur Rechnung addiert. Kann bei hohen Bestellwerten auf Null gesetzt werden („Gratislieferung ab 50 €").
• Mindestbestellwert pro Zone — Zonen nahe am Lokal oft mit niedrigem Mindestwert (z. B. 15 €), entferntere Zonen mit höherem (25–40 €).
• Zeitfenster pro Zone — abweichende Zustellzeiten, z. B. „Randzone nur bis 20:00" statt Hauptzone bis 22:00.
• Mindest-Vorlaufzeit — Zeit, die das Lokal zwischen Bestellung und Auslieferung mindestens braucht (z. B. 45 min bei stark frequentierten Abenden). Wird zur Rüst- und Fahrzeit zusammengezählt.
• Zeitfenster-Granularität — in welchen Schritten der Gast Liefertermine wählen kann (meist 15 oder 30 min).
• Tage im Voraus — Ein Tag (nur heute) bis sieben Tage (wochenweise Vorplanung). Für normale Pizzalieferung 0, für Catering 5–7.
• Feiertage und Schließtage — separat pflegbar, blockieren automatisch den Liefertag.
• Wochenend-/Nacht-/Feiertagszuschlag — pauschal oder prozentual, pro Zone getrennt möglich.
• Maximale Bestellungen pro Zeitfenster — Kapazitätsgrenze pro 15-/30-Minuten-Slot. Ist ein Slot voll, wird er für weitere Gäste ausgeblendet und der Nächstfrüheste angeboten.
• Adressprüfung automatisch — zusätzliches Geo-Coding oder manuelle PLZ-Liste.

Berechtigungen

Varianten

• Reine Innenstadt-Lieferung mit PLZ-Liste — wenige Postleitzahlen, feste Pauschale. Einfach zu pflegen, typisch für Pizzerien und Cafés.
• Umkreis-Lieferung mit Radius — z. B. 5 km ringsum, höhere Pauschale ab 3 km. Geeignet für ländlichere Gebiete ohne saubere PLZ-Struktur.
• Mehrzonen-Modell — drei bis fünf konzentrische Zonen mit unterschiedlichen Pauschalen, Mindestwerten und Zeitfenstern.
• Zone mit Gratislieferung ab Wert X — Pauschale wird automatisch auf Null gesetzt, wenn die Bestellsumme eine Schwelle überschreitet.
• Eingeschränkte Zustellzeitfenster pro Zone — z. B. „Randzone nur mittags 11:30–14:00 und abends 18:00–20:00" — passt bei Betrieben mit zwei Lieferwellen.
• Catering-Zone mit Vorlauf — eigene Zone mit mehreren Tagen Vorlauf und hohem Mindestbestellwert, getrennt vom Tagesgeschäft.
• Feiertagszuschlag — Zuschlag nur an ausgewählten Tagen, Pauschale bleibt sonst unverändert.
• Kombination Lieferung + Abholung — dieselbe Menükarte, beide Flows aktiv. Jeder Flow hat eigene Zeitfenster und Mindestbestellwerte (siehe preorder-takeaway-delivery.md).

Zusammenspiel mit der Menükarte

Zustellzeitfenster werden auf zwei Ebenen gepflegt: einmal pauschal pro Zone (wann darf überhaupt geliefert werden) und einmal pro Artikel/Kategorie in der Menükarte (darf dieser Artikel überhaupt zugestellt werden). Die Schnittmenge entscheidet, was der Gast bei einer konkreten Adresse und Uhrzeit im Checkout sieht. Wenn z. B. ein Pizzaofen freitags bis 23:00 läuft, aber die Randzone nur bis 21:30 beliefert wird, bekommt der Gast aus der Randzone den letzten Liefertermin entsprechend früher angezeigt.

Problembehebung

• „Gast bekommt ‚wir liefern nicht an diese Adresse', obwohl die Adresse eigentlich im Gebiet liegt" → PLZ-Zuordnung prüfen (Tippfehler in der Postleitzahl?). Bei Radius-Zonen: Geo-Coordinate des Betriebs korrekt? Straßen mit ungenauer Zuordnung manuell ergänzen.
• „Lieferpauschale stimmt nicht" → mehrere Zonen überlappen, falsche Zone gewinnt. Priorität der Zonen prüfen; engere Zone (kleinerer Radius, spezifischere PLZ) sollte Vorrang vor weiträumigeren bekommen.
• „Mindestbestellwert wird vom System nicht gezogen" → Wert im Setup gesetzt, aber im aktiven Flow steht noch der globale Wert. Zonen-Wert überschreibt den globalen nur, wenn er explizit gesetzt ist.
• „Keine Lieferzeiten verfügbar" → Das aktuelle Fenster ist voll (Kapazitätsgrenze) oder die Mindest-Vorlaufzeit schneidet heute ab. Kapazitäten kurzfristig erhöhen oder Vorlaufzeit prüfen.
• „Feiertag wurde übersehen" → Schließtag-Kalender pflegen; die meisten Betriebe tragen Feiertage für ein Jahr im Voraus ein.
• „Fahrer sieht die Bestellung nicht" → Workflow ggf. auf „TPS Quick" ohne Fahrer-Zwischenschritt umgestellt. Für Lieferung muss der Fahrer-Schritt aktiv sein (siehe preorder-takeaway-delivery.md).
• „Zuschlag wird nicht angezeigt" → Zuschlag nur zonen- oder zeitabhängig aktiv. Prüfen, ob die aktuelle Bestellung die Bedingung erfüllt (Uhrzeit, Wochentag).

Siehe auch

• preorder-takeaway-delivery.md — Entscheidung Abholung vs. Lieferung vs. Tischbestellung
• menuekarten-management.md — Artikel-Ebene: welcher Artikel darf zugestellt werden
• webshop-einrichtung.md — Grundsetup vor der Zonendefinition
• stripe-paypal-zahlung.md — Online-Zahlung für Lieferbestellungen (Trinkgeld an den Fahrer etc.)
• ../bestellmanager/ — Fahrer-Ansicht und Lieferschein-Bon
• ../myapro/online-reports.md — Auswertung der Lieferumsätze nach Zone

Zielgruppe: Büro, Chef, Marketing-Verantwortlicher
Typische Nutzung: Einmalig beim Einrichten, danach regelmäßig bei Karten-Wechsel (Sommer-/Winterkarte, Wochenmenü, Aktionen)
Aufruf: my.smorder.at → Menükarte (bzw. Menükarten)

Zweck

Die Menükarte ist das, was der Gast im Webshop, in der Smorder-App oder im Kiosk sieht. Sie wird im Büro zentral gepflegt — ähnlich einer Speisekarte — und kann zeitgesteuert veröffentlicht, mehrsprachig gepflegt und für besondere Anlässe (Feiertag, Wochenende, Tagesmenü) separat gefahren werden. Die Artikel selbst kommen aus der Kassenstammdatenpflege; im Menükarten-Bereich wird entschieden, welche davon online angeboten, wie sie präsentiert und wann sie bestellbar sind.

Ablauf

Typischer Ablauf „neue Menükarte einrichten":

1. Menükarte anlegen — im Menükarten-Bereich eine neue Karte mit Namen erstellen (z. B. „Hauptkarte", „Mittagsmenü", „Sommerkarte", „Feiertagsmenü").
2. Struktur aufbauen — Karte in Kategorien gliedern (z. B. „Vorspeisen", „Hauptgang", „Desserts", „Getränke"). Jede Kategorie bekommt einen Namen, ein optionales Titelbild und eine Beschreibung.
3. Artikel aus der Kasse übernehmen — Pro Kategorie werden Artikel aus den Kassenstammdaten hinzugefügt. Preis, MwSt und Beilagen kommen direkt aus der Kasse; online-spezifisch ergänzt werden Bild, Kurzbeschreibung, Allergene und optional ein Aktions-Label („Neu", „Empfehlung", „Unser Tipp", „Reduziert", „Bestseller").
4. Sichtbarkeit und Bestellzeiten definieren — Pro Karte und optional pro Kategorie wird eingestellt, an welchen Wochentagen und zu welchen Uhrzeiten bestellt werden darf. Zusätzlich getrennt: Vorbestellzeiten und Zustellzeiten.
5. Vorschau prüfen — Über den Live-Link oder den Vorschau-Modus kontrollieren, wie die Karte im Shop erscheint.
6. Karte aktivieren — Sobald alles passt, Karte scharfschalten. Ab dem Gültigkeitsbeginn ist sie im Webshop, in der App und am Kiosk verfügbar.
7. Pflege im Betrieb — Preise und Artikel-Bezeichnungen laufen automatisch aus den Kassenstammdaten nach. Online-spezifische Änderungen (Bild, Text, Sichtbarkeit) passieren direkt in der Menükarte.

Einstellungen

Was das Verhalten der Menükarten steuert:

• Gültigkeit pro Karte — Start- und Enddatum für den gesamten Kartenzeitraum. Läuft die Gültigkeit ab, verschwindet die Karte automatisch.
• Bestellfenster pro Kategorie oder Artikel — Wochentage und Uhrzeiten, zu denen online bestellt werden darf. Damit lassen sich z. B. Frühstücksartikel nur bis 11:00 Uhr anzeigen oder Cocktails erst ab 17:00 Uhr.
• Vorbestellfenster (für Abholung) — Zeitraum, in dem Kunden für einen späteren Zeitpunkt vorbestellen dürfen.
• Zustellfenster (für Lieferung) — Zeiten, in denen überhaupt zugestellt wird. Siehe auch lieferzonen-lieferzeiten.md.
• Mehrsprachige Inhalte — Pro Artikel und Kategorie können Name, Beschreibung und Kurztext in mehreren Sprachen hinterlegt werden. Der Gast bekommt die Karte in seiner Browser- oder App-Sprache ausgeliefert; fehlt eine Übersetzung, greift die Hauptsprache.
• Aktions-Labels — Pro Artikel ein optionales Hervorhebungs-Label („Neu", „Empfehlung", „Reduziert", „Coming Soon", „Bestseller").
• Wochenmenüplan — Eigener Karten-Typ für wiederkehrende Tagesmenüs. Pro Kalenderwoche wird die Karte automatisch angelegt; einmal aufgebaute Wochen lassen sich für Folgewochen kopieren, die Zeitfenster werden automatisch mitgezogen.
• Artikel-Kontingent — Optionale Tagesmenge pro Artikel (z. B. „20× Tagesmenü verfügbar"). Beim Erreichen wird der Artikel automatisch als „ausverkauft" markiert.
• Zielgruppe einschränken — Karten können auf bestimmte Benutzergruppen begrenzt werden (z. B. nur für registrierte Mitarbeiter einer Firma im Betriebskantinen-Setup).

Berechtigungen

Varianten

• Hauptkarte (Dauerkarte) — Die Standard-Karte, die ganzjährig läuft. Artikel erscheinen/verschwinden über die Bestellzeiten pro Artikel.
• Saisonkarte — Eigene Karte mit fixer Gültigkeit (z. B. „Sommerkarte 01.05.–30.09."). Läuft parallel oder ersetzt die Hauptkarte im Zeitraum.
• Tages- oder Wochenmenü — Karten-Typ „Wochenmenüplan" mit pro-Tag gepflegten Gerichten. Geeignet für Gasthäuser, Kantinen und Pensionsbetriebe.
• Feiertagsmenü — Separate Karte für Weihnachten, Silvester, Muttertag, Valentinstag. Gültigkeit auf den Feiertag begrenzt, wird z. B. zwei Wochen vorher veröffentlicht und bleibt bis zum Tag aktiv.
• Wochenend-Karte — Karte nur mit Wochentagen „Sa/So", ideal für Brunch-Karten oder verlängerte Abendkarten.
• Mittagskarte — Zeitfenster 11:00–14:30, eigene Artikel oder reduzierte Auswahl der Hauptkarte.
• Betriebsinterne Karte — Auf bestimmte Benutzergruppen (Firmenkunden, Mitarbeiter) eingeschränkte Karte, z. B. für Catering oder Kantine.
• Mehrsprachige Karte — Eine Karte, mehrere Sprachen. Der Gast sieht automatisch seine Sprache, alternativ wählt er sie manuell im Webshop.

Problembehebung

• „Artikel fehlt online" → Zuerst prüfen: Ist der Artikel in der Menükarte einer aktiven Kategorie zugeordnet? Liegt die aktuelle Uhrzeit im Bestellfenster? Ist das Kontingent aufgebraucht? Ist der Artikel in der Kasse als „bonierbar" markiert?
• „Preis stimmt nicht mit der Kasse überein" → Preise kommen aus den Kassenstammdaten; nach einer Preisänderung kann es kurz dauern, bis der Webshop den neuen Wert zieht. Wenn ein anderer Preis dauerhaft bleibt, prüfen, ob online eine Sonder-Preisebene aktiv ist.
• „Neue Karte wird nicht angezeigt" → Gültigkeitsbeginn liegt in der Zukunft oder die Karte ist noch nicht aktiviert. Außerdem: Sichtbarkeit der Kategorien prüfen.
• „Wochenmenü-Anlage dauert lange" → Das Anlegen läuft nach dem Speichern einige Sekunden im Hintergrund. Seite nicht neu laden, sonst entstehen halbe Karten.
• „Bilder werden nicht scharf angezeigt" → Empfohlene Mindestgröße ist 1080 × 720 Pixel im Querformat. Sehr kleine Bilder werden hochgerechnet und wirken unscharf.
• „Mehrsprachige Texte fehlen beim Gast" → Übersetzungs-Feld leer? Dann greift die Hauptsprache. Über die Sprachauswahl in der Kartenpflege lassen sich fehlende Texte gesammelt ergänzen.
• „Ein Artikel soll nur online angeboten werden" → In der Kasse bleibt der Artikel „nicht bonierbar"; online wird er trotzdem über die Menükarte ausgeliefert, solange er in einer aktiven Kategorie steht.

Siehe auch

• preorder-takeaway-delivery.md — Entscheidung, welcher Bestell-Flow für welchen Use Case passt
• lieferzonen-lieferzeiten.md — Zustellzonen und Zeitfenster für Lieferung
• webshop-einrichtung.md — Grundsetup vor dem ersten Karten-Aufbau
• online-gutschein-einloesung.md — Gutscheinverkauf und -einlösung im Webshop
• ../myapro/artikelverwaltung.md — Pflege der Kassenartikel, die in der Menükarte landen
• ../myapro/artikelmaske-verwalten.md — Strukturierung der Kassenartikel
• ../myapro/stuetzungen.md — Preisstützungen und Sonderkonditionen für Benutzergruppen

Zielgruppe: Chef, Büro, Accounting, optional Reports-Rolle für externe Revision
Typische Nutzung: Täglich (Tagesumsatz), wöchentlich (Kellner-Ranking), monatlich (Artikel-Auswertung, FiBu)
Aufruf: my.apro → Reporting

Zweck

Die Online-Berichte in my.apro bündeln alle Kassen-Auswertungen an einer Stelle: Umsätze, Kellnerleistung, Artikel-Ranking, Stundenlasten, Zahlungsarten, Storno-Quoten, Online-Bestellungen. Statt auf jeder Kasse einzeln einen Tagesbericht auszudrucken, sieht das Büro die konsolidierten Zahlen direkt im Browser — für einen Betrieb oder über alle Filialen hinweg.

Ablauf

Standard-Bericht aufrufen:

1. my.apro → Reporting → [gewünschter Bericht] öffnen.
2. Zeitraum wählen — Heute, Gestern, Vorwoche, Vormonat, freier Zeitraum.
3. Betrieb / Filiale wählen (wenn mehrere vorhanden).
4. Filter setzen — je nach Bericht: Kellner, Bereich, Artikelgruppe, Zahlungsmittel, Sparte.
5. Ansehen — Übersicht erscheint direkt im Browser.
6. Export (optional) — als PDF, Excel (XLSX) oder CSV.

Bericht automatisch per Mail erhalten:

1. Bericht öffnen → Als geplante Aufgabe einrichten.
2. Empfänger(E-Mail), Zeitintervall (täglich 07:00, wöchentlich Mo, monatlich am 1.), Format.
3. Speichern — der Bericht läuft ab sofort automatisch und landet im Postfach.

Rundungsdifferenz vs. Einzelbeleg prüfen:

1. Tagesumsatz-Bericht öffnen → Detailansicht ausklappen.
2. Bei Differenz zwischen Summe und Einzelposten: Rundungs-Detail prüfen, Offset ist meist durch Fremdwährung, Rabatt-Rundung oder Stützungs-Split erklärbar.

Einstellungen

• Welche Berichte sind sichtbar — steuert die Rolle des my.apro-Benutzers (my.apro → User → Benutzergruppen). Reports-Rolle sieht Berichte, nichts anderes. Accounting sieht zusätzlich FiBu und Zahlungsübersicht.
• Lokalzuweisung — my.apro → User → User → [User]. Entscheidet, welche Filialen im Bericht auftauchen. Filialleiter sehen nur ihre eigene Filiale.
• Automatischer Tagesbericht per Mail — my.apro → Reporting → [Bericht] → Als Aufgabe planen. Praktisch für den Chef, der den Vortag jeden Morgen frei Haus bekommt.
• Logo/Briefkopf im PDF — my.apro → Kassenmodule → Administration → Betriebsdaten → Logo. Auch für die Smorder-E-Mail-Rechnungen relevant.
• Export-Format Standard — je Bericht individuell wählbar; XLSX für weitere Bearbeitung, PDF für Archiv, CSV für Import in Drittsysteme.
• Reporting-Dienst — Berichte mit aufwändiger Auswertung laufen serverseitig und brauchen den internen Reporting-Dienst. Bei Ausfall erscheinen Berichte nicht oder kommen als leere Mail.

Berechtigungen

Varianten

• Tagesumsatz / Z-Bericht — Tagesabschluss pro Kasse und kumuliert. Klassischer Arbeitsstart des Chefs am Morgen.
• Kellnerabschluss / KellnerZ — Umsatz und Kassen­stand je Kellner pro Schicht. Grundlage für Kellnerabrechnung.
• Artikel-Top / Artikel-Bericht — Welche Artikel wurden wie oft verkauft, Umsatz, Marge. Gut für Speisekarten-Optimierung.
• Bereichs-/Tischumsatz — Umsatz pro Raum, Tisch oder Bereich. Für Kapazitätsplanung.
• Stundenlast — Umsatz und Bonierungen pro Stunde — zeigt Stoßzeiten, hilft bei Personalplanung.
• Zahlungsarten-Bericht — Bar / Karte / Gutschein / Zimmer / Stützung. Für Kassensturz und FiBu-Überleitung.
• Storno-Quote — Stornierungen pro Kellner und Tag. Kontroll-Instrument.
• Online-Bestellungs-Bericht — Umsätze aus Webshop / Smorder / Lieferdiensten.
• Gutscheinsaldo — Offene Gutscheine, eingelöste Gutscheine, Restwerte.
• FiBu-Bericht — Rohdaten vor dem FiBu-Export; Vorschau für die Buchhaltung.
• Online & Reports-Übersicht — Konsolidierte Startseite mit den wichtigsten Kennzahlen.
• Automatische Tages-/Wochen-Mails — Statt manuell aufrufen: landet im Postfach.

Reporting-Menü im Detail (my.apro)

Datenbasis-Grundregel: Online-Reports sind ein informatives Abbild, nicht für buchhalterische Zwecke. Einzelwerte können von Kassenberichten abweichen (andere Berechnungslogik, abweichende Behandlung von Zahlungsmitteln, Rabatten, Lieferscheinen, Stornos). Die zeitliche Basis richtet sich nach der Regel-Tagesabschlusszeit (Standard 05:00) — ein „Tag" ist z.B. 04.07. 05:00 bis 05.07. 05:00. Welcher Bericht mit welchem vergleichbar ist, steht in berichtsvergleiche.md.

Untermenüs unter Reporting:

• Online Reports — Plattform mit Auswertungen: Übersicht (Gesamtumsatz, Durchschnitt pro Kellner/Tisch/Rechnung, Offen, Storno, Wetter), Auslastung (Tisch-/Personalauslastung, belegte Tische), Bonierung/Zeit (Umsatz pro Wochentag/Tageszeit), Kellner (Top/aktive Kellner, verrechenbar/nicht verrechenbar), Renner/Penner (Sparten), Tische, Zahlungsmittel (verrechenbar/nicht verrechenbar). Nicht verrechenbare Zahlungsmittel (Lieferschein, Storno) und offene Bonierungen sind in den Umsatzwerten NICHT enthalten.
• E-Mail Reports (Reporting → Online-Reports → Account-Symbol → E-Mail Reports) — Report-Auswahl (Mehrfachselektion), Intervall, Aussende-Zeitpunkt, Zeitraum (Vortag/Vorwoche/Vormonat/Vorjahr), Versatz (verschiebt den tatsächlichen Berichtszeitraum — für 01.–01. „1 Tag" eintragen) und E-Mail-Adresse(n).
• Kellnerabschläge — alle Kellnerabschläge abrufen/herunterladen (filterbar nach Zeitraum/Kellner).
• Rechnungen — alle Kassenrechnungen (inkl. Faktura-Ausgangsrechnungen) abrufen, herunterladen, per Mail senden; filterbar nach Datum/RG-Nr./Kunde/Zahlungsmittel/Gast/Zimmer. Aktivierung: in Administration → Schnittstellen Standard-Kellner-ID (z.B. 9999) und Standardbetrieb (1) setzen.
• Reports zuweisen — Online-Reporting-Zugänge für Mitarbeiter anlegen und je Benutzer Reports zuweisen/übernehmen/löschen.
• Tagesabschlüsse — alle Tagesabschlüsse abrufen/herunterladen (Zeitraum einschränkbar).
• App Bezahlvorgänge — Bezahlvorgänge über die App suchen (Zeitraum) und Rechnungen nachdrucken.
• Verlauf — wie auf der Kassa, mit Filtermöglichkeiten.

Problembehebung

• „Berichte werden nicht angezeigt" → Meist steht der interne Reporting-Dienst. Zuerst kurz warten; wenn über längere Zeit nichts kommt, Support melden.
• „Z-Bericht / Kellnerbericht wurde nicht erstellt" → Tagesabschluss auf der Kasse prüfen — ohne Tagesabschluss gibt es keinen Z-Bericht. Danach Bericht erneut aufrufen.
• „Tagesmail ist heute nicht gekommen" → Geplante Aufgabe öffnen: letzter Lauf, Status, Fehlermeldung. Oft ist der Mail-Dienst kurzzeitig ausgefallen. Spam-Ordner prüfen.
• „Rundungsdifferenz im Tagesumsatz" → Häufig harmlos: Summe aus Einzelbelegen mit Rabatt, Stützung oder Fremdwährung kann um Cent-Beträge von der direkten Belegsumme abweichen. Detailansicht zeigt, welcher Beleg den Offset erzeugt.
• „Bericht zeigt einen anderen Umsatz als der Tagesabschluss auf der Kasse" → Offene Tische am Tagesende? Tage mit falscher Geschäftstagesgrenze (Mitternachts-Regelung)? Geschäftstag-Parameter in my.apro prüfen.
• „Kellnerin fehlt im Kellnerumsatz" → Sie hat an diesem Tag nicht gebucht oder ihr Bediener wurde gewechselt. Prüfen, ob der Login am Schichtbeginn wirklich stattgefunden hat.
• „Nach Windows-Update funktionieren die Berichte nicht" → Auf der Server-Kasse kann es sein, dass der Reporting-Dienst nicht automatisch gestartet ist. Support kontaktieren; bis dahin Berichte vom Kassen-Client direkt drucken.
• „Externe Buchhaltung will Excel-Export in einer bestimmten Struktur" → CSV-Export und dann in eigener Excel-Vorlage weiterverarbeiten — oder FiBu-Export direkt im Format des Buchhaltungs-Systems nutzen (siehe FiBu-Ablauf).

Siehe auch

• userrollen.md — Welche Rolle welche Berichte sehen darf
• berichtsvergleiche.md — Welche Berichte vergleichbar sind und warum Differenzen entstehen
• zahlungsmittel.md — Verrechenbar/nicht verrechenbar steuert die Berichtszuordnung
• ../uebergreifend/fibu-ablauf.md — FiBu-Export als eigener Kanal für den Steuerberater
• stuetzungen.md — Stützungs-Auswertung und Abrechnung an Stützungsgeber
• kundenkarte-admin.md — Gutscheinsaldo und Kundenkarten-Berichte
• lizenz-uebersicht.md — Einige Berichte (z.B. Online-Bestellungen) setzen aktive Lizenzmodule voraus

Zielgruppe: Chef, Büro
Typische Nutzung: Einmalig beim Einrichten, danach nur bei Angebots-Änderungen
Aufruf: my.smorder.at → Module → Bestellungen (Bestellkriterien) sowie Menükarte (pro Karte/Kategorie)

Zweck

Smorder kennt drei grundsätzliche Bestell-Flows, die sich im Detail deutlich unterscheiden und im Büro ganz bewusst ausgewählt werden müssen: Vor-Ort-Bestellung (Gast sitzt im Lokal, scannt den QR-Code am Tisch), Abholung/Takeaway (Gast bestellt online und holt später selbst) und Lieferung/Delivery (Bestellung wird zum Gast gebracht). Je nach Betrieb werden einer, zwei oder alle drei Flows gleichzeitig angeboten. Dieser Artikel hilft beim Entscheiden und zeigt die Stellen, an denen die Flows in Smorder konfiguriert werden.

Überblick der drei Flows

Ablauf

Typischer Einrichtungs-Ablauf:

1. Flow auswählen — Welche der drei Varianten braucht der Betrieb? Die Auswahl bestimmt alle weiteren Einstellungen. Es ist möglich, mehrere Flows parallel zu betreiben (z. B. Abholung + Lieferung).
2. Bestellkriterien setzen — Pro Flow wird festgelegt: Vorbestellzeit, Mindestvorlaufzeit, Tage im Voraus, Trinkgeld zulassen, Notizfeld erlauben, Mindestbestellwert.
3. Menükarte zuweisen — Pro Artikel/Kategorie wird gesteuert, ob er für Vor-Ort, Abholung und/oder Lieferung bestellbar ist. Siehe menuekarten-management.md.
4. Workflow für die Kasse definieren — Wohin geht die Bestellung nach der Bestellannahme? Direkt in die Küche (Bestellmanager, TPS-Quick), oder erst mit manueller Freigabe („Warten auf Annahme")?
5. Identifikation des Gastes — Pager, Abholname oder Bestellnummer? Pro Flow einstellbar. Bei Abholung hat sich der Abholname bewährt, im Kiosk-SB-Betrieb der Pager.
6. Zahlungsmittel freigeben — Karte, PayPal und/oder Barzahlung an der Kassa. Online-Zahlungsmittel kommen über Stripe und PayPal (siehe stripe-paypal-zahlung.md).
7. Ausgabe- und Lieferkanal — Bei Abholung: Sammelbestellbon, Bestelldrucker, Küchenmonitor. Bei Lieferung: Lieferzone definieren, Fahrer-Workflow setzen (siehe lieferzonen-lieferzeiten.md).
8. Kommunikation mit dem Gast — Bestell-Bestätigung per E-Mail, Statusmeldungen („Angenommen", „In Zubereitung", „Abholbereit", „Abgeholt") in der Smorder-App oder im Webshop.

Einstellungen

Zentrale Stellschrauben im Smorder-Backoffice:

• Flow-Freigabe pro Lokal — Module → Bestellungen bzw. Allgemein → Services. Pro Lokal wird aktiviert, welche Flows angeboten werden.
• Vorbestellzeit und Abholzeit — Module → Bestellungen → Bestellkriterien. Frühestens/Spätestens und Granularität der Zeitfenster (5 min, 15 min, 30 min).
• Tage im Voraus — Wie weit darf der Gast in die Zukunft bestellen (0 = nur heute, 7 = bis zu einer Woche).
• Mindestbestellwert und Zuschläge — Pro Flow eigene Werte. Typisch: Lieferung hat Mindestbestellwert + Lieferpauschale; Abholung meist nicht.
• Trinkgeld online — Pro Flow aktivierbar. Standard: bei Lieferung und Abholung ja, am Tisch meist nein (dort läuft das Trinkgeld klassisch beim Service).
• Gastidentifikation — Pager / Abholname / Bestellnummer (siehe Varianten unten).
• Sammelbestellbon — Alle Artikel einer Online-Bestellung landen auf einem einzigen Bon. Praktisch, wenn Küche und Bar gemeinsam zusammenstellen.
• Workflow in der Kasse — App → Workflows. Beispiele: „TPS Quick" für direkte Weiterleitung an die Kassa, „Abholbereit/Abgeholt" mit Waiter-UI für manuelle Statusänderungen, „Bestellmanager" für Küchenmonitor.
• Ausgabekanal — Modul → Bestellungen → Ausgabe. Kunden-Bon, Küchen-Bon, Barbereich, Pager.
• Kundenregistrierung — Gastbestellung (nur E-Mail) oder registrierter Account. Registrierte Accounts können wiederkehrende Bestellungen und Lieblingsartikel speichern.

Berechtigungen

Varianten

• Vor-Ort mit QR-Tischaufsteller (Tischbestellung) — Gast scannt QR am Tisch, bestellt über App oder Web, Service bringt raus. Zahlung entweder online oder am Tisch bei der Service-Kraft. Typisch für Gastronomie mit Bedienung.
• Vor-Ort mit Kiosk (Self-Order-Terminal) — Gast bestellt am Kiosk-Terminal, der Flow ist technisch wie Abholung am Tresen, läuft aber im Lokal. Typisch für QSR (Quick Service Restaurants), Systemgastronomie.
• Abholung mit Abholzeit-Auswahl (Pre-Order) — Gast wählt konkreten Abholzeitpunkt, Küche produziert rechtzeitig. Beste Planbarkeit für Konditoreien, Bäckereien, Pizzerien.
• Abholung „so schnell wie möglich" — Kein fixer Zeitpunkt, Küche startet sofort. Geeignet für kleine Betriebe mit schnellem Durchsatz.
• Lieferung mit fester Zeitfenster-Wahl — Gast wählt ein Lieferfenster (z. B. 18:00–18:30). Setzt saubere Lieferzonen und Fahrer-Planung voraus.
• Lieferung ASAP — Bestellt wird, sobald die Küche Kapazität hat. Erfordert Live-Steuerung durch das Service-Team.
• Veranstaltungs-/Catering-Bestellung — Vorbestellung mit mehreren Tagen Vorlauf und hohem Mindestbestellwert. Eigener Flow mit langer Vorlaufzeit, häufig kombiniert mit Rechnungsstellung.
• Wochenmenü / Kantine — Registrierte Benutzergruppen bestellen für kommende Tage, pro Tag mit Stornofrist. Kombiniert mit ../myapro/stuetzungen.md für Mitarbeitervergünstigungen.
• Externe Lieferportale (Lieferando, MJAM, Wolt, Foodora) — Eigener Flow, die Bestellung kommt vom Portal in die Kasse. Setup separat, siehe Hinweis unten.

Abgrenzung zu Lieferplattformen

Externe Lieferportale (Lieferando, MJAM, Wolt, Foodora) laufen nicht über den Smorder-Webshop, sondern sind separate Schnittstellen. Die Bestellung kommt vom Portal automatisch in die Kassa, wird aber mit eigenen Tischen, Zahlungsmitteln und Artikelnummern geführt. Wenn der Betrieb beides parallel anbietet (eigener Smorder-Shop plus Drittportale), lohnt sich ein eigener Workflow-Tisch pro Portal für saubere Auswertungen.

Problembehebung

• „Abholzeit-Fenster werden nicht angeboten" → Vorbestellzeiten in den Bestellkriterien geprüft? Bestellzeiten der Menükarte/Kategorie decken das Fenster ab? Feiertag blockiert?
• „Online-Bestellung kommt nicht in der Kasse an" → Workflow und Online-Tisch richtig verknüpft? Online-Kellner angelegt? Service „Smorder + OrderService" läuft?
• „Trinkgeld-Feld fehlt" → Pro Flow deaktiviert? Oder Kassen-Zahlungsmittel hat kein Trinkgeld-Flag?
• „Mindestbestellwert wird nicht gezogen" → Gilt pro Flow. Wurde er für den falschen Flow gesetzt? Lieferzone überschreibt den globalen Wert.
• „Gast sieht keinen Lieferschein" → Adresse außerhalb der definierten Lieferzonen. Siehe lieferzonen-lieferzeiten.md.
• „Bestellmanager zeigt Abholungen und Tischbestellungen vermischt" → Sortier- und Gruppierungsregeln im Bestellmanager-Verhalten anpassen, damit Abholungen eigene Spalte bekommen.

Siehe auch

• menuekarten-management.md — Pro Artikel festlegen, welche Flows er unterstützt
• lieferzonen-lieferzeiten.md — Zonen, Zeitfenster und Zuschläge für Lieferung
• stripe-paypal-zahlung.md — Online-Zahlung für Abholung und Lieferung
• online-gutschein-einloesung.md — Gutschein beim Online-Checkout einlösen
• webshop-einrichtung.md — Grundsetup des Lokals, bevor Flows konfiguriert werden
• ../bestellmanager/ — Küchenmonitor und Bestell-Workflow an der Ausgabe
• ../kiosk/ — Self-Order am Kiosk-Terminal (Vor-Ort-Variante)

Zielgruppe: Büro, Chef
Typische Nutzung: Einmalig beim Einrichten; im Alltag meist unbemerkt im Hintergrund
Aufruf: my.apro → Kassenmodule → Administration → Sync (bzw. Dienste/Status)

Zweck

my.apro ist die zentrale Verwaltung — die Kasse vor Ort ist der Arbeitsplatz. Damit beide dasselbe wissen (Artikel, Preise, Masken, Bediener, Tische), läuft im Hintergrund ein Synchronisations-Dienst zwischen Kasse und my.apro. Das Büro pflegt online, die Änderungen kommen kurze Zeit später automatisch auf jeder Kasse an. Bei Multi-Filial-Betrieben verteilt derselbe Dienst die Daten an alle Filialen.

Ablauf

Typischer Sync-Zyklus im Hintergrund:

1. Änderung in my.apro gespeichert — z.B. neuer Artikel, Preisänderung, neue Maske.
2. my.apro markiert den Datensatz als geändert und legt ihn in eine Warteschlange.
3. Kassen-Server holt regelmäßig ab — im typischen Minuten-Intervall.
4. Lokale Datenbank der Kasse wird aktualisiert — alle Terminals am Standort sehen die neue Information.
5. Bestätigung zurück an my.apro — der Eintrag ist als „synchronisiert" gekennzeichnet.

Manueller Sync-Anstoß (wenn Änderungen sofort live gehen sollen):

1. Am Kassen-Client: Verwaltung → Stammdaten aktualisieren (oder im BonNeu über Administration → Sync jetzt).
2. In my.apro: Kassenmodule → Administration → Sync → Jetzt auslösen für den gewählten Betrieb.
3. Der Fortschritt ist im Sync-Status sichtbar.

Sync-Status prüfen:

1. my.apro → Kassenmodule → Administration → Sync / Dienste öffnen.
2. Letzter erfolgreicher Lauf, offene Datensätze, Fehler im Klartext.
3. Bei roten Einträgen: Fehlermeldung öffnen und der Anleitung folgen.

Einstellungen

• Sync-Intervall — my.apro → Kassenmodule → Administration → Sync → Intervall. Standard sind wenige Minuten. Kürzere Intervalle belasten die Datenleitung, längere verzögern Änderungen. Für die meisten Betriebe passt die Voreinstellung.
• Was wird synchronisiert — Artikel, Sparten, Preise, Artikelmasken, Tischmasken, Tische, Bereiche, Bediener, Bediener-Gruppen, Drucker-Zuordnungen, Stützungen, Kundengruppen, Zahlungsmittel. Umsätze, Belege und Bonierungen laufen umgekehrt (Kasse → my.apro) über denselben Kanal.
• Exportprofil für Filialverbund — my.apro → Kassenmodule → Administration → Sync → Profile. Steuert, welche Filialen welche Stammdaten bekommen (z.B. Stadt-Preise vs. Land-Preise).
• Multi-Filial-Szenario — Ein zentrales my.apro, viele Kassen-Server vor Ort. Jeder Filial-Server holt seine Daten eigenständig ab.
• Bandbreiten-Schutz — Große Stammdatenpakete (z.B. Bild-Dateien für Artikel) werden gestaffelt übertragen, damit die Kasse im laufenden Betrieb nicht ausgebremst wird.
• Offline-Betrieb der Kasse — Der Kassen-Server arbeitet bei Leitungsausfall eigenständig weiter. Sobald die Leitung wieder steht, werden die aufgelaufenen Bonierungen und Pending-Stammdaten nachgeholt.

Berechtigungen

Varianten

• Einzelbetrieb — Ein Kassen-Server, ein my.apro-Mandant. Sync läuft geradlinig.
• Multi-Filiale, zentrale Stammdaten — Zentrale Artikelpflege, Filialen bekommen identische Artikel. Preis kann je Filiale abweichen.
• Multi-Filiale, Filial-Abweichungen — Basisstammdaten zentral, Filial-spezifische Artikel und Masken lokal. Beide Teile laufen parallel über den Sync.
• Saison-Filiale — Ein Filial-Server, der nur saisonal aktiv ist. Beim Reaktivieren werden alle Stammdaten-Deltas nachgezogen.
• Franchise-Netzwerk — Zentrale gibt Pflichtartikel und Pflichtpreise vor; Franchisenehmer darf ergänzen. Das Exportprofil regelt, was überschrieben werden darf.
• Webshop / Online-Bestellsystem — Online-Menükarten und Online-Artikel kommen aus demselben Stamm und werden über denselben Sync aktuell gehalten.

Problembehebung

• „Änderung in my.apro ist an der Kasse noch nicht sichtbar" → Normal, solange der Sync-Intervall noch nicht gelaufen ist (meist wenige Minuten). Wer sofort sehen will: manuell anstoßen.
• „Sync funktioniert nicht — Meldung ,Datenbank voll'" → Die Sync-Historie der Kasse ist voll. Meist Support-Thema (Historie aufräumen). Bis dahin läuft die Kasse offline weiter.
• „Neuer Artikel ist an Kasse 1 da, an Kasse 2 nicht" → Kasse 2 hat aktuell keinen Sync bekommen (offline, Dienst steht, Verbindung unterbrochen). Dienst-Status prüfen, kurz warten oder manuell anstoßen.
• „Meldung: BaseDataService in Auslastung" → Tritt gelegentlich nach der Zeitumstellung oder nach Windows-Updates auf. In der Regel hilft es, den Dienst auf der Server-Kasse neu zu starten — bei wiederholtem Auftreten Support melden.
• „Sync hat gestern funktioniert, heute nicht" → Häufig: Internetverbindung unterbrochen, Zugangsdaten abgelaufen, Windows-Update hat den Dienst angehalten. Internet testen, Sync-Status ansehen, Dienst neu starten.
• „Preisänderung kam nicht bei der Kasse an, obwohl Sync läuft" → Prüfen, ob der Artikel wirklich gespeichert wurde und ob keine Filial-Ausnahme (Exportprofil) aktiv ist, die genau diesen Artikel ausklammert.
• „Bonierungen von gestern fehlen in my.apro" → Umgekehrter Sync-Weg. Prüfen, ob der Tagesabschluss auf der Kasse abgeschlossen wurde. Bonierungen werden in der Regel nach Tagesabschluss spätestens nachgeliefert.

Siehe auch

• artikelverwaltung.md — Alle Artikel-Änderungen laufen über den Sync
• artikelmaske-verwalten.md — Maskenänderungen werden ebenfalls synchronisiert
• bediener-anlegen.md — Neue Bediener brauchen einen Sync, bevor sie sich anmelden können
• lizenz-uebersicht.md — Der Sync-Dienst ist Teil der Basislizenz und muss aktiv sein
• online-reports.md — Bonierungen erscheinen in Berichten erst nach Rück-Sync zur Zentrale

Zielgruppe: Chef, Büro (Einrichtung/Pflege) — Gast nutzt die Zahlung im Checkout
Typische Nutzung: Einmalig beim Einrichten, im Alltag für Refunds/Stornos und monatliche Abstimmung
Aufruf: my.smorder.at → Payment → App-/Web-Payment sowie my.smorder.at → Bestellungen (für Refund/Storno)

Zweck

Stripe und PayPal sind die beiden Standard-Online-Zahlungsmittel im Smorder-Webshop. Stripe deckt Kredit- und Debitkarten (Visa, Mastercard, American Express, Maestro), Apple Pay, Google Pay und je nach Land zusätzliche Methoden wie SOFORT/Klarna oder EPS ab. PayPal kommt zusätzlich, weil ein relevanter Teil der Gäste (besonders in Deutschland) PayPal gegenüber Kartenzahlung bevorzugt. Für den Betrieb sind beide Wege getrennt: eigene Vertragspartner, eigene Auszahlungen, eigene Gebührenstruktur — aber dieselbe Oberfläche im Smorder-Backoffice.

Ablauf Einrichtung

Stripe

Stripe wird als Marktplatz-Integration („Connect") über APRO betrieben: APRO ist die Plattform, der Betrieb ist ein angebundenes Konto. Der initiale Anlageschritt läuft immer in Abstimmung mit APRO:

1. Unterlagen bereitstellen — Unternehmensname, Anschrift, IBAN, Passkopie der Eigentümer mit mehr als 25 % Beteiligung, Firmenbuch- bzw. Gewerberegisterauszug. APRO meldet den Betrieb im Stripe-Dashboard als neues Konto an.
2. Stripe-Assistent durchlaufen — Eingabe der Unternehmensdaten, IBAN, Inhaberdaten.
3. Konto-ID in Smorder hinterlegen — im Payment-Bereich wird die Stripe-Konto-ID mit dem Lokal verknüpft.
4. Zahlungsmittel aktivieren — pro lizenzierter Methode (Kreditkarte, SOFORT, Apple Pay, Google Pay) eine eigene Option. Jede Option lässt sich sichtbar/unsichtbar stellen.
5. Auszahlungs-Report einrichten — ein Zahlungsbericht mit Empfänger-E-Mail und Intervall (täglich/wöchentlich/monatlich) sorgt für automatische Reports an die Buchhaltung.
6. Testmodus ausschalten — nach dem Test mit dem Stripe-Sandbox-Konto auf Live-Modus umstellen und nochmals einen Echt-Ablauf testen.

PayPal

PayPal-Zugangsdaten müssen aus einem bestehenden PayPal-Business-Account kommen. Der Betrieb legt selbst eine App an und übermittelt die Zugangsdaten; Smorder speichert sie im Payment-Bereich:

1. PayPal-Business-Account anlegen oder nutzen — falls nicht vorhanden, zunächst über paypal.com ein Business-Konto eröffnen.
2. App bei PayPal Developer registrieren — im PayPal-Developer-Dashboard unter „Apps & Credentials" → „Live" eine neue App anlegen. Als App-Name den Namen des Betriebs verwenden.
3. Client ID und Secret kopieren — aus der neu angelegten App.
4. In Smorder eintragen — im Backoffice unter Payment → App-/Web-Payment eine neue Option vom Typ „PayPal" anlegen und Client ID und Secret einfügen.
5. Sichtbar stellen und testen — Checkout einmal live durchlaufen, bis eine Echtzahlung im PayPal-Konto des Betriebs ankommt.

Ablauf Zahlung (Gast)

1. Gast bestellt und kommt in den Checkout.
2. Zahlungsmittel wählen — Karte (Stripe), PayPal oder Gutschein.
3. Zahlung abschließen — bei Karte: Kartendaten eingeben oder Apple Pay/Google Pay bestätigen. Bei PayPal: Weiterleitung zu PayPal, Anmeldung dort, Bestätigung, Rücksprung zu Smorder.
4. Bestellung geht in die Kasse — mit dem passenden online-Zahlungsmittel („Smorder Kreditkarte", „Smorder PayPal", „Smorder SOFORT", je nach Methode).
5. Bestätigung per E-Mail an den Gast.
6. Auszahlung — Stripe und PayPal zahlen nach ihren Intervallen auf das Bankkonto des Betriebs aus (Stripe täglich/wöchentlich konfigurierbar, PayPal manuell oder automatisch).

Einstellungen

• Aktive Zahlungsmethoden pro Lokal — pro Betrieb einzeln, sodass z. B. ein Lokal nur Karte und PayPal, ein anderes zusätzlich SOFORT bekommt.
• Sichtbarkeit einzelner Methoden — eine Methode lässt sich ausblenden, ohne sie zu löschen (z. B. Apple Pay saisonal ausschalten).
• Auszahlungs-Reports — E-Mail-Adresse und Intervall. Empfohlen: monatlich an die Buchhaltung zur Abstimmung.
• Zahlungsmittel in der Kasse — pro Online-Methode ein eigenes Kassen-Zahlungsmittel (z. B. „Smorder Kreditkarte"), damit die Auswertung sauber getrennt ist. Die Zahlungsmittel-IDs werden zusätzlich im Smorder-Backoffice beim TPS-User hinterlegt, damit die Kassa die Online-Zahlung korrekt verbucht.
• Währung — wird am Lokal gesetzt und gilt für beide Zahlungsarten.
• Trinkgeld online — erlaubt oder nicht; siehe preorder-takeaway-delivery.md.
• Mindestbetrag für Kartenzahlung — optional, z. B. „Karte erst ab 5 €".

Berechtigungen

Ablauf Refund (Stripe)

1. Bestellung finden — im Smorder-Backoffice die Bestellung öffnen.
2. „Rückabwicklung via Stripe" starten — nur für Admin-Rollen verfügbar.
3. Zahlung auswählen — bei mehreren Zahlungen wird diejenige gewählt, die refundiert werden soll.
4. Beträge bestätigen — ein Teil-Refund ist durch Änderung des Betrags möglich; Gebühren werden je nach Stripe-Vertrag mit erstattet oder behalten.
5. Grund und Meldung eingeben — für Revision und Kundenkommunikation.
6. Refund auslösen — der Betrag geht je nach Zahlungsmethode in 2–10 Tagen an den Gast zurück. Bei SOFORT-Zahlungen erst 3–4 Tage nach der Original-Zahlung möglich.

Ablauf Refund/Storno (PayPal)

1. Im Smorder-Backoffice die Bestellung öffnen und die PayPal-Zahlung auswählen.
2. Refund auslösen — voller oder Teil-Refund. Alternativ direkt im PayPal-Business-Account unter „Aktivitäten" → Transaktion → „Zahlung erstatten".
3. Stornierung einer noch nicht abgeschlossenen Zahlung — bei PayPal im Status „autorisiert" kann die Zahlung storniert werden, bevor sie abgebucht wird.
4. Im Kassensystem — den Tisch/Bon entsprechend stornieren, damit Umsatz und Zahlungsmittel in Einklang bleiben.

Varianten

• Nur Stripe aktiv — Betrieb entscheidet sich gegen PayPal, um nur einen Vertragspartner zu pflegen. Typisch für B2B-lastige Kundschaft.
• Nur PayPal aktiv — Betrieb ohne Stripe-Vertrag, nutzt PayPal auch für Karten (PayPal verarbeitet Karten im Hintergrund mit).
• Beides parallel — Standardempfehlung bei gemischter Kundschaft, führt erfahrungsgemäß zur höchsten Conversion.
• Apple Pay / Google Pay — laufen über den bestehenden Stripe-Vertrag, werden nur zusätzlich freigeschaltet.
• SOFORT / Klarna / EPS — landesspezifisch über Stripe. Pro Methode eine eigene Sichtbarkeit.
• Barzahlung zusätzlich (nur bei Abholung oder Lieferung) — „Zahlung bei Abholung" bzw. „Zahlung an den Fahrer" als zusätzliche Option neben Stripe/PayPal.

Problembehebung

• „Karte wird nicht akzeptiert" → meist Bank-seitige 3-D-Secure-Abfrage, die der Gast bestätigen muss. Wenn sofort rot: Kartenlimit, Gültigkeit oder Kartenart prüfen.
• „PayPal-Weiterleitung kommt nicht zurück" → PayPal-App des Gastes blockiert den Rücksprung. Alternative Bezahlung im Browser.
• „Client ID ungültig" bei PayPal → Kommt meistens von einer Sandbox-App statt einer Live-App. In PayPal-Developer unter „Live" statt „Sandbox" eine neue App anlegen.
• „Refund schlägt fehl" → Bei SOFORT gilt die 3-4-Tage-Sperre nach Zahlung. Bei älteren Bestellungen (über 180 Tage) verweist Stripe auf Überweisung.
• „Auszahlung kommt nicht am Bankkonto an" — Stripe-Dashboard prüfen: steht die Auszahlung auf „ausstehend" wegen Bank-Feiertag oder Dokumenten-Nachforderung? Ggf. Stripe-Compliance-Meldung im Dashboard öffnen.
• „Zahlungsmittel in der Kasse doppelt" → passiert, wenn für eine Stripe-Methode zwei Kassen-Zahlungsmittel angelegt sind. Eines inaktiv setzen und die Zahlungsmittel-ID im Smorder-TPS-User korrigieren.
• „Bestellung bezahlt, in Kasse aber als offen" → Smorder-Service oder OrderService prüfen (läuft der Dienst auf der Server-Kasse?). Bei wiederholtem Auftreten Support.

Siehe auch

• preorder-takeaway-delivery.md — Welcher Flow nutzt welche Zahlungsarten
• online-gutschein-einloesung.md — Gutschein plus Stripe/PayPal als Restzahlung
• webshop-einrichtung.md — Reihenfolge der Einrichtung (Payment kommt nach Lokal-Stammdaten)
• ../myapro/online-reports.md — Abstimmung der Online-Umsätze mit dem Tagesabschluss
• ../uebergreifend/fibu-ablauf.md — Zahlungsmittel-Konten für die Buchhaltung
• Schnittstellen-Doku (für Techniker): docs/schnittstellen/articles/zahlungsterminals/

Zielgruppe: Büro, Chef
Typische Nutzung: Einmalig pro Aktion oder Kundengruppe einrichten; danach läuft die Stützung automatisch beim Bonieren
Aufruf: my.apro → Kassenmodule → Preise & Rabatte → Stützungen

Zweck

Stützungen sind vorkonfigurierte Preis- oder Rabattregeln, die automatisch greifen, sobald eine bestimmte Situation eintritt — z.B. „Happy Hour 17-19 Uhr: Bier -1€", „Mitarbeiterpreis auf Tagesteller", „Betrieb übernimmt 5€ vom Mittagsmenü". Das Büro legt die Regel einmalig an; der Kellner muss am Kassen-Client nichts extra anklicken. Das hält den Servicefluss schnell und vermeidet Fehler bei der manuellen Rabattvergabe.

Ablauf

Stützung im neuen Modus einrichten (ab Version 10.31 empfohlen):

1. Stützungs-Zahlungsmittel anlegen — Name z.B. „Stützung", als umsatzwirksames Zahlungsmittel.

> Einstellung: my.apro → Kassenmodule → Payment → Zahlungsmittel → Neu.

2. Stützungsmodus wählen — Das zuvor angelegte Stützungs-Zahlungsmittel auswählen.

> Einstellung: my.apro → Kassenmodule → Administration → Betriebsdaten → Card „Stützung" → Feld „Stützungsmodus" auf Splitzahlung.

3. Rabatt-Sparte und Rabattartikel anlegen (falls nicht vorhanden).

> Einstellung: my.apro → Kassenmodule → Artikel.

4. Artikelgruppe für Stützung anlegen — die Artikel eintragen, für die die Stützung gelten soll.

> Einstellung: my.apro → Kassenmodule → Preise & Rabatte → Artikelgruppen → Neu.

5. Stützungs-Vorlage anlegen — Typ wählen (Happy-Hour, Menü, Kundengruppen-Preis), Gültigkeitszeitraum, gestützter Betrag oder Prozentsatz.

> Einstellung: my.apro → Kassenmodule → Preise & Rabatte → Stützungen → Umschalter „Vorlagen" → Neu.

6. Gültigkeit festlegen — Wochentage, Uhrzeiten, Datum-von/bis, optional Zählersystem (z.B. „5 Mitarbeiter-Essen pro Tag"). Gepflegt direkt in der Stützungs-Vorlage aus Schritt 5.
7. Zuweisen — Entweder automatisch nach Uhrzeit (Happy Hour) oder an eine Kundengruppe (Mitarbeiter, Stammgast).
8. Speichern. Beim Bonieren erkennt die Kasse die Stützung und verrechnet automatisch.

Stützung testen:

1. Am Kassen-Client den gestützten Artikel zur passenden Uhrzeit / mit passender Kundengruppe bonieren.
2. Prüfen: Rechnung zeigt den vollen MwSt.-Ausweis vom Originalpreis; die Stützung läuft als Splitzahlung.

Einstellungen

• Stützungsmodus (Alt/Neu) — Alter Modus arbeitet mit Minuspreis auf dem Artikel (geringere MwSt.-Basis), neuer Modus mit Split-Zahlung (voller MwSt.-Ausweis beim Gast). Für Neubetriebe immer den neuen Modus.

> Einstellung: my.apro → Kassenmodule → Administration → Betriebsdaten → Card „Stützung" → „Stützungsmodus".

• Zählersystem / Kontingent — Begrenzt pro Tag/Woche, wie viele gestützte Positionen ein Mitarbeiter oder Gast bekommt.

> Einstellung: my.apro → Kassenmodule → Administration → Kassenparameter → Parameter-Gruppe „Zählersystem".

• Kundengruppen-Preise — Preise pro Gruppe (z.B. „Mitarbeiter" bekommt 50% auf Speisen).

> Einstellung: my.apro → Kassenmodule → Preise & Rabatte → Stützungen Kunden.

• Wochenmenü-Pläne — Kombinierbar mit Stützung und Kundengruppen: der Wochenplan legt die Tagesartikel, die Stützung legt den Preis (z.B. Kantinen-Logik).
• Happy-Hour-Zeiten — Pro Wochentag eigene Fenster möglich.

> Einstellung: my.apro → Kassenmodule → Preise & Rabatte → Stützungen → Umschalter „Vorlagen" → <Vorlage> → Sektion „Zeitraum".

• FiBu-Zuordnung — Das Stützungs-Zahlungsmittel braucht ein FiBu-Konto, damit die Rechnung an den Stützungsgeber (Betrieb, Elternverein, Firma) sauber verbucht wird.

> Einstellung: my.apro → Kassenmodule → Payment → Zahlungsmittel → <Stützungs-Zahlungsmittel> → Feld „FiBu-Konto".

Berechtigungen

Varianten

• Happy Hour — Zeitbasiert: Mo-Fr, 17:00-19:00, alle Biere -1€. Artikelgruppe „Biere", fester Rabattbetrag, Zeitfenster. Läuft automatisch.
• Mitarbeiterverpflegung — Kundengruppe „Mitarbeiter". Der Bediener scannt die Mitarbeiterkarte oder wählt die Gruppe. Gestützt wird z.B. der Tagesteller auf 5€ (statt 12€). Der Betrieb bezahlt die Differenz intern.
• Kantinenbetrieb mit Fremdfirma — Die fremde Firma ist Stützungsgeber. Ihre Mitarbeiter zahlen z.B. 3€, die Firma bekommt einmal im Monat die Rechnung über die Differenz.
• Menü-Preis — Vorspeise+Hauptgang+Dessert als Gesamtpreis: Einzelpreise werden gestützt, Summe ergibt den Menüpreis.
• Tageskarte / Wochenkarte — Der gestützte Preis gilt nur an bestimmten Tagen, für ausgewählte Artikel.
• Gutschein-Stützung — Ein Sponsor (Gemeinde, Elternverein) übernimmt einen festen Betrag pro Mahlzeit. Am Monatsende rechnet der Betrieb die gesammelten Stützungen gegen den Sponsor ab.
• Prozentualer Mitarbeiterrabatt — Statt fester Preis: 30% auf alle Speisen für Bediener, die als Mitarbeiter-Gruppe angemeldet sind.

Problembehebung

• „Stützung greift nicht beim Bonieren" → Prüfen: Ist der Artikel in der Stützungs-Artikelgruppe? Ist die Uhrzeit im Gültigkeits-Fenster? Ist die richtige Kundengruppe am Tisch gesetzt? Ist die Stützungs-Vorlage aktiv?
• „Kellner bekommt Meldung: Kontingent überschritten" → Das Zählersystem ist aktiv und das Tages-/Wochenlimit ist erreicht. Entweder Limit erhöhen oder den Gast regulär bonieren.
• „MwSt. auf der Rechnung stimmt nicht mit dem Gastpreis" → Das ist typisch für den alten Stützungsmodus (Minuspreis). Im neuen Modus wird die volle MwSt. vom Originalpreis ausgewiesen. Bei Bedarf auf neuen Modus wechseln.
• „Stützungsrechnung an den Stützungsgeber weist MwSt. aus — sollte aber netto sein" → Im neuen Modus ist die Stützungsrechnung ohne MwSt. (MwSt. war schon auf der Gastrechnung), im alten Modus mit MwSt. (MwSt.-Basis war reduziert). Steuerberater entscheidet, welcher Modus erwünscht ist.
• „Kundengruppe greift nur am ersten Tisch, dann nicht mehr" → Beim Tischwechsel wird die Kundengruppe nicht immer automatisch übernommen. Im Tisch die Gruppe aktiv auswählen oder eine Kundenkarte einlesen.
• „Happy-Hour läuft, aber Bons zeigen alten Preis" → Uhrzeit am Kassen-Client prüfen (inkl. Zeitzone). Bei automatischen Sync-Vorgängen nach Zeitumstellung kurz warten.
• „Stützungs-Zahlungsmittel wird nicht im FiBu-Export berücksichtigt" → Dem Stützungs-Zahlungsmittel fehlt ein FiBu-Konto. Nachtragen unter my.apro → Kassenmodule → Payment → Zahlungsmittel → <Stützungs-Zahlungsmittel>.

Siehe auch

• artikelverwaltung.md — Artikel als Grundlage der Stützungs-Artikelgruppen
• kundenkarte-admin.md — Kundenkarte als Auslöser für Kundengruppen-Preise
• online-reports.md — Stützungsberichte und Abrechnung an Stützungsgeber
• ../uebergreifend/fibu-ablauf.md — FiBu-Konten für das Stützungs-Zahlungsmittel
• ../bonneu/bonieren.md — Wie der Kellner den Tisch mit Kundengruppe anlegt

Zielgruppe: Büro, Chef (einmalig), Accounting (bei Berichtsfreigabe)
Typische Nutzung: Einmalig beim Einrichten, danach nur bei Personalstruktur-Änderungen
Aufruf: my.apro → Kassenmodule → Benutzer → Bediener-Gruppen und my.apro → Benutzer (für my.apro-Rollen)

Zweck

Userrollen regeln, wer was darf — sowohl am Kassen-Client (durch Bediener-Gruppen) als auch in der Onlineverwaltung my.apro (durch my.apro-Rollen). Saubere Rollen verhindern, dass ein Aushilfskellner versehentlich Preise ändert oder ein Buchhaltungsbüro Zugriff auf die komplette Artikelverwaltung bekommt. Je enger die Rechte, desto sicherer läuft der Betrieb.

Ablauf

Bediener-Gruppe am Kassen-Client:

1. my.apro → Kassenmodule → Benutzer → Bediener-Gruppen → Neu anlegen.
2. Name vergeben (z.B. „Kellner", „Chef", „Aushilfe", „Theke").
3. Rechte-Matrix ausfüllen — Häkchen pro Funktion:

• Bonieren, Stornieren vor/nach Rechnung
• Preis ändern, Rabatt geben
• Fremden Tisch übernehmen
• Kellnerabschlag, Tagesabschluss
• Kassabuch-Bewegungen, Tresorbuchung
• Bericht ansehen

4. Speichern.
5. In den Bediener-Stammdaten die passende Gruppe zuweisen.

my.apro-Rolle für Onlineverwaltung:

1. my.apro → Benutzer → Neuer Benutzer anlegen oder bestehenden öffnen.
2. E-Mail + Passwort / Login vergeben.
3. Rolle(n) wählen aus der vordefinierten Liste (z.B. Lokal-Manager, Buchhaltung, Reports, Bestellverwaltung, Maskenverwaltung).
4. Lokalzuweisung — welche Betriebe der Benutzer sieht (wichtig bei Filialbetrieben).
5. Speichern. Der Benutzer bekommt eine Einladungsmail und kann sich dann in my.apro anmelden.

Rolle ändern:

1. Benutzer öffnen → Rolle(n) aktivieren/deaktivieren → Speichern.
2. Greift beim nächsten Login; laufende Sitzungen können kurz neu angemeldet werden.

Einstellungen

• Bediener-Gruppe — my.apro → Kassenmodule → Benutzer → Bediener-Gruppen. Wirkt am Kassen-Client (BonNeu, Bonierapp).
• my.apro-Rolle — my.apro → User → User → [User]. Wirkt in der Onlineverwaltung.
• Lokalzuweisung — my.apro → User → User → [User]. Grenzt ein, welche Betriebe der Benutzer sehen darf.
• Erweiterte Menükarten / Zahlungsmittel — eigene Rollen „Erweiterte Menükarte", „Tester" — wer darf welche Menükarten online sehen und bestellen.
• Benutzergruppenverwaltung — separate Rolle für Betriebe, die viele Fremdfirmen verwalten (z.B. Kantinen mit Mitarbeiterverpflegung).
• Auszahlungsberichte / Reports — Schmale Rolle für Steuerberater oder externe Buchhaltung, die ausschließlich Berichte sehen.

Berechtigungen

Varianten

• Kleiner Betrieb mit zwei Gruppen — „Kellner" und „Chef" am Kassen-Client, dazu ein my.apro-Benutzer mit Büro-Rolle für den Inhaber. Mehr braucht es oft nicht.
• Mittelbetrieb mit Büro-Trennung — Zusätzlich eine Accounting-Rolle für die externe Buchhaltung, eine Reports-Rolle für den Revisor.
• Filialbetrieb — my.apro-Rollen mit Lokalzuweisung: jeder Filialleiter sieht nur seine Filiale, die Zentrale sieht alle.
• Kantine mit Fremdfirmen — Eigene Rolle „Benutzergruppenverwaltung", damit jede Firma ihre Mitarbeiter selbst pflegen kann.
• Online-Shop / Webshop-Betreiber — Rollen „Bestellverwaltung" und „Erweiterte Menükarten" zusätzlich; Kellnerrechte können minimal bleiben.
• Support-Zugriff für APRO — Zeitlich befristete Rolle „Tester" oder „Update Manager" — danach wieder entziehen.

Problembehebung

• „Kellner kann plötzlich keine Rechnung drucken" → Die Bediener-Gruppe wurde geändert oder der Bediener wurde in eine andere Gruppe verschoben. In der Gruppe das Recht „Rechnung drucken" setzen.
• „Kellner kann nach Rechnung nicht stornieren" → Absicht: nach Rechnungsdruck braucht es Chef-Rechte. Entweder Chef holen oder das Recht in der Kellner-Gruppe aktivieren (nicht empfohlen aus fiskaler Sicht).
• „Mitarbeiter sieht in my.apro zu viel" → Seine Rolle ist zu breit. Auf eine schmalere Rolle wechseln (z.B. von „Büro" auf „Maskenverwaltung") und Lokalzuweisung prüfen.
• „Neuer my.apro-Benutzer bekommt keine Einladungsmail" → E-Mail-Adresse prüfen, Spam-Ordner, Benutzer-Status („aktiv"). Einladung neu senden.
• „Rolle wurde geändert, aber Benutzer sieht alte Rechte" → Abmelden und neu anmelden. Browser-Cache löschen, falls das nicht hilft.
• „Accounting-Kollege soll nur FiBu-Export bekommen, sieht aber Artikel" → Rolle auf „Buchhaltung" einschränken und alle weiteren Rollen deaktivieren.
• „Einen Kellner auf zwei Gruppen zuweisen" → Nicht möglich. Entweder eine neue Gruppe anlegen, die beide Rechte-Sets vereint, oder einen zweiten Bediener für den Sonderfall anlegen.

Siehe auch

• bediener-anlegen.md — Bediener für den Kassen-Client anlegen und Gruppe zuweisen
• online-reports.md — Welche Berichte welche Rolle sieht
• lizenz-uebersicht.md — Lizenzierte Module entscheiden, welche Rollen überhaupt sichtbar sind
• stammdaten-sync-konfig.md — Bediener-Gruppen werden mit der Kasse synchronisiert
• ../uebergreifend/fibu-ablauf.md — Buchhaltungs-Rolle und FiBu-Export

Zielgruppe: Chef, Büro, Buchhaltung, APRO-Techniker
Typische Nutzung: Zahlungsarten anlegen/konfigurieren, FiBu-Konten zuordnen, Zahlungsmittel auf Geräte verteilen
Aufruf: my.apro → Kassenmodule → Payment → Zahlungsmittel

Zweck

Unter Payment werden alle Zahlungsmittel definiert, mit denen abgerechnet werden kann — Bar, Karte, Gutschein, Zimmer, Lieferschein, Stützung usw. Jedes Zahlungsmittel trägt die Information, ob es umsatzwirksam/verrechenbar ist, auf welches FiBu-Konto es bucht und auf welchen Geräten es verfügbar ist. Diese Einstellungen bestimmen direkt, wie ein Betrag in Z-Bericht, FiBu-Export und Onlineberichten erscheint.

Ablauf

Zahlungsmittel anlegen:

1. my.apro → Kassenmodule → Payment → Zahlungsmittel öffnen.
2. Neu wählen (oder ein bestehendes Kopieren).
3. Name, Nr., Zahlungsmittelgruppe, FiBu-Konto, Betrieb, Berechtigung setzen.
4. Optionen wie Standard, Zahlungsarttyp (bar), Visualisierung (Text/Icon im SB-Modus) festlegen.
5. Speichern.

Zahlungsmittel auf Geräte zuweisen:

1. Payment → Zuweisung öffnen.
2. Rechts das Zahlungsmittel wählen, per Drag & Drop auf das gewünschte Gerät (Kassa/Orderman/App) links ziehen.
3. Mehrere Zahlungsmittel gleichzeitig per Multiselect zuweisen.

Rechnung per E-Mail versenden:

1. Payment → Zahlungsmittel → [Zahlungsmittel] öffnen.
2. Beim Beleg das Druckprofil „RG E-Mail" zuweisen.
3. Rechnungen werden dann im Standardformat (A4) an die eingegebene E-Mail-Adresse gesendet.

Einstellungen

Felder je Zahlungsmittel:

• Name / Nr. — Bezeichnung und frei wählbare laufende Nummer.
• Zahlungsmittelgruppe — entscheidet umsatzwirksam vs. nicht umsatzwirksam und ob verrechenbar; „Transfer" wird mit Hotelprogrammen verwendet.
• FiBu-Konto — Konto für den Export.
• Betrieb — Lokal, für das das Zahlungsmittel gilt.
• Berechtigung — wer das Zahlungsmittel verwenden darf.
• Umbuchungsbeleg — Stornobeleg für dieses Zahlungsmittel.
• Zahlungsarttyp — ob es ein Barzahlungsmittel ist.
• Visualisierung — im SB-Modus als Text oder Icon.
• Standard — als vorausgewähltes Zahlungsmittel.
• Gutscheinzahlungsmittel — aktiviert zusätzliche Gutschein-Einstellungen (Gutscheinsystem).
• Notizpflicht — Popup mit Grundeingabe beim Umbuchen.
• Systemzahlungsmittel — intern für Online-Payment/Kioskbestellungen.
• Externes Zahlungsmittel — z.B. das verwendete Gutscheinsystem.

Beleg-Einstellungen (auch bei Gutscheinen):

• Name des Belegs (Anzeige auf Kasse/Orderman), Druckprofil, Belegkopie(n) + Kopie-Text (z.B. „Kundenkopie"/„Nachdruck"), Kunde (verpflichtend, wenn Kunde auf der Rechnung gedruckt werden soll), Standard.

Gutschein-spezifische Felder legt der APRO-Techniker an. Beim Gutscheinserver V3 ist die Web-URL voreingestellt; weitere Einstellungen sind dann nicht nötig.

Berechtigungen

Varianten

• Bar — verrechenbar, Zahlungsarttyp bar, meist Standard.
• Karte / Bankomat — verrechenbar; oft mit Terminalschnittstelle gekoppelt.
• Gutschein — als Gutscheinzahlungsmittel markiert, mit angebundenem Gutscheinsystem.
• Zimmer / Transfer — Übergabe an ein Hotelprogramm.
• Lieferschein — nicht (sofort) umsatzrelevant; spätere Sammelrechnung.
• Storno / Werbung / Eigenverbrauch — nicht umsatzwirksame Umbuchungen.
• RG E-Mail — Beleg „RG E-Mail" für A4-Rechnungsversand per Mail.
• Systemzahlungsmittel — Online-Payment / Kioskbestellung.

Problembehebung

• „Zahlungsmittel fehlt am Gerät" → Payment → Zuweisung prüfen; Zahlungsmittel per Drag & Drop dem Gerät zuweisen.
• „Betrag erscheint nicht im Z-Bericht" → Zahlungsmittelgruppe prüfen: nicht verrechenbare Zahlungsmittel sind nicht umsatzwirksam (siehe berichtsvergleiche.md).
• „FiBu bucht auf falsches Konto" → FiBu-Konto am Zahlungsmittel korrigieren.
• „Kunde fehlt auf der Rechnung" → In den Beleg-Einstellungen „Kunde" verpflichtend setzen.
• „E-Mail-Rechnung wird nicht versendet" → Beleg „RG E-Mail" am Zahlungsmittel zugewiesen? E-Mail-Adresse hinterlegt?
• „Gutschein-Einstellungen fehlen" → Häkchen „Gutscheinzahlungsmittel" setzen; Detailkonfiguration durch APRO-Techniker.

Siehe auch

• berichtsvergleiche.md — Verrechenbar/nicht verrechenbar steuert die Berichtszuordnung
• ../uebergreifend/fibu-ablauf.md — FiBu-Konten je Zahlungsmittel im Export
• ../bonneu/gutschein-ausstellen-einloesen.md — Gutscheinzahlungsmittel in der Praxis
• ../bonneu/split-zahlungsmittel.md — Abrechnung auf mehrere Zahlungsmittel
• ../bonneu/druckprofile.md — Druckprofile für Belege (inkl. „RG E-Mail")

Zielgruppe: Büro, Chef
Typische Nutzung: Beim Einrichten neuer Kassen und laufend beim Anpassen der Speisekarte
Aufruf: my.apro → Kassenmodule → Masken → Artikelmasken

Zweck

Die Artikelmaske ist die Oberfläche, die der Kellner beim Bonieren sieht — eine Kachel-Ansicht mit Ebenen wie „Speisen", „Getränke", „Desserts". Hier legt das Büro fest, welche Artikel auf welcher Ebene liegen, in welcher Reihenfolge und Farbe. Eine gute Artikelmaske spart dem Kellner pro Tisch mehrere Sekunden und hält die Einarbeitungszeit neuer Mitarbeiter kurz.

Ablauf

Neue Artikelmaske anlegen:

1. my.apro → Kassenmodule → Masken → Artikelmasken öffnen.
2. Neu anlegen — Name vergeben (z.B. „Restaurant", „Bar", „Take-Away").
3. Ebenen definieren — z.B. Ebene 1 „Speisen", Ebene 2 „Getränke", Ebene 3 „Desserts". Die Ebenen erscheinen später als oberste Tab-Reihe am Kassenclient.
4. Artikel herauslegen — pro Ebene werden Artikel per Drag & Drop auf freie Plätze gezogen.
5. Kacheln gestalten — Farbe, Schrift, Bild, Position und Größe je Kachel.
6. Speichern.
7. Maske dem Gerät zuweisen — my.apro → Kassenmodule → Administration → Geräte → [Kasse] → Artikelmaske. Erst dann sieht die betreffende Kasse die neue Maske.

Bestehende Maske ändern:

1. Maske öffnen.
2. Leere Kachel antippen → Artikel hinzufügen aus der Artikelliste.
3. Bestehende Kachel → Rechtsklick / Kontextmenü → Entfernen, Verschieben, Duplizieren.
4. Speichern.

Artikel aus Maske entfernen (ohne den Artikel zu löschen):

1. Maske öffnen, Ebene wählen.
2. Die Kachel auswählen und Entfernen. Der Artikel bleibt im Stamm, ist nur nicht mehr auf dieser Maske sichtbar.

Einstellungen

• Automatische Zuweisung neuer Artikel — my.apro → Kassenmodule → Betriebsdaten → Artikel → Neue Artikel automatisch auf Maske legen. Ist die Option aktiv, landen neu angelegte Artikel automatisch auf einer oder mehreren definierten Standardmasken. Ohne diese Option muss das Büro nach dem Anlegen eines Artikels die Maske manuell ergänzen.
• Anzahl Kacheln pro Ebene — in der Maske selbst (Raster z.B. 4×5, 6×6 oder frei).
• Mobile Artikelmaske — für Bonierapp/Orderman wird meist eine eigene, reduziertere Maske gepflegt (my.apro → Kassenmodule → Masken → Mobile Artikelmasken).
• Ebenen-Reihenfolge — über die Maskendetails; legt fest, welche Ebene beim Tischöffnen zuerst angezeigt wird.
• Zuordnung je Gerät — jedes Kassengerät bekommt genau eine Artikelmaske. Unterschiedliche Kassen können verschiedene Masken haben (z.B. „Restaurant" für die Servicekasse, „Bar" für den Schankbereich).

Berechtigungen

Varianten

• Eine Maske pro Betrieb — Der Standardfall für kleinere Betriebe mit einheitlicher Bedienung.
• Separate Masken je Bereich — z.B. eigene Maske für die Bar mit Schwerpunkt Getränke, eigene Maske für das Restaurant mit Speisen vorne.
• Mobile vs. stationäre Maske — Die mobile Variante hat größere Kacheln (Tablet/Orderman) und oft weniger Ebenen.
• SB-/Thekenverkauf — Reduzierte Maske mit den meistverkauften Artikeln vorne, meist ohne Ebenen-Wechsel.
• Ebene für Aktionen/Saison — Eigene Ebene „Aktion", die bei Menüwechsel einfach ausgetauscht wird, ohne die Hauptebenen zu verändern.
• Automatische Zuweisung aktiv — Das Büro legt Artikel an, der Artikel erscheint ohne manuellen Zwischenschritt auf der Maske. Typisch in Betrieben mit häufigem Sortimentswechsel.

Problembehebung

• „Neuer Artikel erscheint nicht auf der Maske" → Zuerst: ist die automatische Zuweisung aktiv? Wenn nein, den Artikel manuell auf die Maske ziehen. Prüfen, ob die richtige Ebene gewählt ist.
• „Kachel ist an der Kasse weiß/ohne Beschriftung" → Meist fehlt der Artikel am Kassengerät (Sync noch nicht durch) oder der Artikel wurde in my.apro gesperrt. Sync anstoßen und Artikel-Status prüfen.
• „Nach dem Ändern der Maske sieht die Kasse nichts" → Nach jeder Maskenänderung braucht es einen Sync. Prüfen, ob der Sync läuft (siehe stammdaten-sync-konfig.md) oder manuell auslösen.
• „Gerät zeigt die falsche Maske" → Im Gerät ist eine andere Maske zugewiesen. my.apro → Kassenmodule → Administration → Geräte → [Kasse] → Artikelmaske prüfen.
• „Kachel-Text wird abgeschnitten" → Zu lange Bezeichnung. Im Artikel das Feld „Kurzbezeichnung" pflegen — die erscheint bevorzugt auf der Kachel.
• „Reihenfolge der Ebenen stimmt nicht" → In der Masken-Ansicht die Ebenen per Drag & Drop umsortieren.

Siehe auch

• artikelverwaltung.md — Artikel anlegen (Voraussetzung für das Herauslegen)
• tische-bereiche.md — Analog: Tischmasken und Bereiche
• stammdaten-sync-konfig.md — Wie Maskenänderungen zur Kasse kommen
• ../bonneu/bonieren.md — So nutzt der Kellner die Maske im Alltag

Zielgruppe: Büro, Chef
Typische Nutzung: Laufend — bei neuer Speisekarte, Preiswechsel, saisonalen Änderungen
Aufruf: my.apro → Kassenmodule → Artikel

Zweck

In der Artikelverwaltung pflegt das Büro den kompletten Artikelstamm der Kasse: Speisen, Getränke, Zusatzleistungen, Gutscheine. Hier entscheidet sich, was der Kellner überhaupt bonieren kann, zu welchem Preis, mit welcher Mehrwertsteuer und in welcher Sparte gebucht wird. Änderungen landen nach dem nächsten Sync auf allen Kassen des Betriebs.

Ablauf

Neuer Artikel anlegen:

1. my.apro → Kassenmodule → Artikel öffnen.
2. Neu anlegen — die Artikelmaske öffnet sich.
3. Pflichtfelder ausfüllen:

• Artikelnummer (fortlaufend oder nach eigenem Schema)
• Bezeichnung (erscheint auf Bon, Rechnung und Anzeige)
• Sparte (z.B. „Speisen 10%", „Getränke 20%" — regelt MwSt. und Erlöskonto)
• Preis inkl. MwSt.

4. Optional ergänzen:

• Kurzbezeichnung für die Artikelmaske
• Zweitbezeichnung (z.B. für englische Speisekarte, Kundendisplay)
• Artikel-Typ (Standard, Gutschein, Menü, Leergut, Rabatt …)
• Beilagengruppen, Modifier, Zusatzfragen
• Produktionsdrucker (Küche/Bar)

5. Speichern — der Artikel bekommt sofort eine my.apro-ID und wird beim nächsten Sync an die Kasse(n) verteilt.

Artikel ändern:

1. Artikel in der Übersicht suchen (Nummer, Name, Sparte, Filter).
2. Zeile öffnen, Feld ändern, Speichern.
3. Preisänderungen greifen ab dem Zeitpunkt des Sync — laufende Tische behalten den alten Preis bis zum Abschluss.

Artikel sperren / entsperren:

1. Artikel öffnen → Flag „Gesperrt" (oder „Nicht bonierbar") setzen.
2. Gesperrte Artikel erscheinen nicht mehr in der Artikelmaske und werden auch in Online-Menüs ausgeblendet.
3. Zum Reaktivieren: Flag wieder entfernen.

Einstellungen

• Sparte und MwSt.-Satz — `my.apro → Kassenmodule → Sparten`. Jede Sparte hat einen MwSt.-Satz und ein FiBu-Erlöskonto. Neue Sparten nur anlegen, wenn wirklich ein eigenes Konto oder Steuersatz gebraucht wird.
• Automatische Zuweisung zu Artikelmasken — `my.apro → Kassenmodule → Betriebsdaten → Artikel. Ist die Option aktiv, landen neue Artikel automatisch auf einer definierten Standard-Maske. Sonst muss der Artikel manuell „herausgelegt" werden (siehe `artikelmaske-verwalten.md).
• Produktionsdrucker je Artikel — Artikel → Feld „Produktion". Entscheidet, auf welchem Küchendrucker der Bon erscheint.
• Beilagen- und Modifier-Gruppen — `my.apro → Kassenmodule → Artikel → Beilagen`. Einmal zentral angelegt, werden sie bei beliebig vielen Artikeln verknüpft.
• Außer-Haus-MwSt. — Flag „To-Go erlaubt" am Artikel. Wirkt in Kombination mit dem Tisch-Flag.

Berechtigungen

Varianten

• Standard-Artikel — fester Preis, feste Sparte. Der Regelfall.
• Offener Artikel — Preis wird beim Bonieren abgefragt. Praktisch für Sonderleistungen, Aushilfsware, Preis-auf-Anfrage.
• Menü-Artikel — Sammelartikel aus mehreren Positionen (Vorspeise + Hauptgang + Nachspeise). Eigene Preislogik.
• Gutschein-Artikel — Verkauf eines Gutscheins; der Artikeltyp „Gutschein" löst die Nummernvergabe aus dem Gutscheinsystem aus.
• Leergut / Pfand — Eigener Artikeltyp mit umgekehrter Rechnungslogik.
• Rabatt-Artikel — Negativer Wert, wird z.B. bei Happy-Hour-Stützungen gebucht (siehe stuetzungen.md).
• Artikel mit Waagenkopplung — Menge kommt aus der angeschlossenen Waage.
• Mehrere Betriebe — Ein Artikel kann je Betrieb unterschiedliche Preise haben. Wichtig bei Filialbetrieben.

Problembehebung

• „Neuer Artikel erscheint nicht an der Kasse" → Zuerst prüfen: Ist der Artikel gespeichert? Ist er einer Artikelmaske zugewiesen (manuell oder automatisch)? Ist der Sync gelaufen? Eventuell an der Kasse einen manuellen Stammdaten-Abruf starten.
• „Artikel hat falschen MwSt.-Satz auf der Rechnung" → Die Sparte des Artikels prüfen — nicht den Artikel selbst. MwSt. hängt immer an der Sparte.
• „Preisänderung greift nicht sofort" → Offene Tische rechnen mit dem Preis zum Bonierzeitpunkt. Erst nach Abschluss wird der neue Preis verwendet.
• „Artikel lässt sich nicht löschen" → Artikel, die bereits gebucht wurden, dürfen aus rechtlichen Gründen (Belegkette) nicht mehr gelöscht werden. Stattdessen sperren — dann verschwindet er aus allen Masken.
• „Fehlermeldung: Sparte ohne FiBu-Konto" → Beim FiBu-Export wird geprüft, ob alle Sparten ein Erlöskonto haben. Fehlende Konten in der Sparte nachtragen.
• „Zweitbezeichnung wird nicht gedruckt" → Am Drucker-Layout prüfen, ob das Feld „Zweitbezeichnung" im Bon-Template aufgenommen wurde.

Siehe auch

• artikelmaske-verwalten.md — Wie Artikel auf die Bedien-Oberfläche kommen
• stuetzungen.md — Preisstützungen, Happy-Hour, Kundengruppen-Preise
• stammdaten-sync-konfig.md — Wie Artikel-Änderungen zur Kasse kommen
• ../uebergreifend/fibu-ablauf.md — Sparten-Konten für den FiBu-Export
• ../bonneu/bonieren.md — Wie der Artikel dann am Kassen-Client boniert wird

Zielgruppe: Büro, Chef
Typische Nutzung: Bei Personalwechsel, Saisonstart, neuen Aushilfen
Aufruf: my.apro → Kassenmodule → Benutzer → Bediener

Zweck

Jeder, der an der Kasse bucht, braucht einen eigenen Bediener-Datensatz: Kellner, Chef, Büro-Aushilfe. Über den Bediener werden Umsätze zugeordnet (Kellnerabschluss), Rechte geregelt (was darf der Kellner, was der Chef) und Login-Mittel vergeben (Schloss, Barcode, PIN). Ein Kellner ohne eigenen Account macht weder betriebswirtschaftlich Sinn (kein sauberer Kellnerabschluss) noch rechtlich (Personalzuordnung auf Bon).

Ablauf

Neuen Bediener anlegen:

1. my.apro → Kassenmodule → Benutzer → Bediener → Neu anlegen.
2. Pflichtfelder:

• Bediener-Nummer (intern, oft fortlaufend)
• Name (erscheint auf Bon, Rechnung, Kellnerabschluss)
• Bediener-Gruppe (steuert Rechte — siehe userrollen.md)

3. Login-Mittel vergeben (mindestens eins):

• Schloss / Dallas-Chip / Addymat — Schloss-Nummer eintragen oder am Kassen-Gerät einlernen.
• Barcode — Barcode-Nummer vergeben und als Bediener-Karte drucken.
• PIN — Zahlencode (je nach Betrieb 4-6-stellig).

4. Optional:

• Foto (erscheint im Kellner-Login-Dialog)
• Farbe (Tischbelegungs-Anzeige pro Kellner)
• Zweitsprache (für mehrsprachige Teams)
• Benutzergruppe für Stützungen (Mitarbeiter-Preise)

5. Speichern. Beim nächsten Sync ist der Bediener an der Kasse verfügbar.

Bediener deaktivieren (Kündigung, Saisonende):

1. Bediener öffnen → Flag „Gesperrt" oder „Inaktiv".
2. Kellner kann sich nicht mehr anmelden, bleibt aber in allen alten Belegen und Kellnerabschlüssen erhalten.

Bediener-Karte drucken:

1. Bediener öffnen → Barcode / Ausweis drucken — ergibt eine Kunststoffkarte oder Klebe-Etikette.

Einstellungen

• Bediener-Gruppe — my.apro → Kassenmodule → Benutzer → Bediener-Gruppen. Hier liegen die Kassenrechte (siehe userrollen.md). Jeder Bediener hängt in genau einer Gruppe.
• Login-Methode pro Betrieb — my.apro → Kassenmodule → Betriebsdaten → Login. Ob Schloss, Barcode oder PIN Standard ist.
• Schloss-Einlernen — direkt am Kassengerät (Verwaltung → Bediener → Schloss zuordnen). Die Nummer landet dann im my.apro-Datensatz.
• Lokalzuweisung — bei Multi-Filiale: welche Lokale der Bediener bedienen darf (my.apro → User → Bediener & Mitarbeiter → Mitarbeiter).
• Mitarbeiter-Preis / Kundengruppe — für Personalverpflegung oder Rabatt auf Mitarbeiterkonsum (siehe stuetzungen.md).
• Bonierapp-Zugang — eigenes Flag, wenn der Kellner auch mobil über die Bonierapp arbeiten soll.

Berechtigungen

Varianten

• Kellner — Standard-Rolle. Darf boniert, abrechnen, eigene Tische, eigene Stornos vor Rechnung.
• Chef — Erweiterte Rechte: fremde Tische übernehmen, Preise ändern, Rabatt geben, Storno nach Rechnungsdruck.
• Aushilfe / Saison-Kellner — Technisch wie Kellner; wird am Saisonende nur gesperrt statt gelöscht, um die Umsatzhistorie zu erhalten.
• Büro/Verwaltung — Meist kein Kassen-Login nötig; stattdessen my.apro-Benutzer mit Büro-Rolle.
• Accounting — Nur Lesezugriff auf Berichte, keine Bonierung.
• Mehrfach-Login (ein Mitarbeiter, mehrere Betriebe) — Ein Bediener-Datensatz mit Lokalzuweisung für mehrere Filialen, statt überall neu anzulegen.
• Springer — Ein Bediener ohne feste Lokalzuweisung, der überall arbeiten darf — meist für Inhaber oder Gebietsleiter.

Problembehebung

• „Kellner kann sich nicht anmelden (Schloss)" → Prüfen, ob das Schloss am Gerät eingelernt ist. Gegebenenfalls neu zuordnen. Bei defekten Dallas-Chips: Support.
• „Barcode wird nicht erkannt" → Barcode-Reader am Kassen-Client testen; Barcode-Nummer in my.apro mit dem Aufdruck abgleichen; Bediener-Karte ggf. neu drucken.
• „Bediener zeigt falsche Rechte" → Falsche Bediener-Gruppe zugewiesen. my.apro → User → Bediener & Mitarbeiter → Mitarbeiter → [Name] prüfen.
• „Gesperrter Kellner erscheint trotzdem am Kassen-Login" → Sync wurde noch nicht ausgeführt. Kurz warten oder manuell anstoßen.
• „Kellner wird gelöscht — aber alte Belege zeigen noch seinen Namen" → Das ist gewollt: der Name bleibt in historischen Belegen erhalten (GoBD/RKSV). Für laufende Belege zählt der aktuelle Stand.
• „Zwei Kellner haben denselben Namen" → Bediener-Nummer entscheidet technisch, aber auf dem Bon steht der Name. Im Zweifel Namen um Initial ergänzen („Maria K.", „Maria S.").
• „Kellnerabschluss zeigt nichts" → Abschluss ist tagesbezogen. Prüfen, ob der Kellner an diesem Tag wirklich gebucht hat und ob der Tagesabschluss schon gelaufen ist.

Siehe auch

• userrollen.md — Rechte-Matrix der Bediener-Gruppen
• stuetzungen.md — Mitarbeiter-Preise, Kundengruppen-Preise
• stammdaten-sync-konfig.md — Wie neue Bediener zur Kasse kommen
• online-reports.md — Kellnerumsatz, Kellnerabschluss
• ../bonneu/bonieren.md — Kellner-Login am Kassen-Client

Zielgruppe: Gast beim Checkout — Einrichtung und Pflege durch Büro/Chef
Typische Nutzung: Bei jeder Online-Bestellung, bei der ein Gutschein ganz oder teilweise die Bezahlung ersetzt
Aufruf (Gast): Online-Checkout → Zahlungsmittel → „Gutschein einlösen"
Aufruf (Pflege): my.smorder.at → Payment → Zahlungsmittel und my.apro → Kassenmodule → Gutscheine → Verwaltung

Zweck

Ein Gast hat einen Gutschein — entweder einen APRO-Gutschein, den der Betrieb selbst ausgestellt hat (an der Kassa, im Webshop oder über das Gutscheinmodul), oder einen Fremdgutschein von einem Drittsystem (z. B. Incert, e-guma). Beim Online-Checkout gibt er den Gutscheincode ein; die Kasse prüft den Restwert und verrechnet ihn als Zahlung. Die Logik ist die gleiche wie an der Kasse (../bonneu/gutschein-ausstellen-einloesen.md, ../bonierapp/gutschein-ausstellen-einloesen.md) — nur passiert der Schritt im Webshop, ohne dass der Gast ins Lokal kommt.

Ablauf Gast

Standard-Ablauf „Online bestellen und mit Gutschein zahlen":

1. Bestellung zusammenstellen — Gast wählt Artikel in der Menükarte und geht in den Checkout.
2. Flow wählen — Abholung, Lieferung oder Tischbestellung (siehe preorder-takeaway-delivery.md).
3. Zahlungsmittel „Gutschein einlösen" wählen — erscheint nur, wenn das Lokal Online-Gutscheineinlösung freigegeben hat.
4. Code eingeben — Code aus dem Gutscheinbeleg (APRO-Gutschein) oder aus der Fremdsystem-Mail. Auf dem Smartphone lässt sich der Code auf vorgedruckten Karten auch direkt einfügen.
5. Restwert prüfen — Das System zeigt den aktuellen Restwert des Gutscheins. Wenn er den Rechnungsbetrag deckt, bleibt keine offene Zahlung.
6. Restbetrag begleichen (falls der Gutschein nicht reicht) — Der Gast wählt zusätzlich Karte, PayPal oder — je nach Betrieb — Barzahlung bei Abholung. Eine Kombination mehrerer Zahlungsmittel ist möglich, sofern das Zahlungsmittel split-fähig eingerichtet ist.
7. Bestellung abschließen — Der Gutscheinbetrag wird sofort abgebucht, die Bestellung geht wie gewohnt in die Kasse, und der Gast bekommt Bestätigung per E-Mail (inklusive verbleibendem Gutschein-Restwert, falls etwas übrig ist).

Ablauf im Backoffice

Damit der Gast diesen Schritt überhaupt sieht, muss die Einlösung freigegeben sein:

1. Gutschein-Kategorien anlegen/prüfen — in my.apro → Kassenmodule → Gutscheine → Verwaltung. Dort wird festgelegt, welche Art von Gutschein (Wertgutschein, Rabattgutschein, Wertkarte, Markerl) in welcher Form verwendet werden darf.
2. Kategorie für Online freigeben — pro Kategorie wird getrennt eingestellt, ob sie auf BonNeu, BonierApp, Kiosk und/oder im Smorder-Webshop einlösbar ist.
3. Zahlungsmittel in Smorder anlegen — im Smorder-Backoffice unter Payment → Zahlungsmittel wird ein Zahlungsmittel vom Typ „Gutschein" angelegt und mit der Kategorie-ID verknüpft.
4. Fremdgutschein-Systeme zusätzlich — für Incert, e-guma oder andere Drittsysteme wird zusätzlich zur APRO-Gutschein-Einlösung eine eigene Fremdgutschein-Option freigegeben; Details in der Schnittstellen-Doku.
5. Checkout testen — vor dem Live-Gang einen Testgutschein anlegen und den kompletten Checkout durchspielen.

Einstellungen

• Welche Kategorien online einlösbar sind — pro Gutschein-Kategorie in der Kassenverwaltung einzeln freigebbar.
• Mindest-/Restbetrag — ob ein Gutschein auch für sehr kleine Beträge einlösbar ist; pro Kategorie.
• Split-Zahlung zulassen — Gutschein + zweites Zahlungsmittel (Karte, PayPal). Steuerbar pro Zahlungsmittel im Smorder-Backoffice und in der Kassenstammdaten-Konfiguration.
• Welche Flows unterstützt die Einlösung — Online-Gutschein kann für Abholung, Lieferung und Tischbestellung separat erlaubt werden. Empfehlung: für alle drei Flows gleich behandeln, damit der Gast keine Überraschung erlebt.
• Gutscheinmodul zum Verkauf einbinden — der Verkauf von Gutscheinen auf der Website läuft entweder über das eingebettete Gutschein-Widget (JavaScript-Snippet auf der Homepage), eine direkte Weiterleitung zum Smorder-Gutscheinshop oder eine iframe-Einbettung. Die drei Wege unterscheiden sich nur im Integrationsaufwand — am Ende landet der Gutschein in der gleichen Verwaltung.
• Fremdgutschein-Freischaltung — in Smorder wird pro Fremdsystem die API-Anbindung aktiviert und die Zahlungsmittel-ID zugeordnet.
• E-Mail-Vorlage mit Restwert-Hinweis — nach Teileinlösung kann dem Gast automatisch eine Bestätigung mit dem verbleibenden Restwert zugeschickt werden.

Berechtigungen

Varianten

• APRO-Wertgutschein online einlösen — klassischer Geschenkgutschein, wird als Zahlungsmittel von der Rechnung abgezogen. Restwert bleibt am Code erhalten.
• APRO-Rabatt-Gutschein online einlösen — reduziert die Summe auf Positionsebene (z. B. „10 € Willkommens-Bon"). Für den Gast im Checkout gleich, die Kasse rechnet automatisch.
• Teileinlösung mit Rest-Zahlung — Gutschein deckt nicht die ganze Rechnung, Gast zahlt den Rest per Karte/PayPal. Möglich, sofern das Gutschein-Zahlungsmittel split-fähig ist.
• Mehrere Gutscheine auf eine Bestellung — je nach Konfiguration dürfen Kunden mehrere Codes nacheinander eintragen. Restbeträge jedes Gutscheins werden einzeln abgebucht.
• Wertkarte / Token — aufladbare Karte mit Saldo. Online-Einlösung bucht vom Saldo ab, Aufladungen kann der Gast im Gutscheinshop selbst vornehmen (z. B. als Geburtstagsgeschenk an sich selbst).
• Markerl / Stück-Gutschein — Stück-basiert, pro Einlösung wird ein Stück abgebucht. Online eher selten, aber möglich für B2B-Catering-Szenarien.
• Fremdgutschein (Incert, e-guma u. a.) — der Gast gibt den Code seines Drittsystem-Gutscheins ein; Smorder fragt dort den Restwert ab und zieht ihn ab. Detail-Einrichtung pro System ist in der Schnittstellen-Doku beschrieben.
• Gutscheinverkauf ohne Einlösung — manche Betriebe verkaufen Gutscheine ausschließlich online (eigene Landingpage), lösen sie aber nur am Bon ein. Das ist möglich, indem die Online-Einlösung für die Kategorie deaktiviert bleibt.

Problembehebung

• „Code wird nicht akzeptiert" → Passende Kategorie online freigegeben? Code genau wie gedruckt eingegeben (ohne Bindestriche/Leerzeichen)? Gültigkeitsdatum abgelaufen?
• „Gutschein taucht im Checkout gar nicht als Zahlungsmittel auf" → Online-Zahlungsmittel „Gutschein" im Smorder-Backoffice nicht aktiv oder nicht mit einer Kategorie verknüpft.
• „Restwert passt nicht zu dem, was der Gast erwartet" → Der Gutschein wurde möglicherweise an der Kasse oder einem anderen Kanal schon teilweise eingelöst. Der angezeigte Restwert ist der aktuelle, verbindliche Stand.
• „Fremdgutschein akzeptiert den Code nicht" → Schnittstelle zum Drittsystem prüfen (Zugangsdaten, Endpunkt). Im Zweifel parallel im Admin-Bereich des Drittsystems prüfen, ob der Code dort noch gültig ist.
• „Bestellung war bezahlt, Gutschein aber nicht abgebucht" → Seltener technischer Fall. Bestellung stornieren und erneut einlösen; im Zweifel Support kontaktieren.
• „Split-Zahlung geht nicht (Gutschein + Karte)" → Zahlungsmittel „Gutschein" muss in den Kassenstammdaten als split-fähig markiert sein. Außerdem muss das zweite Zahlungsmittel online verfügbar sein.
• „Gast will nachträglich einen Gutschein einlösen" → Nach Abschluss der Online-Bestellung nicht mehr möglich. Stornieren und neu bestellen, oder bei Abholung den Gutschein direkt an der Kassa einreichen.

Siehe auch

• ../bonneu/gutschein-ausstellen-einloesen.md — Windows-POS-Variante (Einlösung an der Kassa)
• ../bonierapp/gutschein-ausstellen-einloesen.md — Mobile Variante (Einlösung am Tablet/Orderman)
• stripe-paypal-zahlung.md — Zweite Zahlung bei Gutschein + Karte/PayPal
• webshop-einrichtung.md — Grundsetup des Webshops
• ../myapro/stammdaten-sync-konfig.md — Pflege der Gutschein-Kategorien in my.apro
• Schnittstellen-Doku (für Techniker): docs/schnittstellen/articles/gutschein/apro-gutschein.md, docs/schnittstellen/articles/gutschein/fremd-gutschein-sammel.md, docs/schnittstellen/articles/gutschein/incert.md

Zielgruppe: Büro, Chef
Typische Nutzung: Einmalig beim Einrichten, danach selten — z. B. bei einer gesetzlichen Steuersatz-Änderung oder wenn Getränke falsch verbucht werden
Aufruf: my.apro → Kassenmodule → Sparten

Zweck

Wo ändere ich den Steuersatz für Getränke (oder Speisen)? Der Mehrwertsteuer-Satz hängt in APRO nicht am einzelnen Artikel, sondern an der Sparte (Warengruppe). Jeder Artikel ist einer Sparte zugeordnet, und diese Sparte legt MwSt.-Satz und FiBu-Erlöskonto fest. Wer den Steuersatz für Getränke ändern will, ändert also entweder den Satz der Getränke-Sparte oder ordnet die betroffenen Artikel einer Sparte mit dem gewünschten Satz zu.

Ablauf

Steuersatz einer bestehenden Sparte ändern:

1. my.apro → Kassenmodule → Sparten öffnen.
2. Die betroffene Sparte suchen (z. B. „Getränke 20 %") und die Zeile öffnen.
3. Feld MwSt.-Satz auf den neuen Wert setzen.
4. Prüfen, ob das hinterlegte FiBu-Erlöskonto zum neuen Satz passt (sonst mit anpassen — siehe ../uebergreifend/fibu-ablauf.md).
5. Speichern — die Änderung wird beim nächsten Sync an alle Kassen verteilt.

Einzelne Artikel auf einen anderen Steuersatz umstellen (ohne die bestehende Sparte zu verändern):

1. Bei Bedarf eine neue Sparte mit dem gewünschten MwSt.-Satz und einem eigenen Erlöskonto anlegen.
2. my.apro → Kassenmodule → Artikel öffnen, die betroffenen Getränke-Artikel suchen.
3. Im Artikel die Sparte auf die gewünschte Sparte umstellen.
4. Speichern und Sync abwarten.

Einstellungen

• MwSt.-Satz und Erlöskonto je Sparte — `my.apro → Kassenmodule → Sparten`. Zentrale Stelle für alle Steuersätze. Neue Sparte nur anlegen, wenn wirklich ein eigener Satz oder ein eigenes Konto gebraucht wird.
• Sparte je Artikel — `my.apro → Kassenmodule → Artikel`. Bestimmt, welcher Steuersatz für den jeweiligen Artikel gilt.
• Außer-Haus-Steuersatz (To-Go) — Flag „To-Go erlaubt" am Artikel in Kombination mit dem Tisch-Flag. Der reduzierte Außer-Haus-Satz wird automatisch gezogen, wenn der Tisch als To-Go gekennzeichnet ist (siehe ../software-Hinweise zur DE-To-Go-MwSt im Technik-Wiki).

Berechtigungen

Varianten

• Steuersatz der ganzen Sparte ändern (Situation: gesetzliche Umstellung, z. B. neuer Getränkesatz) — wirkt auf alle Artikel der Sparte gleichzeitig.
• Einzelne Artikel umhängen (Situation: nur bestimmte Getränke sollen einen anderen Satz haben) — neue Sparte anlegen und die Artikel dorthin verschieben.
• Außer-Haus vs. Im-Haus (Situation: Take-Away mit reduziertem Satz) — über das To-Go-Flag statt über eine eigene Sparte.

Problembehebung

• „Getränk hat den falschen Steuersatz auf der Rechnung" → Zuerst die Sparte des Artikels prüfen, nicht den Artikel selbst — die MwSt. hängt immer an der Sparte.
• „Steuersatz geändert, aber die Kasse rechnet noch alt" → Sync abwarten bzw. an der Kasse einen manuellen Stammdaten-Abruf starten. Offene Tische rechnen außerdem mit dem Satz zum Bonierzeitpunkt — erst nach Abschluss greift der neue Satz.
• „Fehlermeldung: Sparte ohne FiBu-Konto" → Beim FiBu-Export wird geprüft, ob jede Sparte ein Erlöskonto hat. Fehlendes Konto in der Sparte nachtragen.
• „Alle Getränke auf einmal ändern dauert lange" → Nicht jeden Artikel einzeln umstellen, sondern den Satz an der gemeinsamen Sparte ändern.

Siehe auch

• artikelverwaltung.md — Artikel anlegen und einer Sparte zuordnen
• ../uebergreifend/fibu-ablauf.md — Sparten-Erlöskonten für den FiBu-Export
• stammdaten-sync-konfig.md — Wie die Änderung zur Kasse kommt

Zielgruppe: Büro, Chef
Typische Nutzung: Einmalig beim Einrichten, danach bei Umbauten oder Saisonwechsel (Schanigarten, Terrasse)
Aufruf: my.apro → Kassenmodule → Masken → Tischmasken (bzw. Bereiche / Tische)

Zweck

Tische und Bereiche bilden den Grundriss des Lokals in der Kasse ab: Gastraum, Bar, Terrasse, Saal, Take-Away. Der Kellner sieht beim Login sofort, welche Tische frei, besetzt oder abgerechnet sind. Gut gepflegte Bereiche machen den Servicefluss schneller und halten Auswertungen wie Umsatz-pro-Bereich sauber.

Ablauf

Bereiche anlegen:

1. my.apro → Kassenmodule → Masken → Bereiche öffnen.
2. Neu anlegen — Name vergeben (z.B. „Restaurant", „Bar", „Terrasse", „Schanigarten").
3. Optional: Farbe, Icon, Lokalzuordnung (bei Multi-Filiale).
4. Speichern.

Tische im Bereich anlegen:

1. my.apro → Kassenmodule → Masken → Tische öffnen.
2. Neu anlegen — pro Tisch: Nummer, Name (z.B. „T1", „Fenster 3"), Personenzahl, Bereich.
3. Für mehrere Tische auf einmal die Funktion „Mehrere Tische anlegen" nutzen (Start-Nummer, End-Nummer, Präfix).
4. Speichern — die Tische sind jetzt im Stamm, aber noch auf keiner Maske sichtbar.

Tischmaske anlegen:

1. my.apro → Kassenmodule → Masken → Tischmasken → Neu anlegen.
2. Ebenen definieren — meist eine Ebene pro Raum/Bereich.
3. Tische herauslegen — per Drag & Drop auf die Ebene; Position und Größe so, dass der Grundriss grob passt.
4. Speichern.
5. Maske dem Gerät zuweisen: my.apro → Kassenmodule → Administration → Geräte → [Kasse] → Tischmaske.

Tisch umbenennen / verschieben:

1. Tisch im Stamm öffnen → Name/Bereich ändern → Speichern.
2. Maske öffnen, Tischkachel neu positionieren oder auf andere Ebene ziehen.

Einstellungen

• Bereichszuweisung — my.apro → Kassenmodule → Masken → Tische → [Tisch] → Bereich. Der Bereich steuert Auswertungen („Umsatz Terrasse") und kann pro Bereich ein eigenes Druck- oder Abrechnungsverhalten haben.
• Produktion pro Bereich — my.apro → Kassenmodule → Administration → Drucker in Kombination mit dem Bereich. Beispielsweise gehen Getränke vom Bereich „Bar" auf einen anderen Drucker als die aus dem „Restaurant".
• Produktion erst bei Rechnung — my.apro → Kassenmodule → Masken → Tische → [Tisch] → Erweitert. Praktisch für Theken, Kiosk, Schnellbetrieb.
• Außer-Haus-Tische — Flag „To-Go" am Tisch. Zusammen mit dem Artikel-Flag „To-Go erlaubt" (DE) wird die reduzierte Mehrwertsteuer gebucht.
• Ebenen-Reihenfolge — die zuerst angezeigte Ebene wird beim Kellner-Login als Standard eingeblendet.
• Mehrere Tischmasken — sinnvoll, wenn die Servicekasse den ganzen Grundriss sieht, die Bar aber nur den Thekenbereich.

Berechtigungen

Varianten

• Ein Bereich, eine Ebene — Kleiner Betrieb mit einem Gastraum. Alle Tische auf einer Ebene, kein Bereichs-Wechsel nötig.
• Mehrere Bereiche in einer Ebene — Bereiche werden durch Farbe/Position unterschieden; der Kellner sieht alles auf einen Blick.
• Eine Ebene pro Bereich — Großer Betrieb mit mehreren Räumen. Tabs oben am Kassen-Client wechseln zwischen „Restaurant", „Bar", „Terrasse".
• Saisonbereich Terrasse/Schanigarten — Eigener Bereich, der in der Nebensaison versteckt werden kann.
• Schnellkassen-/Thekenbetrieb — Meist nur ein „virtueller" Tisch oder gar keine Tischmaske, direkt SB-Modus.
• Hotel + Restaurant kombiniert — Zusätzliche „Zimmer-Tische" für Zimmerbuchungen; oft in einem eigenen Bereich gebündelt.
• Event-/Cateringbetrieb — Dynamisches Anlegen von temporären Tischen pro Event (siehe auch „Eventlösung").

Problembehebung

• „Neuer Tisch ist nicht am Kassen-Client sichtbar" → Tisch ist angelegt, aber nicht auf einer Tischmaske herausgelegt. In der Tischmaske ergänzen und Sync abwarten.
• „Tisch lässt sich nicht löschen" → Auf dem Tisch wurden bereits Bonierungen gemacht. Tische dürfen wegen der Belegkette nicht gelöscht werden — stattdessen in einen inaktiven Bereich verschieben oder umbenennen und vor Kellnern verstecken.
• „Tischbezeichnung wurde geändert, Kasse zeigt den alten Namen" → Sync noch nicht gelaufen. Manuell anstoßen oder kurz warten.
• „Umsatz eines Bereichs stimmt im Bericht nicht" → Prüfen, ob alle Tische dem richtigen Bereich zugewiesen sind. Ein Tisch ohne Bereich landet meist in „Sonstige".
• „Getränkebons gehen in die falsche Küche" → Produktion-Zuordnung pro Bereich bzw. Artikel prüfen.
• „Tischmaske zeigt doppelte Tische" → Derselbe Tisch wurde auf zwei Ebenen herausgelegt. Auf einer Ebene wieder entfernen.

Siehe auch

• artikelmaske-verwalten.md — Analoge Logik für Artikelmasken
• artikelverwaltung.md — Artikel, die auf diesen Tischen boniert werden
• stammdaten-sync-konfig.md — Wie Tisch-/Bereichs-Änderungen zur Kasse kommen
• online-reports.md — Auswertungen nach Bereich und Tisch
• ../bonneu/bonieren.md — Tisch öffnen und bonieren im Alltag