Betriebsgastronomie: Lastenheft Kassensystem

• Kassenterminals (Stationär): Jeder Standort benötigt mehrere festinstallierte Kassenterminals mit Touchscreen-Bedienung. Die Terminals sollen ergonomisch und intuitiv bedienbar sein, mit ausreichend großem Display (z.B. 15 Zoll oder größer) und einer robusten Bauart für den täglichen Gastronomieeinsatz. Leistungsfähige Hardware ist erforderlich, um schnelle Buchungen ohne Verzögerung zu ermöglichen (insbesondere zur Mittagszeit mit hohem Durchsatz). Die Terminals müssen spritzwasser- und schmutzresistent sein (Kantinenumgebung, ggf. Speisenausgabe in der Nähe) und leicht zu reinigen. Ein kundenseitiges Display zur Anzeige von Preisen/Summen ist wünschenswert (Soll-Anforderung) für Transparenz gegenüber dem Gast.

• Belegdrucker (Bondrucker): Pro Kasse ist ein Thermobondrucker für Kassenbelege erforderlich (integriert oder extern). Die Drucker sollen schnell und zuverlässig Belege im gesetzlich geforderten Format ausgeben. Eine Unterstützung für digitale Belege (z.B. per QR-Code oder E-Mail versendbar) ist wünschenswert, sofern der Kunde zustimmt und unter Einhaltung des Datenschutzes. Der Bondrucker muss gängige Formate (58mm oder 80mm Papierbreite) unterstützen und über ausreichende Papierkapazität verfügen, um Stoßzeiten ohne häufigen Rollenwechsel zu überstehen.

• Kassenlade: Eine abschließbare Kassenlade zur Aufbewahrung von Bargeld ist erforderlich (Muss), außer an rein bargeldlosen Stationen. Die Lade soll robust sein und sich elektronisch über das Kassensystem öffnen lassen. Integrierte Fächer für Münzen und Scheine in Euro-Währung werden erwartet. Bei bargeldlosen Self-Service-Kassen kann ggf. auf eine Kassenlade verzichtet werden (dann Kennzeichnung als nicht erforderlich). Sicherheit (z.B. Öffnung nur durch berechtigtes Personal) ist zu gewährleisten.

• Scanner (Barcode/QR-Code): An jedem bedienten Kassenplatz ist ein Barcodescanner (1D/2D) oder vergleichbare Erfassungseinheit nötig, um Artikel (z.B. abgepackte Ware wie Getränke) und Mitarbeiterausweise bzw. QR-Codes zu scannen. Unser Betriebsgastronomie-Konzept arbeitet mit Mitarbeiterkarten / Ausweisen als Zahlungsmittel; ein Scanner ermöglicht das schnelle Einlesen solcher Karten (sofern mit Barcode/QR-Code versehen). Ebenso sollen eventuell Gutscheine oder digitale Tickets (mit Barcode/QR) gescannt werden können. Der Scanner sollte omnidirektional und zügig lesen, um keine Wartezeit zu verursachen.

• Waagen-Integration: Da Speisen auch nach Gewicht verkauft werden (Salatbars o.ä.), muss das Kassensystem Wägesysteme integrieren können. Das heißt, eine Kassenwaage kann angebunden werden, deren Gewichtsdaten direkt ins Kassensystem übernommen werden. Die Waage sollte eichfähig sein und den tara/zero-Abzug (z.B. Tellergewicht) unterstützen. Die Integration soll so erfolgen, dass das Produkt automatisch nach Gewicht und Preis pro kg berechnet wird, ohne manuelles Eingreifen der Kassenkraft.

• Bezahlsystem-Terminals: Für kartengestützte Zahlungen (EC-Karte, Kreditkarte, NFC) sind EC-Cash-Terminals bzw. Bezahlterminals vorzusehen. Diese können entweder in das Kassenterminal integriert oder als separates Gerät vorhanden sein. Wichtig ist eine Anbindung an das Kassensystem für automatischen Betragstransfer (keine manuelle Eingabe des Betrags am Terminal). Die Terminals müssen kontaktloses Bezahlen (NFC, z.B. Girocard kontaktlos, Kreditkarten, Smartphone Pay) unterstützen und PCI-DSS konform sein. In Deutschland üblich ist z.B. die ZVT- oder OPI-Schnittstelle für die Kassenintegration – das System sollte solche Standards unterstützen. Die Terminals sollten für alle gängigen Karten (Girocard, Maestro/V-Pay, Mastercard, Visa, ggf. Fleet-Karten) zugelassen sein.

• Weitere Peripherie: Falls an den Standorten Küchendrucker (für Bestellbons in Küche) benötigt werden, muss das Kassensystem solche Drucker ansteuern können (Netzwerk- oder USB-Drucker, Soll-Anforderung falls Ausgabensteuerung gewünscht). Ebenso sollte das System Kundenkarten-Leser unterstützen, falls Mitarbeiter-Ausweise nicht per Barcode sondern z.B. per RFID/Chip ausgelesen werden (z.B. ein USB-Kartenleser für Mifare/NFC Karten). Eine Ansteuerung von externen Anzeigen (z.B. Bildschirme für Ausgabeaufruf oder Info-Screens) ist optional wünschenswert, falls das Konzept z.B. eine Ausgabeanzeige vorsehen sollte (Kann).

• Robustheit und Ersatz: Alle Hardware-Komponenten müssen für den Dauerbetrieb an mindestens 5 Tagen pro Woche ausgelegt sein und auch häufige Bedienvorgänge über Jahre hinweg zuverlässig durchhalten. Industrietaugliche Komponenten sind zu bevorzugen. Der Anbieter soll Mindestanforderungen an die Hardware-Qualität garantieren (z.B. IP-Schutzklassen, Falltests für mobile Geräte etc.). Zudem sollte ein Konzept für Ersatzgeräte bestehen – z.B. Austausch innerhalb kurzer Zeit bei Defekt.

• Verpflegungsautomaten (Snack/Getränkeautomaten): In der Betriebsgastronomie können an Standorten Automaten für den 24/7-Zugriff auf Snacks, Getränke oder fertige Speisen stehen. Das Kassensystem sollte in der Lage sein, diese Automaten bargeldlos in das Zahlungssystem zu integrieren. Das bedeutet, Mitarbeiter sollten an Automaten mit demselben Medium (Mitarbeiterausweis/Guthaben) bezahlen können wie an der Kasse. Erforderlich ist entweder eine direkte Integration der Automaten in das Kassennetzwerk oder zumindest eine Schnittstelle, über die Automatentransaktionen im Backend erfasst werden. Falls bereits Automaten vorhanden sind, muss der Anbieter prüfen, ob Nachrüstsätze (bargeldlose Zahlungseinheiten) kompatibel sind. Eine Automaten-Integration ist vor allem ein Kann-Kriterium, wird aber angestrebt, um ein einheitliches Zahlungssystem über alle Kanäle zu haben.

• Aufladeterminals für Mitarbeiterausweise: Sofern ein Prepaid-Guthabensystem für Mitarbeiterkarten eingesetzt wird, sind Ladeterminals vorgesehen, an denen Nutzer Bargeld oder EC-Kartenzahlung nutzen können, um ihr Karten-Guthaben aufzuladen. Diese Terminals sollten ebenfalls vom Anbieter mitgeliefert oder integriert werden können (Kann). Alternativ kann das Aufladen über die Kassen selbst oder eine App erfolgen. Wichtig ist die Kompatibilität: Ein Mitarbeiter, der an einem separaten Terminal sein Guthaben auflädt, soll dieses unmittelbar auf dem Kassensystem zur Verfügung haben (Echtzeit-Verbuchung im Konto).

• Mobile Kassen (Tablet/Handheld): Für besondere Einsatzzwecke soll das System auch mobile Kassengeräte unterstützen. Dies können z.B. Tablets mit entsprechender Kassensoftware oder spezielle Handheld-Geräte sein. Anwendungsfälle sind z.B. temporäre Verkaufsstationen (etwa bei Events oder Sonderaktionen im Unternehmen) oder Kellnerkassen bei Bedienkonzepten. Die mobilen Kassen müssen online/offline mit dem Backend synchronisieren (WLAN-Fähigkeit) und idealerweise die gleichen Kernfunktionen bieten wie die stationären Kassen (Artikel buchen, Zahlungen entgegennehmen – ggf. Kartenzahlung über ein mobiles Terminal gekoppelt via Bluetooth). Ein Tablet mit ansteckbarem Kartenleser könnte hier ein Szenario sein. Mobile Kassen sind für ein Betriebsrestaurant ein Kann-Kriterium (nice-to-have), es sei denn, es gibt Bereiche mit Tischbedienung (z.B. Konferenzservice), wo sie zum Soll werden.

• Inventur/Verwaltungsgeräte: Abseits des Verkaufsvorgangs könnte auch gefordert sein, dass mobile Geräte (z.B. Scanner) für Inventur oder Bestandsmanagement angebunden werden können. Falls die Betriebsgastronomie beispielsweise ein Lager führt, könnte ein Kann-Kriterium sein, dass mobile Datenerfassungsgeräte unterstützt werden, um Bestände abzubuchen oder Lieferungen zu erfassen. Dies ist jedoch optional und abhängig vom Konzept (eher im Warenwirtschaftskontext, falls Teil des Projekts).

• Lokalnetzwerk: Das Kassensystem muss innerhalb jedes Standorts in das vorhandene Netzwerk integriert werden können. Stationäre Kassen sollen via LAN (Ethernet) angebunden werden (stabile Verbindung, PoS sollten möglichst per Kabel angeschlossen sein). Für mobile Geräte ist WLAN erforderlich. Die Hardware sollte entsprechende Schnittstellen haben (min. 1x LAN RJ45 pro Kasse, WLAN-Modul für Tablets). Die Netzwerkinfrastruktur (Switche, Access Points) wird vom Auftraggeber gestellt, aber der Anbieter muss Anforderungen benennen (z.B. benötigte Ports, QoS, Bandbreite). Das System sollte mit typischen Unternehmensnetzwerken kompatibel sein, inklusive VLAN-Konzepten (z.B. separates VLAN für Kassen) und Sicherheitsvorgaben der IT (z.B. Unterstützung von 802.1x Authentifizierung, falls relevant).

• Standortvernetzung: Da unterschiedliche Aufstellorte zu einem Gesamtsystem gehören, müssen diese vernetzt sein. Entweder geschieht dies über das bestehende Firmen-WAN/VPN oder bei Cloud-Lösung über Internet. Die Hardware vor Ort muss entsprechend konfiguriert werden können, um die Kommunikation zum zentralen Server/Cloud abzusichern (VPN-Client, Firewall-Regeln). Anforderungen an Latenz und Verfügbarkeit: Das System sollte auch bei zeitweiser Verbindungsstörung zwischen Standort und Zentrale lokal weiterarbeiten können. Auf Hardware-Ebene heißt das: Falls ein zentraler Server ausfällt, sollten zumindest die Kassenterminals für eine definierte Zeit autark buchen können (mit TSE vor Ort) – dies ist eher eine Softwarearchitekturfrage, aber eng mit Infrastruktur verbunden.

• USV/Stromversorgung: Es wird empfohlen (Kann), kritische Komponenten wie Server oder Netzwerkgeräte über unterbrechungsfreie Stromversorgung (USV) abzusichern, um Datenverluste bei Stromausfall zu vermeiden. Die Kassenhardware selbst sollte bei Stromausfall kontrolliert herunterfahren oder einen Zwischenpuffer (Batterie für x Minuten) haben, falls möglich, um Transaktionen sauber abzuschließen.

• Performance: Die Netzwerkhardware muss in der Lage sein, die typischen Transaktionsdaten der Kassen in Echtzeit zu übertragen. Kassendaten sind nicht sehr bandbreitenintensiv, aber die Latenz sollte gering sein (<100ms zum Server) um Wartezeiten beim Bezahlen zu vermeiden. Falls Cloud: verlässliche Internetanbindung mit ausreichender Bandbreite pro Standort (Anbieter soll Vorgaben machen, z.B. mindestens x Mbit synchron, je nach System). Falls On-Premise mit Standortkopplung: Standortvernetzung (MPLS, VPN) sollte vorhanden sein. Diese Infrastrukturvoraussetzungen werden im Pflichtenheft vom Auftraggeber konkretisiert, aber der Anbieter muss unterstützen mit technischen Anforderungen.

• Redundanzen: Für zentrale Hardware-Komponenten (z.B. Server, zentrale Datenbank falls lokal gehostet) sind Redundanzen oder ein Hochverfügbarkeitskonzept wünschenswert (Soll). Z.B. RAID für Serverfestplatten, ggf. zweites Servergerät im Hot-Standby (Kann) oder Cloud-Cluster je nach Betriebsmodell. Vor Ort könnte eine Kasse als Ausfallkasse definiert sein, die temporär Übernahmen macht. Alle Kassengeräte sollten sich notfalls auch austauschen lassen ohne lange Ausfallzeiten (Konfigurationen aus Backup einspielbar).

• Erweiterbarkeit: Die Hardware sollte modular erweiterbar sein. Beispielsweise sollte es möglich sein, später zusätzliche Peripherie anzuschließen (weitere Drucker, Scanner) oder Kassenplätze aufzurüsten (Anzahl der Kassen pro Standort skalieren). Schnittstellen wie USB, RS232 (für Waagen/Scanner), Netzwerkports etc. sollten ausreichend vorhanden sein. Bei Self-Service-Kiosken sollte Hardware so ausgewählt sein, dass Upgrades (z.B. bessere Kamera für KI-Kasse) möglich sind, ohne das ganze Terminal tauschen zu müssen.

• Kompatibilität: Falls der Auftraggeber bereits bestimmte Hardware hat (z.B. Monitore, Drucker), soll geprüft werden, ob diese weiterverwendet werden können (Kann). Das Kassensystem sollte gängige Hardwaretreiber unterstützen. Ebenso sollte bei Neuanschaffung auf gängige Industriestandards gesetzt werden, damit Ersatzteile verfügbar sind und kein proprietäres, schlecht ersetzbares System geliefert wird.

• Grundfunktionen Verkauf: Die Kassensoftware muss alle gängigen Verkaufsfunktionen abdecken. Dazu gehört die schnelle Erfassung von Artikeln (per Touch-Auswahl auf einem konfigurierbaren Menü/Artikelbaum oder via Scanner bei Barcode-Artikeln), das Buchen von Mengen, automatische Preisberechnung inkl. ggf. Staffelungen/Rabatte, das Zwischensummen und letztlich das Abschließen des Vorgangs mit Wahl der Zahlart. Vorgänge wie Storno (Abbruch einer Buchung), Artikelstorno (Entfernen eines Artikels), Rabattgewährung (z.B. Personalrabatt oder Aktionsrabatt) müssen vorhanden sein. Storno- und Rabattaktionen sollen gemäß GoBD protokolliert werden (mit Benutzer und Uhrzeit). Eine Parkbon-Funktion (Vorgang zwischenparken) ist nützlich, falls ein Kunde etwas nachholen muss.

