Druck-Warteschlange
Nimmt Druckaufträge an, sendet sie per TCP an den Drucker, wiederholt bei Fehler (5 s, max. 5 Versuche) und weicht auf den Backup-Drucker aus
Funktionen · Plattform & Betrieb
Hier geht es um alles, was an der Kasse angesteckt ist und um den Weg vom fertigen Vorgang auf Papier. Bondrucker und Küchendrucker hängen im Netzwerk und bekommen ihre Aufträge über eine Warteschlange, die bei einem Ausfall selbst nachdruckt oder auf einen Ersatzdrucker ausweicht; wie ein Bon aussieht, legt eine Vorlage fest, die man im Haus selbst bearbeiten kann. Das Kartenlesegerät wird direkt über das Netzwerk angesprochen, ebenso die Kundenanzeige, die Schankanlage und die Anrufer-Erkennung an der Telefonanlage. Läuft die Kasse in der Cloud, steht die Hardware trotzdem im Laden — dann übernimmt ein kleines Programm vor Ort (der Hardware-Agent) das Drucken und die Kartenzahlung und wird von der Cloud ferngesteuert. Der eigentliche Kassiervorgang steht in Kasse & Zahlungen; hier stehen die Geräte.
Drucker und Geräte zentral konfigurieren.
Echte Oberfläche
Keine Stockmotive: Die Aufnahmen stammen aus den reproduzierbaren DiKAS-Demos und zeigen die jeweilige Funktion im Produkt.
Vollständiger Überblick
Alle folgenden Punkte stammen aus dem gegen den Programmcode geprüften Funktionskatalog.
Nimmt Druckaufträge an, sendet sie per TCP an den Drucker, wiederholt bei Fehler (5 s, max. 5 Versuche) und weicht auf den Backup-Drucker aus
Bon zu einem Beleg erzeugen und an den aufgelösten Drucker geben
Sendet beim Zahlungsabschluss und beim Bar-Storno den ESC/POS-Impuls ESC p an den Bon-Drucker. Wirkt auch ohne automatischen (Storno-)Bondruck; die Zahlarten-Maske zeigt die globale Freigabe und je Zahlart Auto/Immer/Nie, Arbeitsplatz und Mitarbeiterrecht entscheiden zusätzlich. Beim Storno gilt die am Originalbeleg eingefrorene Zahlart.
Beliebigen Text/ESC-POS-Inhalt an einen bestimmten Drucker senden
Bewirtungsbeleg (§ 4 Abs. 5 Nr. 2 EStG) zu einem Beleg drucken — Text ODER Grafik, je nach RenderMode der Standardvorlage (dieselbe wie beim Kundenbeleg). Grafisch mit echten Schreiblinien für Anlass, Teilnehmer, Ort/Datum und Unterschrift, dem abzugsfähigen Betrag (70 % inkl. Trinkgeld) im Rahmen und dem Empfängerblock ab 250 € — ohne Kunden als beschriftete Leerfelder. Die Fusszeilen der Vorlage stehen darauf, hinter dem Fiskalblock — an derselben Stelle wie im Textbon.
Beleg-PDF auf einem A4-Systemdrucker ausgeben (lokal oder am Server)
Vorhandene CUPS-Warteschlangen des Rechners anzeigen
Papier, Deckel, Offline je IP-Drucker per ESC/POS-Statusabfrage
Laufende und fehlgeschlagene Aufträge sehen, erneut senden, Fehlerliste leeren
Aufträge eines Druckers vorübergehend auf eine andere IP schicken (Ausfall, Umbau)
Drucker anlegen: Typ (Lokal/IP/Client/A4), IP:Port, Bonbreite, Codepage, Textbreite Automatisch/Breit (Font A)/Schmal (Font B), Zeichentabelle ESC t (eigene Spalte, darf leer bleiben), Schnitt, Backup und druckbare Rasterbreite des Grafik-Bons. „Breit" sendet vor jedem Textauftrag ESC M 0 und verhindert, dass ein vorheriger Auftrag den Drucker in Font B hinterlässt und ein 42-Zeichen-Bon nur zwei Drittel des Papiers nutzt. Die Grafikbreite steht auf Automatik (80 mm → 576 Punkte, schmaler → 384), kann aber auf 384/512/528/576 Punkte gestellt werden. 528 ist die byteweise gültige Stufe für Druckköpfe um 524 Punkte. Die Freigabe „Grafikdruck freigegeben" (PrinterItem.GraphicsCapable) ist am 25.08.2026 ersatzlos entfallen; „Raster 2x" (GraphicsDoubleDensity) am 26.08. ebenfalls — m=33 ist bei GS v 0 kein Dichtemodus und schnitt auf dem Kunden-Drucker den rechten Bonteil ab.
Zweiter Testdruck direkt in der Druckerkonfiguration. Druckt Font A und Font B mit Zeichenlinealen sowie echte Grafikmuster in 384, 512, 528 und 576 Punkten. Der Kunde wählt die Textlinie, die das Papier gut ausfüllt, und die grösste Grafikstufe, deren dicker rechter Rand vollständig sichtbar ist. Der Diagnosebon notiert die aktuellen Werte und hat Ankreuzfelder für das Messergebnis.
IP-Bereich nach Druckern (Port 9100) und ZVT-Terminals (Port 20007) absuchen
Kopf-/Fusszeilen, Logo, QR, TSE-Block, Spaltenbreite, Sortierung je Bon-Art einstellen — mit Vorschau
Je Vorlage (Kundenbeleg, Gutschein): Umschalter Text/Grafik mit der Papierlänge daneben, Stil (Klassik/Markenfeld), Dichte (Luftig/Kompakt), Schriftgrösse (90/100/115 %), Reissleine in mm, Schriftwahl samt Upload einer eigenen Schrift. Für Küchen-, Extra-, Storno- und Tagesabschlussbon gibt es keinen Grafik-Bon und deshalb auch keinen Schalter.
Ein Knopf „Testdruck auf Papier" neben der Vorschau schickt die gerade bearbeitete Vorlage — ungespeicherte Änderungen eingeschlossen — als echten Druckauftrag an einen wählbaren Bondrucker (deaktivierte und A4-Drucker stehen nicht zur Wahl; vorbelegt ist der Standard-Bondrucker). Er nimmt DENSELBEN Weg wie ein echter Bon (IBonJobBuilder.BuildTestJobAsync → Druckpool): dieselbe Aufbereitung, Schriftwahl, Logo, Reissleine, derselbe Rasterauftrag mit mitgeführtem Textbon. Nur die Daten sind die Beispieldaten der Vorschau (BonPreviewSamples). Ein eigener Testweg beantwortete die Frage nicht, wegen der es den Knopf gibt: packt DIESES Gerät den Grafik-Bon? Vorlagen im Textmodus und Vorlagentypen ohne Grafik-Bon drucken ihren Textbon — ohne Rückfall-Marke, das ist kein Rückfall. Der Textbon kommt in DRUCKFORM (GenerateTestBonAsync, Bonform.Druck), nicht in der Vorschauform: die ersetzt Steuerbytes durch Platzhalter, und die stünden sonst lesbar auf dem Papier. Die Kassenlade bleibt zu.
Layout (Rahmen/Markenfeld/Kompakt/Geschenk), QR an/aus und QR-Inhalt (Gutscheinnummer oder Shop-Link) je Gutschein-Vorlage
Zeigt, welche Belege als Textbon herauskamen, obwohl die Vorlage auf Grafik steht — Zeitpunkt, Drucker, Grund im Klartext und ob danach Papier kam. Überlebt den erfolgreichen Druck (Ringpuffer, 20 Einträge).
Vorlage mit Beispieldaten als Text rendern, ohne zu drucken
Logo hochladen; wird auf 384 px Breite und hohen Kontrast für Thermodruck gerechnet. Hochladen und Zurücksetzen nur als Admin (seit 23.08.2026) — es ändert jeden gedruckten Beleg; der Knopf ist für Nicht-Admins nicht mehr sichtbar. Das LESEN bleibt offen, die Kasse zeichnet das Logo vor der Anmeldung.
Der Druckknopf im Kassenbuch reicht nur noch die Drucker-Id an den Server; der baut den Auftrag und reiht ihn ein. Die Textübersicht im Dialog bleibt (GET …/print), gedruckt wird über POST …/print-job. Inhalt und Reihenfolge des Bons ändern sich dabei nicht — nur der Transportweg und das Logo.
Ein Häkchen für BEIDE Abschlussbons: das ShowLogo der TAGESABSCHLUSS-Vorlage (TemplateType 4). Korrigiert 24.08.2026 (Owner: „Logo auch auf Tagesabschluss in Rechnung macht keinen Sinn, ist eh im Tagesabschluss drin"): vorher hing der Kassen-Abschluss am eigenen ECShowLogo der RECHNUNGSVORLAGE — technisch nötig, weil er sich die Standardvorlage mit dem Kundenbeleg teilt, für den Bediener aber ein Abschluss-Schalter in der Rechnung. ECShowLogo bleibt im Vertrag (bestehende Vorlagen tragen es), wirkt nicht mehr und ist in der Maske weg. Der Kundenbeleg ist von beidem unberührt.
Je Vorlage: Matrix (Klasse+Satz, Netto, MwSt, Brutto, Summenzeile) oder Kurzform — die druckt seit 24.08.2026 je Steuersatz eine Zeile MIT dem Satz („enthaltene MwSt A 19 % 7,33"). Bis dahin summierte sie alle Sätze zu einem Betrag ohne Satzangabe — als Steuerausweis unzulässig (Owner-Befund am Testsystem). Die Einstellung „Aus" wird beim Grafik-Kundenbeleg nicht mehr neu angeboten.
Jede Position trägt den Buchstaben ihres Steuersatzes (höchster Satz = A), in beiden Druckwegen direkt hinter dem Preis (4,20 A). Im Grafik-Bon stand er bis 26.08.2026 hochgestellt hinter dem Artikelnamen; die gemeinsame Position macht Grafik- und Textbon einheitlich und gibt dem Artikelnamen die volle Namensspalte. Der Textbon kannte TaxClass vorher an KEINER Stelle — derselbe Beleg sah je nach Druckweg fiskalisch anders aus (Owner-Befund). Beide Wege nehmen dieselbe Vergabe (TaxClassAssigner) und dieselbe Schreibweise (BonTaxLabel). Der Buchstabe steht nur, wo die Steueraufstellung mitgedruckt wird: sie ist die Legende dazu. 🪤 Der Textbon rundete den Satz mit F0 — aus 10,7 % wurde „11%"; das ist behoben.
Die Vorschau im Bon-Editor zeigt seit 24.08.2026 das Beispiel des offenen Vorlagentyps: Kundenbeleg → Rechnungsbon, Gutschein → Gutschein. Vorher riefen Cloud UND On-Device fest das Kundenbeleg-Beispiel — wer ein Gutschein-Layout einstellte, wählte gegen ein Bild, das es nicht zeigen konnte. Für Vorlagentypen ohne Grafik-Bon kommt weiterhin eine ehrliche 409-Antwort mit Begründung (NOT_SUPPORTED_TYPE) statt eines falschen Bildes.
Wirksam: Sortierung (Artikel alphabetisch · Zeit wie erfasst · PLU zahlenmässig), Trennlinie Artikel, PLU-Nummer, Einzelpreis, Positions-Notizen. Seit 24.08.2026 (Task 28) ebenfalls wirksam, in BEIDEN Druckwegen: Sortierung „Nach Warengruppe" und „Warengruppen abgrenzen" (ShowGroupSeparator) — die Warengruppe steht zwar nicht am Beleg, wohl aber die ArticleId, und der Gruppenname wird über IBonWarengruppenAuflöser im Artikelstamm nachgeschlagen (nur wenn einer der beiden Schalter ihn braucht; der Beleg wird NICHT anders gespeichert). Dazu Rabatt-Modus (InvoiceRabattMode, aus ReceiptItem.DiscountAmount/Receipt.DiscountTotal) und die Gruppen-Schrift. Seit 24.08.2026 (Task 29) wirksam, in BEIDEN Druckwegen: Optionspreise und Null-Optionen. Der Kundenbeleg zeigt die Artikeloptionen (+ 2x Pommes), mit ShowOptionPrices samt Aufpreis (Preis × Menge). Die Angabe war nie erfunden: der offene Bon trägt sie (OpenBonExtraOption, Preis aus ArticleOptionItem.VK), sie ging beim Kassieren verloren. Sie steht jetzt additiv am Beleg (ReceiptItem.Options) — ReceiptItem.ExtraOptions bleibt unangetastet, weil dort auf dem Tisch-Weg der Legacy-Positions-Fremdschlüssel steht. Beide Wege bauen die Zeilen aus EINER Stelle (BonOptionszeilen). ShowZeroOptions („Optionen ohne Aufpreis anzeigen“) filtert nur bei eingeschalteten Optionspreisen — beide Schalter stehen ab Werk auf false, unabhängiges Filtern hätte jedem Betrieb die kostenlosen Beilagen vom Bon genommen. 🩤 Bestandsbelege tragen die Liste nicht; ihr Nachdruck sieht unverändert aus. Seit 24.08.2026 (Task 31) auf JEDEM Kassenweg — Direktverkauf, Kiosk/Selbstbestellung, Tisch-Selbstzahlung, Online-Bestellung und Lieferauftrag (Kasse wie Fahrer-Ausgabe); vorher galt es nur für den Tisch-Weg, und derselbe Beleg sah je nach Herkunft anders aus. Im Direktverkauf kannte der HTTP-Vertrag gar kein Optionsfeld (DirectSaleItemRequest.Options ist neu und leer vorbelegt — alte Kassen verkaufen unverändert weiter), und in der Bon-Buchung fehlte die Menge: der Bon schrieb „+ Pommes" statt „+ 2x Pommes", der ausgewiesene Aufpreis war der Einzel- statt des Gesamtpreises, und der Lagerabzug buchte EINE Beilage statt zweier. Eine Prozent-Option geht als Betrag hinaus (10 % auf 4,00 EUR = 0,40 EUR), nicht als Prozentsatz — seit 24.08.2026 (Task 33) auch auf dem Tisch-Weg und bei der Tisch-Selbstzahlung: der offene Bon führt dafür OpenBonExtraOption.IsPercent (additiv; ein Bestandsbon ohne das Feld druckt wie bisher, eine Kasse ohne das Feld bucht wie bisher). 💶 Derselbe Task hat einen Geldfehler behoben: die Tisch-Selbstzahlung (QR) berechnete den Options-Aufpreis DOPPELT — an drei Stellen zugleich (Belegbau, der belastete Betrag in InitiatePayment, die Deckungsprüfung in ConfirmPayment), weil bon.Price den Aufpreis bereits trägt. Gegenstück: die QR-Tischbestellung legte ihre Bons OHNE Preis an, dort kassierte der Kellner den Aufpreis gar nicht. Seit Task 33 gilt EIN Vertrag — OpenBon.Price ist der fertige Stückpreis, nachzulesen in Domain/Services/OffenerBonPreis.cs. 🪤 Die Disco-Karte bleibt draussen: DiscoOpenBon führt keine Optionen, ihr Aufpreis ist beim Übertragen in den Stückpreis gefaltet. Task 34 (24.08.2026) hat dieselbe Doppelrechnung an den übrigen sieben Stellen behoben — Tischsummen, Budgetprüfung, Rabatt-Basis, Disco-Übertragung, Kassen-Fremdbon und die TSE-Signaturzeile der Bestellung-V1; dabei löst der Online-Bestellweg eine Prozent-Option jetzt in Geld auf (OnlineOrderItemValidation.ResolveOptionPrices), statt den Prozentsatz als Betrag durchzureichen. Ausgeblendet bleiben Bon- und Positions-Kommentar: der Bon-Kommentar hat keine Erfassung in der Kasse (Receipt.Notes existiert, wird dort nie gesetzt), der Positions-Kommentar steht schon auf dem Bon und wird von „Bemerkung zur Position" gesteuert. Owner-Entscheid 24.08.2026 (Task 32): beide bleiben DAUERHAFT draussen — zum Bon-Kommentar an der Kasse ausdrücklich „nein" (es kommt kein Eingabefeld, nicht neu aufrollen); ShowPositionComment stünde ab Werk AUS, während ShowItemNotes ab Werk AN ist, und ihn scharfzuschalten hätte den Betrieben die Bemerkung weggenommen. Dafür heißt ShowItemNotes in der Maske jetzt „Bemerkung zur Position" statt „Positions-Notizen", mit einem Satz Hilfetext — es druckt ReceiptItem.Notes in beiden Druckwegen. Seit 24.08.2026 gilt dasselbe für den TEXTBON (Owner-Befund „die Sortierung ... hat immer noch keine Auswirkung bei den normalen Bons"): Sortierung, Trennlinie Artikel, PLU und Einzelpreis wirken dort jetzt ebenfalls, die Sortierung aus derselben Quelle wie der Grafik-Weg (BonArtikelSortierung). 🪤 Der Werkswert der Sortierung ist 0 = „Nach Artikel" — ein Betrieb, der ihn nie angefasst hat, bekommt seinen Textbon ab jetzt alphabetisch statt in Erfassungsreihenfolge. Wer die alte Reihenfolge will, stellt auf „Nach Zeit".
Seit 24.08.2026 (Task 28) wirksam: PLU vor dem Artikelnamen (Sammel- und Extra-Bon), Gruppenname und Gang-Überschrift dort, wo der Wert wechselt, Sortierung nach Gang (äusserer Ordnungsbegriff) und nach Warengruppe (innerer), Gruppen-Schrift. Vorher standen alle sieben Schalter NUR in der Vorschau — der Betrieb schaltete ein, sah es in der Vorschau und fand es auf dem Papier nicht. Die Angaben lagen an der Quelle bereit: Gang am OpenBon, Artikelnummer und Warengruppe am Article, den jeder Erzeuger ohnehin für die Druckoption lädt. 🪤 Jeder Schalter tut GENAU eine Sache — die alte Vorschau koppelte Gang-Text an die Gang-Sortierung. Positionen ohne Gang/Gruppe bekommen keine leere Überschrift und wandern beim Sortieren ans Ende; eine Position ohne Nummer bekommt keine Lücke am Zeilenanfang.
Seit 24.08.2026 (Task 28) wirksam: Kopf-/Fusszeilen, Breite, Trennzeichen, Währung, Zahlungsdetails, Unterschriftenfeld und „Papier nicht abschneiden" des Stornobelegs. Vorher druckte AutoPrintStornoBon mit der KUNDENBELEG-Vorlage und BonTemplateSelector kannte für Typ 3 gar keinen Einstieg — der ganze Reiter war folgenlos. Die fiskalischen Angaben bleiben beim Kundenbeleg (Steuerausweis, Steueranzeige, Fiskaltext, Prüf-QR): der Reiter bietet sie nicht an, und die Werksvorlage für Typ 3 hat sie ab Werk AUS — sie ganz zu nehmen hätte jeden Gegenbeleg ohne Steuerausweis gedruckt. Immer Text: die Grafik-Abbildung lehnt Storno- und Gutschriftsbelege ab (kein Kennzeichen, kein Stornogrund, kein Ursprungsbeleg), RenderMode steht deshalb fest. Seit 24.08.2026 (Task 32) erbt die WERKSVORLAGE Kopf- und Fusszeilen der Rechnungsvorlage, mit der Kennzeichnung „STORNIERUNG" als letzter Kopfzeile — vorher war der Werksstand „STORNIERUNG" und KEINE Fusszeile, und weil der Bon-Editor beim Speichern ALLE Vorlagen schreibt (auch die beim Laden erst erzeugten), hätte ein Betrieb mit Anschrift in der Kopfzeile sie auf dem Gegenbeleg verloren, ohne den Reiter je geöffnet zu haben. Nur solange nichts gespeichert ist: eine vorhandene Typ-3-Vorlage gilt unverändert, auch mit LEEREN Zeilen — „leer" ist dort eine Entscheidung des Betriebs, kein fehlender Wert. Der Werksstand steht an zwei Stellen (BonTemplateSelector.Storno, bon-editor.component.ts defaultTemplate) und muss gleich lauten, sonst zeigt die Vorschau einen anderen Bon als der Drucker.
Je Vorlage (alle Typen): der Bon bekommt keinen Schnittbefehl (GS V) — für Drucker ohne Abschneider oder wenn mehrere Bons am Stück abgerissen werden. Wirkt seit 24.08.2026 (Task 28) in beiden Druckwegen; vorher stand DontCutBonText im Vertrag und wurde von niemandem gelesen. 🪤 Der Papiervorschub bleibt — ohne ihn stünde die letzte Zeile noch unter dem Druckkopf. 🪤 Auch der Gutschein liest ihn: ein Gutschein ohne Schnitt hängt am nächsten Bon.
Die Vorschau des Rechnungsbons im Bon-Editor ist seit 24.08.2026 die Ausgabe desselben Erzeugers wie der Druck (RechnungsBonAsync mit dem Beispielbeleg BonPreviewSamples.Textbeleg()). Jeder Schalter wirkt dort damit genau so wie auf dem Papier. Vorher setzte die Vorschau ihre Zeilen selbst zusammen: sie zeigte Schalter, die der gedruckte Bon ignorierte (PLU, Sortierung, Trennlinien), und kannte die Steuerklassen-Buchstaben nicht, die er druckte — sie war nicht zuviel oder zuwenig, sondern etwas ANDERES. In der Cloud-Demo hängt kein Drucker; dort ist die Vorschau das einzige Fenster auf den Bon. Der einzige verbliebene Unterschied sind ESC/POS-Steuerbytes: QR und Logo erscheinen als [QR-Code]/[LOGO], Schriftumschaltungen entfallen. Seit 24.08.2026 (Task 28) gilt dasselbe für Sammel-, Extra- und Stornobon — GenerateSammelbonPreview, GenerateExtraBonPreview und GenerateStornoBonPreview sind gelöscht, die Vorschau schickt BonPreviewSamples.Küchenbestellung() bzw. .Stornobeleg() durch denselben Erzeuger. 🪤 Übrig als eigene Nachbildungen: nur noch Tagesabschluss und Gutschein.
Die drei Stufen Aus / Kurzform / Matrix wirken seit 24.08.2026 auch im Textbon (Owner: „im normalen Bon hat Steuersatz-Anzeige keine Funktion"). Die Kurzform druckt je Steuersatz eine Zeile MIT dem Satz — dieselbe Regel und dieselbe Beschriftung wie im Grafik-Bon (BonTaxLabel). „Aus" ist für den Kundenbeleg jetzt auch im Textmodus unzulässig und wird beim Speichern abgelehnt (KassenSichV); Der TSE-Nachweis ist seit 24.08.2026 (Task 30) in BEIDEN Druckwegen dieselbe Wahl — vorher gab es im Textmodus kein „nur QR", weil der Textbon ShowQrCode nur innerhalb von ShowTseInfo las.
Der Bon-Editor zeigt seit 24.08.2026 (Task 30) ein Feld „TSE-Nachweis" mit drei Werten — Nur Fiskaltext · Nur QR-Code · Fiskaltext und QR-Code — statt zweier Kästchen. Zwei Kästchen kennen vier Kombinationen, eine davon (beide aus) ist nach KassenSichV verboten: sie war einstellbar und wurde erst beim Speichern bemängelt; das Auswahlfeld kennt sie nicht. Die Datenfelder bleiben getrennt (ShowTseInfo, ShowQrCode) — nur die Maske fasst sie zusammen, gespeicherte Vorlagen laden unverändert. Eine schon gespeicherte unzulässige Kombination bleibt sichtbar (vierter Eintrag „Nichts — fiskalisch unzulässig"), wird aber nicht neu angeboten; das Öffnen der Maske biegt sie nicht still um. Der Textbon druckt den Prüf-QR jetzt auch ohne den Fiskaltext: Überschrift „TSE-Daten" + QR, ohne TSE-Nr/Sig-Zähler. Ohne QR-Nutzlast stehen die Pflichtangaben als Text da statt gar nicht, und TSE-Ausfall/Fernverkauf/„KEINE TSE" erscheinen unabhängig vom Fiskaltext.
Trägt ein Beleg einen TSE-Ausfall (TseError ohne Transaktionsnummer), setzt der Grafik-Bon seit 25.08.2026 die Meldung selbst: TSE-AUSFALL , den dreizeiligen Satz und Fehler: <Grund> — in der Fiskalzone, in Sans, an derselben Stelle wie sonst die Signaturfelder. Vorher lehnte GraphicBonReceiptMapper.PrüfeDarstellbar solche Belege ab und der Bon fiel auf Text zurück: auf einer Box, deren TSE-Inbetriebnahme am Hochlauf scheiterte, trug JEDER Beleg einen Ausfall — der Grafikmodus war eingeschaltet, freigegeben und trotzdem nie zu sehen (Owner: „wollen ja keinen Bruch im Bon-Design"). Der Wortlaut ist zeichengleich zum Textbon (BonTseAusfall, beide Wege lesen dieselbe Zeichenkette) — ein Prüfer vergleicht Belege beider Druckwege. Ohne Signatur kein Prüf-QR, auch nicht im Stil Markenfeld. Die Meldung kostet ~3 mm gegenüber „KEINE TSE". Storno/Gutschrift, Fernverkauf (TseExempt) und Nicht-DE fallen weiterhin auf Text zurück.
Die Bildvorschau des Grafik-Bons zeigt seit 24.08.2026 das hochgeladene Bon-Logo — über denselben Weg wie der Druck (IPrintService.GetBonLogoImageAsync), mit demselben Rückfall auf das eingebettete Standardlogo. Vorher setzte das Vorschau-Beispiel LogoImage an keiner Stelle: die Vorschau konnte das Logo nie zeigen, egal wie die Vorlage stand (Owner: „Logo habe ich hochgeladen, aber wird im Grafik-Bon nicht angezeigt"). Der Druck trug es die ganze Zeit — nachgemessen an den Rasterbytes des fertigen Druckauftrags. Seit 24.08.2026 (Task 32) zeichnet auch der GUTSCHEIN sein Logo — im Grafik-Weg wie im Textdruck, in Vorschau wie Papier (siehe eigene Zeile „Gutschein-Logo"). Der Satz „der Gutschein trägt kein Logo" ist damit widerlegt.
Eine Schrift für den ganzen Grafik-Bon: Sans (Standard), Mono, Serif und die drei Handschriften Kalam, Caveat, Patrick Hand — alle mitgeliefert. Vorgabe Sans, also unverändertes Aussehen für jede bestehende Vorlage. Ausnahme seit 23.08.2026 (Papierprobe): die Fiskalzone — TSE-Signaturblock, die Hinweise „KEINE TSE" und „TSE-AUSFALL", Prüfwert und Steuerausweis — steht IMMER in Sans, auch bei einer hochgeladenen Schrift, damit ein Prüfer sie bei 203 dpi abgleichen kann; Kopf, Positionen, Summe und Fusszeilen folgen der Wahl. Der Bon-Editor nennt das an der Schriftwahl. Seit 24.08.2026 gilt zusätzlich die Kleinschrift-Regel (Owner-Entscheid am Papier, Variante B): jede Textzone unterhalb der Fliesstext-Grösse steht im BETONTEN Schnitt ihrer Schrift — Adresse, Beleg-/Tischzeile, Zahlungszeilen, Steuermatrix, TSE-Block, Prüfwert, Fusszeilen und der ganze Bewirtungsbeleg. Das kostet KEINEN Millimeter Papier (Zeilenhöhen folgen dem Schriftgrad); Positionen, Firmenname und Summenzeile bleiben unangetastet. Der Gutschein fällt seit 24.08.2026 ebenfalls darunter (Owner-Entscheid auf Nachfrage — dasselbe Papier, dieselben 203 dpi): Kleingedrucktes, lesbare Nummer, „gültig bis"/„ausgestellt", QR-Begleittext, Schreiblinien-Beschriftungen und „GUTSCHEIN" im Markenfeld-Kopf; ausgelassen bleibt sein Blickfang (Betrag, Titel, Firmenname). Auf 58-mm-Papier kommt die Regel nachweislich an (gemessen 24.08.: Steuermatrix +10,5 %, TSE-Block +18 %, Bewirtungsbeleg +5 % Tinte bei unveränderter Bandhöhe) — die Kopfzeile der Steuermatrix steht dort allerdings bei nur 12,6 Punkten ≈ 1,6 mm. Bei Patrick Hand und hochgeladenen Schriften wirkt die Betonung über Kunstfett.
Der TSE-Prüf-QR steht allein auf eigener Zeile und bekommt auf 80 mm 5 Punkte je Modul (405 x 405 Punkte = 50,6 mm). Am Papier gemessen (23.08.2026): mit den früheren 3 Punkten je Modul liest ihn zwar jedes Telefon, aber spürbar langsam. Untergrenze bleibt 3 — der Notausgang für 58-mm-Papier; reicht auch die nicht, wird statt eines unlesbaren QR der Prüfwert als Text gedruckt und der Auftrag sichtbar markiert.
Der Betrieb legt eine eigene .ttf/.otf (max. 2 MB) dazu; sie liegt mandantengetrennt als Anhang und wandert mit der Replikation. Abgelehnt wird, was sich nicht als Schrift öffnen lässt — nicht nur die falsche Endung. Nur Admin.
Je Artikel/Warengruppe: Küchenbon, Extra-Bon 1/2, Sammelbon, Gangbon, Schankanlage. Keine Pager-ID: Sie ist keine Druckroute und wird deshalb nicht mehr in der Drucksteuerung angeboten.
Artikel-Schalter „Pager-ID beim Bezahlen abfragen“: Die Kasse fragt einmal pro Verkauf, sobald mindestens ein solcher Artikel im Warenkorb liegt. Die Eingabe wird am Beleg gespeichert und als eigene Zeile auf Text- und Grafik-Kundenbon gedruckt; Direktverkauf und Tisch-/Fremdbon-Zahlung sind gleich behandelt.
Bestellpositionen an die zuständigen Küchen-/Thekendrucker verteilen
ESC/POS-Etikett zu einem Werkstattauftrag erzeugen und drucken; wählt seine Zeichentabelle selbst (ESC t n direkt nach ESC @) — aber nur, wenn am Drucker eine angesagt ist (PrinterItem.EscPosCharTable); ohne Eintrag fällt hier gar kein Kommando — das Präfix des Auftrags ist hier wirkungslos, weil ESC @ die Tabelle zurücksetzt
Die Kasse liest das EAN-13 einer Etikettenwaage: Präfix erkennen → Waagen-PLU → Gewichtsartikel → Position mit dem Gewicht als Menge. Kein Treiber, keine Kabelverbindung, offline.
Je Mandant: In-Store-Präfixe (Vorgabe 21/22), PLU-Stellen, Wertmodus Gewicht/Preis, Nachkommastellen. Vorgabe: aus.
Ein echtes Etikett eintippen/scannen und sehen, was die Kasse daraus macht (PLU, Artikel, Gewicht, Betrag) — inkl. Beispiel-Etikett je Einstellung. Inbetriebnahme-Werkzeug für Händler und Support.
Zahlung, Storno, eigenständige Gutschrift, Beleg-Wiederholung, Abbruch, Status
Kassenschnitt und Umsatz-Zwischensumme je Terminal oder für alle Terminals auf einmal
Terminals anlegen: ZVT, SoftPOS, Stripe Terminal, Stripe Tap to Pay, SumUp-Reader, SumUp Tap-to-Pay, Redsys, Simulator
Reader über einen Pairing-Code an den Terminal-Datensatz binden
Zahlung, Storno, Gutschrift, Kassenschnitt und Status ohne Hardware; simuliertes Trinkgeld am Terminal (fest und/oder prozentual), Ablehnungsrhythmus und Laufzeiten konfigurierbar über Zvt:Simulator — alles standardmässig auf dem bisherigen Verhalten
Programm im Laden-Netz, verbindet sich ausgehend per SignalR, führt Druck, ZVT und Geräte-Suche lokal aus
Fertig serialisierte ESC/POS-Bytes (Bon-Logo, Grafik-Bon) reisen base64-kodiert zum Agent und gehen dort unverändert auf den Socket — keine Codepage, sonst überleben von 256 Bytewerten nur 128
Der Agent meldet beim Verbinden (?caps=), welche neuen Kommandotypen er beherrscht; die Cloud wählt bei mehreren Tablets gezielt eines aus, das den Typ kann, und fällt bei einem alten Agent SOFORT auf den Textbon zurück statt fünfmal zu wiederholen
Verbindungs-Status und Kopplungs-Geheimnis des Mandanten für die Einrichtung anzeigen (nur Admin)
Sammelstatus aus TSE, Bondrucker, EC-Terminal und Hardware-Agent für das Admin-Dashboard
Zusätzliche Geräteplätze beim Lizenzserver anfordern
Zweitschirm registriert sich mit Code (oder Kiosk-Schlüssel) und wird an eine Kasse gebunden
Der Gutschein-QR bekommt auf 80 mm in allen vier Layouts 5 Punkte je Modul — dieselbe Regel und dieselbe Quelle wie der Prüf-QR des Kundenbelegs (Owner 24.08.2026: „gutschein code grösser machen damit man den leicht lesen kann."). Vorher deckelten feste Kantenzahlen aus den Entwürfen (114/126/150 Punkte) ihn auf 3 bzw. 4 — seit Task 22 ist er der EINZIGE maschinenlesbare Code auf dem Gutschein, der Code-128 ist weg. Auf 58 mm nimmt er, was das Papier hergibt, nie unter 3: Kompakt 5 (er steht dort unter dem Text und hat die volle Breite), Markenfeld 4, Rahmen und Geschenk 3. Der Textdruck zieht mit (ESC/POS GS ( k … 1C, Modulgrösse 5); der Fiskal-QR des Kundenbelegs behält dort seine 4. 🪤 Die Gutscheine werden dadurch länger — 80 mm: Rahmen 97, Markenfeld 89, Kompakt 38 (unverändert), Geschenk 111 mm; 58 mm: 107/94/58/111 mm. Lesbare Nummer und Betrag bleiben in jedem Layout stehen.
Der Grafik-Gutschein zeichnet seit 24.08.2026 (Task 32, Owner: „zeichnen") das Bon-Logo im Kopf — in allen vier Stilen. Es ersetzt dort die Wortmarke (Logo ODER Firmenname, wie beim Kundenbeleg) und hängt am Kästchen „Logo drucken", nicht an „Firmendaten". Vorher trug VoucherBonData kein Logofeld und RenderVoucherAsync fragte ShowLogo nie ab: das Kästchen war im Grafik-Modus stumm wirkungslos, während der Textdruck das Logo sehr wohl setzte — derselbe Gutschein trug je nach Drucker eines oder keines. Im Stil „Markenfeld" wird es AUSGESPART (Farbkanäle umgekehrt, Deckkraft bleibt): der Kopf ist dort eine schwarze Fläche, und ein normal gezeichnetes Logo risse entweder ein weisses Rechteck in die Marke (weisser Bildhintergrund) oder verschwände im Schwarz (durchsichtiger Hintergrund) — ein unsichtbares Logo ist schlimmer als keines. 🪤 Der Gutschein wird dadurch länger. Gemessen mit einem Logo von 384x120 Punkten, 80 mm / 58 mm: Rahmen 103,2 / 107,5 mm (ohne Logo 97,1 / 106,6), Markenfeld 93,3 / 96,1 (88,5 / 94,3), Kompakt 54,3 / 71,2 (38,3 / 58,2), Geschenk 117,6 / 113,0 (110,9 / 111,4). Die Zahl hängt am Seitenverhältnis des Bildes, nicht an einer Konstanten — ein flacheres Logo kann den Gutschein sogar kürzer machen als die Wortmarke, die es ersetzt.
Warenkorb und Beleg live anzeigen, QR-Beleg serverseitig erzeugt
Bilder/Videos und Willkommen-Medium bis 100 MB hochladen, Wechselintervall 3–120 s
Buchungen und Stornos an die Zapfanlage senden — Gruber, Addimat, Hogatron, Simulator über Seriell/TCP/UDP
Status, Mitschnitt der Leitung (TX/RX/ERR), Testbuchung, Teststorno, Reset, Neuverbinden, COM-Ports
Hängt die Zapfanlage am seriellen Anschluss einer (Neben-)Kasse, reicht deren dikasarch die Leitung per WebSocket durch — Verbindungstyp „Brücke (dikasarch-Kasse)", Geräte-Alias statt Pfad, Leitungsparameter kommen vom Server. Einrichtung ohne Abtippen über die Kopplung: die Kasse fragt an, der Admin bestätigt am Server, der Schlüssel wandert selbsttätig und verlässt den Server nie Richtung Browser.
Eingehende Rufnummer von einer Fritzbox direkt über deren Callmonitor auf TCP 1012 (RING/DISCONNECT; CALL/CONNECT werden bewusst ignoriert) oder von einem ncidd-Server lesen, Kunden zuordnen (PhoneNumberNormalizer, dieselbe Regel wie die Kundensuche) und das Popup mit Kundendaten beim Auflegen wieder schließen. Der Verbindungstest wertet den erfolgreichen TCP-Aufbau — eine Fritzbox sendet keine Begrüssungszeile — und Speichern/„Neu verbinden" unterbricht sofort den alten Verbindungsversuch. Seit 29.08.2026 (P9): Wiederverbindung mit wachsender Pause (5 → 10 → 20 → 40 → 60 s, NcidReconnectBackoff) statt festem 10-s-Takt; ist im Backoffice nichts eingeschaltet, gilt der Host aus der Einstellungsdatei (Telephony:FritzBox:Host, optional :Port, NcidConfigResolver) — Status meldet hostFromSettings. Nur Nummer und Zeitpunkt liegen im Speicher, nichts wird persistiert. Nur lokal/Einzelmandant — im Cloud-Betrieb schweigt der Dienst. Das Anruf-Popup führt seit P9 „Annehmen" in den Telefon-Modus der Kasse (05)
Anrufe ohne Telefonanlage auslösen, um das Popup zu testen
Münz-/Scheineinheit als Zahlgerät (VNE, Cashmatic, Simulator)
Scanner, NFC-Leser, GPS und Kompass eines Tablets als Fahrer-/Agent-Rolle
Kein Treffer in diesem Bereich. Gesamte Website durchsuchen
Oft gesucht
Marketing-Cookies erlauben?
Wir würden gerne mit Google Ads messen, welche Anzeigen zu einer Anmeldung führen. Dafür werden Cookies gesetzt und Daten an Google (USA) übertragen — nur mit deiner Einwilligung. Unsere anonyme Reichweitenmessung (Matomo) läuft davon unabhängig. Details und Widerruf in der Datenschutzerklärung.