Versionsverlauf von BISpicy ERP

Version 0.0.0.184 — JTL-Auftragsimport: vollständige Liefer-/Rechnungsadresse

Beim Holen von JTL-Aufträgen wurden bisher nur Name, Firma, Straße, PLZ, Ort und Land übernommen — E-Mail und Telefon fehlten. Jetzt wird die vollständige Adresse importiert.

• E-Mail und Telefon der Liefer-/Rechnungsadresse werden jetzt mit importiert.
• Zusätzlich Adresszusatz, Bundesland und getrennte Hausnummer.
• Vollständige Kontakt- und Versanddaten je importiertem Auftrag — Grundlage für Versandbenachrichtigung und Etikett.

Version 0.0.0.178 – 0.0.0.183 — Versand-Rückmeldung an JTL: robust über alle JTL-Versionen

Mehrere Iterationen haben die Rückmeldung versendeter Aufträge an JTL versionsfest gemacht — damit Lieferschein, Versanddaten, Lagerabgang und Auslieferstatus auch auf aktuellen JTL-Versionen sauber zurückgeschrieben werden.

• Lieferschein über JTLs eigene Routine (statt direktem Tabellen-Schreiben), mit Rückfall auf das direkte Schreiben bei älteren JTL-Versionen (.183).
• Erkennt den tatsächlichen JTL-Datenbankaufbau und schreibt nur die vorhandenen Felder, inkl. korrekter Behandlung automatisch vergebener Nummern (.182).
• Abbruch durch eine nicht vorhandene Datenbankspalte behoben — die Rückmeldung läuft auch auf älteren Konten wieder durch (.181).
• Doppelbuchungs-Schutz beim Lagerabgang: der Abgang ist eindeutig an die Versandnummer gekoppelt, Wiederholungsläufe buchen nicht doppelt aus (.178).

Version 0.0.0.180 — Bestandsanpassungen landen in Sekunden in JTL

Manuelle Bestandskorrekturen, Wareneingänge und MDE-Buchungen wurden bisher erst beim 5-Minuten-Abgleich nach JTL übertragen. Jetzt stößt jede Bestandsanpassung sofort einen direkten Push an.

• Bestandsanpassungen kommen in der Regel innerhalb von Sekunden in JTL an (vorher bis zu 5 Minuten).
• Gleiche schnelle Übertragungsspur wie die Kassenverkäufe.
• Der 5-Minuten-Abgleich bleibt als Sicherheitsnetz; doppeltes Verbuchen ist technisch ausgeschlossen.

Version 0.0.0.177 — Druckerverwaltung: Admin-Recht + zentrale Arbeitsplatz-Zuordnung

Die BISPrint-Druckerverwaltung konnte bisher jeder Mitarbeiter ändern, und die Zuordnung „dieser PC nutzt diesen Drucker" musste an jedem PC einzeln gewählt werden.

• Eigene Berechtigung „Druckerverwaltung" — standardmäßig nur Administrator, andere Rollen schreibgeschützt (Drucken bleibt für alle frei).
• Zentrale Liste „Arbeitsplätze (PCs)": jeder PC erscheint automatisch (letzter Nutzer/IP/Zeit).
• Der Admin ordnet jedem Arbeitsplatz von einem Bildschirm aus den Drucker-Client zu — ohne Einstellen am einzelnen PC.
• Arbeitsplätze sind benennbar; ohne Zuordnung greift weiterhin der Standard-Drucker.

Version 0.0.0.176 — In BIS ERP versendete JTL-Aufträge werden in JTL nachgeführt

Wurde ein importierter JTL-Auftrag in BIS ERP versendet, wurde der JTL-Lagerbestand bisher nicht ausgebucht und der Auftrag nicht als erledigt markiert.

• Der Lagerabgang wird lagertyp-sicher in JTL gebucht (WMS lagerplatzgenau, FEFO).
• Lieferschein und Tracking werden an JTL zurückgemeldet, der Auftrag als komplett ausgeliefert markiert.
• Kein Doppelversand (JTL sieht den Auftrag als erledigt) und keine Doppelbuchung bei bereits von der Kasse ausgebuchten Aufträgen.

Version 0.0.0.175 — JTL-Aufträge in BIS ERP abwickeln: offene Aufträge werden importiert

Bei direkter (On-Premise-)JTL-Anbindung konnten Aufträge bisher nicht in BIS ERP übernommen werden. Jetzt werden offene JTL-Aufträge nach BIS ERP geholt und lassen sich dort über Packtisch und Versand abwickeln.

• Offene JTL-Aufträge werden importiert (Webshop, Marktplatz, manuell, offene Kassen-Versandaufträge).
• Nur offene/unversandte Aufträge ab einstellbarem Startdatum — keine bereits versendeten, keine Dubletten.
• Erster Baustein für „JTL-Aufträge komplett über BIS ERP abwickeln" (Versand-Rückmeldung folgt in 0.0.0.176).
• Aktivierung pro JTL-Verbindung; bestehende Verbindungen bleiben unverändert.

Version 0.0.0.174 — BISPrint: jeder Arbeitsplatz druckt auf seinen eigenen Drucker

Die BISPrint-Drucker-Zuweisung galt bisher betriebsweit — „Rechnung" konnte nur auf einen Drucker gehen. Jetzt bekommt jeder Arbeitsplatz (= jeder BISPrint-Client/PC) seine eigene Drucker-Zuweisung je Dokumenttyp.

• Eigene Drucker-Zuweisung pro Arbeitsplatz — Büro-, Lager- und Kassen-PC drucken parallel auf je eigene Drucker.
• BISPrint-Clients lassen sich direkt in den Einstellungen umbenennen (wie Kassen).
• Einmal pro PC „Dieser Arbeitsplatz" wählen — danach nutzt jeder Druck automatisch dessen Drucker.
• Die betriebsweite Zuweisung bleibt als Standard-Drucker (Fallback); Ein-PC-Betriebe müssen nichts umstellen.

Version 0.0.0.172 – 0.0.0.173 — MDE- und manuelle Bestandsbuchungen erreichen jetzt JTL

Wareneingang, Bestandskorrektur und Inventur über die Lager-/MDE-App sowie manuelle Plus-/Minus-Korrekturen wurden in BIS ERP verbucht, aber nicht an ein angebundenes JTL-Wawi weitergegeben — Bestände liefen auseinander.

• MDE-Buchungen (Wareneingang/Korrektur/Inventur) werden automatisch ans angebundene JTL-Wawi übertragen (.172).
• Manuelle Plus-/Minus-Korrekturen ebenfalls — die Buchung läuft atomar (Bestand, Charge, Seriennummern, Historie in einer Transaktion) (.173).
• Lagertyp-sicher: Zugänge bei JTL-WMS-Lägern lagerplatzgenau; riskante Abbuchungen werden nicht blind geschrieben.
• Rein serverseitig — die MDE-App muss nicht neu installiert werden.

Version 0.0.0.171 — Cloud-Druck: Druckaufträge gehen nicht mehr verloren

BISPrint-Druckaufträge verfielen schon nach 5 Minuten ohne Online-Client — Drucke gingen lautlos verloren. Jetzt bleiben sie standardmäßig 72 Stunden in der Warteschlange.

• Standard-Ablauf von 5 Minuten auf 72 Stunden erhöht — Aufträge werden gedruckt, sobald der Client wieder online ist (bestehende Konten automatisch umgestellt).
• Benachrichtigung in der Glocke meldet offene Aufträge ohne Client inkl. Restlaufzeit; der Hinweis verschwindet automatisch, sobald wieder gedruckt wird.
• Die Ablauf-Frist ist in den Druck-Einstellungen in Stunden (bis 7 Tage) einstellbar.

Version 0.0.0.170 — JTL-Lageranbindung: WMS-Bestände werden nicht mehr durcheinandergebracht

Beim Zurückschreiben von Beständen an JTL hat BIS ERP bisher nicht unterschieden, ob das Lager ein einfaches Standardlager oder ein lagerplatzgeführtes JTL-WMS-Lager ist. Jetzt erkennt BIS ERP den Lagertyp automatisch.

• Automatische Erkennung des JTL-Lagertyps (Standard vs. WMS-Lager).
• Standardlager: unverändert — Bestände werden wie bisher fortgeschrieben.
• WMS-Lager: Zubuchungen laufen über den offiziellen JTL-Weg mit Lagerplatz; riskante Ab-/Überschreibbuchungen werden vorgemerkt statt blind ausgeführt.
• Das Sync-Protokoll zeigt pro Lauf, in welchen Lagertyp gebucht wurde.

Version 0.0.0.169 — Cloud-Druck (BISPrint): keine Doppeldrucke bei mehreren Druck-Clients

Liefen zwei BISPrint-Druck-Clients gleichzeitig im selben Konto auf denselben Druckern, konnte ein Dokument doppelt gedruckt werden. Jetzt übernimmt jeden Druckauftrag nur ein Client.

• Jeder Druckauftrag wird nur von einem Client übernommen — keine doppelten Belege/Etiketten.
• Automatischer Failover: ein nicht fertiggestellter Auftrag (Client-Absturz) wird wieder freigegeben und von einem anderen Client gedruckt.
• Aufträge gehen an den Client mit dem passenden Drucker (bei getrennten Druckern je Rechner).

Version 0.0.0.167 — Spaltenbreiten in allen Listen frei anpassbar und gespeichert

In den Listenansichten (Artikel, Bestellungen, Rechnungen, Eingangsrechnungen, Kunden, Abonnements) ließen sich Spalten zwar ein-/ausblenden und neu anordnen — aber die Breite konnte man nicht selbst bestimmen. Lange Inhalte wie Lieferantennamen oder Beträge wurden abgeschnitten oder verschwendeten Platz.

• Spaltenbreite per Maus ziehen: Am rechten Rand jeder Spaltenüberschrift lässt sich die Breite direkt mit der Maus anpassen.
• Geräteübergreifend gespeichert: Die eingestellten Breiten merkt sich BIS ERP pro Benutzer — genau wie Sichtbarkeit und Reihenfolge der Spalten. Am nächsten Tag oder an einem anderen Gerät sind sie sofort wieder da.
• Gilt für alle Listen: Artikel, Bestellungen, Rechnungen, Eingangsrechnungen, Kunden und Abonnements. Die Eingangsrechnungs-Liste lässt sich jetzt zusätzlich ein-/ausblenden und umsortieren.
• Zurücksetzen mit einem Klick: Über „Spalten zurücksetzen" im Spalten-Editor kehren Sichtbarkeit, Reihenfolge und Breite gemeinsam zum Standard zurück.

Version 0.0.0.133 — GoBD: Rechnungen unveränderbar archiviert (revisionssicher)

Finalisierte Rechnungen wurden bisher als PDF nur im Arbeitsspeicher des Servers abgelegt — bei jeder System-Aktualisierung gingen diese Dateien verloren.

• Eingefrorenes Belegbild: Beim Finalisieren wird das verwendete Layout (Vorlage, Ränder, Texte), das Branding (Firmen-/Bankdaten) und das Logo als Bild dauerhaft mit der Rechnung eingefroren. Ein späterer Wechsel von Vorlage, Logo oder Bankdaten ändert bereits ausgestellte Rechnungen nicht mehr.
• Revisionssichere Ablage: Die fertige Rechnungs-PDF wird verschlüsselt-privat in einem dauerhaften Cloud-Speicher abgelegt (überlebt System-Updates) und beim Download unverändert ausgeliefert — inkl. SHA-256-Prüfsumme.
• Lesen verändert nichts mehr: Das Anzeigen/Herunterladen (einzeln oder als ZIP), der E-Mail-Versand und der Druck liefern immer das identische ursprüngliche Belegbild — ohne den Datensatz zu verändern.
• Bestandsrechnungen: Ein einmaliger Backfill sichert vorhandene Rechnungs-PDFs originalgetreu in die dauerhafte Ablage.

Version 0.0.0.132 — Rechnungs-PDF: korrekter QR-Überweisungsbetrag + Stabilitäts-Fixes

Bei einer Tiefenprüfung des Rechnungs-Designers (GoBD/Korrektheit/Usability) sind drei konkrete Fehler aufgefallen:

• GiroCode-QR mit exaktem Betrag: Der QR-Code kodiert jetzt immer den korrekten Rechnungsbetrag (inkl. Cent, auch über 1.000 €).
• Kein Leer-Speichern mehr: Beim Speichern, Duplizieren und Migrieren von Vorlagen wird ein leeres Layout automatisch mit dem Werks-Layout aufgefüllt.
• Saubere Fehlermeldungen bei Werks-Reset und Layout-Modus statt technischer Fehlerseite.

Version 0.0.0.131 — Rechnungs-PDF: PayPal-Zahllink, Status-Stempel & klickbare Links

Als digitale Zahloption bot die Rechnung nur den SEPA-GiroCode.

• PayPal-Zahllink: Ist unter Einstellungen → Unternehmen → Bankverbindung ein PayPal-Zahllink hinterlegt (PayPal.Me-Adresse wie paypal.me/meinefirma oder PayPal-E-Mail), erscheint auf der Rechnung ein klickbarer „Schnell & sicher mit PayPal bezahlen"-Block samt QR-Code — Betrag und Verwendungszweck sind vorausgefüllt. Bei bereits bezahlten oder stornierten Rechnungen wird der Zahllink automatisch ausgeblendet (Schutz vor Doppelzahlung) — genau wie der GiroCode.
• Status-Stempel: Je nach Rechnungsstatus zeigt das PDF einen dezenten, diagonalen Stempel — BEZAHLT (grün), STORNIERT (rot) oder ÜBERFÄLLIG (orange).
• Fälligkeit prominent: „Fällig am TT.MM.JJJJ" steht jetzt gut sichtbar neben dem Endbetrag. Skonto-Hinweis und Leistungszeitraum werden — sofern hinterlegt — automatisch ergänzt.
• Klickbare Links: E-Mail-Adresse und Website im Fußbereich öffnen direkt das Mailprogramm bzw. die Website.
• Einheitliches Datumsformat: Alle Datumsangaben erscheinen im deutschen Format (TT.MM.JJJJ).
• Designer-Erweiterung: Zwei neue Elemente „PayPal-Zahllink" und „Status-Stempel" stehen im Rechnungs-Designer bereit; die Live-Vorschau zeigt auf Wunsch auch, wie eine bezahlte/stornierte/überfällige Rechnung aussieht.

Version 0.0.0.130 — Kassen-Rechnung bei JTL: kein Beleg geht mehr verloren

Wenn ein Kunde an der Kasse „auf Rechnung" kaufte und der Betrieb eine JTL-Anbindung hatte, ging BIS ERP davon aus, dass JTL die Rechnung automatisch erstellt und an den Kunden liefert — und unterdrückte deshalb den eigenen Rechnungsdruck.