• Geschwindigkeit und Usability: Die Oberfläche sollte intuitiv sein, so dass Einarbeitungszeiten gering sind. In Stoßzeiten muss die Kassenapplikation sehr reaktionsschnell sein – keine merkbaren Verzögerungen bei Eingaben. Buttons und Texte sollen groß/genug für Touch-Bedienung dimensioniert sein. Für unterschiedliche Verkaufsarten (Frühstück, Mittag, Snack) könnten unterschiedliche Layouts/Profile ladbar sein (optional). Mehrsprachigkeit der Oberfläche (Deutsch als Pflicht, Englisch optional) wäre ein Vorteil (Kann), falls z.B. internationales Personal an der Kasse arbeitet.

• Artikel- und Warengruppenverwaltung (Frontend-Aspekte): Die Kassenoberfläche sollte nach Warengruppen oder Menüstrukturen gegliedert werden können. Beispielsweise Menüs: Getränke, Hauptspeisen, Beilagen etc. – idealerweise frei konfigurierbar je Standort oder zentral vorgegeben. Jeder Artikel hat definierte Preise (ggf. mehrere je nach Nutzergruppe, siehe Nutzergruppen-Kapitel) und Steuerkennzeichen. Die Applikation muss verschiedene Steuersätze handhaben können (z.B. 7% Lebensmittel, 19% Getränke, falls relevant) – in der Gemeinschaftsverpflegung meist relevant, da Speisen ggf. ermäßigt besteuert werden, Getränke voll. Diese Logik muss abgebildet sein.

• Kassenvorgänge: Unterstützung für spezielle Vorgänge: Bon splitten (Aufteilung einer Rechnung, z.B. wenn mehrere zusammen zahlen und dann getrennt werden – in Kantine selten, aber falls z.B. Besucher gemeinsam zahlen und dann trennen, optional), Mehrfachzahlung (Kombination von Zahlungsmitteln pro Vorgang, z.B. teilweise Bar, teilweise Karte – sollte möglich sein). Trinkgeld-Funktion (bei Kartenzahlung Trinkgeld erfassen) ist wahrscheinlich im Kantinen-Kontext weniger relevant, kann aber optional vorhanden sein (Kann).

• Belegerstellung: Nach Abschluss eines Verkaufs muss ein Kassenbeleg erstellt werden, der alle gesetzlich erforderlichen Angaben enthält (Name Unternehmer, Datum/Uhrzeit, Artikel, Entgelte, Steuern, Transaktionsnummer etc. gemäß §6 KassenSichV). Die Software muss diese Belege korrekt formatieren und drucken. Zudem sollte sie die Option bieten, elektronische Belege auszugeben (z.B. QR-Code auf dem Display, E-Mail an Kunden), sofern der Kunde zustimmt. Im Betriebsrestaurant ist elektronische Belegausgabe für Mitarbeiter durchaus sinnvoll (z.B. Anzeige in App), aber Papierbeleg sollte standardmäßig verfügbar sein (Belegausgabepflicht ab 2020).

• Benutzeranmeldung an der Kasse: Das System sollte Funktionen zur Benutzeranmeldung für Kassenpersonal bieten (Passwort, PIN, Mitarbeiterschlüssel). Damit wird nachvollziehbar, wer welche Kassiervorgänge getätigt hat. Idealerweise unterstützt die Software schnelles Umschalten, z.B. mittels Mitarbeiter-Chipkarte zum Login, oder einem kurzen PIN-Eingabecode. Berechtigungen (wer darf stornieren, wer darf Preis ändern etc.) werden im Backend je Rolle definiert, aber an der Kasse umgesetzt (z.B. Supervisor-Freigabe nötig bei hohen Rabatten).

• Offline-Fähigkeit an der Kasse: Die Kassenapplikation sollte auch bei temporärer Netzwerkunterbrechung weiter funktionieren (Offline-Modus). Beispielsweise, wenn die Verbindung zum zentralen Server fehlt, müssen zumindest weiter Verkäufe erfasst und in der TSE signiert werden können; ein Datenabgleich erfolgt später. (Details im Betrieb-Kapitel, aber die Software muss diese Pufferung können, falls relevant bei On-Premise Lösungen mit zentraler DB).

• Artikel- und Preisverwaltung: Zentrales Anlegen und Pflegen von Artikeln, Warengruppen, Preisen und Steuerkennzeichen. Im Betriebsrestaurant ändern Speisepläne täglich, daher muss die Lösung schnelle Anpassungen erlauben (z.B. neue Gerichte des Tages einpflegen, Preise ändern). Die Software sollte Preissteuerung nach Zeitpunkt ermöglichen (z.B. automatischer Wechsel zwischen Frühstücks- und Mittagsmenü an bestimmten Uhrzeiten) und vor allem unterschiedliche Preise je Benutzergruppe (Mitarbeiter vs. Gast) verwalten können. Preisänderungen sollten planbar sein (Vorab-Eingabe mit Gültigkeitsdatum). Historisierung von Preisen ist hilfreich für Nachvollziehbarkeit.

• Benutzer- und Rollenverwaltung: Das Backend soll alle Benutzer des Kassensystems verwalten: Kassierer, Kantinenleitungen, Administratoren. Rollenkonzepte sind nötig, um Berechtigungen zu steuern (wer darf Stammdaten ändern, wer nur Berichte einsehen, etc.). Jede Transaktion an der Kasse wird idealerweise mit dem Benutzer verknüpft. Im Backend muss man Benutzer anlegen, sperren, Passwörter vergeben oder idealerweise Single-Sign-On an die Firmen-AD koppeln (falls gewünscht, siehe Integration). Auch Kundenkonten (Mitarbeiterkonten für Guthaben) könnten als eigenes Modul vorhanden sein, s.u.

• Konfiguration und Einstellungen: Das System muss vielfältige konfigurierbare Optionen bieten (z.B. Beleglayout, Steuersätze, TSE-Einstellungen, Zahlungsarten aktivieren/deaktivieren, Textbausteine, etc.). Diese Einstellungen sollten dokumentiert und von autorisierten Personen veränderbar sein. Für die vier Standorte wird entweder eine zentralisierte Konfiguration angestrebt oder standortbezogene Parameter (z.B. unterschiedliche Artikelangebote pro Standort). Das Backend sollte Mehrstandortfähigkeit haben, d.h. Filialfunktionen: z.B. zentrale Artikelstammdaten, aber Möglichkeit, pro Standort individuelle Preise oder Sortiment zu definieren, falls nötig.

• Kassiererabrechnung und -abschluss: Das Backoffice soll Funktionen bieten für Tagesabschlüsse/Z-Abschlüsse. Jede Kasse (oder jeder Standort) macht in der Regel täglich einen Abschluss (Kassensturz). Die Software sollte Summenzähler führen und Kassenabschlüsse drucken (Z-Bon mit den vorgeschriebenen Angaben). Im Backend sollte man diese Abschlüsse nachverfolgen können. Zudem sollte es Möglichkeiten zur Kassenbuchführung geben (wenn relevant, oft macht das Finanzbuchhaltung extern, aber die Rohdaten kommen hier). "Keine Buchung ohne Beleg" und fortlaufende Belegnummern sind ohnehin Pflicht, das gewährleistet das System.

• Berichtswesen (Reporting): Ein wesentlicher Teil des Backoffice sind Auswertungen und Statistiken. Das System muss umfangreiche Berichte ermöglichen: Umsatz pro Tag, Umsatz pro Artikel/Warengruppe, Anzahl verkaufter Essen, Peak-Zeiten, Zahlungsmittelstatistik (Bar vs. Karte vs. Mitarbeiterguthaben), etc. Berichte sollten für einzelne Standorte sowie konsolidiert über alle Standorte abrufbar sein. Idealerweise können Berichte als PDF/Excel exportiert werden. Auch automatisierte Berichtsversendung (z.B. Tagesreport per E-Mail an Leitung) ist wünschenswert (Kann). Die Datenanalyse hilft, das Geschäft zu optimieren; daher sind flexible Filter (nach Datum, Standort, Produktgruppe) sinnvoll. Wenn vorhanden, können auch BI-Tools angedockt werden (siehe Analytics in Zukunfts-Sektion). Insgesamt gilt: umfangreiche Berichtsfunktionen sind ein großer Pluspunkt.

• Kundenkonto-/Guthabenverwaltung: Falls das Konzept vorsieht, dass Mitarbeiter Vorauszahlungen/Guthaben nutzen (Prepaid-Karten) oder auf Rechnung/Kostenstelle konsumieren, muss die Software entsprechende Module bieten. Eine Kundenverwaltung (für Mitarbeiterprofile) wäre erforderlich: Jeder Mitarbeiter hat ein Konto, auf dem entweder Guthaben aufgeladen werden kann oder über das Umsätze gesammelt und z.B. monatlich via Lohn abgerechnet werden. Das System sollte Transaktionen einem Mitarbeiterkonto zuordnen können (über die Ausweiserkennung an der Kasse). Guthabenauf- und -abbuchungen müssen lückenlos nachvollziehbar sein. Falls eine Integration ins Lohn&Gehalts-System angestrebt ist (Abrechnung über Gehalt), sollte das System entsprechende Exportfunktionen (CSV/Excel mit Personalnr, Summe etc.) oder eine Schnittstelle bieten (hierzu mehr im Schnittstellen-Abschnitt). Diese Anforderung ist spezifisch für Betriebsgastronomie und daher wichtig (Soll bis Muss, je nach gewähltem Modell).

• Aktionen und Rabatte: Das Backend soll Möglichkeiten bieten, Promotionen zu konfigurieren, z.B. vorübergehende Rabatte (Happy Hour, Woche der Gesundheit – Salate 10% günstiger etc.), oder Bundles (Menüpreis für Kombination). Auch Gutscheine (Wertgutscheine oder Freikarten) sollten verwaltet werden können: d.h. Erstellen von Gutschein-Codes, Einlösen mit Tracking, Restwertverwaltung. Solche Funktionen sind Kann-Kriterien, aber bei moderner Kassensoftware oft vorhanden.

• Sicherheit und Protokollierung: Die Software muss alle relevanten Aktionen protokollieren (Audit Trail). Jede Datenänderung (z.B. Preisänderung, Stornierung) sollte mit Benutzer und Zeit festgehalten werden, um den GoBD-Vorgaben zu entsprechen (Nachvollziehbarkeit). Außerdem sollte das System Manipulationsschutz bieten – in Kombination mit TSE (siehe Compliance). Einstellungen sollten ggf. revisionssicher gespeichert werden. Ein Rechte- und Rollen-System (schon erwähnt) stellt sicher, dass nur befugte Personen kritische Änderungen vornehmen. Für Supportfälle wäre ein Logbuch/Systemlog hilfreich (Kann, rein technisch).

• Finanzbuchhaltung / ERP: Die Kassensoftware soll eine Schnittstelle zur Finanzbuchhaltung bieten, um Tagesumsätze oder Buchungsjournale an das zentrale ERP-System (z.B. SAP, Datev etc.) zu übergeben. Zumindest ein Export der Summen (Tagesabschlussdaten, Umsätze nach Konten) im Format CSV/Excel oder über Webservice (REST API) sollte möglich sein (Soll). Optimal wäre eine zertifizierte Schnittstelle, die automatisch Buchungen erstellt (Kann, je nach ERP). Damit wird Doppelarbeit vermieden – die FiBu erhält direkt die Kassendaten.

• Warenwirtschaft / Lagerverwaltung: In vielen Betriebsrestaurants existiert eine Warenwirtschaftslösung zur Verwaltung von Rezepten, Lagerbeständen und Einkauf. Das Kassensystem soll mit dieser kommunizieren können. Beispielsweise könnte bei Verkauf eines Artikels der entsprechende Bestand im Warenwirtschaftssystem abgebucht werden (z.B. Zutatenabbuchung für Rezept – optional). Realistischer ist der Abgleich auf Artikelebene: Es reicht, wenn das Kassensystem Artikelnummern hat, die dem Warenwirtschaftssystem bekannt sind, sodass über Berichte die Bestände manuell angepasst werden können. Automatisierte Integration (via Datei oder API) wäre jedoch ideal (Kann). Es wurde erwähnt, dass Standardprozesse automatisiert werden können durch reibungslose Anbindung an Warenwirtschaft und externe Geräte – das ist ein Ziel.

• Personal-/HR-System: Falls die Abrechnung über Lohn und Gehalt läuft (Mitarbeiterverzehr), braucht es eine Schnittstelle zum HR-System. Das Kassensystem sollte z.B. monatlich pro Mitarbeiter eine Verbrauchsliste erzeugen, die ans Lohnprogramm übertragen wird. Oder eine Anbindung via CSV: Personalnummer, Betrag, Kostenstelle. Alternativ, falls das Kassensystem selbst die Lohnabrechnung ansteuert, muss es die Daten gem. Vorgabe ausgeben. Auch ein Abgleich von Mitarbeiterstammdaten (z.B. neu eingetretene Mitarbeiter automatisch als berechtigt hinzufügen, ausgeschiedene entfernen) wäre sinnvoll – ggf. via LDAP/AD oder über Importlisten. Diese Integration ist als Soll-Kriterium einzustufen in einer komplexen Umgebung.

• Zutrittssystem / Ausweissystem: In vielen Unternehmen existieren Mitarbeiterausweise mit RFID-Chips oder QR-Codes, die fürs Zutrittskontrollsystem genutzt werden. Das Kassensystem sollte möglichst diese Ausweise auch nutzen können (um nicht zwei Karten pro Person auszugeben). Daher sollte der Anbieter entweder kompatible Leser bereitstellen oder bestehende Ausweis-Technologie integrieren. Eine Schnittstelle/Kooperation mit dem Ausweissystem (z.B. Abgleich von Kartennummern gegen Mitarbeiterdatenbank) kann nötig sein. I.d.R. handelt es sich jedoch darum, dass die Kassensoftware die Kartennummern als Identifikator akzeptiert; tieferer Austausch (z.B. Sperrlisten) wäre Kann.

• Payment-Gateway: Für App-Zahlungen (siehe Verkaufskanäle) oder Online-Bestellungen kann ein Payment-Gateway (für Lastschrift, PayPal etc.) erforderlich sein. Das Kassensystem sollte hier offen sein, entweder durch eigene Module oder durch bereitgestellte APIs, um Zahlungen aus einer App entsprechend als bezahlt zu markieren (z.B. Webshop-Integration). Per App können Zahlarten wie SEPA-Lastschrift, PayPal, Kreditkarte, digitales Guthaben, Kostenstelle oder Lohn & Gehalt angebunden werden. Das Kassensystem muss diese Vielfalt verarbeiten können, sprich z.B. eine vom App-Server gemeldete Zahlung verbuchen. Gängige Methoden: Webservice-Schnittstelle oder gemeinsame Datenbank.

• Self-Service-Terminals: Die Software (inkl. Firmware) muss in der Lage sein, auf Self-Service-Kiosken zu laufen bzw. diese anzusteuern (siehe Verkaufskanäle Kapitel). Falls Self-Checkout-Terminals eingesetzt werden (mit Kamera oder Scanner), ist die Kassenapplikation in einem speziellen Modus dort aktiv. Diese Integration ist zu beachten, aber intern – Schnittstelle hier ist eher, dass die gleiche Software oder ein Modul davon auf dem Kiosk läuft. Ein separates Self-Service-Modul vom gleichen Hersteller sollte nahtlos mit dem Backend verbunden sein.

• Webservices / API: Insgesamt ist es wünschenswert, dass der Anbieter eine offene API anbietet (REST/JSON oder SOAP) um Kernfunktionen abfragen oder steuern zu können. Beispielsweise, um aus externer Software einen Verkauf einzuspielen (nicht üblich) oder um Abfragen wie „aktueller Saldo Mitarbeiter X“ zu machen. Eine API würde Zukunftssicherheit erhöhen (Kann-Kriterium, aber wertvoll für Integration).

• Standardberichte: Das System muss eine Reihe vordefinierter Standardreports haben, z.B.: Tagesumsatzbericht (pro Kasse, pro Standort, gesamt), Monatsbericht, Umsatz nach Warengruppen, Renner/Penner-Liste (meistverkaufte vs. selten verkaufte Artikel), Umsatz nach Zahlungsmitteln, Anzahl Transaktionen, Durchschnittsbon, etc. Diese Berichte sollten per Stichtag oder Zeitraum generierbar sein.

• Flexibles Ad-hoc-Reporting: Ein gutes System erlaubt auch ad-hoc Abfragen: z.B. Filter auf bestimmte Artikel über Zeitraum X, oder Umsatz nach Stunde am Tag. Falls kein integriertes BI vorhanden, sollte es zumindest den Export der Raw-Daten (Einzeltransaktionsdaten) ermöglichen, damit der Auftraggeber eigene Auswertungen machen kann. Exportformat idealerweise CSV oder eine Datenbankanbindung.

• Mehrstandort-Auswertung: Wichtig ist, dass Reports gesamthaft und je Standort möglich sind. Die Zentrale will z.B. Gesamtumsatz aller vier Standorte sehen, aber auch vergleichen können, welcher Standort wie viel Umsatz hat, etc. Das System sollte daher standortübergreifende Berichte liefern, wenn es ein zentrales Backend gibt. Falls jede Kasse eigenständig wäre (nicht angestrebt), müsste zumindest Summen konsolidiert werden – aber im Konzept soll es ja vernetzt sein.

• Grafische Aufbereitung / Dashboard: Kann-Kriterium: Ein Dashboard für die Kantinenleitung mit Echtzeit-Information (z.B. „heute bisher X Essen verkauft, noch Y verbleibend“ etc.) wäre hilfreich. Z.B. bei cloudbasierten Lösungen gibt es oft Web-Dashboards. Auch Auswertungen in Diagrammform (Umsatzkurve, Peakzeiten) sind nützlich für Management.

• Langfristige Datenanalyse / Trend: Das System sollte historische Daten unbegrenzt (bzw. mind. 10 Jahre wegen Aufbewahrung) speichern, so dass man Trends über Jahre sehen kann. Mögliche Analysis: Wochentagvergleich, Saisonalität, etc. Falls gewünscht, könnte auch eine Schnittstelle zu externen Analytics-Tools (PowerBI, Tableau) ermöglicht werden (durch DB-Zugriff oder API).

• Personalbezogene Auswertungen: Falls Mitarbeiterkonten genutzt werden: Berichte pro Mitarbeiter (Verzehrverhalten, Summen pro Monat) können relevant sein, z.B. um steuerliche Freigrenzen im Blick zu behalten (Job-Lunch-Benefits). DSGVO beachten – solche Auswertungen evtl. anonymisiert für Trends oder nur befugten Personen zugänglich.

• Export für Steuerprüfer: Eng verwandt mit Compliance: das System muss einen GoBD-Export bzw. DSFinV-K Export (siehe Compliance) ermöglichen, was im Grunde ein Reportingformat ist. Dies wird dort behandelt, aber ist zu erwähnen, dass Reporting diese speziellen Exporte (Journaldaten in definierter Struktur) umfasst.

• Benutzerklassen: Typische Rollen: Administrator (voller Zugriff), Manager/Leiter (z.B. kann Berichte sehen, Konfiguration ändern, aber evtl. nicht alles technisch), Kassierer (darf Kassieren, begrenzte Rechte auf Backend), ggf. Buchhalter (Export-Daten ziehen). Das System soll diese Rollen definieren lassen und mit Rechten verknüpfen (z.B. Rabattfunktion nur Supervisor, Storno über X € nur Managerfreigabe etc.).

• Login-Mechanismen: Benutzer sollten persönliche Logins haben. Idealerweise Single Sign-On (z.B. Active Directory Integration) für Backend-Benutzer, damit Unternehmensaccounts verwendet werden können (Soll). An der Kasse ein einfacheres System (PIN, Karte). Jede Kassenbedienung muss einem Benutzer zuordenbar sein.

• Mehr-Mandanten-Fähigkeit: Sollte in diesem Projekt nicht benötigt werden, da es ein Mandant (ein Unternehmen, 4 Standorte) ist. Aber falls z.B. ein externer Caterer mit mehreren Kunden wäre, bräuchte es Mandanten – hier nicht der Fall, deshalb nicht relevant.

• Audit und Protokolle: Das System soll alle administrativen Aktionen (z.B. Benutzer anlegen/löschen, Rechteänderung) protokollieren. Bei sicherheitsrelevanten Dingen wie Passwortänderungen sollte eine Bestätigung erfolgen.

• Passwortrichtlinien: Es sollte Einstellungen geben für Passwortstärke, Ablauf, etc., sofern lokale Benutzerverwaltung. Oder es wird an AD ausgerichtet, dann entfällt das.

• Anzahl Benutzer/Lizenzen: Das System sollte es erlauben, ausreichend viele Benutzer anzulegen ohne exorbitante Lizenzkosten (die Anbieter sollten entsprechende Lizenzen anbieten, z.B. pro Kasse oder Server, aber Benutzer unbegrenzt – das ist vertraglich zu klären, im Lastenheft als Wunsch formuliert).

• Wartungsvertrag: Es wird ein Wartungs- und Supportvertrag mit dem Anbieter angestrebt. Dieser soll folgende Leistungen abdecken: Hotline-Support, Remote-Support, ggf. Vor-Ort-Service, Ersatzteilbeschaffung und Software-Updates. Der Anbieter muss ein Servicekonzept vorlegen, das idealerweise deutschsprachigen Support beinhaltet (Muss) und zu betriebsrelevanten Zeiten verfügbar ist. Mindestens an Werktagen von 8:00 bis 17:00 sollte Support erreichbar sein. Wünschenswert wäre erweiterter Support zu Randzeiten um die Mittagszeit abzusichern (z.B. 7:00 bis 15:00 bei Kernnutzung, oder sogar 6-18 Uhr) – je nach Betriebszeiten der Kantinen.

• Reaktions- und Lösungszeiten: Im Vertrag sollen Service Level Agreements (SLA) definiert werden. Muss-Kriterium: Kritische Störungen (z.B. Kassenausfall, Systemstillstand) – Reaktion (Bearbeitungsbeginn) innerhalb von max. 1 Stunde, Lösung möglichst binnen 4 Stunden (Workaround ausreichend, finale Lösung evtl. länger). Weniger kritische Probleme – Reaktion z.B. am nächsten Werktag, Lösung innerhalb vereinbarter Tage. Der Bieter soll konkrete SLA-Vorschläge machen. Bei einem Ausfall im Mittagspeak muss zumindest ein Workaround (z.B. Ausfallkasse aktivieren) schnell gegeben werden können – der Support sollte telefonisch oder per Fernwartung helfen können.

• Vor-Ort-Service: Für Hardwaredefekte oder komplexe Probleme sollte ein Vor-Ort-Einsatz möglich sein. Entweder durch eigene Techniker oder Partner vor Ort. Ein Ziel ist, dass defekte Hardware (z.B. Kasse komplett ausgefallen) am nächsten Werktag ersetzt oder repariert wird (Soll). Falls für die vier Standorte (die evtl. geographisch verteilt sind) unterschiedliche Serviceteams nötig sind, muss der Anbieter das abdecken. Geografische Nähe oder Partnernetzwerk wäre ein Pluspunkt (Kann).

• Remote Maintenance: Die Software sollte fernwartbar sein (z.B. via VPN oder TeamViewer o.ä.), damit der Support viele Probleme ohne Anfahrt lösen kann. Natürlich nur nach Freigabe durch den Auftraggeber aus Sicherheitsgründen (DSGVO, Zugriffsschutz). Der Anbieter sollte in der Lage sein, Logs auszuwerten, Einstellungen remote zu ändern oder Updates einzuspielen – mit minimaler Betriebsunterbrechung.

• Ersatzteile und Austausch: Der Anbieter muss garantieren, dass Ersatzteile für die angebotene Hardware für einen gewissen Zeitraum verfügbar sind (mind. 5 Jahre, siehe Hardware-Kriterium). Eventuell sollte ein kleines Ersatzgerätepool vereinbart werden – z.B. eine Reservekasse, die beim Kunden gelagert oder beim Anbieter bereitsteht – um im Defektfall schnell tauschen zu können (Kann). Bei defektem Kartenterminal z.B. muss ebenfalls rasch Ersatz her (oft Leasing über Zahlungsdienstleister – aber als Koordination liegt es beim Kassensystemanbieter, falls Terminal Teil des Pakets ist).

• Release-Management: Im Rahmen der Wartung muss der Anbieter regelmäßige Software-Updates bereitstellen. Gerade wegen rechtlicher Änderungen (GoBD-Anpassungen, neue DSFinV-K Versionen, Änderungen Steuersätze) ist das wichtig. Der Anbieter soll zusichern, dass gesetzliche Änderungen zeitnah via Updates umgesetzt werden und im Wartungsvertrag inklusive sind (Muss). Zudem Sicherheitsupdates, Fehlerkorrekturen etc. Major-Upgrades (Versionssprünge mit neuen Funktionen) sollten entweder im Wartungsvertrag enthalten sein oder klar geregelt (evtl. kostenpflichtige Upgrades – hier möglichst vermeiden, lieber alles inkl.).

• Support-Dokumentation: Bei Supportfällen ist es wünschenswert, dass eine Dokumentation erfolgt (Ticket-System). Der Auftraggeber sollte Einblick in Tickets und deren Status haben können. Das ist ein Kann-Kriterium (z.B. Webportal für Tickets).

• Initiale Schulung: Der Anbieter muss ein Schulungskonzept für die Einführung anbieten. Das umfasst typischerweise: Admin-Schulung (für Systemverantwortliche des Kunden, z.B. IT und Kantinenleiter – wie Stammdaten gepflegt werden, Berichte gezogen, Troubleshooting Basis), Kassierer-Schulung (für das Bedienpersonal an den Kassen) und evtl. Schulung für Techniker (wenn ein Teil der Wartung vom Kunden selbst übernommen werden soll, z.B. Papier wechseln ist trivial, aber vielleicht kleine Konfigs etc.). Die Schulungen sollten vor Ort an einem Standort oder zentral beim Kunden stattfinden – idealerweise kurz vor dem Pilotstart oder Rollout. Schulungsunterlagen in Deutsch müssen bereitgestellt werden (Muss).

• Train-the-Trainer: Da vier Standorte betroffen sind, kann es effizienter sein, erst einige Key-User zu schulen, die dann ihr Team einweisen. Der Anbieter sollte beide Modelle unterstützen: entweder direkte Schulung aller Endnutzer (Kassierer) oder Ausbildung von Multiplikatoren. In jedem Fall muss genug Schulungszeit eingeplant werden, damit beim Echtstart alle sicher im Umgang sind.

• Folgeschulungen: Bei personellen Wechseln oder Einführung neuer Features sollte der Anbieter optionale Nachschulungen anbieten können (Kann). Evtl. via Videotutorials, Online-Schulungen oder vor Ort Termine. Dies kann im Angebot als separate Position ausgewiesen werden.

• Dokumentation/Handbücher: Der Anbieter muss Benutzerhandbücher in deutscher Sprache bereitstellen: Für Kassierer ein kürzeres Manual (idealerweise mit Bildern, Schritt-für-Schritt Anleitungen der Kassiervorgänge), für Administratoren ein ausführlicheres Handbuch (Installation, Konfiguration, Wartung, Backup, etc.). Auch Online-Hilfesysteme oder kontextsensitive Hilfen in der Software sind wünschenswert. Die Verfügbarkeit einer Online-Wissensdatenbank (FAQ, Troubleshooting, z.B. auf der Website des Anbieters) wäre ein Plus.

• Akzeptanzförderung: Es ist zu erwarten, dass das neue System von den Mitarbeitern im Betriebsrestaurant angenommen werden muss. Daher soll der Anbieter auch auf Benutzerfreundlichkeit achten und ggf. in der Anlaufphase mit Rat zur Seite stehen. Das kann z.B. bedeuten: Hilfestellung bei Ersteinrichtung der Artikeldaten, Testläufe mit dem Personal, Feedbackschleifen. Diese Aktivitäten sind teilweise im Schulungsumfang enthalten bzw. optional als Consulting buchbar (Kann).

• Regelmäßige Updates: Der Anbieter muss sicherstellen, dass die Software (Kassen-App, Backend, ggf. Firmware der Geräte) stets auf dem aktuellen Stand gehalten wird. Im Wartungsvertrag soll festgehalten sein, wie oft Updates bereitgestellt werden (z.B. quartalsweise minor Updates, jährliche größere Releases, dazu Hotfixes bei Bedarf). Kritische Sicherheitsupdates oder gesetzliche Patches müssen sofort nach Verfügbarkeit installiert werden können.