• BIS ERP überspringt den eigenen Rechnungsdruck jetzt nur noch dann, wenn in der JTL-Anbindung tatsächlich ein Rechnungs-Workflow hinterlegt ist (der die JTL-Rechnung erzeugt und zustellt). Fehlt dieser Workflow, stellt die Kasse / BIS ERP die Rechnung wieder selbst aus — kein Kunde bleibt ohne Beleg.
• Die saubere DATEV-Trennung bleibt unverändert: Jeder Vorgang wird weiterhin nur einmal gebucht (POS-Erlöse über den POS-Export, Rechnungskäufe über JTL bzw. die Rechnung — nie doppelt). Gegenstück in der Kasse (POS 1.1.22): Der lokale DATEV-Export der Kassen-App zählt Rechnungskäufe (Zahlart „Rechnung") nicht mehr als Barumsatz mit — sie gehören als Forderung ins Rechnungs-/Warenwirtschaftssystem. Das verhindert eine doppelte Umsatzbuchung zwischen Kassen-Export und JTL. Technisch: PosInvoiceController::jtlDeliversPosInvoice verlangt jetzt invoiceWorkflowId IS NOT NULL für den „JTL-primär"-Pfad. Fail-safe: im Zweifel liefert BIS ERP selbst. Details: docs/audit/POS_KASSENKUNDE_RECHNUNG_WALKTHROUGH.md §7.

Version 0.0.0.129 — Neuer EU-Widerrufsbutton für Shopify + Bridge ins Retourenmodul

Ab dem 19.06.2026 verlangt die EU (Richtlinie 2023/2673) von B2C-Online-Shops eine echte Widerrufsfunktion: einen gut sichtbaren „Vertrag widerrufen"-Button mit zweistufiger Bestätigung, der automatisch eine Eingangsbestätigung mit exaktem Zeitstempel an den Kunden schickt.

• Eigenständige Shopify-App „BISWiderruf": rechtskonformer Button als Theme-Block, zweistufiges Formular (nur Name, Bestellnr., E-Mail — gesetzeskonform), automatische Eingangsbestätigung per E-Mail inkl. PDF und Zeitstempel, Händler-Benachrichtigung, Verwaltung mit Audit-Log.
• Bridge ins BIS-ERP-Retourenmodul: Jeder bestätigte Widerruf kann automatisch als Retoure in Ihrem Mandanten landen — Sie bearbeiten Widerruf, Retoure und Erstattung an einem Ort. Die Pflicht-E-Mail an den Kunden bleibt einmalig (keine Doppel-Mail).
• Premium-Option: Versand der Bestätigungen über Ihr eigenes SMTP (eigene Absenderdomain) ist als kostenpflichtiges Premium-Feature freischaltbar.
• Optionale Bestellnummern-Prüfung: Auf Wunsch gleicht die App die angegebene Bestellnummer mit Ihrem Shopify-Shop ab und markiert den Widerruf als „verifiziert" oder „nicht gefunden" — rein informativ zur Triage, der Widerruf wird nie blockiert.

Version 0.0.0.128 — Rechnungs-PDF: Steuer-Block, Käuferblock & Adressen vollständig

Auf finalisierten Rechnungen (besonders aus Kassen-Verkäufen) blieben Felder leer, obwohl die Daten vorhanden waren: Der Steuer-Block zeigte „MwSt.

• Steuer-Block wird korrekt befüllt: Die Umsatzsteuer wird jetzt pro Steuersatz aus den Positionen aufgeschlüsselt — „MwSt. gesamt" zeigt den echten Betrag, und es erscheinen nur die tatsächlich vorkommenden Sätze.
• Käufer & Adressen vollständig: Käufername, PLZ, Kundennummer, USt-IdNr. und Auftragsnummer werden zuverlässig gezogen. Leere Adressfelder erzeugen keinen „, , , DE"-Salat mehr.
• Kassen-Laufkunde sauber: Bei Barverkäufen ohne Kundenadresse steht nur noch „Laufkunde" — kein leerer Adressblock.
• Zahlungsbedingungen werden als Text ausgegeben (inkl. Skonto-Hinweis, falls hinterlegt).
• Bearbeiter zeigt den Mitarbeiternamen statt der Login-E-Mail.
• Firmendaten im Kopf/Footer greifen jetzt zusätzlich auf die in der Rechnung gespeicherte Absenderadresse zurück, falls die Unternehmens-Einstellungen lückenhaft sind.

Version 0.0.0.125 — Designer-UX: „+ Neue Vorlage" befüllt sofort, Werks-Vorlage löschbar (mit Auto-Reseed)

Zwei Stolpersteine im Invoice-Designer: 1.

• „+ Neue Vorlage" befüllt sofort: Backend erkennt leere elements-Arrays und befüllt mit dem aktuellen Werks-Builder + Tenant-Appearance-Settings (Akzentfarbe, Land-Steuersätze, Logo-Auto-Befüllung). User sieht direkt nach dem Speichern das volle Layout, kann bearbeiten/löschen wie eine eigene Vorlage.
• Header-Default 85 mm (DIN-5008 Form B konform) statt 60 mm — beim Anlegen einer neuen Vorlage sitzt der Adressblock direkt richtig für DIN-Lang/C4-Briefumschlag-Fenster.
• Werks-Vorlage löschen ist jetzt möglich — der DELETE-Endpoint erkennt isFactory=1 und seedet sofort eine neue Werks-Vorlage. Effektiv „Reset auf Werkseinstellungen". Response liefert reseeded: true + Hinweistext.
• Frontend lädt das Template nach Save neu — damit die vom Backend ergänzten Default-Elemente sofort im Designer sichtbar sind, ohne Reload.
• Factory-Reset-Button im Erscheinungsbild-Panel: State wird vorher auf null gesetzt, sodass loadTemplates die neue Vorlage tatsächlich lädt (vorher hing die alte gelöschte ID im State).

Version 0.0.0.124 — Bestellübersicht: keine Doppel-Rechnung mehr, stattdessen „Rechnung ausgeben"

In der Bestellübersicht erschien beim Markieren einer Bestellung in der Aktionsleiste unten immer der Button „Rechnung" — auch dann, wenn für die Bestellung längst eine Rechnung erstellt war.

• Hat eine markierte Bestellung bereits eine Rechnung, wird der „Rechnung"-erstellen-Button ausgeblendet.
• Stattdessen erscheint „Rechnung ausgeben" — ein Klick lädt die vorhandene Rechnung direkt herunter (einzelne Bestellung als PDF, mehrere als ZIP).
• Bei gemischter Auswahl (einige mit, einige ohne Rechnung) sind beide Buttons sichtbar: „Rechnung" legt nur für die offenen an, „Rechnung ausgeben" lädt nur die bereits vorhandenen. Das Verhalten entspricht jetzt der Einzel-Zeilenaktion und dem Rechtsklick-Menü, die schon länger zwischen Erstellen und Herunterladen unterscheiden.

Version 0.0.0.123 — JTL-Doppelungs-Schutz bei Rechnungskauf an der Kasse

Wenn ein Tenant JTL nutzt UND ein Kassenkunde wählt „Rechnungskauf" UND der Kassierer aktiviert zusätzlich den DIN-A4-Toggle, entstanden zwei Rechnungen mit unterschiedlichen Nummern für denselben Vorgang: eine aus BIS ERP (RE-2026-…) und eine aus dem JTL-Workflow (eigene JTL-Nummer).

• Automatische Erkennung der Konstellation: posTransactions.isInvoicePayment=1 + mindestens eine aktive jtlConnections-Zeile.
• BIS-ERP-Rechnung wird trotzdem erzeugt — für Audit-Konsistenz, Backoffice-Sichtbarkeit und einheitlichen Datenbestand. Damit fehlen im BIS-ERP keine Belege mehr für JTL-Rechnungskäufe.
• Markierung im Notizen-Feld: internal_notes='Rechnungsdruck via JTL — interne Beleg-Dokumentation. Kunde erhält die JTL-Rechnung'. Der Steuerberater sieht sofort, dass das nur ein Audit-Beleg ist, keine Kunden-Auslieferung.
• Versand an den Kunden blockiert: — POST /pos/transactions/{saleId}/invoice/email → 412 mit klarem Hinweis — POST /pos/transactions/{saleId}/invoice/bisprint → 412 mit klarem Hinweis — GET .../invoice.pdf liefert das PDF (Audit/Backoffice), setzt aber Response-Header X-Invoice-JTL-Primary: 1
• POS-App-Hook überspringt den lokalen Druck wenn der Header gesetzt ist (fetchPosInvoicePdfWithMeta). Der Kunde bekommt nur die JTL-Rechnung — kein Doppel-Druck.
• DATEV-Trennung bleibt sauber: POS-DATEV filtert Rechnungskauf raus (isInvoicePayment=0), Invoice-DATEV filtert POS-Rechnungen raus (source!='pos'), JTL bucht 1×. Tenants ohne JTL-Anbindung sind nicht betroffen — alle Pfade laufen wie bisher, BIS ERP liefert die Rechnung normal aus.

Version 0.0.0.122 — Versand-Workflows: Bestellungen & Rechnungen per E-Mail, PDF (ZIP) oder BISPrint

Das Bestellungs-Kontextmenü hatte nur eine Handvoll Aktionen — „Bestellung per E-Mail an Kunden senden" gab es überhaupt nicht.

• Bestellungs-Kontextmenü um „Pickliste erstellen" und „Bestellung per E-Mail senden" erweitert. E-Mail-Versand resolved Empfänger automatisch aus Liefer- oder Kunden-E-Mail-Adresse, Bestell-PDF im Anhang.
• Modaler Rechnungs-Dialog zeigt jetzt nicht mehr nur „Entwurf vs. Finalisiert", sondern Checkboxen für Folgeaktionen: per E-Mail an Kunden, PDF herunterladen, über BISPrint drucken. Bei Bulk-Erstellung wird ein ZIP-PDF aller erzeugten Rechnungen generiert, alle E-Mails / Druckaufträge laufen parallel.
• Bulk-Bar in Bestellungen erweitert um drei Buttons: „E-Mail" (eine Mail pro Kunden), „PDF (ZIP)" (Sammel-Download), „Drucken" (über BISPrint).
• Rechnungsliste hat jetzt Mehrfachauswahl: Checkbox pro Zeile, „alle auf Seite"-Checkbox im Header. Sticky Bulk-Bar mit Versenden, ZIP-PDF, Drucken, Bezahlt markieren, Sammel-Stornierung mit gemeinsamem Grund.
• Neue Backend-Endpoints: POST /orders/{id}/send-email, POST /orders/batch/pdf, POST /invoices/batch/pdf. POST /invoices/{id}/send-email resolved Empfänger jetzt automatisch aus buyer_address.email, wenn nicht explizit übergeben.
• Pro Beleg ein eigener Audit-Log-Eintrag — saubere GoBD-Spur auch bei Bulk-Versand.

Version 0.0.0.121 — Tenant-Logo-Upload, TSE-Counter-Nachlieferung, Reactive BISPrint-Probe, End-to-End-Walkthrough

Vier zusammenhängende Lücken im POS-DIN-A4-Workflow: das Firmenlogo konnte ein Tenant nur über den SuperAdmin-Bereich hochladen (gar kein Zugang für Tenants!), die TSE-Counter wurden mit null synct (Counter/Serial/ClientId erst nach dem Sync verfügbar — der TSE-Block auf der Rechnung zeigte „—"), die BISPrint-Checkbox war immer aktiv auch ohne Client (User klickte und bekam 412-Fehler), und es gab keine Schritt-für-Schritt-Anleitung für den Ersttest.

• Tenant-Logo-Upload unter Einstellungen → Allgemein → Unternehmen → Firmenlogo. Drag-and-Drop oder Klick, akzeptiert JPEG/PNG/WebP/SVG bis 5 MB, Upload nach DigitalOcean Spaces mit Hash-Suffix gegen Browser-Cache. URL landet in tenant_settings.company.logoUrl. Kein SuperAdmin-Zugang mehr nötig.
• Logo-Prioritätsreihenfolge im Renderer: erst Tenant-eigenes Logo (company.logoUrl), dann historischer Fallback auf system.companyLogoUrl. Bestehende SuperAdmin-Logos bleiben aktiv bis ein Tenant-eigenes hochgeladen wird.
• TSE-Counter-Nachlieferung: Neuer Endpoint POST /pos/transactions/{saleId}/tse-data reicht Signatur-Zähler, Serial-Number, Client-ID und QR-Code-Daten nach TSE-Finalize an die POS-Transaktion und automatisch auch an eine evtl. existierende DIN-A4-Rechnung. POS-App ruft das nach jedem TSE-Sign im SalesViewModel.
• Reactive BISPrint-Probe in der POS-App: Beim Start prüft die App GET /bisprint/status. Nur wenn mindestens ein BISPrint-Client online ist (clientsOnline > 0), wird der BISPrint-Pfad verfügbar gemacht. Sonst wählt das System automatisch den lokalen Android-Drucker — kein User-Frust mehr durch 412-Errors.
• End-to-End-Walkthrough-Doku unter docs/audit/POS_KASSENKUNDE_RECHNUNG_WALKTHROUGH.md. Schritt-für-Schritt: Tenant-Setup, Verkauf, technischer Hintergrund, Verifikation, Storno-Workflow, DATEV-Übersicht, Troubleshooting.

Version 0.0.0.119 — Tenant-eigene SMTP-Einstellungen + System-Fallback auf [email protected]

Tenants konnten gar keine eigenen SMTP-Daten hinterlegen — es gab nur eine Master-SMTP-Konfiguration, die der SuperAdmin pflegte und die sich alle Tenants teilten.

• Neue Sektion „E-Mail & SMTP" unter Einstellungen → Allgemein. Pro Tenant individuelle SMTP-Daten: — Host, Port, Benutzer, Passwort, Verschlüsselung (TLS/SSL/Keine) — Absender-Adresse + Name — Reply-To (optional) — Toggle „Eigene SMTP-Konfiguration aktivieren" — aus = System-Fallback — „Test-Mail senden"-Button der die Konfig sofort prüft (auch mit ungespeicherten Werten)
• Sicheres Passwort-Handling: Passwort wird beim GET niemals zurückgeliefert (nur passwordSet: bool). Beim Speichern bedeutet ein leeres Feld „bestehendes Passwort beibehalten".
• **System-Fallback auf [email protected]:** Wenn ein Tenant keine eigene SMTP-Konfig aktiv hat, läuft der Mailversand automatisch über die zentral gepflegte Master-SMTP (Default: purpose=system mit [email protected]). Damit kann jeder Tenant ab dem Onboarding Rechnungen mailen, ohne erst eigene SMTP-Daten einzurichten.
• Klares UI-Banner im Settings-Panel wenn der System-Fallback aktiv ist: „Empfänger sehen die System-Adresse statt Ihrer eigenen — aktivieren Sie unten Ihre eigene Konfiguration, um das zu ändern."
• Neue API-Endpoints unter /email-settings/smtp: — GET → Settings + Fallback-Status — POST → Speichern (mit Validation von E-Mail-Adressen + Encryption-Auswahl) — POST /test → Test-Mail senden mit optionalem Override

Version 0.0.0.118 — Steuerblock zeigt nur die tatsächlich vorkommenden Sätze

Mit 0.0.0.117 wusste der Steuerblock, welche Sätze landesüblich sind (DE 19/7, FR 20/10/5,5/2,1 usw.) — aber er hat sie alle angezeigt, auch wenn die Rechnung nur einen davon nutzte.

• **Neuer Element-Typ taxSummaryBlock: Der Renderer entscheidet zur Render-Zeit** anhand der tatsächlichen vatSummary der Rechnung, welche Spalten gezeigt werden. Default showOnlyUsedRates: true. — DE-Rechnung mit nur 19 % → 4 Spalten (Netto 19 % / 19 % MwSt. / MwSt. gesamt / Rechnungsbetrag) — DE-Rechnung mit 19 % + 7 % → 6 Spalten (wie vorher) — FR-Rechnung mit 20 % + 10 % → 6 Spalten (statt 10) — IT-Rechnung mit allen 4 Sätzen → 10 Spalten mit verkleinerter Schrift
• Schriftgröße passt sich automatisch an die Spaltenanzahl an (8 pt bei 1-2 Sätzen, 7 pt bei 3, 6,5 pt bei 4+).
• Builder-Layout deutlich schlanker: Statt 12+ statischer Spalten-Elemente jetzt EIN taxSummaryBlock-Element mit availableRates-Pool. Designer-Vorschau zeigt die verfügbaren Sätze als Übersicht.
• **Property availableRates** ist editierbar: Wer aus Sonderfällen heraus für eine bestimmte Vorlage feste Spalten haben will (z. B. interne Templates mit fixierter Aufschlüsselung), schaltet showOnlyUsedRates: false und der Block zeigt alle Pool-Sätze.

Version 0.0.0.117 — Werks-Vorlage international: 31 Länder-Steuersätze, Logo aus Company-Settings, DIN-676-Faltmarken

Mit 0.0.0.116 saß das Layout sauber im DIN-Lang-Fenster, aber drei Themen waren noch offen: die Steuersätze waren hartcodiert auf DE (19 %/7 %) — französische, österreichische oder schweizer Tenants sahen die falschen Labels.

• Steuersätze für 31 Länder automatisch erkannt aus der Tenant-Firmenanschrift. Pro Land werden die landesüblichen Sätze in den Spalten des Steuerblocks erkannt: — DE: 19/7 · AT: 20/13/10 · FR: 20/10/5,5/2,1 · IT: 22/10/5/4 · ES: 21/10/4 · NL: 21/9 · BE: 21/12/6 · LU: 17/14/8/3 · PT: 23/13/6 · PL: 23/8/5 · CZ: 21/15/10 · DK: 25 · SE: 25/12/6 · FI: 25,5/14/10 · IE: 23/13,5/9 · GR: 24/13/6 · HR: 25/13/5 · HU: 27/18/5 · BG: 20/9 · CY: 19/9/5 · EE: 22/9 · LT: 21/9/5 · LV: 21/12/5 · MT: 18/7/5 · RO: 19/9/5 · SI: 22/9,5/5 · SK: 23/10/5 — plus CH 8,1/3,8/2,6 · GB 20/5 · NO 25/15/12 · TH 7 %. — Bei 1 Satz: 4 Spalten. Bei 2 Sätzen: 6 Spalten (wie bisher). Bei 3 Sätzen: 8 Spalten. Bei 4 Sätzen: Schriftgröße schrumpft auf 6,5 pt, alle Spalten passen weiter in eine Zeile. — Land-Override im Designer-Appearance-Panel — wer für einen speziellen Use-Case andere Sätze braucht, kann manuell wählen.
• Logo automatisch aus den Company-Settings: Das Image-Element im Briefkopf trägt jetzt den Placeholder company.logo — der Renderer holt das Logo direkt aus tenant_settings.system.companyLogoUrl. Wer es schon hochgeladen hat (z. B. für die Social-Media-Posts), bekommt es automatisch auf der Rechnung. Wer eines hochladen will: /app/admin/social-media → Konfiguration → Logo. — Unterstützte Quellen: lokaler Pfad, data:image/...;base64,xxx, HTTPS-URL (z. B. DigitalOcean Spaces — wird mit 4s-Timeout heruntergeladen).
• DIN-676 Faltmarken + Lochmarke: Drei dezente Striche am linken Rand bei 105 mm (1. Falt), 148,5 mm (Lochmarke) und 210 mm (2. Falt). Macht das saubere Falten für DIN-Lang-Briefumschläge fehlerfrei. Toggle im Appearance-Panel.

Version 0.0.0.116 — Werks-Vorlage DIN-5008-konform: Adressfenster, Spalten überarbeitet, PDF-Auto-Regenerate

Mit 0.0.0.115 war die Werks-Vorlage gut aufgestellt, hatte aber drei spürbare Probleme: der Adressblock saß zu weit oben (passte nicht in DIN-Lang- oder C4-Fenster-Briefumschläge), die Positionstabelle zeigte „Artikelnummer" (zu lang, schnitt das Bezeichnungs-Feld ab) und hatte eine Hersteller-Spalte, die kaum jemand braucht.

• Adressblock nach DIN 5008 Form B — Anschrift sitzt jetzt bei 45-85 mm von der Papier-Oberkante und 20 mm vom linken Rand. Passt in Standard-DIN-Lang-Briefumschläge (110×220 mm) mit Sichtfenster und in C4-Umschläge ohne Knicken/Verrutschen. Rücksendezeile auf 28 mm (kleine graue Zeile).
• Header höher (85 mm statt 60 mm): schafft den nötigen Platz für den DIN-konformen Adressblock plus Logo/Titel/Meta-Box rechts daneben.
• Spalten überarbeitet: — „Artikelnummer" → kurz: „SKU" — Hersteller-Spalte entfernt (war meist leer) — Bezeichnung deutlich breiter (78 mm statt 60 mm — keine abgeschnittenen Namen mehr) — „Einzelpreis netto" + „Gesamt brutto" statt nur Netto (so wie's der Kunde später auf der Banking-App vergleicht)
• PDF Auto-Regenerate-Fallback: Wenn der Download-Endpoint feststellt, dass pdf_path leer ist oder die Datei nicht mehr existiert (typisch nach Deploy mit flüchtigem Storage), wird das PDF on-the-fly neu gerendert und ausgeliefert. Keine 404er mehr für finalisierte Rechnungen.
• **Expliziter POST /invoices/{id}/regenerate-pdf-Endpoint:** Backoffice-Power-User können das Neu-Rendern manuell triggern — z. B. um alte Rechnungen auf das neue Layout zu aktualisieren.
• Billing-Overview wird wieder lädefähig: Statt 500 bei einem Service-Ausfall liefern wir 200 mit partiellen Daten plus _partial: true + _errors-Block für Debugging.
• „Werks-Vorlage neu erstellen"-Button im Designer-Appearance-Panel — nach einem BIS-ERP-Layout-Update kann der Tenant die Vorlage auf den aktuellen Stand zurücksetzen. User-bearbeitete eigene Vorlagen bleiben unangetastet.
• Steuerblock-Aliase: extractVatRow erkennt jetzt sowohl net/vat als auch base/amount/subtotal/taxAmount als vatSummary-Feldnamen — alte und neue Rechnungen rendern korrekt. Logo einfügen: Im Designer das Image-Element auswählen (Briefkopf rechts oben, 60×22 mm) → Property-Panel rechts → Bild-URL oder Upload setzen. Logo-Auto-Befüllung aus Company-Settings ist als nächste Iteration vermerkt.

Version 0.0.0.115 — Werks-Vorlage näher am klassischen Geschäftsbrief: Barcode, Rückfrage-Hinweis, Tenant-Akzentfarbe, optionales „AN"-Label

Mit 0.0.0.114 war das moderne A4-Standardlayout in trockenen Tüchern, aber drei Klassiker fehlten noch: der Code128-Barcode der Rechnungsnummer (Pickerei/Versand-Workflow), der traditionelle Hinweis „Bitte bei allen Rückfragen angeben!" und die Möglichkeit, die Akzentfarbe pro Tenant zu wählen — das Layout war fest auf dunkles Blau eingestellt, obwohl manche Tenants ein orangefarbenes Logo (z.

• Barcode (Code128) der Rechnungsnummer zwischen Logo und Titel im Briefkopf — Pickerei-Mitarbeiter scannen die Rechnung und der Beleg ist sofort dem System zugeordnet. Auch EAN-13, Code 39 und UPC-A wählbar, falls die Tenant einen anderen Industrie-Standard nutzt.
• „Bitte bei allen Rückfragen angeben!" als klassischer grauer Hinweis unter der Meta-Box rechts oben.
• Tenant-spezifische Akzentfarbe (tenant_settings.invoiceDesign.accentColor) — Default dunkelblau, im Designer per Farbpicker änderbar. Wirkt auf die Linie unter dem Logo und auf den Endbetrag in der Steuerleiste.
• „AN"-Label vor Empfänger als optionaler Toggle — moderne UI bevorzugt es, klassische Geschäftsbriefe und die asia-in/myasia-Vorlage haben es nicht. Beim Ausschalten rückt der Empfänger-Block 4 mm nach oben.
• Auto-Reseed: Wer die Akzentfarbe oder einen Stil-Toggle ändert, bekommt die Werks-Vorlage automatisch neu gebaut — kein manuelles „Auf Werkseinstellung zurücksetzen" nötig. User-bearbeitete Vorlagen (mit isFactory=0) bleiben unangetastet.
• Neues Designer-Element „Barcode" im Sidebar-Element-Pool (zusätzlich zu QR-Code) — auch in eigenen Templates platzierbar mit Typ-Auswahl + Datenfeld-Konfiguration.

Version 0.0.0.114 — Modernes A4-Standardlayout für alle Dokumente, optional ein gemeinsames Layout für Rechnung/Lieferschein/Auftragsbestätigung/Gutschrift/Angebot/Mahnung/POS

Die Factory-Vorlagen für die A4-Dokumente waren funktional, aber gestalterisch nicht zeitgemäß: einfaches links/rechts-Header-Layout, unauffällige Trennlinien, kein eigener Steuerblock, kein GiroCode, keine ZUGFeRD-Hinweise.

• Ein modernes A4-Standardlayout mit klaren Sektionen — angelehnt an gut etablierte Geschäftsbrief-Vorlagen, aber visuell aufgeräumt: Mini-Absender-Zeile oben, klar abgesetzter Empfänger-Block links, Logo-Bereich rechts oben mit dezenter Akzent-Linie, Titel gesperrt, Meta-Box mit Label/Wert-Paaren und Trennlinien zwischen den Zeilen.
• Kompakter Steuerblock in einer Zeile: Eine Tabelle Netto 7 % · 7 % MwSt. · Netto 19 % · 19 % MwSt. · MwSt. gesamt · Rechnungsbetrag — der Endbetrag rechts in Akzentfarbe hervorgehoben. Spart Platz und ist visuell prägnant.
• GiroCode QR-Code für Sepa-Überweisung optional rechts neben dem Steuerblock (Rechnung + Mahnung) — Kunden scannen mit der Banking-App und die Überweisung ist fertig vorausgefüllt.
• 4-Spalten-Footer: Adresse · Kontakt · Steuer-/USt-ID/HRB/GF · Bank — plus ZUGFeRD-Hinweis und Seitenzahl unten.
• TSE-Block automatisch im Footer der POS-Rechnung (KassenSichV-konform).
• GLOBALES LAYOUT (neu, Default für neue Tenants): Eine gemeinsame Vorlage für ALLE A4-Dokumente. Wer das Logo, den Briefkopf oder die Akzentfarbe ändert, ändert es für Rechnung, Lieferschein, Auftragsbestätigung, Gutschrift, Angebot, Mahnung und POS-Rechnung gleichzeitig. Titel, Hinweistext und sichtbare Spalten passen sich pro Dokumenttyp automatisch an.
• Toggle „Globales A4-Layout verwenden" im Designer: Tenants, die für einzelne Dokumenttypen (z. B. die Mahnung) ein völlig anderes Layout wollen, schalten den Toggle aus und pflegen pro Typ eine eigene Vorlage wie bisher.

Version 0.0.0.113 — DIN-A4-Rechnung jetzt auch über BISPrint (USB, Netzwerk, Bluetooth)

Mit 0.0.0.112 stand der komplette DIN-A4-Workflow: Toggle in der Kasse, automatisches Drucken auf einem lokalen A4-Drucker am POS-Tablet (Android Print Manager), Mail-Versand und Backoffice-Button.

• DIN-A4-Rechnung über BISPrint: Pro Verkauf kann zusätzlich (oder anstelle des lokalen Druckers) ein BISPrint-Drucker angesteuert werden. Funktioniert mit: — USB-Druckern (Windows-Client nutzt Windows Print Spooler — alle Treiber-installierten Drucker werden erkannt, auch USB-A4 und USB-Bondrucker) — Netzwerkdruckern via IP (TCP Port 9100 — sowohl Windows- als auch Android-Client) — Bluetooth-Druckern (Android-Client mit BT-SPP-Profil)
• Toggle erweitert: Im Zahlungs-Dialog gibt es jetzt eine dritte Checkbox „Über BISPrint-Drucker" zusätzlich zu „A4-Drucker (lokal)" und „E-Mail". Alle Kombinationen erlaubt.
• Backoffice-Modal: Im Kassenjournal-Modal jetzt drei Buttons statt zwei — „PDF anzeigen", „An BISPrint-Drucker senden" (NEU), „Per E-Mail senden". Tenants ohne BISPrint-Konfiguration bekommen eine klare Fehlermeldung mit Verweis auf die Einstellungen.
• Neuer Endpoint: POST /pos/transactions/{saleId}/invoice/bisprint legt den Druck-Job in die BISPrint-Queue (Body optional: copies, priority, printerName für abweichenden Drucker).
• Drucker-Mapping über das bestehende Tenant-Setting tenant_settings.bisprint.printerMapping['posInvoice']. Fallback: erster aktiver BISPrint-Client + dessen Default-Drucker.
• Idempotente Rechnungs-Erzeugung: Re-Submit eines BISPrint-Jobs verbraucht keine neue Rechnungsnummer — es entsteht nur ein neuer Druck-Auftrag für dasselbe PDF.

Version 0.0.0.112 — DIN-A4-Rechnung an der Kasse: Toggle live, Backoffice-Trigger, Auto-Gutschrift bei Storno

Mit 0.0.0.111 stand der serverseitige Renderer fertig — Endpoints, Designer-Template und DATEV-Trennung waren da, aber es fehlten die Auslöser.

• POS-Checkout-Toggle „DIN-A4-Rechnung": Direkt im Zahlungs-Dialog ausklappbarer Block mit zwei Optionen: ☐ auf A4-Drucker drucken / ☐ per E-Mail an Kunden senden (Stammkunden-Mail vorausgefüllt). Default eingeklappt zu „Nur Bon" — Mainstream-Fall ohne Mehrklick.
• Automatisches Drucken / Versenden nach Sync: Sobald der Verkauf in BIS ERP angekommen ist, holt die Kasse die fertige PDF und übergibt sie an den Android Print-Dialog (PrintManager / A4PrintService) — oder löst den Mail-Versand aus. Verkauf bleibt auch bei Drucker-Offline erfolgreich; Backoffice-Button fungiert als Fallback.
• Backoffice-Button im POS-Journal: In Berichte → Kassenjournal jetzt pro Verkauf ein Button „DIN-A4". Modal mit zwei Aktionen: „PDF anzeigen / drucken" (öffnet neuen Tab) und „Per E-Mail an Kunden senden" (Adressfeld, Tenant-SMTP). Idempotent gegen den Server-Endpoint — kein neuer Rechnungsnummern-Verbrauch bei Mehrfachaufruf.
• Auto-Gutschrift bei POS-Storno: Wenn ein POS-Storno für einen Verkauf synct, der bereits eine DIN-A4-Rechnung trägt, erzeugt BIS ERP automatisch eine Gutschrift (creditNote) und markiert die Original-Rechnung als 'cancelled' — strukturell sauber, keine manuellen Klicks. Failure-silent: Sync läuft auch durch, wenn die Gutschrift-Erzeugung scheitert.
• **Invoice-Designer um tseBlock-Element erweitert:** Sidebar zeigt jetzt den Element-Typ „TSE-Block (KassenSichV)", Property-Panel mit Checkboxen für Signatur-Zähler / Serial / Client-ID / QR-Code / Compliance-Hinweis. Canvas zeigt eine Vorschau mit grauem Block, Beispiel-Daten und QR-Symbol — der Server rendert dann mit echten TSE-Daten.
• Workflow-Guide docs/guides/POS_DINA4_RECHNUNG.md — komplette Mitarbeiter- und Entwickler-Doku zum gesamten Datenfluss, allen Fehler-Cases und der Tenant-Konfiguration.

Version 0.0.0.111 — DIN-A4-Rechnung aus dem POS-Verkauf, KassenSichV-konform via Invoice-Designer

Wer aus einem POS-Verkauf eine DIN-A4-Rechnung erstellen wollte, musste den Umweg über JTL nehmen — und die JTL-Rechnung enthielt keine Bezugnahme auf die TSE-fiskalisierte Original-Transaktion.

• KassenSichV-konforme DIN-A4-Rechnung direkt aus BIS ERP — gerendert mit dem bestehenden Invoice-Designer (Logo, Briefkopf, Bankdaten, ZUGFeRD/EN16931-XML eingebettet). Neuer Element-Typ **tseBlock** im Designer zeigt TSE-Signatur-Zähler, Seriennummer, Client-ID, Zeitstempel und einen QR-Code mit den TSE-Daten — plus festen Compliance-Hinweis: „Dieser Vorgang wurde gemäß KassenSichV in der Kasse fiskalisiert. Diese Rechnung ist eine ergänzende Beleg-Ausstellung, kein zweiter Umsatzdatensatz."
• **Factory-Template posInvoice** wird beim ersten Tenant-Zugriff automatisch erzeugt — mit Bonnummer-Bezug im Briefkopf und TSE-Block im Footer. Anpassbar wie jedes andere Designer-Template.
• Strukturell ausgeschlossene DATEV-Doppelbuchung: POS-DIN-A4-Rechnungen werden als invoices.source='pos' markiert und in allen invoice-basierten DATEV-Pfaden (Export, Online-Submission, HealthCheck) per Filter ausgeschlossen. Der Erlös läuft ausschließlich über den POS-DATEV-Export aus posTransactions — wie bisher. JTL ist nicht beteiligt.
• POS-App 1.1.22 sendet ab sofort die vollständigen TSE-Daten (Signatur-Zähler, Serial, Client-ID, QR-Code) im Sync mit und transportiert per Verkauf einen Modus „nur Bon / drucken / mailen / beides". Die Detail-UI für den Toggle kommt in einem nachgelagerten 1.1.22-Sub-Drop.
• Endpoints für die POS-App: GET /pos/transactions/{saleId}/invoice.pdf (idempotent — Re-Download liefert dasselbe PDF) und POST /pos/transactions/{saleId}/invoice/email.
• Audit-Doku zur Vorlage beim Steuerberater unter docs/audit/POS_DINA4_RECHNUNG_GOBD.md — beschreibt Datenfluss, Compliance-Felder, DATEV-Trennung und gesetzliche Bezüge.

Version 0.0.0.110 — Sonderpreis-Matrix pro Verkaufskanal × Kundengruppe (bidirektional)

Sonderpreise konnten in BIS ERP nur pro Kundengruppe gepflegt werden — die Verkaufskanal-Dimension (BISpicy POS, B2B Kasse, B2C Kasse, Onlineshop, Marktplatz) fehlte komplett.

• Matrix-Editor im Artikel-Tab „Preise": Pro Verkaufskanal ein Tab (plus „Global" als Default-Tab), in jedem Tab eine Tabelle mit allen Kundengruppen. Pflegbar pro Zeile: Basispreis brutto, Sonderpreis brutto, Aktion ab/bis-Datum. Quelle pro Zeile als Badge sichtbar („JTL" / „BIS" / „BIS → JTL" wartet auf Rück-Sync / „JTL-Fehler" mit Tooltip).
• Verkaufskanal-Spiegel: Neue Tabelle jtlSalesChannels wird beim Sync aus dbo.tShop befüllt — UI lädt die Tabs daraus. Soft-Disable für Kanäle, die in JTL gelöscht werden.
• **Auto-Pflege tShopKundenGruppe:** Für jeden BIS-POS-Kanal in JTL werden alle aktiven Kundengruppen automatisch registriert. Behebt das Problem, dass im JTL-Sonderpreis-Dialog die Tabs für „B2B Kasse 1" / „B2C Kasse 1" nur eine oder gar keine Kundengruppe sichtbar zeigten.
• Geschützte Pflege: BIS-UI-Änderungen (source='manual') und ausstehende Rück-Sync-Einträge (jtlSyncStatus='pending') werden vom JTL-Pull nicht mehr überschrieben.
• Bidirektionaler Push BIS → JTL: Was im BIS-UI gepflegt wird, landet beim nächsten Sync-Lauf automatisch in JTL — Basispreis in tPreis/tPreisDetail (mit kKundenGruppe + kShop), Sonderpreis in tArtikelSonderpreis (Header pro Artikel) + tSonderpreise (Zeile pro Gruppe × Shop, mit dStart/dEnde). Löschen in BIS löscht auch in JTL. Drossel: max. 50 pending Zeilen pro Lauf.

Version 0.0.0.109 — Geister-Kundengruppen aus JTL-Sync automatisch deaktivieren

Wer in JTL eine Kundengruppe gelöscht hat, hatte ein altes Problem: die alte Gruppe blieb in BIS ERP weiter sichtbar (z.

• Orphan-Cleanup beim JTL-Pull: Kundengruppen mit Quelle jtl, die in JTL nicht mehr existieren, werden beim nächsten Sync automatisch deaktiviert (isActive=0). Sie verschwinden aus Dropdowns und der POS-Gruppen-Liste, bestehende Kunden-Zuordnungen bleiben aber erhalten (Soft-Disable statt Hard-Delete). Manuell im Tenant-Kundencenter angelegte Gruppen (source='manual') bleiben unangetastet.
• Re-Aktivierung bei Wiederkehr: Taucht eine deaktivierte JTL-Gruppe später wieder auf, wird sie beim nächsten Sync automatisch reaktiviert.

Version 0.0.0.108 — BIS Insights: Detail-Auswertungen, BI & Steuer-Exporte in einem Paket

Detail-Berichte in BIS ERP (Sales, Kunden, Artikel, Lager, Marktplätze, Gebühren, Performance) UND in der POS (Kassenjournal, UStVA, EÜR, BWA, DATEV, DSFinV-K) waren alle frei — auch für Tenants ohne Kassenlizenz.

• Zwei eigenständige Premium-Pakete, frei kombinierbar: — BIS Remote (10 €/Monat, 14 Tage gratis testen) — Remote-Steuerung der Kasse: Einstellungen, Bonvorlagen, Favoriten, Kunden zentral pflegen, mehrere Kassen verwalten. — BIS Insights (15 €/Monat, 30 Tage gratis testen) — Detaillierte Auswertungen & Statistiken: Verkaufs-/Kunden-/Artikel-/Lager-Reports, Marktplatz-Performance, Gebühren-Analyse, ABC, RFM, Trends. Plus ALLE POS-Berichte (Kassenjournal, UStVA, EÜR, BWA, DATEV-Export, DSFinV-K) und unbegrenzte Cloud-Historie. Vertieft sich kontinuierlich Richtung BI — ein Pro-Tier mit Forecasts, AI-Insights und Jera/JTL2DATEV-Integration ist geplant.
• Standalone buchbar — kein Voraussetzungs-Bündel: wer nur Berichte+Buchhaltung will, braucht KEIN BIS Remote; wer nur mehrere Kassen verwalten will, braucht KEIN Insights. Beide zusammen = 25 €/Monat.
• Dashboard-Quickviews bleiben frei — die schnellen KPI-Übersichten auf der BIS-ERP-Startseite und im Kundencenter bleiben für alle Tenants kostenlos. Erst beim Sprung in detaillierte Auswertungen greift das Gate.
• Monatlich kündbar, keine Mindestvertragslaufzeit. Stripe-Subscription mit nativem trial_period_days — kein Coupon-Trick.
• Re-Upload bei Aktivierung: Wer BIS Insights später bucht, dessen POS-App lädt die lokale Sales-Historie automatisch im Hintergrund nach — kein Datenverlust, kein Manuell-Aufwand.
• Bestandskunden behalten alles: Tenants mit aktiver „BIS Remote Accounting"-Lizenz (Vorgänger-Name) bleiben transparent freigeschaltet — das System hält den Legacy-productCode als Alias.

Version 0.0.0.107 — Gebinde kommen jetzt aus der JTL-Gebindeverwaltung (nicht mehr nur über Funktionsattribute)

Gebinde wurden vorrangig über Funktionsattribute (bis_gebinde_*) erkannt.

• Native Gebinde-Quelle: BIS ERP liest die Gebinde jetzt direkt aus der JTL-Gebindeverwaltung (tGebinde). Das deckt alle Artikel ab, ohne dass Funktionsattribute angelegt werden müssen.
• Preis automatisch: Da die JTL-Gebindeverwaltung keinen Gebindepreis kennt, wird er automatisch hochgerechnet (Einzelpreis × Menge, je Kundengruppe). Vorhandene Funktionsattribut-Preise gelten weiterhin als Override, und manuelle Gebindepreise in BIS ERP haben Vorrang.
• Funktioniert ohne JTL: Gebinde lassen sich auch ganz ohne JTL direkt in BIS ERP pflegen (Artikeldetails → Gebinde) — diese bleiben beim Sync unangetastet.

Version 0.0.0.106 — Mindestabnahme pro Kundengruppe + gekoppeltes Tray-/Stückpreis-Popup

Es gab keine Möglichkeit, eine Mindestabnahme je Kundengruppe zu hinterlegen (z.

• Mindestabnahme pro Kundengruppe: In den Artikeldetails (Bereich „Mindestabnahme pro Kundengruppe") lässt sich je Kundengruppe eine Mindestabnahme und ein optionales Abnahmeintervall pflegen. Wird bidirektional mit der JTL-Wawi abgeglichen (native Tabelle, keine Funktionsattribute).
• Kasse setzt die Mindestabnahme durch: Liegt die gescannte Menge darunter, zeigt die Warenkorbzeile einen roten Hinweis und beim Abschluss erscheint eine Sperre mit den Optionen „Auf Mindestmenge erhöhen", „Trotzdem verkaufen" (Berechtigung) oder „Abbrechen".
• Gekoppeltes Tray-/Stückpreis-Popup (Kasse): Beim Antippen des Preises einer Gebinde-Position rechnen Stück- und Tray-Preis (netto) automatisch ineinander — Tray ändern → Stückpreis, Stückpreis ändern → Tray.

Version 0.0.0.105 — Kundengruppen- und Staffelpreise: immer der richtige Preis an der Kasse

Hatte ein Artikel je Verkaufskanal (z.

• Eindeutiger Preis: Die Kasse erhält jetzt zuverlässig den JTL-Global-Preis je Kundengruppe — bei Kundengruppen- wie bei Staffelpreisen. Kein versehentlich übernommener kanal-spezifischer Wert mehr.

Version 0.0.0.104 — Gebinde-Preise für Kundengruppen kommen jetzt an der Kasse an

Hatten Sie für ein Gebinde (z.

• Gebinde-Gruppenpreise greifen an der Kasse: Händler-, VIP- und andere kundengruppenspezifische Gebindepreise werden jetzt korrekt an die Kassen übertragen und dort je nach Kundengruppe des Kunden angewendet.
• Aufgeräumte Preisprojektion: Veraltete, doppelte Gebinde-Preiszeilen werden beim Sync automatisch entfernt.

Version 0.0.0.103 — Fernwartungs-Zugriffe enden zuverlässig zum gewährten Zeitpunkt

Wenn Sie unserem Support per „Support-Zugriff anfordern" eine befristete Fernwartung erlaubt haben (z.

• Harte Ablaufgrenze: Nach Ende des von Ihnen gewählten Zeitraums ist kein Support-Login auf Ihr Konto mehr möglich — serverseitig erzwungen, nicht nur ausgeblendet.
• Korrekte Anzeige: Genehmigte, aber abgelaufene Anfragen werden jetzt zuverlässig als „Abgelaufen" geführt; der Einlog-Knopf verschwindet.
• Session gekoppelt: Eine laufende Support-Sitzung kann den gewährten Zeitraum nicht mehr überdauern.

Version 0.0.0.102 — Aktionen „Kaufe X erhalte Y gratis" zentral verwalten + JTL-Funktionsattribut

• Neue Seite „Aktionen (POS)" unter Einstellungen → Aktionen (POS): Aktionen wie „Kaufe 1, erhalte 1 gratis" (1+1), „3+1" und Co. zentral anlegen und an alle Kassen verteilen. Drei Varianten: gleicher Artikel, artikelübergreifend (kaufe A → erhalte B gratis) und „günstigste Einheit einer Kategorie gratis". Mit Artikel-Suche, Kategorie-Auswahl, „An Kassen senden"-Button.
• Pfand bleibt korrekt: Bei pfandpflichtigen Artikeln wird das Pfand an der Kasse weiterhin voll berechnet — nur der Artikelpreis der Gratis-Einheit ist 0 €.
• JTL-Funktionsattribut: Wer JTL-Wawi nutzt, kann eine Aktion auch direkt am Artikel als Funktionsattribut hinterlegen (bis_promo_buy, bis_promo_get, optional bis_promo_free_sku für einen anderen Gratis-Artikel, bis_promo_deposit). Beim JTL-SQL-Sync wird daraus automatisch eine Aktion erzeugt und auf alle Kassen verteilt. Dokumentiert im Funktionsattribut-Kompendium.
• Bidirektionaler Sync: Neue Tabelle posPromotions, Pull/Push über die bestehende POS-Sync-Infrastruktur (push_promotions-Befehl).

Version 0.0.0.101 — Kundengruppe der Kasse auch ohne aktive JTL-Verbindung wählbar

Im Kundencenter (JTL-Integration) ließ sich die Standard-Kundengruppe für die Kasse — sowohl für die Verbindung als auch pro einzelner Kasse — nur dann auswählen, wenn der BISConnect-Client gerade online war und die JTL-Wawi live antwortete.

• Immer verfügbar: Das Auswahlfeld bezieht die Kundengruppen jetzt aus den im Konto gespeicherten Kundengruppen. Eine aktive JTL-Live-Verbindung ist nicht mehr nötig — die Auswahl funktioniert auch bei offline BISConnect-Client.
• Live-Ergänzung: Ist die JTL-Verbindung gerade online, werden zusätzlich frisch in JTL angelegte, noch nicht synchronisierte Gruppen ergänzt.
• Voll kompatibel: Die gespeicherte Auswahl nutzt denselben Kundengruppen-Schlüssel wie JTL — Preise an der Kasse werden unverändert korrekt aufgelöst, bestehende Einstellungen bleiben gültig.

Version 0.0.0.100 — Zahlungsarten: „EC-Kartenterminal" statt „girocard" + ab Werk nur Barverkauf aktiv

Im Kundencenter (Zahlungsarten-Konfiguration) erschien die EC-Kartenterminal-Zahlart unter dem rohen technischen Schlüssel „girocard" — verwirrend, weil die Kasse beim Hinzufügen „EC-Kartenterminal" anbietet.

• Klartextname: Die Zahlart girocard (technischer Schlüssel für das EC-Kartenterminal, Kassen-Typ EC_TERMINAL) wird jetzt überall als „EC-Kartenterminal" angezeigt — im Kundencenter, auf dem Z-Bon und im Kassenbericht. Bestehende Konfigurationen werden beim nächsten Öffnen der Zahlungsart-Seite automatisch umbenannt (einmalig, idempotent). Der DATEV-Export ist nicht betroffen (nutzt Kontonummern, nicht das Label).
• Ab Werk nur Barverkauf aktiv: Neu angelegte Tenant-Konfigurationen aktivieren standardmäßig nur Barverkauf — sowohl „aktiv in der Kasse" als auch „in der Kundenanlage". Jede weitere Zahlungsart (Karte, EC-Terminal, SumUp …) schaltet der Betreiber bewusst frei. Bestehende Konfigurationen bleiben unverändert.

Version 0.0.0.99 — Doku „Individuelle Zahlungsart" (manuelle Kartenzahlung)

Wenn das Kartenterminal nicht direkt an der Kasse angebunden war (Stand-alone-Terminal, Anbindungsproblem, Schnittstellenausfall), gab es keine offizielle Anleitung dafür, wie der Kassierer den Vorgang sauber verbucht.

• Neue Dokumentationsseite bispos.app/docs/zahlungsart-manuell.html: kompletter 8-Schritte-Walkthrough mit Screenshots in Deutsch und Englisch (per Tab umschaltbar). Zeigt, wie eine eigene Zahlungsart vom Typ „Individuell" angelegt und mit DATEV-Konto (z. B. 1200 EC-Karten) belegt wird.
• Klar dokumentierter Workflow: Kassenkraft drückt den Button „Kartenzahlung", die Kasse zeigt „Terminal bereit für Zahlung", die Zahlung wird manuell am Terminal abgewickelt — anschließend signiert die Kasse den Vorgang regulär mit der TSE und druckt einen vollwertigen Bon.
• GoBD- und KassenSichV-Argumentation explizit auf der Seite: Bon ist TSE-signiert, Terminal-Beleg dokumentiert nur den Zahlungsfluss, Z-Bon weist die Zahlart als eigene Zeile aus — fertige Antwort für Betriebsprüfer.
• In der Doku-Übersicht (/dokumentation.html) eingehängt, JSON-LD-Strukturdaten (HowTo + FAQPage) für SEO ergänzt.

Version 0.0.0.98 — Scan-to-Order: Modus „Digitales Menü"

Die Scan-to-Order-Funktion ließ sich nur komplett ein- oder ausschalten.

• Modus „Digitales Menü": Neuer Schalter menuOnly in den Scan-to-Order-Einstellungen. Ist er aktiv, zeigt der QR-Link weiterhin die Karte (mit Bildern, Beschreibungen, Preisen, Modifier-Gruppen), Bestellungen sind aber abgeschaltet — sowohl im Gastfrontend (Bestellbuttons werden ausgeblendet) als auch serverseitig: Bestell-Requests werden mit HTTP 403 abgelehnt.
• Saubere Tenant-Konfiguration: Spalte menuOnly in scan_to_order_config, automatische Schema-Migration über ensureScanToOrderTables. Wert wird in saveSettings gespeichert und im Public-Menü-Endpunkt (/public/scan-to-order/menu/{code}) als restaurant.menuOnly zurückgegeben.
• Use-Cases: Gastronomie-Betriebe ohne eigenes Bestell-Setup (Bedienung läuft klassisch, QR ist nur Info), Bars/Cafés mit reiner Karten-Anzeige, Pop-up-Stände, Friseure/Praxen mit Behandlungsübersicht statt Bestellung.

Version 0.0.0.97 — Freemail-Spam-Schutz für Admin-Mails

System-Mails von BIS ERP (Willkommens-Mail, Passwort-zurücksetzen-Link, TSE-Willkommen, Lieferanten-Bericht, Support-Zugriff, Test-Mail) sowie Admin-Marketing-Kampagnen wurden je nach Einstellung über den hauseigenen SMTP-Server oder die Gmail-API versendet.

• Freemail-Spam-Schutz: Admin-Mails an Empfänger mit Freemail-Adressen werden ab sofort automatisch über den verbundenen Master-Gmail-Account ([email protected]) verschickt — unabhängig davon, was unter „E-Mail-Routing" konfiguriert ist. Mails an Geschäfts-Domains gehen wie bisher den normalen Weg.
• 22 Standard-Freemail-Domains sind voreingestellt: gmail.com, googlemail.com, gmx.de/net/at/ch, web.de, icloud.com, me.com, mac.com, hotmail.com/.de, outlook.com/.de, live.com/.de, yahoo.com/.de, aol.com, t-online.de, freenet.de, mail.de.
• Vollständig konfigurierbar: Unter Super-Admin → Gmail-OAuth gibt es jetzt einen Bereich „Freemail-Spam-Schutz" — Toggle zum An-/Abschalten, Tag-Editor zum Ergänzen oder Entfernen einzelner Domains, „Standard wiederherstellen" als Notausstieg.
• Kampagnen-Versand verbessert: Auch Admin-Marketing-Kampagnen (BIS ERP → Tenants) prüfen jeden Empfänger einzeln und schalten bei Freemail-Empfängern automatisch auf den Gmail-Versandweg um.
• Branding bleibt erhalten: Der Absender-Name (z. B. „BIS ERP") bleibt sichtbar; Antworten landen wie bisher in der eingestellten Reply-To-Adresse.

Version 0.0.0.96 — BISprint: Preisschilder auch an Lager-Geräte drucken

Der BISprint-Druck konnte Preisschilder an eine gekoppelte Kassen-App schicken.

• Druckziel Lager-Gerät: Im BISprint-Druckdialog („Auf Gerät drucken") lassen sich jetzt auch Lager-Handhelds als Druckziel auswählen.
• Rolle sichtbar: Jedes Gerät im Auswahlfeld zeigt seine Rolle an — „Kasse" oder „Lager" — damit klar ist, wohin der Druck geht.
• Bestehende Kassen unverändert: Bereits gekoppelte Kassen und der bisherige BISprint-Druck funktionieren wie zuvor.

Version 0.0.0.94 — Artikel-Zustände (Neu / Gebraucht / B-Ware)

Denselben Artikel in verschiedenen Zuständen zu verkaufen — neu, gebraucht, B-Ware/„zweite Wahl" — war nicht sauber abbildbar.

• Zustand pro Artikel: In der Artikel-Detailansicht gibt es das neue Feld „Zustand" (Neu, Gebraucht, B-Ware …). Die Zustände stammen aus JTL-Wawi und werden bei jedem Abgleich aktuell gehalten.
• Gleiche EAN erlaubt: Mehrere Artikel desselben Produkts dürfen sich jetzt dieselbe EAN teilen, solange ihr Zustand unterschiedlich ist — keine „doppelte EAN"-Warnung mehr. Jeder Zustand behält seinen eigenen Preis und Bestand.
• Zustandsabfrage an der Kasse: Wird an der Kasse eine EAN gescannt, hinter der mehrere Zustände stecken, fragt die Kasse kurz nach, welcher Zustand verkauft wird (Neu / Gebraucht / B-Ware) — mit Preis. Gibt es nur einen Artikel zu der EAN, läuft alles wie gewohnt ohne Rückfrage.
• Bidirektional mit JTL: Der Zustand wird in beide Richtungen mit JTL-Wawi (tZustand) abgeglichen.

Version 0.0.0.93 — Amazon: Vorlagen-Verwaltung & ASIN-Suche

Die Amazon-Anbindung bewarb „Globale Vorlagen", „Design-Vorlagen" und die ASIN-Suche als Funktionen — die zugehörigen Oberflächen waren fertig programmiert, aber in keiner Ansicht eingebunden und damit nicht erreichbar.

• Neuer Tab „Vorlagen" im Amazon-Modul mit drei Bereichen: Globale Vorlagen (Versandart, Bearbeitungszeit, Preisaufschlag), Design-Vorlagen (Aufzählungspunkte, Beschreibung, Suchbegriffe) und Listing-Vorlagen.
• Neuer Tab „ASIN-Suche" — Amazon-Produkte per ASIN nachschlagen: Produktdetails, Bewertungen und bestehende Angebote.
• Alle Editoren sind vollständig in Deutsch, Englisch und Thai verfügbar.

Version 0.0.0.92 — Individuelle Kundenpreise

Preise ließen sich bisher nur pauschal oder pro Kundengruppe festlegen.

• Preis pro Einzelkunde: In der Artikel-Detailansicht gibt es den neuen Bereich „Individuelle Kundenpreise" — dort weisen Sie einem bestimmten Kunden direkt einen eigenen Preis für diesen Artikel zu. Umgekehrt zeigt die Kundenkarte unter dem Tab „Preise" alle Sonderpreise dieses Kunden auf einen Blick.
• Mengenstaffeln: Pro Kunde und Artikel sind auch mehrere Staffelpreise möglich (z. B. ab 1 Stück, ab 10 Stück).
• Greift automatisch an der Kasse: Sobald ein Kunde dem Verkauf zugeordnet ist, verwendet die Kasse (Web-Kasse und POS-App) automatisch seinen individuellen Preis — er hat Vorrang vor Kundengruppen- und Standardpreis.
• JTL-Wawi in beide Richtungen: Individuelle Kundenpreise werden bidirektional mit JTL-Wawi abgeglichen — in BIS ERP angelegte Preise landen in JTL, in JTL gepflegte Preise erscheinen in BIS ERP. Aktivierbar in den JTL-Einstellungen.

Version 0.0.0.90 — JTL-Wawi: Produktübertragung an die Kasse zuverlässiger

Beim Anbinden von JTL-Wawi konnte es passieren, dass Artikel nicht an der Kasse ankamen — obwohl die Synchronisation „erfolgreich" meldete.

• Neu zugewiesene Artikel kommen jetzt automatisch an: Sobald Sie einen Artikel in JTL dem Verkaufskanal „BISpicy POS" zuweisen, überträgt ihn der nächste Abgleich an die Kasse — auch ohne den Artikel extra zu bearbeiten und ohne einen vollständigen Neu-Abgleich anzustoßen.
• Gebinde mit langen Codes: Gebinde mit langen EAN-/Barcode-Werten (z. B. GS1-Element-Strings) werden jetzt korrekt importiert, statt den Abgleich mit einem Fehler zu beenden.

Version 0.0.0.89 — Amazon: Dashboard-Widget mit echten Zahlen, mehrsprachige Oberfläche

Die Amazon-Kachel auf dem Dashboard zeigte nur Nullen — eine Platzhalter-Anzeige ohne echte Daten.

• Dashboard-Widget mit echten Zahlen: Das Amazon-Widget zeigt jetzt tatsächliche Werte — Bestellungen und Umsatz heute und diese Woche, aktive Listings, ausstehende Bestellungen, aufgeschlüsselt je Amazon-Konto. Ohne Amazon-Verbindung erscheint ein klarer Hinweis statt leerer Nullen.
• Vollständig mehrsprachig: Die Tabs „FBA-Einlieferung" und „Berichte & Gebühren" sowie alle Amazon-Meldungen sind jetzt in Deutsch, Englisch und Thai verfügbar.
• Aktualisierte Funktionsübersicht: Die Amazon-Feature-Seite zeigt jetzt auch Berichte & Finanzen sowie Rechnungs-Upload und DATEV-Kontierung.

Version 0.0.0.88 — DATEV-Export: Gesundheitsprüfung vor dem Export

Beim DATEV-Export ließ sich ein Buchungsstapel erzeugen, ohne dass vorher geprüft wurde, ob alle Umsätze vollständig erfasst sind.

• Der DATEV-Export ist jetzt ein zweistufiger Assistent: Schritt 1 wählt Zeitraum und Export-Typ, Schritt 2 zeigt eine Gesundheitsprüfung je Marktplatz/Kanal.
• Die Prüfung zeigt pro Kanal (Amazon, eBay, Shopify, manuell …) eine Ampel mit konkreten Punkten: Bestellungen ohne Rechnung, Entwurfsrechnungen, Marktplatz-Rechnungen ohne Auftragsbezug und Amazon-Gebühren ohne DATEV-Konto.
• Fehler lassen sich direkt in der Prüfung beheben: „Rechnung erstellen" für eine Bestellung ohne Rechnung, „Finalisieren" für einen Entwurf — danach wird automatisch neu geprüft.
• Der Export bleibt jederzeit möglich: Wer offene Punkte nicht beheben will, exportiert mit „Trotzdem exportieren".

Version 0.0.0.87 — Gebinde-Preise: Korrektur des B2B-Modells

Mit 0.0.0.84 wurde ein „Global-B2B"-Preis eingeführt, der pauschal für *alle* Kundengruppen mit B2B-Kennzeichen galt.

• Das Gebinde-Preismodell ist jetzt zweistufig: ein Global-Preis und optional ein Preis je einzelner Kundengruppe.
• bis_gebinde_N_preis_b2b gilt nur noch für die Kundengruppe, die exakt „B2B" heißt — nicht mehr für alle B2B-gekennzeichneten Gruppen.
• Kundengruppen ohne eigenen Gebinde-Preis bekommen den Global-Preis — genau wie in der JTL-Wawi.
• Der „Preise bearbeiten"-Dialog hat dadurch nur noch „Global" + „Preis je Kundengruppe" (kein separates „Global-B2B"-Feld mehr).

Version 0.0.0.86 — Amazon: FBA-Einlieferung, Rechnungen & Kosten-Kontierung

Mit 0.0.0.85 kam die Amazon-Anbindung — Verbinden, Listings, Bestellungen, Bestand.

• FBA-Einlieferung: Neuer Tab „FBA-Einlieferung" — Versandpläne für das Amazon-Lager erstellen, Sendungen anlegen, Versandetiketten abrufen. Dazu eine Pan-EU-Übersicht: Ihr FBA-Bestand je EU-Land auf einen Blick.
• Rechnungsübertragung: Finalisierte Rechnungen aus BIS ERP per Klick an die jeweilige Amazon-Bestellung übertragen. Nutzt Ihr Konto Amazons Rechnungsservice (VCS), wird der eigene Upload automatisch unterdrückt — keine doppelten Rechnungen.
• Berichte & Gebühren: Neuer Tab — Amazon-Berichte (Abrechnungen, Bestandslisten u. a.) anfordern und herunterladen; Amazon-Gebühren, Werbekosten, Anpassungen und Erstattungen werden eingelesen und nach Art ausgewertet.
• DATEV-Kontierung: Jede Amazon-Gebührenart lässt sich einem DATEV-Konto zuordnen. Der DATEV-Export enthält jeden Posten mit Konto, Auftrags- und Rechnungsnummer — jeder Cent ist sauber zuordenbar für Buchhaltung und Bilanzierung.

Version 0.0.0.85 — Amazon-Anbindung

BIS ERP brachte Artikel zwar auf eBay — eine in der Praxis nutzbare Amazon-Anbindung fehlte aber.

• Amazon verbinden — zwei Wege: Entweder mit einem Klick über „Mit Amazon verbinden" (Sie bestätigen den Zugriff direkt bei Amazon) oder klassisch mit Ihrer eigenen SP-API-App über den 6-Schritt-Assistenten.
• Bestellungen automatisch: Neue Amazon-Bestellungen landen alle 20 Minuten von selbst in BIS ERP — inklusive Lieferadresse. Sie lassen sich in lokale Aufträge umwandeln und der Versand zurück an Amazon melden.
• Listings & Bestand: Artikel als Amazon-Listing anlegen, mit vorhandenen ASINs verknüpfen, Preise und Bestand zu Amazon übertragen; FBA-Bestände einsehen.
• Berichte & Gebühren: Amazon-Berichte (z. B. Abrechnungen) anfordern und herunterladen; Amazon-Gebühren und Erstattungen werden eingelesen und nach Gebührenart ausgewertet.
• Mehrere Konten: Mehrere Amazon-Verkäuferkonten parallel, mit Auswahl eines Standard-Kontos.

Version 0.0.0.84 — Gebinde-Preise pro Kundengruppe

Gebinde kannten nur zwei Preisstufen: einen Standardpreis und einen B2B-Preis, der pauschal für alle B2B-Kundengruppen galt.

• Preise je Kundengruppe: Jedes Gebinde hat jetzt einen Global-Preis, optional einen Global-B2B-Preis und beliebig viele kundengruppenspezifische Preise. Auflösung je Kunde: eigener Gruppenpreis → Global-B2B (bei B2B-Gruppen) → Global.
• Bearbeiten-Dialog: Im Preise-Tab öffnet je Gebinde der Button „Preise bearbeiten" eine Preis-Matrix — Global, Global-B2B und eine Liste „Preis je Kundengruppe" mit Auswahl aus den echten, im System angelegten Kundengruppen, jeweils inkl. Sonderpreis und Zeitfenster.
• Nichts ist mehr fest auf „B2C/B2B" verdrahtet — die Preise nutzen durchgängig die tatsächlichen Kundengruppen.
• Funktionsattribut-Konvention erweitert: bis_gebinde_N_preis_{kundengruppe} für gruppenspezifische Preise; der bidirektionale JTL-Sync schreibt sie in beide Richtungen mit.

Version 0.0.0.83 — Gebinde & Pfand bidirektional mit JTL + Pfandtyp-Anzeige korrigiert

Gebinde (Verpackungseinheiten wie Sixpack oder Karton) und Pfand kamen über JTL-Funktionsattribute nur in eine Richtung nach BIS ERP — bearbeiten ließen sie sich ausschließlich in der JTL-Wawi.

• Pfandart wird wieder angezeigt — das Auswahlfeld nutzt jetzt systemweit dieselbe Schreibweise (EINWEG / MEHRWEG / KASTEN). Wirkt nach dem Update sofort für alle Pfandartikel.
• Bidirektionaler Sync: Gebinde und Pfand lassen sich jetzt direkt in BIS ERP pflegen — Änderungen werden automatisch als Funktionsattribute in die JTL-Wawi zurückgeschrieben. Sofort beim Speichern; ist der JTL-Rechner gerade nicht erreichbar, holt der nächste Sync-Lauf es nach.
• Gebinde-Editor erweitert: B2B-Verkaufspreis und Sonderpreise (B2C und B2B, je mit Gültigkeits-Zeitfenster) direkt am Gebinde pflegbar.
• Preise-Tab aufgeräumt: Gebinde erscheinen als kompakte Übersicht — eine Zeile je Gebinde mit den Spalten VK B2C, VK B2B und Sonderpreis statt einer Zeile pro Kundengruppe.
• Gebinde und Pfand werden auch beim Duplizieren, in der Massenbearbeitung und beim CSV-Import vollständig mitgeführt (inkl. Kistenpfand-Betrag und -Schwelle).

Version 0.0.0.82 — Alle Kundengruppen an die Kasse + neue Checkbox „Kundenanlage"

Eine Kundengruppe wurde nur dann an die POS-Kasse übertragen, wenn das Flag „An Kasse synchronisieren" gesetzt war.

• Alle aktiven Kundengruppen werden an die Kasse übertragen — unabhängig von Einstellungen. Damit löst die Kasse jeden Kunden korrekt auf.
• Die DB-Spalte customerGroups.syncToPos wurde umbenannt zu showInPosCustomerCreation (Migration automatisch). Bedeutung neu: Sie steuert nur noch, welche Kundengruppen der Kassierer beim Anlegen eines neuen Kunden im Dropdown auswählen kann.
• Die Checkbox in der Kundengruppen-Verwaltung (Einstellungen → Kundengruppen und Kundencenter → JTL-Integration) heißt jetzt „Kundenanlage" statt „An Kasse".
• POS-Kasse (siehe POS-Versionshinweise): Das Kundenanlage-Dropdown zeigt nur noch Gruppen mit aktivem „Kundenanlage"-Haken.

Version 0.0.0.81 — POS-Bestellungen mit vollständigen Kundendaten + Dublettenschutz beim Kundensync

Wurde ein POS-Verkauf als Bestellung in BIS ERP gespiegelt, zeigte die Bestellung den Kunden unvollständig: 1.

• createOrderFromPosSale schreibt Personenname und Firma jetzt getrennt in die Bestellung (shippingName/billingName = Personenname, shippingCompany/billingCompany = Firma) und füllt zusätzlich Telefon und USt-IdNr.
• Die POS-Kasse liefert mit jedem Verkauf einen vollständigen Kunden-Snapshot mit (Anschrift, Land, E-Mail, Telefon, USt-IdNr.). createOrderFromPosSale verwendet vorrangig diesen Snapshot — die Bestellung ist damit self-contained und korrekt, auch wenn der Kunde server-seitig unvollständig gespeichert ist. Der Kundendatensatz dient nur noch als Fallback.
• Der Kundensync (syncCustomer / syncNewCustomerOnlyFromPos) erkennt einen vorhandenen Kunden zusätzlich über die Kundennummer sowie über Vorname + Nachname + Firma (normalisiert). Für Kunden ohne E-Mail/Telefon entstehen damit keine neuen Dubletten mehr — ein erneuter Push aktualisiert den bestehenden Datensatz.

Version 0.0.0.80 — Fix: B2B-Erkennung bei JTL-Kundensuche nicht mehr aus dem Firmennamen

Die JTL-Direktsuche der POS-Kasse (searchJtlCustomersDirect) leitete das isB2B-Kennzeichen eines Kunden aus dem Firmennamen ab: sobald das Feld „Firma" in JTL irgendetwas enthielt, galt der Kunde als B2B.

• searchJtlCustomersDirect ermittelt isB2B jetzt aus der Kundengruppe des Kunden (customerGroups.isB2B), nicht mehr aus dem Firmennamen. Die JTL-Kundengruppen-ID wird 1:1 gegen die BIS-ERP-Kundengruppen aufgelöst.
• Die POS-Kasse (siehe POS-Versionshinweise) wertet zusätzlich beim B2B-Entscheid die Kundengruppe vorrangig aus — das abgeleitete Flag ist nur noch Fallback.

Version 0.0.0.79 — Legacy bis_gebinde_N_pfand_betrag-Pfad entfernt — Pfand nur noch am Basisartikel

Pfand-Werte für die Kiste konnten in zwei Stellen gepflegt werden: 1.

• JtlWawiSqlSyncService::syncGebindeFromFunktionsattribute() liest und schreibt kein Pfand mehr: — bis_gebinde_N_pfand_betrag wird beim Sync ignoriert — articlePackagingUnits.depositAmount wird vom FA-Sync nicht mehr gefüllt — Der automatische Override articles.crateDepositThreshold/Amount aus bis_gebinde_N_* ist entfernt
• Pfand wird ausschließlich über Artikel-FAs gepflegt: — bis_pfand_typ + bis_pfand_betrag → Flaschenpfand — bis_kistenpfand_betrag + bis_kiste_ab → Kistenautomatik
• Quellenpriorität für Kistenpfand-Betrag und Schwelle ist auf zwei Stufen zurechtgestutzt: (1) BIS-ERP-UI → (2) JTL-FA. Kein Legacy-Fallback mehr.

Version 0.0.0.78 — Mehr-Kassen-Betrieb: eindeutige Bonnummern + Auswertungen pro Kasse

• Geräte-Kürzel an jeder Kasse: Beim Anlegen einer WebPOS- oder Android-POS-Kasse vergibt das System automatisch ein 1–8 Zeichen langes Kürzel aus dem Geräte-Namen (z. B. „Kasse 1" → K1, „Bar" → BAR). Das Kürzel ist im Kundencenter editierbar (PUT /pos/devices/{id}/short-code) und tenant-weit eindeutig.
• Neue Bonnummer für WebPOS: Format WEB-{Kürzel}-{Jahr}-{0001} — z. B. WEB-K1-2026-0001. Bestehende Belege bleiben unverändert (TSE-Signaturen referenzieren die ursprüngliche Nummer; Migration wäre Manipulation).
• DATEV-Export pro Kasse: Im Export-Dialog erscheint bei den Typen „Kassen-Belege (Z-Bons)" und „Kombinierter Export" ein neuer Dropdown „Kasse". Wahlmöglichkeit: alle Kassen aggregiert (Default) oder eine einzelne. Hinweis-Banner stellt klar: an das Finanzamt wird stets aggregiert gemeldet — der Filter dient nur der internen Kontrolle.
• POS-Reports filterbar: UStVA, EÜR und Kassenjournal in BIS ERP → Berichte → POS-Berichte zeigen alle Kassen mit Kürzel im Filter-Dropdown.
• DSFinV-K-Vorschau pro Kasse: Auf der Export-Seite gibt es vor dem Export eine Tabelle mit Belegen, Brutto/Netto/Steuer pro Kasse — als interne Kontrolle. Der eigentliche Export ans Finanzamt bleibt KassenSichV-konform aggregiert.

Version 0.0.0.77 — Auto-Anlage der BIS-Funktionsattribute in JTL + saubere Quellenpriorität

• Auto-Anlage der BIS-FAs: Beim ersten Sync-Lauf legt JtlWawiSqlSyncService::ensureBisFunktionsattribute() idempotent die zwölf BISpicy-POS-Funktionsattribute in JTL an (Gruppe „BISpicy POS"): — bis_gebinde_1_name, bis_gebinde_1_menge, bis_gebinde_1_ean, bis_gebinde_1_preis — bis_pfand_typ, bis_pfand_betrag — bis_kistenpfand_betrag, bis_kiste_ab — bis_gebinde_2_name, bis_gebinde_2_menge, bis_gebinde_2_ean, bis_gebinde_2_preis
• tGebinde nur als Fallback: Wenn ein Artikel bis_gebinde_*-FAs hat, gewinnen diese als Single-Source-of-Truth für VPE-Stammdaten + Preis + Pfand. Der pullGebindeViaSql-Code skippt tGebinde-Einträge für Artikel, die bereits FAs haben — keine Duplikate mehr in articlePackagingUnits.
• Klare Quellenpriorität: Bei Mehrfach-Pflege gewinnt die spezifischere Quelle: 1. bis_gebinde_N_* (FA mit Preis + Pfand) 2. tGebinde (JTL-Stammdaten zum Scannen, ohne Preis) 3. Keine VPE
• **tGebinde bleibt in JTL für die Lagerverwaltung** wirksam — der BIS-ERP-Sync nutzt es nur noch als Fallback.

Version 0.0.0.76 — Kistenpfand-Pflege ohne Gebinde-Pflicht + Trigger-Schwelle pro Artikel

• Neue JTL-Funktionsattribute am Artikel: — bis_kistenpfand_betrag — Pfand für die Kiste selbst (NICHT pro Flasche, NICHT an Gebinde-Index gebunden) — bis_kiste_ab — Schwelle: ab wieviel Flaschen automatisch eine Kistenpfand-Position kommt
• Pflege auch im BIS ERP möglich: Im Artikel-Detail unter „Pfand" zwei neue Felder „Kiste automatisch ab" und „Kistenpfand-Betrag". JTL-Sync arbeitet *only-if-empty* — manuell gepflegte Werte haben Vorrang und werden vom Sync nicht überschrieben.
• Quellenpriorität für beide Werte: (1) BIS-ERP-UI → (2) neue JTL-FAs → (3) alte JTL-FAs (bis_gebinde_1_menge / bis_gebinde_1_pfand_betrag als Bestandsdaten-Fallback) → (4) keine Automatik.
• POS-Kasse: Der Kassierer kann die automatisch hinzugefügte Kistenpfand-Position bei Bedarf aus dem Warenkorb entfernen (z. B. wenn der Kunde die Flaschen ohne Kiste nimmt). Flaschenpfand bleibt zwingend. Wird die Kiste entfernt und der Kassierer scannt weitere Flaschen desselben Artikels, kommt die Kiste in diesem Bon nicht erneut zurück — die Suppress-Markierung wird beim Bon-Abschluss automatisch zurückgesetzt.

Version 0.0.0.75 — Tisch-Status (besetzt/frei/reserviert) jetzt auch live ins Kundencenter

Die Tisch-Cloud-Sync aus 0.0.0.74 übertrug nur Stammdaten (Tischnummer, Anzeigename, Kapazität, Form, Farbe).

• POST /api/pos/sync/tables/upsert akzeptiert das Feld assigned_employee und behandelt es bei UPDATE optional (nur wenn der Key im Body steht — verhindert versehentliches Nullen aus Push-Snapshots, in denen das Feld absichtlich nicht enthalten ist).
• GET /api/pos/sync/tables liefert das Feld nun mit aus.
• POS-App (siehe Versionshinweise im POS-Repo) pusht jede Status-Mutation automatisch ans Backend: belegen, freigeben, reinigen, gästezahl, mitarbeiter, deaktivieren, aktivieren. Backend triggert daraufhin den FCM-Push settings/tables an alle Geräte des Tenants.
• Vorgabe „Kundencenter ist Kontroll-Tool" bleibt: Tisch-Übersicht aktualisiert sich auf Knopfdruck (Aktualisieren-Button), zeigt dann aber den aktuellen Live-Stand.

Version 0.0.0.74 — Tische zwischen POS-App und Kundencenter wirklich synchron

Die Android-POS-App (BISpicyPOS) speicherte Tische ausschließlich lokal auf dem Tablet und kannte das Tisch-Schema im Kundencenter (webpos_tables) gar nicht.

• Backend: Zwei neue API-Endpoints für die Android-POS-App: — GET /api/pos/sync/tables — liefert die Tisch-Stammdaten des Tenants — POST /api/pos/sync/tables/upsert — anlegen/aktualisieren (Match per table_number als Natural Key, oder per Backend-UUID falls bekannt)
• POS-App-Anbindung (siehe POS-Versionshinweise) holt diese Tische beim Öffnen des Tischplans, beim FCM-Push category=tables und schickt jede neue/geänderte lokale Tisch-Anlage sofort ans Backend.
• Konflikt-Strategie: table_number ist Natural Key auf beiden Seiten — bei manueller Doppelanlage gewinnt der Cloud-Stand.
• Kundencenter bleibt manuell: Vorgabe unverändert, Refresh-Button bleibt für die Kontroll-Sicht.

Version 0.0.0.73 — POS-Zahlungsarten zentral konfigurieren + DATEV-Konten pro Zahlart

• Neue Sektion „POS-Zahlungsarten konfigurieren" im Kundencenter unter /my/jtl-integration. Pro Zahlungsart (bar, card, ec, girocard, sumup, zettle, rechnung, vorkasse, paypal, gutschein, lastschrift, überweisung) konfigurierbar: — In Kundenanlage sichtbar (Checkbox) — steuert, ob die Zahlart im POS-Dropdown „Standard-Zahlungsart" beim Kunden-Anlegen/-Bearbeiten erscheint — DATEV-Konto SKR03 + SKR04 (separat hinterlegbar, mit sinnvollen Defaults) — Rechnungskauf-Flag (Checkbox) — markiert Zahlarten, deren Erlös beim Rechnungslauf in der WaWi gebucht wird (Ansatz B, verhindert Doppelbuchung)
• **Neue Master-DB-Tabelle posPaymentMethodConfig** mit Auto-Seed beim ersten Aufruf — keine manuelle Pflege nötig, sinnvolle Defaults sind hinterlegt.
• DATEV-Export nutzt die Konfiguration: PosReportController::buildDatevIncomeLines löst pro Transaktion das Konto über posPaymentMethodConfig auf (mit Fallback auf den Default-Kontorahmen). Rechnungskauf-Verkäufe werden im POS-DATEV-Export jetzt korrekt übersprungen.
• POS-App filtert die Kunden-Zahlart-Dropdown anhand der availableInCustomerCreation-Liste, die über posPaymentMethodConfig aus dem Sync kommt. Lokale Zahlungsarten bleiben unangetastet — gefiltert wird nur die UI.
• Z-Bon / Kassenjournal gruppieren Zahlungsarten konsistent über den normalisierten Schlüssel (CASH/Bargeld/Bar → bar, Credit Card/Kreditkarte → card) und zeigen einheitliche deutsche Labels.
• **Neuer Service PaymentMethodNormalizer** (Backend + POS-App-Spiegelung) als Single Source of Truth für die kanonischen Zahlungsart-Schlüssel.

Version 0.0.0.72 — Tische anlegen im Kundencenter + Live-Sync zwischen Kassen-Tablets

• Kundencenter-Tischverwaltung repariert: Tabellen-Schema wird beim ersten Request automatisch angelegt. Aktualisieren-Button und „Neuen Tisch anlegen" funktionieren wieder.
• Live-Sync zwischen POS-Tablets: An jeder tisch-mutierenden Aktion an einer Kasse (Tisch öffnen, zahlen, freigeben, umziehen, splitten, Mitarbeiter zuweisen, reservieren, neuen Tisch anlegen) bekommen alle anderen aktiven Kassen-Tablets desselben Tenants einen Echtzeit-Push und aktualisieren ihre Tisch-Übersicht automatisch.
• Kundencenter bleibt bewusst manuell: Das Kundencenter ist nur für Steuerung/Kontrolle/Auswertung gedacht und braucht keinen Echtzeit-Sync. Aktualisieren-Button refresht weiterhin auf Knopfdruck.

Version 0.0.0.71 — Master-Schalter Kistenautomatik im Kundencenter

• Im Kundencenter unter /my/jtl-integration neue Sektion „Kistenpfand-Automatik" mit einem Master-Schalter. Default: aktiviert.
• Backend-Spalte jtlConnections.crateAutomationEnabled TINYINT(1) NOT NULL DEFAULT 1 (Migration automatisch).
• Endpoints GET /settings/jtl/crate-automation und POST /settings/jtl/crate-automation.
• JtlPosSyncHandler::buildConfig gibt das Flag an die POS-App weiter — die Kistenautomatik im Cart greift nur, wenn der Schalter true ist und am Artikel crateDepositThreshold/crateDepositAmount gepflegt sind.
• Greift erst nach dem nächsten POS-Sync auf der Kasse. Artikel ohne Kistenpfand-Konfiguration sind weiterhin nicht betroffen.

Version 0.0.0.70 — JTL-Verkaufskanal-Haken wirkt jetzt pro Kasse

Der JTL-Verkaufskanal-Haken am Artikel (Reiter „Verkaufskanäle" — z. B.

• Der JTL-Sync wertet die Haken pro Kasse aus und schreibt die Zuordnung in posArticleAssignments mit targetType='device' und targetId = posDevices.id — passend zum bestehenden Lookup in der POS-Sync-API.
• Pro JTL-Shop wird über das bestehende posDeviceShops-Mapping (in jtlConnections) die zugehörige Kasse aufgelöst (Match-Reihenfolge: id_hex → androidId → legacyFingerprint → deviceName).
• Diff-Logik: Hinzufügen/Entfernen pro Kasse beim Setzen/Lösen des Hakens.
• Bestehende Setups ohne Mapping verhalten sich unverändert: ist kein posDeviceShops-Eintrag vorhanden oder löst keiner zu einer registrierten Kasse auf, läuft der bisherige globale Modus weiter — kein Hard-Cut.
• Manuell gepflegte Channel-Preise (fixedPrice, channelSpecialPrice) bleiben durch Filter auf priceMode='article' AND fixedPrice IS NULL AND channelSpecialPrice IS NULL beim Cleanup unberührt.

Version 0.0.0.69 — Kistenpfand-Konfig aus Gebinde-Funktionsattributen + POS-Kistenautomatik

• Beim JTL-Sync wird aus den Gebinde-Funktionsattributen jetzt automatisch die Kistenpfand-Konfiguration auf den Basisartikel geschrieben: — bis_gebinde_1_menge (z. B. 12) → articles.crateDepositThreshold — bis_gebinde_1_pfand_betrag (z. B. 1,50) → articles.crateDepositAmount — bis_gebinde_1_ean → articles.crateDepositSku
• Bestehende Kistenpfand-Werte am Artikel werden NICHT überschrieben (only-if-empty) — manuelle Konfig hat Vorrang.
• **POS-App-Logik (SalesViewModel.syncCrateDepositForProduct)** ergänzt: bei sortenreinen 12er/24er-Vielfachen automatisch Kasten-Pfand-Item dazugefügt. Berücksichtigt VPE-Scans (Kasten/Träger als Verpackungseinheit gescannt → Flaschen-Äquivalentmenge wird automatisch berechnet).
• Override "Ohne Kiste" durch manuelles Entfernen des Kasten-Items im Cart.

Version 0.0.0.68 — Pfand-Position automatisch im JTL-Auftrag

• Beim POS→JTL-Push erkennt BIS ERP, wenn ein verkaufter Artikel Pfand hat (articles.depositType != none) oder eine VPE mit Kistenpfand gescannt wurde (articlePackagingUnits.depositAmount > 0). Pro betroffenes Item wird eine eigene Pfand-Position als tAuftragPosition an den JTL-Auftrag angefügt — sichtbar auf Rechnung und Lieferschein.
• B2C vs. B2B: Die Kundengruppe des Bons entscheidet, ob der Pfand-Nominalwert als Brutto (B2C, MwSt enthalten) oder Netto (B2B, MwSt kommt drauf) verbucht wird. Default ist Brutto.
• Pfand-Steuersatz: 19 % (in DE üblich).
• Positionsname: Pfand Einweg 0,25 EUR bzw. Kistenpfand 1,50 EUR. Eindeutiger Pseudo-cArtNr z.B. PFAND-EINWEG-025 oder PFAND-KISTE-150.

Version 0.0.0.67 — JTL-Pfand via Funktionsattribute + Kompendium

• Pfand am Basisartikel lässt sich jetzt direkt in JTL als Funktionsattribut pflegen: — bis_pfand_typ = EINWEG / MEHRWEG / KEIN — bis_pfand_betrag = Nominalwert (z. B. 0,25 €) — brutto bei B2C-Kundengruppen, netto bei B2B-Kundengruppen
• Pfand am Gebinde: das bestehende bis_gebinde_*-Set kennt jetzt bis_gebinde_X_pfand_betrag für Kistenpfand (z. B. 1,50 €). Kein eigener Pfandtyp am Gebinde — Kisten sind immer Mehrweg.
• Migration: Neue Spalte articlePackagingUnits.depositAmount (automatisch).
• Kompendium: Vollständige Übersicht aller bis_*-Funktionsattribute — intern als Entwickler-Guide (docs/guides/JTL_FUNKTIONSATTRIBUTE_KOMPENDIUM.md) und als öffentliche Doku auf beiden Marketing-Sites: — [bispicy.com/docs/jtl-funktionsattribute.html](https://bispicy.com/docs/jtl-funktionsattribute.html) — [bispos.app/docs/jtl-funktionsattribute.html](https://bispos.app/docs/jtl-funktionsattribute.html)

Version 0.0.0.66 — Lieferschein-Trigger via CONTEXT_INFO umgehen

Der 0.0.0.65-Fix legte den Lieferschein direkt per INSERT an — JTL hat aber Trigger auf dbo.tLieferschein und dbo.tLieferscheinPos, die direkte INSERTs blockieren mit der Meldung „Die Tabelle dbo.tLieferschein kann nur über die SPs spLieferscheinErstellen und spLieferscheinLoeschen bearbeitet werden".

Die Trigger erlauben direkte INSERTs, wenn CONTEXT_INFO einen Bypass-Wert hat: - 0x5113 → tLieferschein-Trigger akzeptiert INSERT (und legt automatisch tLieferscheinEckdaten-Row an) - 0x5115 → tLieferscheinPos-Trigger akzeptiert INSERT

BIS ERP setzt jetzt die jeweiligen CONTEXT_INFO-Werte vor den INSERTs und nutzt zusätzlich UPDATE auf die automatisch erzeugte tLieferscheinEckdaten-Row, um nVersandStatus=2 (komplett versendet) zu setzen.

Version 0.0.0.65 — Hotfix: Lieferschein als separater Call mit eigener Nummer

Der 0.0.0.64-Versuch packte den Lieferschein-INSERT in denselben Transaktionsbatch wie den Auftrag und nutzte spGetNextNummer @cName='Lieferschein'.

- Lieferschein-Insert ist jetzt ein separater Relay-Call nach erfolgreichem Auftrags-Insert — in eigenem try/catch gekapselt. Wenn der Lieferschein scheitert, bleibt der Auftrag erhalten, nur eine Warnung wird ins Sync-Log geschrieben. - Lieferschein-Nummer wird selbst generiert (POS-<receiptNr>), spGetNextNummer entfällt komplett.

Version 0.0.0.64 — POS-Lieferschein in JTL, Lieferstatus bleibt erhalten

Nach dem JTL-Workflow „Rechnung erstellen" setzte JTL den Lieferstatus des POS-Auftrags zurück auf „ausstehend" (nKomplettAusgeliefert=0, nLieferstatus=1, dLetzterVersand=null, fAnzahlGeliefert=0).

BIS ERP legt jetzt bei jedem POS-Auftrag im selben Batch einen Lieferschein an: - dbo.tLieferschein mit cLieferscheinNr aus spGetNextNummer und dErstellt = Verkaufsdatum - dbo.tLieferscheinPos pro Auftragsposition mit der vollen Menge - dbo.tLieferscheinEckdaten mit nVersandStatus=2 (komplett versendet) und dVersendet = Verkaufsdatum

Damit erkennt JTL den Auftrag als sauber ausgeliefert, der Rechnungs-Workflow läuft sauber durch und der Lieferstatus bleibt nach dem Workflow stabil.

Version 0.0.0.63 — Hotfix: Position-Eckdaten verdoppelt nicht mehr fAnzahlGeliefert

Der 0.0.0.62-Versuch (UPDATE auf tAuftragPositionEckdaten setzt fAnzahlGeliefert = p.fAnzahl) kollidierte mit dem nachfolgenden Stock-Booking, das fAnzahlGeliefert = fAnzahlGeliefert + qty rechnet — Resultat war 2*qty.

- INSERT in tAuftragPositionEckdaten startet jetzt mit fAnzahlOffen = qty, fAnzahlGeliefert = 0. Stock-Booking baut das anschließend korrekt auf geliefert = qty, offen = 0 auf. - Das nachträgliche UPDATE auf Position-Eckdaten wurde komplett entfernt — die Werte sind durchgängig konsistent zwischen INSERT, Stock-Booking und Workflow-SP. - fAnzahlAufRechnung bleibt conditional (0 bei Rechnungskauf, qty bei Sofortzahlung).

Version 0.0.0.62 — Hotfix: Lieferstatus bleibt "komplett ausgeliefert"

Nach dem 0.0.0.61-Fix für Rechnungskauf-Positionen blieb der POS-Auftrag in JTL als „ausstehend" (nLieferstatus = 1, nKomplettAusgeliefert = 0) sichtbar — obwohl der Kunde die Ware ja sofort mitgenommen hat.

Das UPDATE setzt jetzt fAnzahlGeliefert = p.fAnzahl und fAnzahlOffen = 0 — die Position bleibt als „geliefert" markiert (entspricht der Realität an der Kasse), und die JTL-SP berechnet nLieferstatus = 5, nKomplettAusgeliefert = 1 korrekt.

Version 0.0.0.61 — Hotfix: Workflow-Trigger erreicht den Sync, Rechnung findet offene Positionen

- JtlPosSyncHandler::buildConfig(), JtlSyncHandler.php und zwei Stellen in JtlConnectionController.php mappen jetzt alle drei Workflow-Felder durch. - Das tAuftragPositionEckdaten-UPDATE setzt fAnzahlAufRechnung jetzt conditional: 0 bei Rechnungskauf, qty bei Sofortzahlung.

Version 0.0.0.60 — JTL-Workflow nach Rechnungskauf an der Kasse

• Workflow-Trigger für Rechnungskauf: In /my/jtl-integration lässt sich pro Tenant ein JTL-Workflow auswählen (z. B. „Rechnung Drucken"), der nach jedem POS-Verkauf mit Zahlart „Rechnung" automatisch ausgelöst wird. Die Auswahl wird live aus der eigenen JTL geladen — kein Tippen von IDs nötig.
• Verzögerung wählbar: Sofort oder 1 Minute nach Auftragsanlage. Letzteres gibt der JTL Zeit, alle Eckdaten einzulesen, bevor der Workflow läuft.
• Wie funktioniert das technisch? Nach erfolgreichem Auftrags-INSERT in Verkauf.tAuftrag legt das BIS-ERP einen Eintrag in dbo.tWorkflowQueue an (nEvent=1, kBenutzer=1, dStartDate=GETDATE() bzw. +1 Min). Der JTL-Worker arbeitet die Queue ab und führt den Workflow aus.

Version 0.0.0.59 — BISConnect-Polling 2.5× engmaschiger

• Polling-Intervalle halbiert/gedrittelt: Der BISConnect-Cloud-Relay (Brücke zwischen ERP und lokaler JTL-Datenbank) ist Long-Polling-basiert wie BISPrint. Das Backend wartet auf das Job-Ergebnis und der Windows-Client wartet auf neue Jobs — jeweils in regelmäßigen Abständen. Wir reduzieren beide Intervalle: — Backend wartet auf Job-Result: 250ms → 100ms — Cloud-Relay liefert Jobs an Client: 500ms → 200ms
• Was das bringt: Pro Relay-Anfrage spart das bis zu 450ms an reiner Wartezeit. Bei ~5 Relay-Anfragen pro POS-Verkauf summiert sich das auf 2-3 Sekunden weniger Latenz pro Verkauf. Auf 1000 Tenants hochgerechnet bleibt die DB-Last unkritisch (im Schnitt nur 30 zusätzliche Polls pro Sekunde).

Version 0.0.0.58 — POS-Sync Pickup-Latenz reduziert

• 5-Minuten-Scheduler skippt POS-Push wenn nichts zu tun: Bisher hat der reguläre 5-Minuten-JTL-Scheduler bei jedem Lauf den kompletten pushPosOrdersToJtl()-Setup ausgeführt (Shop-Sync, Customer-Matching, etc.) — auch wenn die Queue alle Verkäufe bereits gepusht hatte. Das blockierte den scheduler-Worker 10-20 Sekunden lang, in denen ein frischer POS-Verkauf auf seine Verarbeitung warten musste. Jetzt prüft der Scheduler zuerst per SELECT COUNT(*) FROM posTransactions WHERE syncedToJtl=0, ob überhaupt was offen ist — wenn nicht, wird der Setup übersprungen.
• Sweep-Intervall halbiert: Der Queue-Sweep läuft jetzt alle 15 statt 30 Sekunden — Retry-Recovery (z.B. wenn der BISConnect-Client kurz offline war) greift schneller.

Version 0.0.0.57 — Bulk-Stock-Lookup: vier Anfragen in einer

Bei jedem POS-Verkauf liefen bisher mehrere SQL-Abfragen separat, um Artikelnummern aufzulösen, FEFO-Bestände zu laden und bei Retouren die Original-Verkaufsdaten zu holen. Ab dieser Version sind all diese Abfragen in einer einzigen Anfrage zusammengefasst, die SQL Server's FOR JSON PATH nutzt, um mehrere Ergebnisse als JSON-Spalten in einer Antwort zurückzugeben.

Erwartete Auswirkung: 2–3 Sekunden weniger pro Verkauf — die End-to-End-Latenz vom POS bis nach JTL sinkt von rund 15–17 s auf 10–12 s.

Greift automatisch beim nächsten Verkauf. Kein Eingriff nötig.

Version 0.0.0.56 — Bulk-Relay: JTL-Order-Push dreimal schneller

Jeder POS→JTL-Verkauf brauchte zuvor drei separate Anfragen über die BISConnect-Verbindung: Auftragsnummer holen, Auftrag schreiben, verifizieren. Jetzt läuft alles in einem einzigen T-SQL-Batch — die Auftragsnummer wird per @cNeueNummer OUTPUT direkt vom Stored Procedure in die Transaktion gezogen, der Verify-Call entfällt komplett.

• Kollisions-Retry sauberer: Bei seltenen Nummernkreis-Kollisionen wird der gesamte Batch automatisch bis zu dreimal wiederholt — jedes Mal mit frischer Nummer vom selben Stored Procedure.
• Auch Rechnungs-Erstellung beschleunigt: Wenn „Rechnung im POS erstellen" aktiviert ist, läuft die Rechnung jetzt ebenfalls in einem einzigen Batch.

Erwartete Auswirkung: POS→JTL-Latenz typisch von 8–15 Sekunden auf 3–5 Sekunden reduziert; Worker-Durchsatz pro Container steigt entsprechend.

Version 0.0.0.55 — Kassen-Verkäufe in Sekunden ins JTL übertragen

Kassen-Verkäufe gehen jetzt durch eine dedizierte Warteschlange direkt von der ERP-Datenbank in den eigenen Worker-Container, der den Push an JTL übernimmt. Die Kasse selbst bekommt die Sync-Antwort in unter einer Sekunde, der Auftrag landet typisch wenige Sekunden später in JTL.

• Skalierbar bis 1000+ Tenants: Die Warteschlange in der Master-DB nutzt SELECT ... FOR UPDATE SKIP LOCKED, sodass mehrere Worker-Container parallel arbeiten können, ohne dass derselbe Verkauf doppelt gepusht wird.
• Robuste Wiederholungen: Wenn der BISConnect-Client offline ist oder JTL kurz nicht erreichbar war, bleibt der Verkauf in der Warteschlange und wird automatisch mit exponentiellem Backoff (5 s → 20 s → 80 s) erneut versucht. Nach fünf Fehlversuchen wird der Auftrag als „failed" markiert.
• Reporting-Fix: Der Sync-Log unterscheidet jetzt korrekt zwischen „erfolgreich angelegt" (created) und „echter Fehler" — vorher wurden alle Verkäufe fälschlicherweise als „failed" angezeigt.

Version 0.0.0.54 — Bestellliste: Sortierung bleibt nach Reload erhalten

Wenn du die Sortierreihenfolge in der Bestellliste änderst, bleibt die Auswahl jetzt auch nach einem Reload und beim nächsten Besuch erhalten. Vorher wurde nach jedem Neuladen wieder die Standardsortierung (neueste oben) verwendet.

Version 0.0.0.53 — Bestellliste: Erstellt-Spalte zuerst, neueste oben, „Laufkunde" für POS

• Standard-Spaltenreihenfolge angepasst: Die Bestellliste zeigt ab Werk die Spalte „Erstellt" am Anfang, damit das Bestelldatum auf einen Blick sichtbar ist.
• Sortierung absteigend nach Datum: Neue Bestellungen erscheinen automatisch oben.
• „Laufkunde" für POS-Verkäufe ohne Kunde: Bei POS-Verkäufen ohne ausgewählten Kunden zeigt die Kundenspalte jetzt „Laufkunde" (kursiv) — angelehnt an die JTL-Wawi-Konvention.

Version 0.0.0.52 — JTL-Trigger-Kompatibilität für Kunden-Updates

Die JTL-Trigger (tgr_tKunde_INSUP) blockierten direkte UPDATE dbo.tKunde-Statements — dadurch wurden Zahlungsart, Zahlungsziel und Rabatt bei bestehenden Kunden still verschluckt. Alle drei Update-Stellen (Kunden-Update, Nachbearbeitung nach Neuanlage, Orphan-Linking) verwenden jetzt den offiziellen Stored-Procedure-Weg über Kunde.spKundeUpdate.

Version 0.0.0.51 — POS-Kunden inkl. Zahlungsart vollständig in JTL

• Standard-Zahlungsart wird zur JTL übertragen: Wird an der Kasse ein neuer Kunde angelegt und ihm eine JTL-Zahlungsart als Standard zugewiesen (z. B. „Rechnung Kasse"), so wird diese jetzt korrekt als kZahlungsart im JTL-Kundenstamm gespeichert.
• Zahlungsziel wird mitgeschrieben: Das Zahlungsziel wird beim Push neuer und beim Update bestehender Kunden korrekt nach JTL geschrieben.
• Auflösung via JTL-Originalnamen: Die Zuordnung Kunden-Zahlungsart → JTL erfolgt über den Original-Namen aus tZahlungsart.cName.

Version 0.0.0.50 — JTL-Zahlungsarten als eigenständige Kassen-Zahlarten

Zahlungsarten aus JTL (z. B. „Rechnung 30 Tage netto", „EC-Karte", „girocard") erscheinen jetzt als eigenständige Zahlarten in der Kassen-App — mit ihrem Original-JTL-Namen, nicht auf eine Standard-Zahlart gemappt. Pro JTL-Zahlungsart steuerst du per Checkbox „An Kasse", ob sie in der App verfügbar sein soll. Bestehende Standard-Zahlarten (Bargeld, EC-Karte, SumUp) bleiben wie gewohnt sichtbar.

Version 0.0.0.49 — KI-Artikelanlage: Keine Mutmaßungen mehr + Zusatzinformationen

• Keine Halluzinationen mehr: Die KI erfindet keine Maße, Gewichte oder Materialien mehr, die nicht aus den Produktbildern erkennbar sind.
• Zusatzinformationen vor der Analyse: Nach dem Bild-Upload kannst du Material, Maße, Farbe und weitere Eigenschaften als Stichpunkte angeben. Die KI behandelt diese als verifizierte Fakten.
• Zielplattform wählen: OTTO, eBay, Amazon oder eigener Shop — die Beschreibung wird automatisch für die gewählte Plattform optimiert.
• Individuelle Anweisungen: Freitext-Feld für eigene Vorgaben an die KI.

Version 0.0.0.48 — Doppelte Umsatzbuchung bei „Kauf auf Rechnung" verhindert

Wenn ein Kunde an der Kasse auf Rechnung kauft und die Rechnung später in der Warenwirtschaft erstellt wird, entstand bisher in DATEV ein doppelter Erlös — einmal aus dem Z-Bon und einmal aus der Rechnung. Ab sofort bucht die Kasse für Rechnungskauf-Zahlarten keinen Erlös mehr im DATEV-Export. Der Umsatz wird ausschließlich beim Rechnungslauf in der Warenwirtschaft gebucht.

• Rechnungskauf-Checkbox pro Zahlungsart: In den DATEV-Einstellungen jeder Zahlungsart gibt es jetzt eine Checkbox „Rechnungskauf". Aktiviere sie für Zahlarten wie „Auf Rechnung" oder „B2B-Rechnung".
• Neuer DATEV-Export-Typ „POS-Z-Bon": Der Export unterstützt jetzt einen eigenen Typ für POS-Tagesabschlüsse, der Rechnungskauf-Vorgänge korrekt ausschließt.
• Z-Bon-PDF mit getrennter Forderungs-Sektion: Umsatzwirksame Zahlarten (Bar, EC) und nicht-umsatzwirksame Forderungen (Rechnungskauf) werden getrennt ausgewiesen.
• GoBD-/KassenSichV-konform: Jeder Verkauf wird weiterhin TSE-konform erfasst.

Version 0.0.0.47 — POS-Zahlungsarten & DATEV-Konten zentral konfigurierbar

Für jede Zahlungsart (Bar, Kreditkarte, EC, SumUp, Rechnung …) hinterlegst du jetzt das DATEV-Buchungskonto separat — sowohl für SKR03 als auch SKR04. Bei Erstaufruf werden sinnvolle Standardkonten vorbelegt (Bar = 1000/1600, Kreditkarte = 1360/1370, Rechnung = 1400/1200), direkt einsatzbereit und jederzeit anpassbar.

Version 0.0.0.46 — TSE-Mehrfachkauf im Shop

Wenn du mehrere Kassen betreibst, kannst du jetzt direkt im Kundencenter-Shop die gewünschte Anzahl TSE-Lizenzen (1–10) auf einmal bestellen. Für jede gekaufte Einheit wird automatisch ein eigener Fiskaly-TSE-Client angelegt — ohne Mehrfach-Checkouts. Die Karte zeigt direkt den monatlichen Gesamtpreis.

Version 0.0.0.45 — KI-Artikelanlage mit Credit-System

Die KI-Artikelanlage nutzt jetzt das globale Credit-System. Pro Analyse wird ein fester Betrag vom Guthaben abgezogen — der Preis ist pro KI-Modell konfigurierbar (z. B. Sonnet 0,50 €, Opus 0,75 €, Haiku 0,25 €). Auf der Einstellungsseite siehst du den Preis pro Analyse für das ausgewählte Modell.

Version 0.0.0.44 — Performance-Optimierung

• Dashboard gebündelt: Alle Dashboard-Widgets laden über einen einzigen API-Call (/dashboard/init) statt 12–15 separater Anfragen. Datenbankverbindungen pro Dashboard-Aufruf reduzieren sich von ~15 auf 2.
• Polling-Intervalle optimiert: Header-Benachrichtigungen (5 s → 60 s), Hintergrund-Imports (2–3 s → 5 s), Marketplace-Sync (10 s → 30 s) — insgesamt ~90 % weniger wiederkehrende API-Aufrufe.

Version 0.0.0.43 — KI-Artikelanlage

Lade Produktbilder hoch — die KI erkennt Artikelname, Beschreibung, Zutaten, Nährwerte, Allergene, EAN, Herkunftsland, Inhaltsmenge und mehr. Jeder Vorschlag zeigt einen Vertrauenswert. 3-Schritte-Wizard: (1) Bilder hochladen, (2) Vorschläge prüfen, (3) Artikel anlegen. Die KI generiert auf Wunsch direkt Übersetzungen in Englisch und Thai.

Version 0.0.0.42 — POS-Kundensync vollständig

Beim Anlegen oder Bearbeiten von Kunden in der POS-App werden jetzt sämtliche Formularfelder korrekt an BIS ERP und JTL übermittelt — darunter Firmenname, Rabatt, USt-IdNr, Bankdaten (IBAN/BIC), Notizen, Adresszusatz, Geburtsdatum, VIP-Status, B2B-Kennzeichen, Rechnungsformat und Treuekarten-Barcode.

Version 0.0.0.41 — JTL Zahlungsarten in POS & Kunden-Zahlungsziele

• Kunden-Zahlungsart im POS-Verkauf: Wird ein Kunde mit hinterlegter Zahlungsart ausgewählt, erscheint seine bevorzugte Zahlungsart im Payment-Dialog an erster Stelle und wird automatisch vorausgewählt.
• Kunden-Zahlungsziel hat Vorrang: Bei B2B-Kunden mit individuellen Zahlungszielen (z. B. 30 Tage netto) wird dieses jetzt bei Rechnungszahlungen verwendet.
• BIS ERP Rechnungen berücksichtigen Kunden-Zahlungsziel: Beim Erstellen von Einzelrechnungen wird das individuelle Zahlungsziel des Kunden automatisch angewendet.

Version 0.0.0.40 — Fulfillment-Kette: Versand-Push & Wareneingang

• Versanddaten an JTL gesendet: Wird eine Sendung in BIS ERP versendet (Status „shipped" + Tracking-Nummer), werden automatisch Lieferschein und Versanddaten in JTL angelegt.
• Wareneingang bucht Bestand korrekt: Wareneingänge erzeugen jetzt lückenlos Bestandsbewegungen, aktualisieren Lagerplatz- und Chargen/MHD-Bestände in einer Transaktion.
• Wareneingang vollständig bedienbar: Workflow „Entwurf → Bearbeiten → Abschließen". Pflichtfelder für MHD, Chargen und Seriennummern werden validiert.

Version 0.0.0.39 — Pfand B2B/B2C MwSt & konfigurierbare Pfandarten

Bei B2B-Kunden wird der Pfandbetrag jetzt korrekt als Nettobetrag behandelt — die MwSt wird aufgeschlagen. Bei B2C bleibt der Pfandbetrag inkl. MwSt. Pfand-Rückgabeartikel (Einwegpfand, Mehrwegflasche, Bierkiste etc.) lassen sich im Kundencenter unter „Pfandarten" verwalten. Änderungen werden sofort per FCM an alle POS-Geräte übertragen.

Version 0.0.0.38 — JTL-Kundensuche & Kunden-Push repariert

In neueren JTL-Versionen liegen Name, Adresse und Kontaktdaten nicht in tKunde, sondern in tAdresse. Die Suche wurde komplett auf einen JOIN mit tAdresse umgestellt. Kundennummer, Vorname, Nachname, Firma, E-Mail, Telefon und Mobilnummer werden jetzt alle durchsucht.