• Update-Prozess: Es ist zu beschreiben, wie Updates eingespielt werden. Bei Cloud-Lösungen geschieht es zentral (der Kunde muss nur Ausfallzeiten kennen), bei On-Premise entweder durch Remote-Service des Anbieters oder durch geschulten Admin des Kunden. Idealerweise sind Updates automatisiert oder skriptbar, um alle Kassen gleichzeitig zu aktualisieren (z.B. in der Nacht). Downtime-Minimierung: Updates sollten nach Möglichkeit außerhalb der Öffnungszeiten stattfinden oder sehr kurz sein. Der Anbieter muss Testen in einer Testumgebung ermöglichen, bevor produktiv upgedatet wird (gerade bei größeren Versionssprüngen). Evtl. stellt er eine Test-Lizenz zur Verfügung.

• Kompatibilität: Es ist sicherzustellen, dass Updates rückwärtskompatibel mit bestehenden Daten sind. D.h. keine Verlust von Journalen, Reports etc. Auch die TSE-Anbindung muss nach Update noch funktionieren (wenn z.B. Zertifikate ausgetauscht werden müssten, muss das vorher bekannt sein). Der Anbieter sollte in den Releasenotes klar ausweisen, was sich ändert.

• Upgrades (neue Versionen): Sollte es in Zukunft komplett neue Softwaregenerationen geben, ist zu vereinbaren, wie der Übergang stattfindet. Aus Kundensicht wäre wünschenswert, im Rahmen der Wartung auch größere Upgrades zu erhalten (Soll). Alternativ, falls eine neue Version extra Lizenzkosten bedeutet, muss das vorab bekannt sein. Da wir aber produktneutral bleiben, formulieren wir: Der Anbieter soll die Weiterentwicklung seines Produktes aufzeigen und sicherstellen, dass die gelieferte Lösung für die erwartete Nutzungsdauer (mind. 5-8 Jahre) aktuell gehalten wird.

• Lieferung Hardware: Nach Zuschlag muss die Lieferung der Hardware termingerecht erfolgen. Erwartet wird, dass alle benötigten Komponenten innerhalb von <X> Wochen geliefert werden können. (Genauen Zeitplan legen wir evtl. in Ausschreibung fest, hier als Anforderung: schnelle Lieferfähigkeit). Der Bieter soll eine Aussage zur Lieferzeit machen (z.B. „alle Komponenten sind innerhalb von 8 Wochen ab Bestellung lieferbar“). Längere Lieferzeiten könnten kritisch sein und fließen ins Bewertungskriterium „Implementierungszeitplan“ ein.

• Implementierungs-/Projektplan: Der Anbieter muss gemeinsam mit dem Auftraggeber einen detaillierten Projektplan für die Einführung erstellen (Soll). Dazu gehören: Termine für Konzeption/Workshop (zur Detailabstimmung der Konfiguration), Lieferung Hardware, Installation vor Ort, Integrationstests, Schulungen, Pilotbetrieb, Rollout an den weiteren Standorten. Es wird erwartet, dass der Anbieter Projektmanagement-Unterstützung bietet – idealerweise stellt er einen Projektleiter, der als Ansprechpartner dient und die Umsetzung koordiniert.

• Installation und Inbetriebnahme: Die Installation der Software und Konfiguration des Systems sollte im Angebot inbegriffen sein (Muss). Der Anbieter soll Techniker schicken oder remote begleiten, um die Kassen, Server etc. korrekt zu installieren, mit dem Netzwerk zu verbinden, TSE einzurichten, etc. Ebenso soll er bei der Erstkonfiguration (Artikel anlegen, Grundeinstellungen) helfen – damit das System startklar ist.

• Abnahme und Tests: Vor dem Live-Betrieb sollte ein Abnahmetest erfolgen (Soll). Der Anbieter soll Testläufe unterstützen: z.B. Probebuchungen, Funktion aller Schnittstellen überprüfen, TSE-Test etc. Erst wenn alle Anforderungen nachweislich erfüllt sind, gilt die Abnahme als erfolgreich. Kriterien dafür sollten gemeinsam festgelegt werden (Checkliste).

• Ressourcenplanung: Vom Auftraggeber-Seite stehen interne Ressourcen (IT, Kantinenleitung, Kassierer für Test) zur Verfügung, aber der Anbieter muss klar benennen, welche Zuarbeit er braucht (z.B. „Personalstammdaten in CSV bereitstellen“, „Netzwerkanschlüsse an Kassenplätzen vorhanden“ etc.). Solche Anforderungen sind im Angebot zu spezifizieren.

• GoBD (Grundsätze zur ordnungsmäßigen Buchführung bei elektronischen Systemen),

• KassenSichV (Kassensicherungsverordnung) i.V.m. §146a AO (Abgabenordnung),

• DSFinV-K (Digitale Schnittstelle der Finanzverwaltung für Kassensysteme),

• §146a AO (gesetzliche Grundlage für TSE, Belegausgabe, u.a., Kassengesetz),

• TSE (Technische Sicherheitseinrichtung) – als Kern der KassenSichV,

• DSGVO (Datenschutz-Grundverordnung) – da personenbezogene Daten (Mitarbeiterkonten, Zahlungsdaten) betroffen sein können.

Die GoBD umfassen Grundsätze wie Einzelaufzeichnungspflicht, Unveränderbarkeit, Vollständigkeit, Ordnung, zeitgerechte Buchung, Aufbewahrungspflicht (10 Jahre) etc.

• Einzelaufzeichnung und Unveränderbarkeit: Jeder Geschäftsvorfall (Kassiervorgang) muss einzeln aufgezeichnet werden und ist unveränderbar zu speichern. D.h. keine nachträgliche Manipulation ohne Spur. Korrekturen erfolgen immer durch Storno/Negativbuchung, nicht durch Löschen. Das System muss diese Logik sicherstellen (z.B. keine Löschfunktion für abgeschlossene Bons).

• Protokollierung: Alle relevanten Änderungen (z.B. Storno, Preisänderung, Trainingsmodus etc.) müssen protokolliert sein. Es soll ein prüfungssicheres Journal geführt werden. Die TSE übernimmt einen Teil der Sicherung, aber auch das System selbst muss z.B. eine Verfahrensdokumentation ermöglichen.

• Aufbewahrung: Daten müssen mindestens 10 Jahre gespeichert oder archivierbar sein. Das System sollte Funktionen haben, Altdaten in einem Archivformat zu exportieren oder zu sichern, sodass auch nach Systemwechsel die Daten lesbar bleiben. Idealerweise bietet der Anbieter eine revisionssichere Archivierung an (Kann, z.B. Cloud-Archiv).

• Verfahrensdokumentation: GoBD verlangt, dass eine Dokumentation des Systems und der Prozesse vorliegt. Der Anbieter sollte dafür Unterlagen liefern (z.B. Systemdokumentation, Bedienrichtlinie), die der Auftraggeber in seine Verfahrensdoku aufnehmen kann. Das ist ein Muss seitens Auftraggeber, aber der Anbieter sollte Unterstützung liefern (Soll).

• Zertifizierungen: Es gibt für Kassensoftware (noch) keine verpflichtende Zertifizierung, aber eine Prüfung nach IDW PS 880 oder eine Bescheinigung eines Wirtschaftsprüfers, dass die Software GoBD-konform ist, wäre hoch erwünscht (Kann). Einige Anbieter werben damit – produktneutral fordern wir es nicht zwingend, aber ein vorhandener Testat gibt Pluspunkte bei der Bewertung.

• GoBD-Export: Traditionell war der GoBD-Export oft in Form von GDPdU-Daten (auch als Z3-Daten bezeichnet). Ab 2024 ist jedoch klargestellt, dass die DSFinV-K als einheitliche Schnittstelle dienen soll. Trotzdem sollte das System auch bisherige Exportformen (z.B. Daten im IDEA-Format, CSV) bedienen können. Mindestens muss es alle steuerrelevanten Daten elektronisch bereitstellen können.

• Keine Buchung ohne Beleg: Gesetzlich darf kein Umsatz ohne Beleg im System sein. Das System muss dem entsprechen – es sollte z.B. verhindern, dass Buchungen „verschwinden“. Auch muss es Belegnummern lückenlos vergeben. Diese Anforderungen decken sich mit TSE-Funktionen (Signaturen), aber auch intern sollte z.B. ein Z-Bon die lückenlose Sequenz aufführen.

• Technische Sicherheitseinrichtung (TSE): Seit 1.1.2020 (bzw. September 2020 nach Nichtbeanstandungsfrist) müssen alle elektronischen Kassensysteme in Deutschland mit einer vom BSI zertifizierten TSE ausgestattet sein. Die TSE zeichnet jede Transaktion auf, signiert sie und erzeugt eine eindeutige Transaktionsnummer/Signatur. Das angebotene System muss eine TSE integriert oder anbindbar haben – entweder als Hardware-Modul (USB, SD-Karte, Fiskalbox etc.) oder als Cloud-TSE. Beide Varianten sind zulässig und technisch offen; wichtig ist die BSI-Zertifizierung. Idealerweise unterstützt das System verschiedene TSE-Typen (Technologieoffenheit), sodass der Auftraggeber wählen kann. Die TSE muss in der Lösung so implementiert sein, dass jeder Geschäftsvorfall ordnungsgemäß geschützt ist (Signatur auf Beleg, Export der TSE-Daten im Falle einer Prüfung).

• TSE-Betriebsdauer: Hinweis: Eine TSE hat ein Zertifikat meist für 5 Jahre. Das System muss vorsehen, TSEs zu wechseln bzw. rechtzeitig zu erneuern. Diese organisatorische Aufgabe (z.B. neue TSE beschaffen und einspielen) soll unterstützt werden (z.B. Warnmeldungen, wenn Zertifikat abläuft – Kann).

• Belegausgabepflicht: Seit 2020 muss jedem Kunden ein Beleg angeboten werden. Das Kassensystem muss diese Belege drucken können (oder elektronisch bereitstellen) und es darf kein Vorgang ohne Beleg abgeschlossen werden (Software sollte das sicherstellen). Inhalte des Belegs sind in §6 KassenSichV vorgeschrieben (Unternehmername, Datum/Zeit, Artikel, Betrag, Steuern, TSE-Signatur, Transaktionsnummer etc.). Das System muss diese Anforderungen an Beleginhalte erfüllen. Bei elektronischen Belegen (z.B. E-Mail) ist DSGVO zu beachten – nur mit Einwilligung, das hatten wir. Die Lösung könnte z.B. QR-Codes auf dem Papierbeleg anbieten, über den der Kunde den digitalen Beleg abrufen kann (technologieoffen, wie in KassenSichV erlaubt).

• Meldepflicht nach §146a AO (seit 2020/2025): Der Betreiber (Auftraggeber) muss jede Kasse und jede TSE beim Finanzamt anmelden. Das System selbst muss dies nicht automatisch tun, aber es sollte alle dafür erforderlichen Informationen bereitstellen: z.B. Hersteller, Modell, Seriennummer der Kasse, TSE-Seriennummer und Zertifizierungs-ID, Software-Version, Einsatzort usw. Die BMF-Ausfüllanleitung definiert die Felder. Der Anbieter sollte dem Auftraggeber die nötigen Daten liefern (z.B. in Form eines Dokumentes für jede Kasse/TSE-Kombination) – Muss. Die Fristen: bestehende Systeme bis 31.07.2025 gemeldet, neue innerhalb eines Monats, das betrifft den Auftraggeber, aber das System muss zumindest ermöglichen, dass man die Daten strukturiert ausliest.

• DSFinV-K Export: Gemäß §146a AO müssen die Kassendaten über eine einheitliche digitale Schnittstelle exportiert werden können. Diese Schnittstelle ist die DSFinV-K (Digitale Schnittstelle der Finanzverwaltung für Kassensysteme), aktuell Version 3.0. Das Kassensystem muss die gesamte Transaktionshistorie in diesem Format ausgeben können, z.B. für eine Betriebsprüfung. Die DSFinV-K definiert ein detailliertes XML/CSV-Datenmodell, in dem alle Einzelbuchungen, Stammdaten und TSE-Daten enthalten sind. Das System muss einen solchen Export ohne Datenlücke erstellen können. Im Idealfall ist diese Funktion vom Hersteller zertifiziert oder zumindest erprobt. Die DSFinV-K-Datei wird von Prüfern verwendet, um die Kasse maschinell zu prüfen. Angebote ohne DSFinV-K-Export-Fähigkeit sind nicht zulässig (Ausschluss).

• Kassen-Nachschau Unterstützung: Seit 2018 können Finanzbehörden unangekündigt eine Kassen-Nachschau machen. Das System muss daher einen Prüfermodus ermöglichen – d.h. auf Verlangen muss sofort ein Export der aktuellen Daten möglich sein oder Einblick ins System gewährt werden. Praktisch heißt das: Ein Prüfer kommt, der Betreiber muss innerhalb kurzer Zeit die DSFinV-K Exporte auf USB-Stick ziehen können oder dem Prüfer einen Zugang geben, um Daten einzusehen (z.B. im Beisein). Das System sollte daher einfach und schnell eine Datenüberlassung ermöglichen (Muss). Im Idealfall gibt es einen speziellen Benutzer oder Modus, der dem Prüfer nur Lesezugriff gibt (Kann).

• Schutz vor Manipulation: Neben TSE (Kernschutz) sollten keine zusätzlichen Funktionen existieren, die Manipulation erlauben (wie Trainingsmodus, der echte Daten beeinflusst etc., ohne Aufzeichnung). Wenn ein Trainingsmodus vorhanden ist, muss er getrennt vom Echtdatenbereich sein, um keine echten Aufzeichnungen zu verfälschen. Im Grunde muss das System „manipulationssicher“ sein in dem Sinne, dass ohne Spuren nichts geändert werden kann. KassenSichV verbietet z.B. die Werbung für nicht konforme Systeme und stellt Verstöße unter Bußgeld bis 25.000 € – der Anbieter soll also zusichern, dass sein Produkt konform ist, damit weder Kundenunternehmen noch Anbieter in diese Lage kommen.

• Belegverkettung: Die KassenSichV verlangt, dass die Belege eine Verkettung aufweisen (TSE-Start- und Endzähler, Signaturkette). Das ist technisch von TSE gewährleistet, aber die Software muss die entsprechenden Werte auf dem Beleg ausgeben. Dies wird als gegeben vorausgesetzt, aber sollte erwähnt sein.

• Zertifizierung: Es werden nur TSE-Lösungen akzeptiert, die vom BSI zertifiziert sind nach TR-03153. Anbieter sollen angeben, mit welcher TSE sie arbeiten (z.B. Swissbit Hardware-TSE, Fiskaly Cloud-TSE, Bundesdruckerei Cloud-TSE etc.). Mehrere sind denkbar. Wichtig: Die TSE muss in Deutschland zulässig sein (BSI-Liste).

• Integration: Die TSE kann pro Kasse lokal sein (z.B. USB-Stick in jeder Kasse) oder zentral (z.B. eine TSE im Server für alle Kassen, wenn erlaubt) oder Cloud (eine Cloud-TSE-Instanz pro Kasse oder für das Unternehmen). Der Anbieter soll das Konzept erläutern. Für uns ist technologieoffen beides möglich. Cloud-TSE hat Vorteile (weniger Hardware austauschen, zentral), aber erfordert Internet. Hardware TSE hat evtl. offline Vorteile. Der Auftraggeber ist offen, solange die Betriebssicherheit gewährleistet ist. Daher Muss: Vollständige TSE-Anbindung, egal in welcher Form.

• Performance: Die TSE darf den Kassiervorgang nicht unzumutbar verzögern. Anbieter müssen angeben, wie schnell ein Vorgang signiert ist (normalerweise <300ms). Bei Cloud-TSE muss Netzlatenz berücksichtigt werden. In Stoßzeiten mit vielen parallelen Buchungen muss die TSE das bewältigen (evtl. Queue, aber ohne Abbruch). Tests sollten zeigen, dass es keine signifikanten Warteschlangen gibt.

• TSE-Ausfallszenarien: Was passiert, wenn die TSE nicht verfügbar ist (z.B. defekt oder Cloud offline)? Gesetzlich darf man begrenzte Zeit weiterarbeiten und nachsignieren, aber praktisch sollte das System entsprechende Fallbacks haben. Anbieter sollen beschreiben, wie ihr System reagiert – z.B. Zwischenspeicherung und spätere Signatur. Dies ist ein Kann, da es Spezialfall ist, aber relevant für Betriebsunterbrechungsfreiheit.

• TSE-Datenexport: Zusätzlich zur DSFinV-K muss bei Prüfung oft auch das TSE-TAR-File vorgelegt werden (das ist das exportierte Archiv der TSE). Das System oder der TSE-Managementsoftware soll das ermöglichen. Anbieter sollen bestätigen, dass sie Tools dafür haben oder wie der Prozess ist (z.B. TSE-Admin-Tool, das CSV/ TAR exportiert).

• Laufende Kosten TSE: Cloud-TSEs haben oft jährliche Kosten. Das soll zwar im Angebot als Preis erscheinen, aber hier erwähnen wir: Der Anbieter sollte transparente Kosten für die TSE-Nutzung nennen (z.B. Lizenz pro Kasse pro Jahr, falls Cloud). Das fließt in kaufmännische Bewertung, aber auch qualitativ wenn Service.

• Umfang: Der DSFinV-K Export enthält Stammdaten (Unternehmen, TSE-Info, Terminal-IDs etc.), Einzelaufzeichnungen aller Geschäftsvorfälle mit Zeitstempel, Zahlungsinformationen, Stornoverknüpfungen etc., sowie die TSE-Tar-Datei oder Referenzen darauf. Das System muss in der Lage sein, jederzeit einen Export für einen vom Prüfer gewünschten Zeitraum X bis Y zu erzeugen.

• Aktualität Version: Die DSFinV-K wird gelegentlich aktualisiert (aktuell Version 3.0 seit 2023). Der Anbieter muss garantieren, immer die neueste Version zeitgerecht zu unterstützen.

• Validierung: Es wäre wünschenswert, dass das System den erstellten DSFinV-K Export auf Plausibilität prüfen kann (Kann). Zumindest aber wird erwartet, dass ein Export ohne Fehlermeldungen bei den Prüftools der Finanzverwaltung durchläuft.

• Dokumentation: Der Anbieter muss in der technischen Dokumentation darlegen, wie die DSFinV-K Datenstruktur abgebildet wird. Für den Kunden im Alltag wichtig: Ein Bediener sollte per Backend einen Menüpunkt "DSFinV-K Export" haben und einfach Start- und Enddatum wählen können. Das Ergebnis ist z.B. ein ZIP-File mit den geforderten CSV/XML-Dateien. Diese Datei muss an den Prüfer gegeben werden können. Sie enthält auch die TSE-Exportdaten. Diese Funktion ist Muss (wie oben gesagt).

• Bedeutung: Ohne DSFinV-K Export gilt die Kassenführung als formell nicht ordnungsmäßig, was im Worst Case die Buchführung verwerfen kann. Daher ist es ein zentrales Element.

• Datenminimierung: Es sollen nur notwendige personenbezogene Daten gespeichert werden. Für den Betrieb reicht evtl. eine Personalnummer oder Kartennummer für die Identifikation, ohne Klarnamen an der Kasse – Details kann der Auftraggeber vorgeben. Das System sollte es erlauben, personenbezogene Daten zu pseudonymisieren (z.B. Anzeige nur Nummer statt Name in Kassenjournal).

• Zugriffsschutz: Personenbezogene Verzehrdaten (wer hat was gegessen) könnten als sensitiv gelten – Zugriff darauf sollte beschränkt sein (z.B. nur Administrator oder Auswertung anonymisiert). Die Software sollte entsprechende Rechte vergeben können. Auch die Übertragung sensibler Daten (z.B. in Cloud) muss verschlüsselt erfolgen.

• Speicherort: Wenn Cloud-Lösung, müssen Server in der EU (vorzugsweise Deutschland) liegen. Es muss ein Auftragsverarbeitungsvertrag (AVV) abgeschlossen werden können. Anbieter sollen klar angeben, wo Daten liegen. Cloud-Anbieter mit Daten außerhalb EU werden nicht akzeptiert (Ausschluss).

• Datensicherheit: Neben Zugriffsschutz (Passwörter, Rollen) ist technische Sicherheit wichtig: Verschlüsselung von sensiblen Datenbanken, zumindest aber Passwort-Hashes etc. Der Anbieter sollte Sicherheitsaudits vorweisen können (Kann). Das System muss vor unbefugtem Zugriff geschützt sein, was sowohl software- als auch hardwareseitig gilt (gehärtete OS an Kassen, Firewall etc.). Während des Betriebs vor Ort sollten Kassendaten nicht für jedermann zugänglich sein (z.B. Kundendisplay zeigt keine persönlichen Infos).

• Logs und Auskunft: DSGVO gibt Betroffenen Rechte (Auskunft, Löschung). Wenn personengebundene Daten gespeichert werden (z.B. wer hat was gekauft), muss der Auftraggeber auf Anfrage eines Mitarbeiters Auskunft geben können. Das System sollte daher zumindest nach Mitarbeiter filterbare Kaufhistorie bereitstellen (um Auskunft zu erteilen). Löschung ist tricky wegen 10-Jahres-Frist (steuerrechtlich müssen Daten aufbewahrt werden, was hier überwiegt). Dennoch sollte das System ermöglichen, nach Ablauf der Aufbewahrungsfrist Daten zu löschen oder anonymisieren (Kann, langfristig).

• Datenschutzhinweise: Der Anbieter muss dem Auftraggeber Infos geben, welche personenbezogenen Daten im System gespeichert werden, damit dieser sein Verzeichnis der Verarbeitungstätigkeiten pflegen kann. Dies kann in Dokumentation erfolgen (Kann).

• Besondere Fälle: Falls Videotechnik (KI-Kasse) eingesetzt wird, greift auch DSGVO (Videodaten). Darauf wird im Zukunftskapitel eingegangen, aber im Kern: Falls solche Module (Bilderkennung) eingesetzt werden, müssen sie datenschutzgerecht (evtl. keine Speicherung von Bilddaten oder Zustimmung der Nutzer) sein. Für Lastenheft reicht die Anforderung: Bei Einsatz von KI-Kassen oder personalisierter App sind entsprechende Datenschutzkonzepte vorzulegen (Muss bei Realisierung solcher Module).

• Steuerliche Anforderungen UStG: Im Speisenbereich kann die Mehrwertsteuer tricky sein (unterschiedliche Sätze). Das System muss dies korrekt behandeln. Das ist eigentlich eine fachliche Anforderung, aber auch gesetzlich (UStG §22 verlangt getrennte Aufzeichnung nach Steuersätzen). Also: Ja, es muss z.B. 7% vs 19% korrekt ausweisen und summieren.

• Arbeitszeit oder Jugendschutz? – Eher nicht relevant für Kassensystem direkt.

• Technische Normen: Kassensysteme haben oft eine Kassenladen-Schnittstelle (RJ11) genormt, aber das ist Detail.

• IT-Security-Standards: Falls der Auftraggeber interne IT-Policies hat (z.B. BSI-Grundschutz, ISO 27001 in Rechenzentrum), sollte der Anbieter Auskunft geben, ob er diese einhält (Kann).

• Barrierefreiheit: In öffentlichen Bereichen könnte BITV gelten, aber hier interne Kantine – nicht zwingend. Evtl. aber ein Aspekt: Touchscreen-Kassen sind meist nicht barrierefrei (für Sehbehinderte etc.). Vermutlich kein Muss in diesem Kontext, daher nicht gefordert außer optional.

• On-Premise-Lösung: Die Software (Datenbank, Backend) läuft auf Servern, die im Unternehmen betrieben werden (z.B. im Rechenzentrum der Firma oder vor Ort in einer Filiale). Vorteile: volle Datenhoheit, keine Abhängigkeit von Internet, Integration in interne Systeme (AD, DB) einfacher. Anforderungen: Der Anbieter muss Hardware- und Softwareanforderungen für den Server nennen (Betriebssystem, DBMS etc.), und ggf. Unterstützung bei Installation bieten. Das System sollte auf standardisierten Plattformen laufen (z.B. Windows Server oder Linux + SQL Database). Redundanz: Bei On-Prem sollte bedacht werden, ob ein zweiter Server (Cluster) nötig ist – falls ja, Fähigkeit der Software zu Multi-Server-Betrieb. On-Prem erfordert vom Kunden regelmäßige Backups, der Anbieter sollte dafür Tools/Anleitungen liefern.

• Cloud-Lösung (SaaS): Die Anwendung (Datenbank, Backend) wird in der Cloud des Anbieters oder eines Partners gehostet. Die Kassen vor Ort kommunizieren übers Internet mit der Cloud. Vorteile: Weniger administrativer Aufwand für den Kunden, Updates und Backups vom Anbieter gemanagt, standortübergreifend trivial. Anforderungen: Hohe Verfügbarkeit der Cloud (möglichst >99,5%), redundante Systeme dort, Rechenzentrumsstandort EU wegen DSGVO (Muss, siehe Compliance). Performance: Latenz muss niedrig sein, also idealerweise Rechenzentrum in Deutschland. Offline-Fähigkeit: Da Internet nie 100% garantiert ist, muss die Kassensoftware kurze Ausfälle überbrücken können (Puffer, Weiterbuchung und spätere Synchronisation – Anbieter soll Lösung darstellen). Datenaustausch: Bei Cloud muss dennoch möglich sein, Daten ins eigene ERP zu bekommen – also API oder gesicherte Übertragung. Vertrag/AVV: Cloud bedingt AV-Vertrag und klare Verantwortlichkeiten (der Anbieter muss garantieren, dass Daten sicher sind).

• Hybrid: Manche Lösungen ermöglichen Mischmodelle, z.B. zentrale Cloud aber lokale Edge-Server je Standort zur Offline-Fähigkeit. Anbieter können so etwas vorschlagen (Kann). Das könnte Vorteile verbinden: Lokale Geschwindigkeit + zentrale Datenhaltung.

• Portabilität: Wenn der Kunde z.B. in 5 Jahren doch von Cloud auf On-Prem (oder umgekehrt) wechseln will, sollte das vom System unterstützt werden (Kann). D.h. Datenmigration sollte möglich sein. Produktneutral kann man das erwähnen, um langfristige Flexibilität zu haben.

• Lizenzmodell: Eng verknüpft – On-Prem meist Kauf plus Wartung, Cloud meist Mietmodell. Hier keine konkrete Vorgabe, aber bei Bewertung wird TCO betrachtet.

• Zentrale vs. Dezentrale Datenhaltung: Für 4 Standorte soll möglichst eine zentrale Datenbank geführt werden, damit alle Stammdaten einheitlich sind und Auswertungen zentral möglich. D.h. die Kassen-Clients (Terminals) arbeiten mit einer gemeinsamen Datenbank (online). Diese kann in der Zentrale stehen (On-Prem) oder in Cloud (SaaS). Das System muss also filialfähig sein: mehrere Standorte greifen auf denselben Datenbestand zu, aber können individuell konfiguriert sein (z.B. Filiale A hat Artikel X verfügbar, Filiale B nicht). Diese Filialfähigkeit ist Muss.

• Lokaler Ausfallschutz: Falls zentrale DB nicht erreichbar, soll pro Standort ein lokaler Puffer vorhanden sein. Das kann z.B. bedeuten, dass die Kassen an Standort X notfalls auf eine lokale Instanz umschalten. Oder dass jede Kasse alle Stammdaten offline vorhält und Transaktionen cached. Anbieter sollen Lösung darstellen (z.B. "unsere Kassen speichern bis 2000 Buchungen offline und synchronisieren später"). Wichtig: Bei Offline-Betrieb muss TSE weiter funktionieren (TSE ist lokal, also ja) und doppelte Belegnummern sollten vermieden werden.

• Mehrkassen-Betrieb: An einem Standort werden mehrere Kassen parallel laufen. Das System muss Mehrbenutzerfähig sein – gleichzeitig Buchungen durchführen, ohne Einbußen oder Dateninkonsistenz. Es sollte ein Mechanismus da sein, der z.B. Belegnummern kassenindividuell oder global eindeutig vergibt. Die Performance der DB muss hoch genug sein, um parallele Zugriffe zu managen (DB-Transaktionen). IdR ist das Standard, aber wichtig ist die Kapazität: Bsp. wenn pro Standort 3 Kassen in Peak 30 Buchungen/Minute machen, plus Self-Service – das DB-System muss das problemlos schaffen.

• Systemarchitektur technisch: Falls On-Prem: Bestände, Applikationsserver und DB. Der Anbieter könnte ein 3-Tier System liefern (Clients auf Kassen, Applikationsserver als Middleware, DB als Backend). Oder Kassen direkt auf DB (mit Service). In Cloud-SaaS spürt man es als Kunde weniger, aber uns interessiert vor allem Zuverlässigkeit. Ein Schichtenmodell mit klaren Schnittstellen (z.B. REST zwischen Client und Server) wäre modern, aber nicht zwingend.

• Technologieoffenheit: Falls On-Prem, bevorzugt der Kunde Lösungen, die auf verbreiteten Standards laufen (z.B. MS-SQL, Oracle oder OpenSource DB, Windows/Linux). Rein proprietäre black-box Appliances sind ungern gesehen, da schwer wartbar. Produktneutral fordern wir es nicht hart, aber beim IT-Betrieb wird Kompatibilität berücksichtigt.

• Active Directory: Möglichkeit, die Benutzerverwaltung (für Backoffice Login) ans AD anzubinden (LDAP) – kein Muss, aber Soll.

• Client-OS: Falls Kassen auf Windows laufen, muss das OS in Domäne eingebunden werden können und den Sicherheitsrichtlinien entsprechen.

• Drucker etc.: Nutzung von Netzwerkdruckern, falls relevant, sollte möglich sein.

• VPN: Falls Cloud, muss es über das Unternehmensinternet mit Proxy/Firewall funktionieren. Der Anbieter sollte Ports/Protokolle nennen. Für Cloud-Lösungen evtl. IP-Whitelist etc., damit es sicher ist.

• Bei On-Prem: Der Anbieter muss ein Konzept vorschlagen, wie Daten gesichert werden sollen. Evtl. tägliche DB-Backups (nachts) auf externe Medien. Auch TSE-Backup (TSE-Daten sind in TSE selbst, aber man kann TAR Files runterladen). Der Auftraggeber legt Wert auf Wiederherstellbarkeit. Ein Desaster-Szenario (Serverausfall, DB kaputt) – wie schnell kann aus Backup wiederhergestellt werden? Das muss durch ein gutes Backupkonzept (Backup täglich, Vorhalten mind. 10 Jahre etc.) und ggf. Hochverfügbarkeit abgefedert werden.

• Bei Cloud: Der Anbieter muss zusichern, dass er Backups fährt (meist in AVV geregelt) und ggf. georedundant speichert.

• Redundanz: Schon erwähnt – ideal wäre ein Ausfallschutz:

• On-Prem: Redundanter Server im Cluster oder wenigstens virtuelle Maschine, die schnell neu gestartet werden kann in anderer Umgebung.

• Cloud: Redundante Systeme im Rechenzentrum (Cluster), Fallback Rechenzentrum.

• Netzwerk-Security: Kassensysteme dürfen nicht Einfallstor ins Firmennetz sein. Wenn Kassen an Firmennetz, sie sollten in DMZ/VLAN isoliert sein. Der Anbieter sollte angeben, welche Kommunikation nötig ist (z.B. Kasse ↔ Server Port X). So kann die IT Firewallregeln setzen.

• System Hardening: Kassen-PCs sollten nur Kassensoftware ausführen, evtl. Kiosk-Mode (keine Ablenkung, kein Surfen). Der Anbieter könnte einen abgesicherten Modus anbieten oder zumindest keine unnötigen Dienste installieren.

• Antivirus: Muss auf Windows-Kassen laufen (sollte kompatibel sein mit gängigen Virenscannern).

• Datenverschlüsselung: Sensible Daten (z.B. Perso-Datenbank oder Cloud-Verbindungen) sollten verschlüsselt werden. Cloud comm via HTTPS/TLS. Lokale DB gern Transparent Data Encryption (Kann).

• z.B. Anzahl Artikel (vermutlich einige hundert Artikel, was gering ist – kein Problem).

• Anzahl Transaktionen pro Tag (vllt 1000 pro Standort, auch kein Problem).

• Aber wir wollen, dass das System auch bei z.B. 4 Standorte jetzt, evtl. 6 in Zukunft, oder 2x so vielen Mitarbeitern, immer noch funktioniert. Also skalierbar.

• Sie sollen angeben, ob es Limitierungen gibt (z.B. max 10 Kassen pro Filiale in Standardversion, etc.).

• Gewünscht ist Skalierbarkeit nach oben, vielleicht mal auf 10 Standorte erweiterbar, falls Unternehmen wächst (Kann).

• Datensicherheit: Teilweise schon im DSGVO-Teil: Es geht um Schutz der Daten vor Verlust und vor unbefugtem Zugriff.

• Schutz vor Verlust: Backups, Redundanz (schon besprochen).

• Schutz vor Zugriff: Authentifizierung (User mgmt, AD integration), Zugriffsrechte (intern im System), Netzwerk-Security (Firewall, VPN).

• Verschlüsselung: Wiederholt, aber: Datenbankverschlüsselung (optional), Übertragung von Kassendaten an Server verschlüsselt (ja, sollte).

• Penetrationstest: Evtl. fordert der AG, dass vor Abnahme ein Pentest durchgeführt werden darf. Der Anbieter müsste das zulassen (Kann, im Vertrag zu regeln).

• Notfallkonzept: Der Anbieter soll im Rahmen der Doku ein grobes Notfallkonzept mitliefern – z.B. was tun bei Totalausfall Server (manuell Not-Kassenjournal auf Papier führen, etc.). Aber eher interne Sache. Dennoch wäre gut, wenn der Anbieter so was unterstützt (z.B. Offline-Funktion war analog dazu).

• Active Directory / LDAP: Wenn On-Prem, wäre es gut, wenn z.B. die Backoffice-Benutzer gegen AD authentifiziert werden können, damit Benutzerpflege nicht doppelt läuft. Kann-Bedürfnis je nach IT. Viele Kassensysteme haben eigene Benutzerverwaltung; AD-Anbindung ist eher selten, aber als Soll definieren wir es.

• Email/SMTP: Das System könnte E-Mails verschicken (Berichte, oder digitale Belege). Dafür muss es ans Mail-System des Unternehmens angebunden werden können (SMTP-Server konfigurieren). Das sollte möglich sein (Soll).

• Zeitwirtschaft: In manchen Kantinen nutzt man Kasse für Zeitdatenerfassung (z.B. Arbeitszeiterfassung, oder Kommen/Gehen der Mitarbeiter). Das ist hier vermutlich kein Thema, daher nicht fordern.

• Leitungssysteme (z.B. SAP): Falls Unternehmen z.B. SAP ERP hat, wäre eine Integration toll (Stammdaten oder FI/CO-Buchungen). Aber das geht meist über generische Exporte. Kann man optional erwähnen "Unterstützung von IDoc-Export an SAP (Kann)".

• Cashless Payment Systeme: Falls das Unternehmen schon ein Closed-Loop Payment System hat (z.B. Kartenguthaben mit eigener Infrastruktur), dann muss Kassensystem das ansteuern. Das kann z.B. Mifare-Karten mit Wertspeicher sein. Der Anbieter muss offen sein, sich da anzubinden (z.B. via SDK des Kartensystems). Solche speziellen Integrationen sind schwer als Muss, aber könnten relevant sein. Da es nicht im Input stand, lassen wir es, außer was wir eh sagten (Mitarbeiterausweis).

• Self-Service Integration: falls es separate Self-Service Terminals (z.B. von einem anderen Hersteller) gäbe, müsste Integration klappen. Aber vermutlich nimmt man alles aus einer Hand.

• Administrationsaufwand gering: Das System sollte einfach zu administrieren sein. Keine täglichen manuellen Schritte nötig (alles automatisch). Z.B. Datensicherung automatisiert, Logrotate etc.

• Monitoring: Wenn möglich, soll es Monitoring-Hooks geben (z.B. SNMP oder Web-Dashboards), damit IT sieht, ob Kassen online sind, ob Fehler. Kann-Kriterium.

• Update-Einflüsse: Wann immer Patches (Windows Updates etc.) eingespielt, muss Klarheit, dass Kassensoftware kompatibel bleibt. Der Anbieter soll dazu eine Policy haben (z.B. freigegebene OS-Versionen, Test nach MS Patchday etc.)

• Rollout remote: IT sollte in der Lage sein, per Softwareverteilung (z.B. SCCM) neue Kassensoftware-Versionen auszubringen falls On-Prem. Oder manuell. Eine automatisierte Verteilung (Cloud or on-prem update server) wäre gut.

• Mitarbeiter vs. Gäste: Es sollen mindestens zwei Haupt-Nutzergruppen unterschieden werden: Mitarbeiter (interne) und externe Gäste. Mitarbeiter erhalten in der Regel subventionierte Preise (günstigeres Essen, vom Arbeitgeber bezuschusst), während Gäste den vollen Preis zahlen. Das Kassensystem muss in der Lage sein, für jedes Produkt mehrere Preisstufen zu verwalten und je nach Kundengruppe automatisch den richtigen Preis anzuwenden. Beispielsweise: Ein Menü kostet für Mitarbeiter 5,00 € und für Gäste 7,00 €. Bei der Buchung muss erkannt werden, ob der Kunde Mitarbeiter ist, um entsprechend 5 € zu berechnen.

• Weitere Gruppen: Möglich ist auch eine dritte Gruppe, etwa „Externe Firmenangehörige“ (z.B. Partnerfirmen am Standort) oder „Azubis/Praktikanten“ etc., je nach betrieblichem Modell, oder „Management“ falls Sonderkonditionen. Das System sollte daher mind. 3-5 Preisgruppen abbilden können (Soll), auch wenn zunächst nur 2 aktiv genutzt werden.

• Identifikation der Gruppe: Damit die Preislogik greift, muss die Nutzergruppe an der Kasse identifiziert werden. Das ist idealerweise automatisiert: z.B. Mitarbeiter weisen sich durch ihren Mitarbeiterausweis aus, den die Kasse scannt (Barcode oder RFID) – daraufhin weiß das System: das ist Gruppe Mitarbeiter X, wendet Preise B an. Falls jemand keinen Ausweis hat (Gast), könnte default = Gastpreisliste genommen werden. Alternativ kann das Kassenpersonal per Knopfdruck die Gruppe umstellen („Gastverkauf“). Das System sollte beide Möglichkeiten bieten. Optimal: Automatische Erkennung über Ausweis – verringert Fehler und Aufwand. In Self-Service-Szenarien ebenso: dort müsste ein Mitarbeiter sich am Terminal authentifizieren (Karte/Code), um den Rabatt zu erhalten. Diese Funktion ist ein Muss, da unterschiedl. Preise integraler Bestandteil sind.

• Abrechnung der Differenz: Oft übernimmt der Arbeitgeber den Differenzbetrag als Sachbezug/Benefit. Das System muss das aber nicht selbst abwickeln (das passiert buchhalterisch). Allerdings könnten Anforderungen entstehen, z.B. Bericht wieviel Subvention gegeben wurde (Summe der Rabatte). Daher: Das System sollte fähig sein, pro Transaktion den „Rabatt“ bzw. Zuschuss auszuweisen oder zumindest abrufbar zu machen (Soll). Beispiel: Menü normal 7 €, Mitarbeiter zahlt 5 €, 2 € sind Zuschuss. Summiert über Monat kann man das als Firmenaufwand reporten.

• Aktualisierung der Mitarbeiterliste: Da Mitarbeiter kommen und gehen, muss die Pflege der Berechtigten einfach sein. Je nach Identifikationsmethode:

• Bei Barcode-Ausweisen: evtl. jeder Ausweis hat z.B. Personalnummer kodiert. Das System müsste eine Liste oder Regel haben: Diese Personalnummern = Gruppe Mitarbeiter. Falls Gäste einen generischen Code oder keinen Code haben, dann anders.

• Besser: Das System verwaltet eine Datenbank der berechtigten Mitarbeiter. Diese kann regelmäßig importiert werden (z.B. aus HR-System). Das System sollte also Massenimporte/Sync erlauben (Soll). Oder es erlaubt on-the-fly: scannt man unbekannten Ausweis -> Kassierer fragt „Mitarbeiter?“ und markiert, dann wird es im System hinterlegt. Sowas sollte aber kontrolliert werden.

• Externe Gäste: Was ist mit extern? Oft sind das Personen, die keinen Ausweis haben, zahlen einfach als Gast. Evtl. will man trotzdem gewisse externe Stammgäste anlegen – aber meist nicht nötig. Das System kann Standardgruppe Gast für alle ohne Erkennung nutzen.

• Sonderfälle: Manche Betriebe haben Vollsubventionierte (z.B. Kantinenpersonal isst kostenlos) – dann bräuchte Gruppe mit 0-Preis. Oder Steuerfreie Zuschüsse bis 100€: Das System könnte tracken, wie viel ein Mitarbeiter pro Monat verzehrt (in €), um zu wissen, wann die steuerfreie Schwelle überschritten ist. Dies ist komplex, eher im HR zu machen, aber wenn gewünscht: System kann pro Mitarbeiter Summen berechnen (Kann).

• Preissteuerung nach Zeit: Nicht nur nach Person, manchmal auch nach Zeit (z.B. Happy Hour). Aber das fällt eher unter Promotion.

• Bargeld: Nach wie vor muss Barzahlung möglich sein (Muss), auch wenn das Ziel sein kann, es zu reduzieren. Das System muss Barbeträge annehmen, Wechselgeld berechnen und verbuchen. Eine Wechselgeldanzeige für Kassierer und Kunde ist Standard. Kassenschublade-Ansteuerung hatten wir.

• Elektronische Kartenzahlung (Girocard/Kreditkarte): Ein Muss ist die Akzeptanz von EC-Karten (Girocard) und gängigen Kreditkarten. Dies erfolgt über ein angebundenes Zahlterminal (siehe Hardware). Das System muss Beträge ans Terminal schicken und Rückmeldungen verarbeiten (Zahlung ok/abgelehnt). Der Workflow: Kassierer wählt „Karte“, Terminal führt aus, Bestätigung zurück, Bon drucken. Kontaktloses Bezahlen (NFC via Girocard, VISA payWave, Mastercard PayPass, Apple Pay, Google Pay) ist inkludiert, da die Terminals das regeln. Wichtig: PIN-Eingabe oder Betragshöhe-limitierte Offline-PIN etc. – alles Terminal-seitig. Das Kassensystem muss aber schnelle Transaktionen ermöglichen (<2 Sek online oft).

• Mobile Payment (App, QR-Code): Abseits klassischer Karten gibt es Trends wie Mobile Payment per App. Hier sind zwei Formen zu unterscheiden:

• App der Kantine: falls eine eigene Kantinen-App vorhanden ist (siehe Verkaufskanäle), könnte ein Mitarbeiter darüber bezahlen (z.B. Guthaben abbuchen oder Paypal). Dann kommt der Mitarbeiter evtl. nur zum Abholen. Diese Zahlung läuft dann bereits vorab – die Kasse verbucht im Backend als bezahlt. Das System muss diese Online-Zahlarten integrarete behandeln, i.e. die Bestellung gilt als bezahlt, Kasse braucht nur Quittung.

• Externe Wallets: Apple Pay/Google Pay sind im Prinzip nur Karte. QR-Code Pay (Alipay, WeChat Pay) spielen in DE kaum Rolle in Kantinen; eventuell Bluecode oder Paydirekt kann man optional erwähnen, aber nicht Must.

• Mitarbeiter-Ausweis mit Guthaben (Prepaid): In vielen Unternehmen gibt es ein betriebsinternes bargeldloses Bezahlsystem: Der Mitarbeiter lädt seine Kantinenkarte mit Guthaben auf (z.B. per EC am Automat oder Online-Überweisung), und dann zahlt er an der Kasse durch Scannen der Karte, Betrag wird vom Guthaben abgezogen. Das Kassensystem soll diese Funktion unbedingt unterstützen (Soll, eher Muss wenn verbreitet). Dafür muss es Kundenkonten führen (so wie Guthaben-Konto pro Mitarbeiter). Anforderungen:

• Aufladung: Möglichkeit, Guthaben auf Karte zu buchen (evtl. an Kasse durch Bargeld oder via separatem Terminal – Integration? Minimale Anforderung: Kasse kann Guthabenbuchung vornehmen).

• Zahlung: Beim Scan der Karte erkennt das System Guthaben, zieht Betrag ab, zeigt Rest an. Bei unzureichendem Guthaben ggf. Meldung und alternative Zahlung anbieten (Split: erst Guthaben, Rest Bar).

• Sicherheit: Guthabenveränderungen müssen manipulationssicher sein.

• Alternativ zu Prepaid: Debit auf Gehaltskonto – Hier würde der Mitarbeiter nichts laden, sondern das System merkt sich seine Konsumtionen und generiert z.B. monatlich eine Summe, die ans Lohnbuchhaltung geht (die bucht es vom Gehalt ab). Das System muss in diesem Modell Postpaid-Konten führen können (quasi negativer Saldo oder Abrechnungsliste).

• Prepaid ist technisch einfacher (Geldfluss vorher, weniger Risiko).

• Postpaid spart Aufladeprozesse, aber braucht Integration Lohn.

• Wir formulieren: Mitarbeiterkarte als Zahlungsmittel wird unterstützt – entweder auf Guthabenbasis oder über Monatsabrechnung (Anbieter soll darstellen).

• Kostenstelle/Verzehr auf Rechnung: Es kommt vor, dass für Bewirtungen oder Gäste auf Kostenstellen abgerechnet wird. Z.B. ein Abteilungsleiter lädt einen Gast ein, das Essen soll auf Abteilung XY gebucht werden. Das System sollte eine Funktion "auf Kostenstelle buchen" bieten (Soll). D.h. anstatt direkt zu kassieren, wird ein Beleg erstellt, der intern weiterverrechnet wird. Umsetzung: Der Kassierer wählt Kostenstelle aus einer Liste (die vorher gepflegt ist), druckt einen Bewirtungsbeleg. Die Summen pro Kostenstelle kann man dann monatlich auswerten, und der Auftraggeber bucht intern um.

• Alternativ, in Lohn und Gehalt für den Mitarbeiter verbuchen (wenn jemand privates Essen auf Firma bucht – aber eher Kostenstelle nutzen).

• Dieses Feature ist ein Kann/Soll je nach Bedarf – wir erwähnen es, da es in vielen Kantinen gewünscht ist für interne Meetings etc.

• Gutscheine/Essensmarken: Manche Betriebe arbeiten mit Essensmarken (z.B. Mitarbeiter erhält X Marken pro Monat). Das Kassensystem könnte das akzeptieren: z.B. ein Barcode-Gutschein pro Essen, Wert 0€ aber wird entwertet. Oder Wertgutschein (z.B. 5 € Gutschein). Das System sollte Gutscheine einlösen können (Soll). Das erfordert: Erfassung des Gutscheins (Barcodenummer), Abzug vom Betrag, Verbuchung als Gutschein (damit Kassensturz stimmt: weniger Bargeld, aber Gutscheinwert erfasst). Schöne-to-have: Verwaltung von ausgegebenen Gutscheinen (aber das ist extra Aufwand, Kann).

• Eher wichtig, falls z.B. Essenszuschüsse per digitalem Gutschein kommen (es gibt Anbieter, die statt Kantine eigene Karten/Gutscheine ausgeben). Weniger relevant hier, da interne Kantine.

• Trinkgeld: In Kantinen unüblich, kann ignoriert werden. Wenn es doch vorkommt (z.B. Catering an Besucher?), das System kann es als separate Position verwalten, ist aber optional.

• Kontaktlos & Schnellbezahlmethoden: Apple Pay/Google Pay haben wir, das ist abgedeckt über Karten-Terminal (Muss).

• NFC-Mitarbeiterkarte: Wenn die Mitarbeiterkarte RFID hat, wäre es noch komfortabler, wenn das Kassensystem diese kontaktlos liest statt Barcode. Das ist aber Hardware – kann man auch vorsehen (Kartenleser).

• Self-Checkout Bezahlarten: Bei Self-Service-Kiosken wird man kein Bargeld akzeptieren (meist nur Karte oder Mitarbeiterbadge). Das System sollte erlauben, dass an Self-Station Bargeld deaktiviert ist. D.h. pro Kasse konfigurierbare Zahlarten (ja).

• Mehrfachzahlungen/Split: Wurde in Software erwähnt: z.B. Gesamtsumme 10€, Kunde gibt 5€ bar, Rest mit Karte. System muss es können (Soll, aber wir hatten das).

• Wechselgeldfunktionen: Kasse sollte Rechenhilfe bieten, z.B. bei 20€ gegeben, 3,50€ Kauf -> zeigt 16,50€ zurück. Standard in Kassensoftware.

• Währungen: Hier nur Euro, keine Fremdwährungen nötig.

• Mitarbeiterkonten: Wenn Guthaben oder Abrechnung über Lohn, das System hat quasi "Kundenkonten". Das wurde unter Zahlungsarten angesprochen.

• Benutzer sollen Möglichkeit haben, ihr Guthaben zu erfahren (Kassendisplay zeigt an, oder via App).

• Kassenpersonal sollte Guthaben einsehen können, falls jemand fragt (Soll).

• Konto-Sperre: Falls Karte verloren, man muss sperren können (im System Flag setzen).

• Limits: Evtl. Limit je Tag (z.B. maximal 2 Mahlzeiten subventioniert). Das System könnte sperren nach 2. Aber das ist sehr speziell, meist wird es nicht kontrolliert. Wenn gewünscht, kann man optional erwähnen "System kann Limits pro Person/Zeitraum setzen" (Kann).

• Externe Nutzer: Falls es Stammgäste gibt, evtl. wollen die auch Guthaben-Karten kaufen (z.B. Fremdfirmen-MA). Das System sollte dies erlauben (eine Person kann als Kunde angelegt werden mit Karte, bekommt die Gruppe "Externer" ohne Rabatt aber mit Guthaben) – so dass die Person bargeldlos zahlen kann aber kein Rabatt.

• Benutzerverwaltung vs. Kundendaten: Nicht verwechseln: Hier reden wir von Essenskunden (Mitarbeiter), nicht System-User. In Softwareteil sprachen wir von System-Benutzern.

• Datenschutz: Bei Personenkonten unbedingt DSGVO -> die Daten (wer wann was aß) falls gespeichert, streng geschützt. Vielleicht sinnvoll, nach X Monaten die Verknüpfung Person->Einzelessen zu löschen, aber Summe behalten (je nach Policy). Das System sollte evtl. erlauben, detaillierte Verbrauchsdaten eines Mitarbeiters nach bestimmter Zeit zu anonymisieren (Kann).

• Traditioneller Kassenplatz: Dies ist der Standard, wie bisher beschrieben. Die Anforderungen dafür wurden im Hardware- und Software-Teil schon adressiert (Touchkasse, Bediener, etc.). Hier nur zusammengefasst: Bediente Kassen mit Personal müssen schnellen Durchsatz ermöglichen, intuitive Bedienung für Kassierer haben, und durch die direkte Interaktion können Fehler reduziert werden. Die Möglichkeit, Zusatzverkäufe durch Personal anzuregen (z.B. Kassierer fragt "Möchten Sie noch ein Getränk?") ist ein Vorteil, aber das betrifft eher Schulung als System – jedoch sollte das System spontane Buchungen zulassen (z.B. "No Sale" Offene Kasse – in Kantine unüblich).

• Tischbedienung (Kellnerkasse): In Betriebsrestaurants selten, aber falls es Bereiche mit Bedienservice gibt (Konferenzräume, Gästecasino), muss das System Serviceabläufe unterstützen. Kellnerkassen mit Tablet-Aufnahme am Tisch. Das hieße:

• Funktionen wie Tischplan, Split Rechnung, Zusammenführen – wohl kaum benötigt in Kantine.

• Eher relevant: Konsignation: Man bringt z.B. Getränk nach und schlägt es später an – im Kantinenmodus unwichtig.

• Wenn es ein Gästecasino mit Bediening gäbe, besser ein eigenes Pflichtenheft – wir belassen es als Kann, falls der Caterer in Konferenzräumen bedient. Das System kann optional modulare Kellnerkassenfunktion haben, aber kein Muss.

• Self-Checkout-Stationen: Es ist angestrebt, evtl. SB-Kassen einzusetzen, wo Mitarbeiter ihre Speisen selbst scannen und bezahlen, ohne Kassierer. Dies erhöht Flexibilität und spart Personal bzw. entlastet es. Anforderungen:

• Die Software auf SB-Kasse sollte eine angepasste UI für Kunden haben (mehrsprachig, sehr einfach, mit Schritt-für-Schritt).

• Artikelidentifikation: Oft gibt es Barcodeetiketten an den Gerichten oder ein PLU-System (z.B. Tellergröße code). Das System muss den Kunden erlauben, alle gekauften Artikel einzuscannen. Alternativ wählen aus Kategorien – aber scanning ist schneller.

• Mitarbeiter-Identifikation: Damit der richtige Preis berechnet wird, muss der Mitarbeiter sich authentifizieren (z.B. vor dem Scan hält er seine Karte ans Terminal, dann scannt Essen, System weiß er ist MA, rechnet MA-Preise). Oder umgekehrt: Erst scannt Essen, am Ende "Bitte Ausweis scannen oder Gast auswählen".

• Zahlung: SB-Stationen sollten bargeldlos funktionieren (Karten, evtl. Firmenausweisguthaben). Das Terminal daher mit Kartenleser und Ausweisleser. Keine Bargeldannahme (macht Station aufwändig).

• Sicherheit/Kontrolle: Um Diebstahl zu verhindern, wird in manchen SB-Systemen eine Stichprobenkontrolle oder Gewichtskontrolle (Warengewicht) eingesetzt (im Supermarkt üblich, in Kantine seltener). Hier zu entscheiden: Wenn volles Vertrauen, kann man es weglassen; bei höherem Risiko evtl. Überwachung durch Personal oder Kamera (Diskussion unter KI-Kasse).

• Einfachheit: Das SB-System muss intuitiv sein, da Nutzer ungeübt sind. Große Schaltflächen, klare Anweisungen, eventuell Bilder der Artikel (falls keine Barcodes).

• Beleg: Muss auch hier erzeugt werden (Papier oder digital).

• Systemintegration: SB-Kassen sind dem Kassensystem gleichgestellt (eigene Kassen-ID, auch an TSE angebunden).

• Mini-Kassen: Mini-Kassen für ein Produkt per Ausweis. Das könnte z.B. eine Kühlschranklösung sein: Nur Getränke, man hält Ausweis dran, bucht ein Standardprodukt. Das System sollte solche speziellen SB-Punkte integrieren können, zumindest vom Datenfluss (Verkauf wird registriert mit Produkt und Person).

• Diese Flexibilität (unterschiedliche SB-Formen) ist wünschenswert (Kann), da es "Kasse per Smartphone" oder "Grab & Go" Ideen gibt.

• Waagen-/Vision-Self-Checkout (KI-Kasse): Schon im Zukunftskapitel gefordert, aber teils real

• Es gibt Teller-Scanner mit Kameras, die automatisch erkennen, was auf dem Teller liegt. Anbieter haben solche KI-Kassen in Betrieb. Das System muss ggf. mit solch externer Hardware kommunizieren können.

• Temperaturerkennung, 3D-Kamera: Erwähnt im Text, vmtl. Hilft Tellerinhalt zu bestimmen oder zu prüfen, ob es wirklich ein Teller da ist.

• Hohe Erkennungsrate, Datenbank mit Bilder der Speisen, evtl. Abgleich mit Speiseplan (um Tagesangebote zu erkennen).

• Integration: Der KI-Scanner gibt ans Kassensystem: "Gericht A, B erkannt" – Kasse legt diese Positionen in den Bon.

• Speziell: Allergene-Anzeige: In dem KI-Kassen-Text wird erwähnt, dass Self-Service-Kassen mit Bilderkennung auch Vorabinfo zu Allergenen geben – also z.B. es zeigt: "Gericht X (enthält Gluten, Erdnuss)". Das wäre toll (Kann).

• Solch KI-Kasse ist derzeit noch neu; wir als Lastenheft formulieren es in Erweiterbarkeit (Kap 8) als Ziel, aber hier kann man anführen, dass Self-Service möglichst auch durch innovative Technik erfolgen soll.

• Mitarbeiter-App für Vorbestellung: Eine mobile App (oder Web-Anwendung) soll Mitarbeitern ermöglichen, Speisen im Voraus auszuwählen und zu bezahlen, um Wartezeiten zu verringern. Anforderungen:

• Speiseplananzeige: Die App sollte den aktuellen Speiseplan mit Beschreibung, Preisen und evtl. Allergenen anzeigen (muss mit Speiseplandaten gefüttert werden, z.B. vom Kassensystem oder Speiseplan-System).

• Vorbestellung Funktion: Mitarbeiter können z.B. bis zu einer bestimmten Uhrzeit (z.B. 10:00) ihr Mittagessen für denselben Tag (oder künftige Tage) auswählen und bestellen. Die Bestellung wird im System registriert.

• Bezahlung in App: Idealerweise bezahlt der Mitarbeiter direkt in der App (z.B. Lastschrift, PayPal, Guthaben). In der App sollten verschiedene Zahlarten möglich sein (Lastschrift, PayPal, Kreditkarte, digitales Guthaben, Kostenstelle, Lohnabrechnung) – das ist umfangreich, aber zeigt: die App kann an das Kassensystem angebunden sein, um diese Zahlungen zu verbuchen.

• Abhol-Workflow: Die Lösung muss definieren, wie die Küche/ Ausgabe von der Bestellung erfährt (vielleicht separate "Küchenmonitor" oder einfach der Mitarbeiter zeigt Quittung).

• Effekte: Vorbestellungen steigern Effizienz und Zufriedenheit – wir erwarten, dass System dies unterstützt.

• Bezahlen via App vor Ort: Zusätzlich zur Vorbestellung kann eine App auch spontan vor Ort Zahlung ermöglichen:

• z.B. Mitarbeiter scannt an der Kasse einen QR-Code, der ihn identifiziert und von seinem hinterlegten Zahlungsmedium abbucht (sozusagen Self-Checkout mit Handy in der Hand – "Scan2Go" meint evtl. der Nutzer scannt Speisen selbst mit Handy).

• Das Kassensystem müsste dann API für App-Interaktion bieten. "Scan2Go" könnte sein: Mitarbeiter nimmt Essen, scannt Barcode mit Smartphone-Kamera, bezahlt in App, zeigt am Ausgang einen Erfolgs-QR. Das wäre sehr zukunftsweisend, einige Unis probieren das.

• Wir könnten als Kann erwähnen: Mobile Self-Scanning wird unterstützt (Integration von App, die Kassenfunktionen übernimmt, inkl. Payment) – das geht Richtung Zukunftssicherheit.

• Eine mögliche Implementierung: Die App überträgt die Bestellung ans Kassensystem-Backend, dort wird sie in einer Warteschlange geführt. Bei Abholung scannt der Mitarbeiter einen QR-Code (Bestellbestätigung) an einer Kasse oder Abholstation; das System findet die Bestellung und schließt sie ggf. ab (wenn bezahlt) oder kassiert (wenn noch nicht bezahlt).

• Alternativ: Vorbestellung separate Module.

• Minimale Forderung: System sollte Schnittstelle für Vorbestellungen ermöglichen (Soll).

• Besser: Anbieter hat eigenes Vorbestellmodul (App/Web) integriert (Kann bis Soll, je nach Marktlage).

• Dies überschneidet sich mit Hardware-Kapitel, aber hier aus Verkaufskanal-Sicht:

• Snack-/Getränkeautomaten und Kaffeeautomaten: Der Verkauf dort erfolgt meist ohne Kassenpersonal. Das Kassensystem soll dennoch die Transaktionen (sofern bargeldlos über Mitarbeiterkarte) mit erfassen, um eine Gesamtübersicht zu haben und Guthaben abzubuchen.

• Die Integration kann via Schnittstelle geschehen: Automaten-Controller, der mit dem Kassensystem kommuniziert. In Praxis bieten einige Kassensystemhersteller auch Lösungen an, oder man nutzt standardisierte Protokolle (MDB for vending machines interfacing).

• Minimale Forderung: Einheitliches Zahlungssystem (Mitarbeiterkarte funktioniert am Automaten), was bedeutet der Automatenleser ist im selben System wie Kasse. In dem Fall fließen Umsätze der Automaten ins Kassensystem-Backend (Soll).

• Falls das initial nicht umgesetzt wird, aber erweiterbar sein soll, ist es zumindest ein Kann, dem Beachtung zu schenken: "Schnittstelle für Automatenanbindung (Verkäufe und Ladegeräte) vorhanden".

• Aufwerter (Ladeterminals): Schon gesagt, das ist quasi ein Self-Service Terminal wo MA Guthaben auflädt. Das ist kein Verkaufskanal, sondern Service-Kanal. Integration: diese Transaktionen (Aufladungen) müssen ins System (Guthaben) fließen.

• Catering/Veranstaltungen: Wenn die Kantine auch Catering für Events anbietet, Abrechnung kann über Kasse laufen (z.B. Abteilung XY hat Catering, der Buchungsvorgang eher Rechnung). Das kann über Kostenstelle-Funktion abgedeckt sein.

• Drive-In oder Außenverkauf: unwahrscheinlich im Firmenrestaurant.

• Webshop für Essens-Versand: nein.

• Modularer Aufbau: Das Kassensystem sollte modular konzipiert sein. D.h. neue Funktionen oder Module (z.B. ein Kundenbindungsmodul, Couponing, KI-Erkennung) können hinzugefügt werden, ohne das Gesamtsystem neu anschaffen zu müssen. Eine offene Architektur und definierte Schnittstellen (APIs) begünstigen dies. Im Angebot sollte erkennbar sein, welche Module es gibt und wie sie interagieren (z.B. getrennte Frontend-/Backend-Module, Add-ons für Self-Service etc.).

• Skalierbarkeit: Schon erwähnt, aber nochmals: falls die Betriebsgastronomie wächst (mehr Nutzer, mehr Standorte, mehr Kassen), muss das System mithalten. Insbesondere bei Cloud-Lösungen ergibt sich das oft automatisch (dann skaliert die Cloud entsprechend). Bei On-Prem sollte z.B. die Datenbank auch 2 Mio. Buchungen verwalten können, und evtl. 10 Standorte. Wir erwarten, dass das System mind. in einer Größenordnung bis ~50 Kassen und ~10000 Transaktionen/Tag skaliert ohne Performanceprobleme (Zukunftsreserve).

• Multi-Client-Fähigkeit: Falls der Caterer wechselt oder ein anderer Dienstleister auf dem System arbeitet, sollte man getrennte Mandanten haben können. In Betrieben oft egal, da System dem Betreiber gehört. Aber man könnte sagen: falls ein externer Caterer das System stellt, und mehrere Kunden damit bedient, Mandantenfähigkeit (Kann).

• Update-Fähigkeit: Zukunftssicherheit heißt auch, das System lässt sich einfach updaten. Kein Museumsstück. Der Anbieter soll committen, dass er regelmäßig Updates wie in Service-Kap. erwähnt liefert.

• Technologie-Stack modern halten: Z.B. wenn OS Upgrades (Windows 11 etc.) kommen, Software ist kompatibel.

• KI-gestützte Kassen (Computer Vision): Der Trend, Speisen via Bild-/Objekterkennung zu erkennen, wurde im SB-Kapitel erörtert. Zukunftssicher heißt: das System soll in der Lage sein, solche Technologien einzubinden.

• Entweder hat der Anbieter schon ein KI-Modul (dann super),

• oder es gibt eine API, um Erkennungsergebnisse einzuspeisen (z.B. externe KI-Software liefert Artikel-ID und Preis, diese wird an Kasse übergeben).

• In 5 Jahren könnten solche Lösungen Standard sein; unser System sollte bis dahin upgradebar sein.

• Wir verlangen nicht, dass es sofort umgesetzt wird (Kann-Kriterium), aber wir formulieren: Die Lösung soll KI-Ready sein oder entsprechende Roadmap aufweisen.

• Automatische Bestellungen: z.B. Nachschub in Küche antriggern wenn x verkauft – eher WMS Thema.

• Analytics: KI in Analytics könnte Verzehrprognosen erstellen. Evtl. wünschenswert: System bietet oder erlaubt Anbindung von Tools, die z.B. mithilfe historischer Daten und KI die Mengen für nächste Woche prognostizieren (Kann). Das ist jedoch eher im Warenwirtschaft/Betriebsoptimierung angesiedelt.

• Bots: Evtl. Chatbot-Bestellung via MS Teams – sehr futuristisch, kann man als Kann erwähnen (offene API könnte sowas erlauben).

• Self-Ordering via Sprachassistent: Theoretisch Alexa-Bestellung – eher SciFi hier, aber wir können eine generelle Formulierung nehmen "offen für neue Inputmethoden (Voice, Chatbot)".

• Mobile First: Wir haben App besprochen. Zukunftssicher wäre, dass das System mit der Smartphone-Nutzung mitgeht. Vielleicht Integration in Mobile Wallets (z.B. digitale Mitarbeiter-ID in Apple Wallet).

• z.B. Apple/Google Wallet Integration – efsta hat was mit digitalem Beleg in Apple Wallet. Das ist auch ein Punkt: der digitale Beleg als Passbook-Pass war mal Idee – kann man optional nennen.

• Cloud readiness: Wenn aktuell On-Prem gewählt, sollte theoretisch ein Wechsel in Cloud-Später möglich sein. Also containerisierbar etc. – Aber das ist sehr technisch.

• Anbindung an BI-Tools: Evtl. in Zukunft will man Big Data Analysen fahren (Verzehr vs. Wetter?). Das System soll Daten gut zugänglich machen.

• Oder der Anbieter bietet ein eigenes Analytics Dashboard mit Trends, vgl. mention in fm-connect: "umfassende Berichtsfunktionen ermöglicht Datenanalyse über Verkaufszahlen, Bestellungen, Lager, Kundenvorlieben".

• Wir fordern mind. Export, optional integrierte Tools.

• Erweiterungen für Nachhaltigkeit/Gesundheit: Trendthemen wie Anzeige CO2-Fußabdruck pro Gericht, Ernährungsampel etc. – Das Kassensystem könnte theoretisch solche Infos speichern und auf Beleg drucken ("Dieses Menü: 2.5 kg CO2").

• Das hängt von Speiseplandaten. Optional kann man anregen: System kann Zusatzinfos je Artikel verwalten (Allergene, Nährwerte) und auf Wunsch ausgeben (Kann).

• Z.B. Allergene sind sogar Pflicht in Gastronomie – aber in Betriebsgastro reicht oft Aushang, aber wenn Self-Service Terminal, der sollte Allergene anzeigbar machen.

• Wir erwähnen es, um zukunftsorientiert zu sein (Kann).

• Vendor Roadmap: Der Anbieter sollte im Angebot seine Produkt-Roadmap darlegen: welche größeren Features in Entwicklung, wie investiert er in KI etc. Das ist in Ausschreibung oft qualitativ. Hier als Anforderung: "Hersteller gibt Auskunft über Weiterentwicklung und stellt langfristigen Support sicher" (Muss).

• Community/Updates: Offene Systeme mit Community-Fallback (vllt. irrelevant, aber falls kleiner Anbieter, hat man Angst, dass er pleite geht – ein quelloffenes System wäre dann safe. Wir erwähnen es nicht unbedingt, aber wir wollen, dass die Firma robust ist, Referenzen etc.)

• Pilotbetrieb: Wir wollen ein geordnetes Vorgehen: 1 Standort pilotieren, dann stufenweise Rollout. Das mindert Risiken und erlaubt Feinjustierung. - Der Anbieter muss bereit sein, aus Pilot-Erfahrungen schnell zu lernen und ggf. Softwareanpassungen/Parametrierungen vorzunehmen, bevor auf alle Standorte ausgerollt wird.

• Die Pilotphase sollte klar definiert sein (z.B. 1 Monat an Standort A mit vollem Funktionsumfang).

• Abnahmekriterien Pilot: z.B. System stabil, Personal kommt zurecht, Umsätze stimmen – dann Freigabe für Rollout.

• Rolloutplanung: - Standorte ggf. nacheinander, nicht alle gleichzeitig, um Support zu fokussieren. - Genügend zeitlicher Puffer, aber auch zügig, damit Nutzen bald überall da. - Abhängigkeiten (z.B. Netzwerkinfrastruktur bereit). - Schulung abgestimmt (Team Standorte B, C, D erst kurz vor deren Rollout schulen, damit Wissen frisch). - Der Anbieter sollte pro Standort anfangs Vor-Ort-Betreuung am ersten Tag leisten (Soll).

• Risiko-Management: Mögliche Probleme (Hardware-Ausfall im Rollout, unerwartete Software-Bug) – man sollte Notfallplan haben (z.B. alte Kasse noch parallel vorhalten in Pilot). - Dies gehört zum Vergabeteil (im Extended in Task 4 war Pilotphase extra erwähnt).

• Kontaktlos/Corona-Anpassungen: Evtl. Perspektive: Das System sollte sich an unvorhersehbare Lagen anpassen – z.B. pandemiebedingt auf komplett kontaktloses System wechseln (Self-checkout, App). Der Anbieter, der so etwas in Petto hat, punktet.

• Loyalty & Gamification: Mögliche Zukunft: Mitarbeiter kriegen Bonuspunkte für jeden Kauf (zur Gesundheitsförderung, Gamification). Aktuell nicht gefordert, aber System, das Bonuspunkte modul könnte, wäre flexibel (Kann).

• Interoperabilität: In Zukunft könnten kantinenübergreifende Systeme kommen (z.B. Mitarbeiter besucht andere Niederlassung, kann dort mit gleichem Ausweis zahlen). Wenn wir 4 Standorte in einem Unternehmen haben, sicherlich soll der Ausweis an allen gehen. In Zukunft, vllt. Partnerschaften, aber nicht relevant.

• Buchung mehrerer Artikel mit Mitarbeiter- und Gastpreis, Belegdruck.

• Durchführen eines Stornos.

• Demonstration Self-Service-Kasse (falls angeboten) oder App.

• Auswertung am Backend (Tagesabschluss, Bericht ziehen).

• Simulation eines TSE-Exports (wie einfach, welche Schritte?).

• Bedienerfreundlichkeit der Oberfläche (Schulungsaufwand abschätzbar).

• Performance der Demo (zügige Reaktionszeiten).

• Verständnis des Anbieters für unsere Anforderungen (geht er gezielt darauf ein?).

• Qualität der Antworten auf Fachfragen (z.B. zu Sicherheit, Integration).

• Gesamteindruck des Unternehmens (Zuverlässigkeit, Professionalität).

• Wählen Sie idealerweise einen mittelgroßen, repräsentativen Standort für den Piloten.

• Setzen Sie alle Komponenten des neuen Systems dort ein (inkl. ggf. Self-Service und App), um das Zusammenspiel unter realen Bedingungen zu testen.

• Definieren Sie Pilotziele: z.B. Stabiler Betrieb über 4 Wochen, Akzeptanz bei X% der Nutzer, keine offenen kritischen Bugs.

• Lassen Sie den Anbieter während der Pilot-Go-Live Phase intensiv betreuen (Techniker vor Ort an den ersten Tagen, tägliche Check-ins).

• Holen Sie Feedback von Kassierern, Kantinenleitung und Nutzern ein. Protokollieren Sie Verbesserungsvorschläge.

• Bereiten Sie Standort 2 vor (Hardware installieren, Schulung durchführen) während Pilot noch läuft, aber schalten Sie erst um, wenn Pilot ok.

• Planen Sie ausreichend Zeit zwischen den Rollouts (z.B. 2-4 Wochen pro Standort), damit das Kernteam ggf. mitreist und überall Starthilfe leistet.

• Stellen Sie sicher, dass vor jedem Rollout eventuelle Softwareupdates (aus Pilot-Learnings) eingespielt sind.