Versionsverlauf von BISpicy ERP

Steht der Auftrags-Abgleich auf bidirektional, wandert jetzt auch ein von Hand im BIS ERP angelegter Auftrag nach JTL. Bisher gingen nur Aufträge aus eBay, Shopify, Gambio und Etsy den Weg.

Lieferscheine, die aus dem Versand des BIS ERP in JTL entstanden, standen dort ohne Zeilen da: Kopf vorhanden, Positionen keine. Für JTL sah der Vorgang aus wie ein Lieferschein über nichts.

Ein am Packtisch versendeter Auftrag galt als versendet, trug aber kein Versanddatum — anders als Aufträge, die aus der Auftragsverwaltung, aus BISJustShip oder von eBay heraus versendet wurden.

Die Sendungsliste beginnt mit der neuesten Sendung, zeigt ab Werk Lieferadresse und Status und lässt sich frei einrichten — dauerhaft, auch am zweiten Gerät. Der Lieferschein kommt jetzt aus dem Design Studio und führt MHD, Charge und Serien-/IMEI-Nummer je Position auf.

Ob die Charge beim Entnehmen bestätigt werden muss, stand an drei Stellen — und Packtisch im Browser und Handheld folgten verschiedenen davon. Jetzt gibt es eine Einstellung mit drei Stufen, getrennt nur noch nach Kommissionierung und Packtisch.

Im Versandschritt steht jetzt die Versandart des Auftrags — statt „Versandweg" und „Versanddienstleister" nebeneinander, die dasselbe zweimal sagten. Die Auswahl bestimmt Dienstleister, Sendungsart und ob ein Label entsteht; eine andere Versandart lässt sich weiterhin wählen.

Plätze mit der Kennung „TRANSIT-" lassen sich nicht mehr von Hand anlegen — sie gehören den Zwischenplätzen, die beim Kommissionieren und Verpacken automatisch entstehen. Außerdem prüft die Einzelanlage jetzt wie die Massenanlage, ob es den Code im selben Lager schon gibt.

Am Packtisch entscheidet jetzt der erste Scan, in welcher Einheit die Menge zählt: Beim Gebinde-Barcode steht die benötigte Menge in Gebinden (48 Stück und ein 12er-Karton ergeben „4"), bei der Einzel-EAN in Stück. Der Bestätigungs-Scan bucht Menge × Gebinde. Ein Gebinde, das nicht in die Restmenge passt, wird abgelehnt, statt stillschweigend gekürzt zu werden.

Die Warteschlange am Packtisch blendet nicht vollständig lieferbare Aufträge aus — gemessen wurde bisher aber am Lager des Auftrags. Da Aufträge kein Lager tragen, zählte die Prüfung den Bestand aller Läger zusammen und war für Shop-, Marktplatz- und JTL-Aufträge wirkungslos. Jetzt zählt der Bestand im gewählten Lager.

Am Packtisch wird vorab ein Lager gewählt — im Browser wie am Handheld. Diese Wahl bestimmt jetzt durchgängig, woraus gearbeitet wird. Aufträge aus Shops, Marktplätzen und der JTL-Wawi gehören keinem Lager und erscheinen in jedem Lager zur Auswahl; im Browser verschwanden sie bisher, sobald ein Lager gewählt war.

Die Liste der Arbeitsplätze in den Druck-Einstellungen beantwortet jetzt zuerst die Frage, die man beim Einrichten eines Druckers wirklich hat: Welcher PC ist gerade da? Verbundene und eingerichtete Arbeitsplätze stehen oben, alte namenlose Einträge räumen sich weg.

Zwei Dinge, die den Packer bisher vor ein leeres Regal schickten: Aufträge ohne Bestand standen trotzdem in der Warteschlange, und der Chargendialog bot Chargen an, die am Lagerplatz der Position gar nicht liegen.

Nimmt der Packer eine Position am Gerät zurück, wird sie jetzt auch dann korrekt vom Packplatz zurückgebucht, wenn das Gerät die Charge nicht kennt — etwa nach einem Neustart der App oder bei einem Karton von vor der Umstellung. Bisher meldete das Gerät „Nicht zurückgebucht", obwohl die Ware sichtbar auf dem Packplatz lag.

Gebucht wird jetzt beim Scannen statt erst beim Kartonabschluss — damit ist zu jedem Zeitpunkt ablesbar, wo sich ein Artikel befindet. Zusätzlich deckt eine gewählte Charge nur noch so viel Menge ab, wie an ihrem Platz wirklich liegt.

Ware, die aus dem Regal entnommen ist, verschwindet nicht mehr aus dem Bestand. Bisher buchte die Kommissionierung die Menge sofort komplett aus — zwischen Regal und Versandkarton existierte der Artikel im System nicht mehr. Jetzt ist die Entnahme eine Umlagerung: Kommissionierwagen und Packplatz sind eigene Lagerplätze.

Beim Versand zieht das System den Bestand jetzt von dem Lagerplatz ab, den der Mitarbeiter am Gerät bestätigt hat. Bisher entschied allein die Bestandsstrategie, welche Bestandszeile sinkt — lag derselbe Artikel mit derselben Charge an zwei Plätzen, konnte der Abzug den falschen Platz treffen. Der Gesamtbestand stimmte, die einzelnen Platzbestände liefen auseinander.

Beim Verpacken zählte ein Scan bisher genau ein Stück — sechs lose Stück bedeuteten sechs Scans. Die neue Einstellung lässt die Stückzahl vor dem Scan einstellen, per Plus/Minus oder Ziffernfeld. Führt das Lager Lagerplätze, arbeitet der Packtisch zusätzlich geführt: nächste offene Position in Laufwegreihenfolge, Menge bereits vorbelegt. Ab Werk ausgeschaltet.

Die Mandanten-Auswahl beim Login (eingeführt mit 0.0.0.405) erreicht jetzt alle Oberflächen: WebPOS, die Dokumentenverwaltung, die Kassen-App und die Lager-App zeigen bei einer E-Mail mit mehreren Mandanten die Firmenauswahl — jeweils für Passwort- und Google-Anmeldung. Die Registrierungs-Sperre für bereits vergebene E-Mail-Adressen wurde zusätzlich gegen parallele Versuche und Schreibweisen-Tricks gehärtet.

Zwei neue Einstellungen für Kommissionieren und Verpacken, beide ab Werk ausgeschaltet. Erstens: Der Lagerplatz wird vor dem Artikel gescannt — greift der Mitarbeiter zu Ware, die laut Bestand woanders liegt, wird der Scan abgewiesen und die Meldung nennt den richtigen Platz. Zweitens: Das Mindesthaltbarkeitsdatum lässt sich auch dann bestätigen, wenn nur eine einzige Charge im Bestand liegt — bisher wurde sie stillschweigend gebucht.

Beim Verpacken am Lagergerät wird die Menge ausschließlich gescannt. Bisher ließ sie sich mit einem Plus-Knopf frei hochzählen, und ein Tipp legte die gesamte Restmenge auf einen Schlag in den Karton — damit war ein ganzer Auftrag abschließbar, ohne die Ware je vor den Scanner gehalten zu haben. Korrigieren bleibt möglich: Der Minus-Knopf nimmt einen Fehlscan einzeln zurück. Betriebe, die es anders brauchen, schalten das freie Zählen unter Einstellungen wieder frei.

Dieselbe E-Mail-Adresse kann jetzt bei mehreren Mandanten als Benutzer registriert sein — etwa für Steuerberater, die mehrere BISpicy-Kunden betreuen, oder Servicepartner mit Zugang zu mehreren Betrieben. Gehört ein Konto zu mehreren Mandanten, erscheint beim Login eine Auswahl der Firmennamen; das gilt auch für die Google-Anmeldung. Das Passwort gilt kontoweit für alle verknüpften Mandanten.

Einige Mandanten-Datenbanken trugen ein abweichendes Spaltenschema in der Kundentabelle — von der Kasse angelegte Kunden kamen dort nie an. Die Datenbanken gleichen sich jetzt automatisch an. Dabei gleich mit repariert: Sammelrechnungs-Lauf, Neukunden-Zähler, Top-Kunden/RFM-Analyse, Käuferadresse auf Gutschriften und der DATEV-Debitorensync fragten veraltete Spaltennamen ab und liefen still ins Leere.

Wurde ein Kundenverkauf an der Kasse storniert, kam der Storno-Beleg bisher ohne Kundenzuordnung an und wurde in BIS ERP und JTL als „POS-Laufkunde" gebucht — obwohl der Original-Beleg einem echten Kunden zugeordnet war. Ab sofort erbt der Storno-Beleg beim Eintreffen automatisch den Kunden seines Originalbelegs.

Der Scan eines Reparaturauftrag-Belegs im Web-POS funktionierte nur mit exaktem „REP-"-Präfix und braven Scannern — eigene Nummernkreise oder ein US-Tastaturlayout endeten stumm in der Artikelsuche. Jetzt wird normalisiert verglichen, ein Scan ins Suchfeld funktioniert, und jede Scan-Aktion meldet sich sichtbar zurück. Außerdem neu: optionales Geburtsdatum in den Verkäuferdaten des §25a-Geräteankaufs.

Der Kassenabschluss (Z-Bon) sah je nach Weg unterschiedlich aus: Kundencenter-Download, PDF-Export an der Kasse, E-Mail-Z-Bon und DATEV-Versand nutzten vier verschiedene Vorlagen. Ab sofort erstellt die Kasse das PDF selbst — in genau einem Layout — und überträgt es beim Abschluss automatisch ins Kundencenter, wo es unveränderlich gespeichert wird. Auch die Kasseneröffnung liegt jetzt als eigenes PDF vor.

Nach einem Kassenverkauf entstand die Rechnung korrekt — mit richtigen Beträgen und allen Positionen — blieb dann aber liegen: keine Mail an den Kunden, kein Versanddatum. Und ein am Handgerät als „Karton" angelegtes Gebinde hiess nach dem JTL-Abgleich plötzlich „10er Gebinde". Beides ist behoben.

Die Bezeichnung eines Gebindes entscheidet, als welche Einheit es in JTL ankommt. Bisher war das freie Eingabe — mit der Folge, dass die JTL-Gebindeverwaltung solche Gebinde gar nicht anzeigte. Jetzt sind die Bezeichnungen eine gepflegte Liste unter Einstellungen → Artikel, die sich in beide Richtungen mit JTL abgleichen lässt.

Am Handgerät angelegte Gebinde standen vollständig und richtig in JTL — und waren in der Gebindeverwaltung trotzdem nicht zu sehen. Der Grund lag in einem Feld, das seinen Namen nicht verdient: Was wie ein Bezeichnungsfeld aussieht, ist in JTL die Einheit des Gebindes — eine Auswahlliste (Stück, Karton, Palette …). Wir schrieben dort den Gebindenamen hinein („Tray"), und zu so einem Wert blendet die Warenwirtschaft die Zeile komplett aus.

Wer am Lager-Handgerät ein Gebinde mit eigenem Barcode anlegte, hatte danach drei Enttäuschungen — obwohl alles korrekt gespeichert war: In der JTL-Gebindeverwaltung tauchte es nicht auf, an der Kasse liess es sich nicht scannen, und am Handgerät war es mal auffindbar und mal nicht. Alle drei Ursachen sind behoben.

Wer einen Artikel in BIS ERP oder am Handgerät änderte — Barcode, Preis, Einkaufspreis, Gewicht, Status — konnte erleben, dass die Änderung in JTL nie ankam. Ohne Fehlermeldung: In der Warenwirtschaft stand der neue Wert, drüben der alte. Ursache war der Abgleich aus JTL, der an jedem Artikel „zuletzt nach JTL übertragen" vermerkte — auch wenn gar nichts übertragen wurde.

Trägt jemand eine EAN ein, die es schon gibt, sagt das System jetzt, wo sie hängt — als Standard-EAN, als weitere EAN oder in einem bestimmten Gebinde eines genannten Artikels. Vorher stand dort nur „bereits vergeben", und an drei Stellen wurde gar nicht oder nur halb geprüft.

Die Retourenannahme am Handgerät läuft jetzt auf das eingestellte Lager. Ist keines gewählt, sagt das Gerät das schon beim ersten Scan — statt die Ware erst auszupacken und dann festzustellen, dass sie nirgends hingebucht werden kann.

Artikel ohne hinterlegten Barcode ließen sich am Handgerät nicht zubuchen: Die Buchung brach mit einer Fehlermeldung ab, die nichts erklärte. Betroffen war alles, was über die Artikelnummer vom Regal-Etikett gescannt wird — bei einem Kunden 422 von 1.552 Artikeln. Solche Artikel bucht die Lager-App jetzt über die Artikelnummer, und der Vorgang läuft normal durch.

Ein am Handgerät angelegtes Gebinde ließ sich kurze Zeit später weder ändern noch löschen. Der JTL-Abgleich baut die Gebinde eines Artikels neu auf und vergab dabei jedes Mal neue Kennungen — wer die Artikel-Auskunft offen hatte, griff danach auf eine Zeile zu, die es unter dieser Kennung nicht mehr gab. Am Gerät sah das aus, als würde die Pflege nicht angenommen.

Wer am Handgerät ein Lager gewählt hat, arbeitet ab sofort ausschließlich mit dessen Bestand. Bisher suchte eine Buchung die passende Bestandszeile allein über Artikel, Haltbarkeit, Lagerplatz und Charge — das Lager kam darin nicht vor. Passte die Kombination, landete eine Zubuchung für Mönchengladbach in Krefeld.

Führt ein Artikel ein Mindesthaltbarkeitsdatum, fragt das Handgerät ab sofort auch beim Einbuchen danach — bisher wurde nur beim Ausbuchen danach verlangt. Diese Schieflage hatte eine unangenehme Folge: Ware kam ohne Datum in den Bestand, und beim späteren Ausbuchen verlangte das System eine Charge, die es zu diesem Artikel nie gab.

Wer Lagerplätze angelegt hat, arbeitet ab sofort auch verlässlich mit ihnen. Bisher konnte eine Zubuchung am Handgerät mitten in einer Serie ohne Lagerplatz durchgehen — ohne Hinweis. Die Ware landete im Bestand, aber ohne Platz. Die Frage „führt dieses Lager Lagerplätze?" beantwortet jetzt der Server; bleibt die Antwort aus, wird nicht ohne Platz gebucht, sondern sichtbar gewartet.

Wer einen Mitarbeiter anlegt, bekommt jetzt das, was er erwartet: Der Kollege erhält eine Bestätigungsmail, öffnet den Link und kann sich anmelden. Bisher endete das still in einer Sackgasse — der Zugang wurde angelegt, aber es ging keine Mail raus, und ohne bestätigte Adresse weist die Anmeldung jeden ab.

Ein Artikel kann beliebig viele EANs haben — je nach Lieferant ein anderer Barcode. Die zuerst gepflegte EAN ist die Standard-EAN, alle weiteren lassen sich hinzufügen, ändern, löschen oder zur Standard-EAN machen. Die Gebindeverwaltung bleibt für Kisten, Träger und Paletten.

Die Historie zeigt jeden Schritt mit Bezug: von welchem Lagerplatz auf welchen Kommissionierwagen, für welche Pickliste und welchen Auftrag — und danach den Versand, der bisher ganz fehlte, wenn vorher kommissioniert wurde.

Beim Verpacken wird zu jedem Stück eines seriennummernpflichtigen Artikels die Nummer erfasst — bisher fragte das Lagergerät dort gar nicht danach. Die Nummer hängt jetzt am Auftrag und ist in der Auftragsansicht sichtbar, samt Empfänger und Verkaufsdatum.

Liegen mehrere Chargen eines Artikels im Lager, entscheidet jetzt überall dieselbe eingestellte Strategie, welche rausgeht — beim Verpacken, Kommissionieren, Schnellversand, bei Sendungen und Korrekturen. Am Lagergerät wird bei mehreren Chargen nachgefragt, die passende steht vorausgewählt.

Antwortete der Mailserver langsam, wartete die Anwendung bis zu 60 Sekunden auf ihn — genau die Zeitspanne, nach der die Verbindung abbricht. Jetzt sind es höchstens 10 Sekunden, ein hängender Mailserver kann keinen Vorgang mehr zum Abbruch bringen.

Sicherungen liegen jetzt im Objektspeicher statt auf dem Anwendungsserver und überstehen damit jede Aktualisierung. Der komplette Weg wurde einmal durchgespielt: Sicherung erstellen, Zugang löschen, Daten in einem neuen Zugang wiederherstellen.

Am Handheld beginnt das Verpacken nicht mehr nur mit der Auftragsnummer: Ein Artikel-Scan zeigt alle Aufträge, die diesen Artikel enthalten. Gebinde-Barcodes werden mit ihrer Stückzahl verrechnet — der Scan eines 12er-Kartons legt 12 Stück ins Packstück.

Zugänge, die 90 Tage lang nicht genutzt werden, durchlaufen künftig eine Erinnerungskette: 90 Tage bis zur Deaktivierung, weitere 30 bis zur Löschung. Eine einzige Anmeldung stoppt den Vorgang jederzeit — vom letzten Zugriff bis zur Löschung vergehen rund sieben Monate.

Ohne bestätigte E-Mail-Adresse ist keine Anmeldung mehr möglich — weder in BIS ERP, noch im Kundencenter, noch an der Kasse. Bisher war die Bestätigungsmail nur eine Empfehlung.

Das Anlegen eines Zugangs wird jetzt binnen Sekunden bestätigt — der Aufbau der Betriebsdatenbank läuft danach im Hintergrund weiter. Bisher wartete die Seite darauf und meldete am Ende teils einen Fehler, obwohl das Konto längst stand.

Führt die Kasse die Artikel (POS → BIS ERP oder bidirektional), wird eine an der Kasse gelöschte Warengruppe jetzt auch in BIS ERP gelöscht — der Artikel-Sync legt sie nicht mehr wieder an. Andere Kassen räumen sie beim nächsten Abgleich ebenfalls ab.

Zu jedem Packstück lässt sich am Packtisch ein Etikett (100 × 150 mm) drucken — „Palette 1 von 3“, Empfänger, Absender, Inhalt und Barcode. Das Layout ist eine Vorlage im Formulardesigner und damit selbst anpassbar.

Die Zone „Inland" trug intern dieselbe Kennung wie der Ländercode für Deutschland. Bei einem Betrieb außerhalb Deutschlands galt eine Lieferung nach Deutschland dadurch als Inlandsversand und zog den falschen Tarif.

Bei den Fulfillment-Konditionen wurde der Pick-Aufschlag erst ab der zweiten Position berechnet — in der Annahme, der erste Pick stecke in der Auftragspauschale. Dienstleister rechnen üblicherweise jede Position, auch die erste.

Die Auswahl „Sonstige (selbst benennen)" bei den Versandarten sprang sofort auf „Keiner" zurück — ein eigener Spediteur ließ sich damit nicht anlegen. Außerdem meint die Zone „Inland" jetzt tatsächlich Ihr Land statt fest Deutschland.

Der mobile Packtisch verteilt einen Auftrag auf beliebig viele Packstücke — diese Information blieb bisher am Gerät. Im Auftrag gibt es jetzt den Bereich „Packstücke" mit Inhalt und Gewicht je Palette, beides nachträglich korrigierbar.

Für den eigenen Versand gab es bisher keinen Ort, um Konditionen zu hinterlegen — was ein Paket kostet, tauchte erst nach dem Import einer Paketdienst-Rechnung auf. Jetzt legen Sie je Versandart eine Staffel an, und die Margenübersicht trennt sauber zwischen dem, was der Käufer zahlt, und dem, was Sie zahlen.

Die erwartete Marge je Verkaufskanal zeigte eine Reihe Zahlen ohne Überschrift und nur Prozentwerte. Jetzt hat sie eine Kopfzeile, nennt den Gewinn in Euro und stellt die Versandmodelle nebeneinander — inklusive des Preises, den kostenloser Versand voraussetzt.

Der mobile Packtisch kannte nur ein Paket je Auftrag — bei einer Palette aus zwanzig einzeln verpackten Kartons ging das nicht auf. Jetzt packen Sie einen Auftrag in beliebig viele Packstücke, wahlweise als Paketsendungen mit je eigenem Etikett oder als eine Speditionssendung.

Die erwartete Marge je Verkaufskanal zeigte weiter den alten, gespeicherten Preis — blind genau in dem Moment, in dem man einen Preis sucht. Jetzt folgt sie dem Formular und weist zusätzlich die Fulfillment-Kosten des Standorts aus, noch vor dem Verkauf.

Die Lagerplatz-Übersicht wies jeden Platz als leer aus, und die MHD-Liste eines Artikels blieb leer. Beides las aus derselben Altlast wie 0.0.0.366 — der zweiten Bestandstabelle, in der längst nichts mehr ankam.

Die Artikelliste zeigte einen anderen Bestand als der Artikel selbst, und Gebinde konnten Ware anbieten, die es nicht mehr gab. Beides hatte dieselbe Ursache: Der Bestand wurde an mehreren Stellen unterschiedlich zusammengerechnet. Ab jetzt kommt jede Zahl aus einer Quelle.

Die Lager-App konnte bisher nur buchen. Jetzt scannen Sie einen Barcode und sehen alles zum Artikel — und korrigieren EAN, Gebinde-EAN und Fotos gleich vor Ort, ohne zurück an den Rechner zu müssen.

Bisher kannte die BIS AI Bridge genau eine JTL-Datenbank — wer mehrere Firmen betreibt, hätte das Programm mehrfach installieren müssen. Jetzt tragen Sie beliebig viele Datenbanken ein, jede mit einem Namen Ihrer Wahl, und Ihre KI wählt beim Fragen selbst aus.

Der Abgleich der Kundenstammdaten aus JTL-Wawi hat bei aktuellen JTL-Versionen keinen einzigen Kunden übernommen. Aufgefallen ist es an anderer Stelle: Rechnungen aus dem Rechnungskauf an der Kasse enthielten keine E-Mail-Adresse, obwohl der Kunde in JTL eine hinterlegt hat — der Versand wurde dann stillschweigend übersprungen.

Die neue BIS AI Bridge verbindet Ihre eigene KI (Claude, ChatGPT, Cursor) direkt mit Ihrer JTL-Datenbank. Fragen in normaler Sprache stellen, Auswertungen erhalten und Daten ändern lassen — ohne SQL-Kenntnisse. Die Brücke läuft auf Ihrem Rechner, Ihre Daten verlassen Ihr Netzwerk nicht.

Wer seinen Tischplan im ERP oder Kundencenter pflegt, hat seine Bereiche — „Innenbereich", „Terrasse", „Bar" — bisher verloren, sobald ein Tisch an der Kasse das erste Mal belegt wurde. Ab sofort bleibt die Pflege erhalten.

Für Kunden sichtbar ist hier nichts — und das ist beabsichtigt. Diese Version schafft die Voraussetzung, Betriebe künftig auf mehrere Datenbank-Server zu verteilen statt alle auf einen zu halten.

Die Umkehrung von 0.0.0.358: Statt reihum jeden Betrieb zu fragen „hast du etwas zu tun?", meldet sich jetzt, wer etwas zu tun gegeben hat. Damit hängt die Last an der tatsächlichen Arbeit statt an der Zahl der Kunden.

Mehrere Hintergrundläufe haben bisher jede Minute jeden einzelnen Betrieb auf dem Server angetippt — auch die, die seit Wochen ruhen. Das hat die Datenbank für alle spürbar ausgebremst.

Mit über 20 Modulen war der Shop im Kundencenter unübersichtlich geworden. Er zeigt jetzt zuerst Ihre eigene Ausstattung, sortiert die Module nach Betriebsart und fasst Tarifstufen zu einem Eintrag zusammen.

Nach der Messung vom Mittag haben wir die nächsten beiden Bremsen gelöst: unnötige Tabellen-Umbauten im Support-Bereich und Leerschreibvorgänge beim Kassen-Abgleich.

Zählen Sie am Lager-Handgerät einen Artikel (freie Inventur bzw. Direktzählung), steht die neue Menge ab sofort unmittelbar auch in JTL-Wawi — statt erst mit dem nächsten regelmäßigen Abgleich.

Wir haben gemessen, womit die Datenbank ihre Zeit verbringt, und zwei Posten gefunden, die reine Verschwendung waren: ein fehlender Index auf der Zuordnungstabelle zwischen BIS ERP und JTL-Wawi sowie eine überflüssige Rückfrage bei jedem Tabellenzugriff.

Legen Sie ein differenzbesteuertes Gebrauchtgerät (§ 25a) in BIS ERP an oder pflegen Sie dort dessen IMEI/Seriennummer, übernimmt die Kasse diese Nummer ab sofort direkt — auf Kassenbon und A4-Rechnung steht damit immer die echte Gerätenummer.

Uhrzeiten in BIS ERP waren bislang zwei Stunden zu früh (im Winter eine): Die Server rechnen nach Weltzeit, angezeigt wurde diese Uhrzeit ungerechnet. Das ist jetzt durchgängig korrigiert — in der gesamten Oberfläche, im Kundenportal und auf allen Belegen, die BIS ERP druckt.

Ein nachträglich erfasster Einkaufspreis wird jetzt auch in JTL-Wawi eingetragen — direkt in der bereits gebuchten Wareneingangszeile. Es entsteht keine zweite Buchung: der Bestand bleibt unberührt, korrigiert wird nur der Wert.

Direktlieferung, Fulfillment-Dienstleister, extern erledigter Versand: Manchmal ist ein Auftrag beim Kunden, ohne dass Ware Ihr Lager verlassen hat. Der neue Weg „Als versendet markieren" setzt den Auftrag auf Versendet, lässt den Bestand aber unangetastet — mit Sendungsnummer, Meldung an den Marktplatz und jederzeit umkehrbar.

Der freie Wareneingang am Handgerät fragt den Einkaufspreis ab Werk nicht ab — stattdessen erinnert BIS ERP im Nachgang daran. Eine Meldung in der Glocke und eine Kachel auf der Startseite führen zur Nachtrags-Ansicht mit allen Positionen und eingetroffenen Mengen.

Sie bestimmen jetzt selbst, welcher Einkaufspreis Ihre Verkaufspreise bestimmt: gepflegter EK, Durchschnitt, letzter EK oder der Wert der Ware, die tatsächlich noch im Lager liegt (FIFO). Zusätzlich zeigt der Lagerwert überall dieselbe Zahl — die ABC-Analyse bewertete Artikel ohne Durchschnittspreis bisher mit 0 €.

BIS ERP lässt sich jetzt direkt mit Lexware Office (ehemals lexoffice) verbinden. Ausgangs- und Eingangsrechnungen sowie Gutschriften werden automatisch als Buchungsbelege übertragen — samt Kunden- und Lieferanten-Stammdaten. Einrichtung per API-Key, danach manuell, stündlich oder täglich. Teil von BIS Insights.

Bei angebundenem JTL bleiben Lagerplätze jetzt in beide Richtungen automatisch synchron: alle Plätze eines Lagers werden gespiegelt (nicht mehr nur belegte), Anlegen und Löschen funktioniert in JTL wie in BIS ERP — Löschen nur ohne Bestand. Ein Button „Mit JTL synchronisieren" gleicht ein Lager sofort ab.

Nach der platzgenauen Inventur zeigte die Artikelansicht trotzdem keinen Lagerplatz. Jetzt schreibt die Inventur auf den gescannten Platz, und der JTL-Bestandsabgleich spiegelt den Lagerplatz mit — der Platz bleibt in der Artikelansicht erhalten.

Wird am Lager-Handgerät ein Gebinde/Karton gescannt, bucht, zählt und lagert BIS ERP automatisch die enthaltene Einzelware in der richtigen Stückzahl (ein 30er-Karton wird zu 30 Stück, nicht „1"). MHD-, Chargen- und Lagerplatz-Angaben gehen dabei bis in JTL.

Die Bestandstabelle bekommt einen eindeutigen Schlüssel über alle Dimensionen (Artikel, Lager, Lagerplatz, Charge, MHD, Seriennummer, Herkunft) — doppelte Bestandszeilen sind damit strukturell unmöglich. Bestehende Duplikate werden automatisch zusammengeführt, die Mengen bleiben exakt erhalten.

Wer bei einer Inventur einen Lagerplatz scannt, erwartet den Bestand in JTL genau dort — bisher landete er auf dem „Boxenplatz". Der Ausweich-Platz bevorzugt jetzt echte Regalplätze, und der Inventur-Übertrag setzt den gezählten Bestand platzgenau fest, statt nur eine Differenz zu verrechnen.

Die Versandkonditionen eines Fulfillment-Dienstleisters werden jetzt pro Versandart gepflegt — je Produkt (z. B. DHL Warenpost, DHL Paket) eine eigene Staffel aus Zone/Land, Gewicht und Preis, wie auf der Preisliste. Zone/Land und Versandart wählt man aus einer Liste statt sie einzutippen; für die Kostenrechnung greift automatisch der günstigste passende Tarif.

Jede Bestandszeile trägt jetzt ihre Herkunft — JTL-Abgleich oder manuelle Buchung (Inventur, Wareneingang, Korrektur, Retoure, MDE). Der JTL-Abgleich räumt beim Aktualisieren nur noch seine eigenen Spiegel-Zeilen ab: Bestände in rein internen Lägern ohne JTL-Zuordnung werden vom Abgleich strukturell nie mehr angetastet.

Hinter den Kulissen beginnt der Umbau der Bestandsführung auf eine einzige Bestandstabelle. Der Auftakt: Die Retouren-Wiedereinlagerung bucht jetzt wirklich ins Lager, Zählungen überleben den JTL-Abgleich auch bei blockierter Übertragung, und eine tägliche Konsistenz-Überwachung misst die Genauigkeit der Bestandsdaten je Betrieb.

Die Benutzerlizenz gilt jetzt pro Gerät: mehrere Fenster oder Tabs am selben Computer sind eine Anmeldung und kosten keine zusätzliche Lizenz. Ein weiteres Gerät ist eine eigene Anmeldung – reicht die Lizenzanzahl nicht, wird das zuletzt genutzte andere Gerät automatisch abgemeldet, am Lager-Handheld in Sekunden. Der Server kennt jederzeit alle aktiven Anmeldungen und sorgt selbst für saubere Verhältnisse.

Ein Artikel oder Lagerplatz kann nur in einer offenen Inventur zugleich stecken. Wird er gerade in einer laufenden, geplanten, pausierten oder zu prüfenden Inventur gezählt, lässt er sich nicht in eine zweite aufnehmen — so werden zwei parallele Zählungen desselben Bestands vermieden. In der Auswahl bleibt er sichtbar, aber gesperrt, mit dem Hinweis „in INV-000012".

Die Inventur-Übersicht hat jetzt zwei Reiter: „Aktiv" zeigt alles, woran noch gearbeitet wird, „Archiv" sammelt die fertigen Inventuren. Außerdem werden in der Lagerübersicht am Artikel Läger ohne Bestand nicht mehr angezeigt.

Beim Anlegen einer Inventur nach Artikeln müssen Sie die Artikel nicht mehr auswendig kennen und einzeln suchen. Wählen Sie ein Lager und lassen Sie „Nur Artikel mit Bestand" aktiv — dann erscheint direkt eine Liste aller Artikel mit Bestand in diesem Lager, aus der Sie bequem auswählen.

Ein Schalter blendet beim Anlegen alle Artikel aus, die im gewählten Lager nichts liegen haben. Wichtiger noch: Bisher zeigte die Auswahl — und vor allem der Soll-Bestand in der Zählliste — den Bestand über alle Läger zusammen. Eine Inventur für ein einzelnes Lager bekam damit einen Sollwert, der Ware aus anderen Lägern enthielt, und jede Position zeigte eine Differenz, die es gar nicht gab.

Eine freigegebene Inventur schlägt sich jetzt verlässlich im Bestand nieder — bisher konnte eine Zählung wirkungslos verpuffen, wenn der Bestand am Lager statt an einem einzelnen Lagerplatz hing. Gezählt wird immer genau ein Lager, und mehrere Mindesthaltbarkeitsdaten je Artikel und Lagerplatz lassen sich einzeln erfassen.

Eine versehentlich angelegte Inventur blieb bisher dauerhaft in der Liste stehen — es gab keine Möglichkeit, sie loszuwerden. Jetzt lässt sie sich löschen, und solange noch niemand gezählt hat, auch nachträglich ändern: Termin, Zuständiger, Notizen und vor allem der Umfang selbst, also welche Artikel oder Lagerplätze gezählt werden.

Wird am Lager-Scanner ein Gebinde gescannt — ein 6er-Karton, eine 24er-Palette —, wird die Buchung jetzt abgelehnt, mit klarem Hinweis auf die zu buchende Einzelware und die Stückzahl. Ein Gebinde hat keinen eigenen Bestand: im Regal liegen die Einzelstücke. Wurde trotzdem darauf gebucht, lag der Bestand am falschen Artikel, es wurde nicht nach dem Mindesthaltbarkeitsdatum gefragt, und die Übertragung an JTL lief ins Leere.

Das Verbuchen einer Bestandskorrektur dauerte bis zu drei Sekunden — unvorhersehbar mal eine halbe, mal drei. Jetzt sind es rund drei Zehntelsekunden, gleichbleibend. Der Grund war nicht die Buchung: Vor jeder Anfrage prüfte das System die Datenbankstruktur des Mandanten erneut, für eine Bestandsbuchung über 40 einzelne Abfragen. Jetzt merkt es sich pro Mandant, dass die Prüfung für den aktuellen Programmstand erledigt ist — aus über 40 Abfragen wird eine.

Scannen Sie den Barcode eines 6er-Kartons, steht in der Maske jetzt die Einzelflasche mit Menge 6 — denn im Regal liegen sechs Flaschen, nicht ein Karton. Bisher wurde der Bestand auf das Gebinde gebucht statt auf die Einzelware, es wurde nicht nach dem Mindesthaltbarkeitsdatum gefragt, und die Übertragung nach JTL lief ins Leere, weil Gebinde dort meist keine eigenen Artikel sind.

Beim Scannen eines Artikels in der Bestandskorrektur dauerte es nach dem Enter rund fünf Sekunden, bis der Artikel dastand — jetzt etwa eine. Der Grund war nicht ein langsamer Server, sondern die Anzahl der Abfragen: erst eine Trefferliste, dann eine gezielte Nachfrage, dann das vollständige Nachladen. Jetzt genügt eine einzige Abfrage, die den gescannten Code direkt nachschlägt.

In der Bestandskorrektur erschienen bei der Artikelsuche auch Stücklisten — bei „2201" etwa 18 von 19 Treffern. Eine Stückliste liegt physisch nicht im Regal und lässt sich weder zählen noch buchen; sie taucht dort nicht mehr auf. Zusätzlich lässt sich die Suche auf SKU, Name oder EAN eingrenzen, wie beim Anlegen einer Inventur. Nebenbei laden die betroffenen Masken nicht mehr den kompletten Artikelstamm beim Öffnen.

Bei einer Rechnung in Dollar, Franken oder Baht bucht die Bank einen Euro-Betrag ab, den das System bisher nur über den amtlichen Tageskurs schätzen konnte — die Bank rechnet aber zu ihrem Kurs ab. Jetzt merkt sich BIS ERP bei der Zuordnung den echten Betrag, und alle Auswertungen rechnen mit ihm statt mit einer Schätzung.

Die Inventur führt jetzt Schritt für Schritt: Lagerplatz scannen, Artikel scannen, Menge eingeben, bei Bedarf Charge, Mindesthaltbarkeit und Seriennummern — bestätigen, weiter zum nächsten Artikel. Gleich im BIS ERP und in der Lager-App. Der erwartete Bestand wird dabei nicht mehr angezeigt: Wer die Sollmenge sieht, übernimmt sie erfahrungsgemäß, statt zu zählen.

Bisher war „Nachzählen" in der Inventur-Prüfung folgenlos: Wer eine Zählung anzweifelte, klickte ins Leere — die Inventur blieb mit der zweifelhaften Menge stehen. Jetzt wird die Position tatsächlich wieder geöffnet, das System führt sie als 2. Zählung, und der Inventurbericht dokumentiert jede Runde.

Bei der Ad-hoc-Inventur mussten die Lagerplatz-Codes bisher von Hand eingetippt werden — man musste sie auswendig kennen, Tippfehler fielen erst hinterher auf. Jetzt werden die vorhandenen Lagerplätze aufgelistet und angeklickt, mit Suchfeld und Bereichsauswahl per Umschalttaste. Außerdem wird der zuständige Mitarbeiter aus einer Liste gewählt — und die Zuweisung entscheidet nun darüber, wer die Inventur sieht.

Die Inventur-Übersicht sagt jetzt direkt, wie viel noch zu zählen ist — „2 Artikel offen" statt nur „1 / 3". Bei Inventuren nach Artikeln ist das die Zahl, auf die es ankommt; bisher musste man sie im Kopf ausrechnen.

Bei einer Inventur nach Artikeln stand in der Übersicht bisher die Zahl der betroffenen Lagerplätze. Wer drei Artikel ausgewählt hatte, die sich zwei Lagerplätze teilen, las „0 / 2" und musste annehmen, ein Artikel sei verlorengegangen — vorhanden waren sie immer, nur die Bezugsgröße war die falsche.

Die Artikelsuche beim Anlegen einer Inventur findet jetzt zuverlässig den Artikel, den Sie meinen — und das spürbar schneller. Bisher wurden die Treffer nach Anlagedatum sortiert: Wer nach der Artikelnummer 2201 suchte, bekam zuerst alle später angelegten Artikel zu sehen, während der Artikel 2201 selbst ans Ende rutschte und abgeschnitten wurde.

Meldet sich eine Störung im BIS ERP, kann unser Support sie ab sofort nachträglich einsehen — Sie müssen den Fehler nicht mehr eigens nachstellen, damit wir ihn sehen. Bisher fehlte uns bei einer Fehlermeldung genau das, was zählt: Brach die Anwendung mit dem Hinweis „Die Anwendung wurde aktualisiert" ab, war die eigentliche Ursache nirgends nachlesbar.

Meldet sich derselbe Benutzer im BIS ERP an, während er noch am Lager-Scanner angemeldet ist, wird die Anmeldung am Scanner jetzt tatsächlich beendet. Bisher blieb der Scanner weiter benutzbar, obwohl seine Anmeldung serverseitig schon beendet war — er holte sich im Hintergrund einen neuen Zugangsschlüssel, der anschließend nicht mehr überprüft wurde. Damit ließ sich derselbe Zugang unbemerkt dauerhaft auf mehreren Geräten nutzen.

Wer viele Lagerplätze auf einmal anlegen wollte, kam ab einigen tausend Plätzen nicht mehr durch: Der Vorgang brach nach ein bis zwei Minuten mit „Fehler: HTTP 504" ab — und es war kein einziger Platz angelegt. Die Anlage läuft jetzt in Blöcken mit sichtbarem Fortschritt und überspringt bereits vorhandene Plätze, sodass ein unterbrochener Lauf gefahrlos neu gestartet werden kann. Außerdem: Lager-Scanner werden nicht mehr gegen das Kassen-Gerätelimit geprüft, und die Benutzerverwaltung zeigt wieder die vorhandenen Benutzer.

Eine Inventur über mehrere Artikel wirkte eingefroren: Nach jeder gezählten Position landete man erneut bei „Lagerplatz scannen", und ein Klick auf Bestätigen ohne erneuten Scan blieb ohne jede Reaktion. Jetzt wird ein Lagerplatz nur noch einmal gescannt, der Knopf sagt, was fehlt, und am Ende erscheint ein Abschluss-Bildschirm statt eines Rücksprungs auf den ersten Artikel.

Die Einstellung „frühestens X Stunden im Voraus buchbar" war faktisch aufgehoben — die Buchungsseite bot Termine an, die nur Minuten entfernt waren. Ursache: Die Server rechnen in UTC, Termine und Öffnungszeiten stehen aber in der Ortszeit des Betriebs. Maßgeblich ist jetzt durchgängig die Zeitzone des Betriebs.

Mehrere Bereiche haben E-Mails über einen internen Weg verschickt, der live nichts zugestellt hat — ohne jede Fehlermeldung. Kundenportal, Newsletter, Gelangensbestätigungen und die Automatisierungs-Aktion „E-Mail senden" nutzen jetzt Ihren eigenen SMTP-Zugang, sonst den E-Mail-Versand von BISpicy.

Ein gebuchter Termin belegt jetzt zuverlässig eine Person — der Zeitraum verschwindet damit aus der Auswahl, statt weiterhin buchbar zu bleiben. Zusätzlich sieht der Gast, wer ihn behandelt, und erhält seine Bestätigung wieder per E-Mail.

Feinste Ausbaustufe der Lager-Verfügbarkeit: In den Lagereinstellungen lässt sich ein Lager gezielt für einzelne Verkaufskanäle blockieren. Angehakte Kanäle sehen den Bestand dieses Lagers nicht mehr als verfügbar; alle anderen zählen ihn weiter. So steuern Sie pro Kanal, aus welchen Lägern verkauft wird.

Fordert ein Kunde an der Kasse seine Rechnung per E-Mail an, erhält er jetzt zuverlässig seinen eigenen Beleg — auch bei Betrieben mit mehreren Kassen, bei denen sich Bonnummern wiederholen können. Die Rechnung wird eindeutig dem richtigen Verkauf und der anfragenden Kasse zugeordnet.

In JTL-Wawi angelegte Lieferantenbestellungen erscheinen jetzt in BIS ERP und lassen sich direkt am MDE-Handheld abarbeiten: Bestellung per Nummer oder Scan öffnen, gelieferte Menge (mit MHD/Charge/Serie) erfassen, Wareneingang buchen. Der Wareneingang wird korrekt zurück nach JTL gebucht — Bestand, gelieferte Menge und Bestellstatus werden dort automatisch aktualisiert.

Ergänzend zur lagerweiten Blockierung (0.0.0.304) lässt sich im Artikel-Tab „Lager" für einen einzelnen Artikel ein Lager als „Für Verkauf blockieren" schalten. Sein Bestand zählt dann nur für diesen Artikel nicht mehr als verfügbar; der Gesamtbestand wird sofort neu berechnet. Feinste Stufe des Lager-Verfügbarkeitssystems.

Liegt ein Artikel in mehreren Lägern, zählt jetzt die Summe aller Läger als verfügbarer Bestand. In den Lagereinstellungen lässt sich ein Lager als „Für Verkauf blockieren" markieren, sodass sein Bestand nicht mehr mitzählt. Bei gleichzeitiger JTL- und Fulfillment-Network-Anbindung erkennt BIS ERP den JTL-Spiegel eines Fulfillment-Lagers automatisch und rechnet ihn nicht doppelt, während echter Filial-/Ladenbestand normal weiterzählt.

Der Zahlungsabgleich ordnet Ausgangszahlungen an Lieferanten jetzt auch dann automatisch der passenden Eingangsrechnung zu, wenn der Bankauszug keinen Verwendungszweck enthält (z. B. beim CSV-Export von Revolut) — anhand von Empfängername und Betrag. Unterschiedliche Schreibweisen wie „CLAUDE" statt „Anthropic, PBC" oder „Hetzner" statt „Hetzner Online GmbH" werden erkannt. Einmal manuell zugeordnete Empfänger merkt sich BIS ERP als Lieferant, sodass künftige Importe automatisch treffen.

Ergänzend zu 0.0.0.301: Bei gleichzeitiger Anbindung von JTL und dem JTL-Fulfillment-Network führt BIS ERP den Bestand FFN-geführter Artikel jetzt durchgängig aus dem Fulfillment-Network — auch in der Lager-Detailansicht und nach „Bestand neu berechnen". Der veraltete JTL-Spiegel fließt nicht mehr in die Bestandsrechnung ein, sodass der korrigierte Wert nicht mehr überschrieben wird.

Wer die Warenwirtschaft parallel über JTL und das JTL-Fulfillment-Network (über unsere direkte Schnittstelle) betreibt, hatte denselben Artikel bisher aus zwei Quellen mit unterschiedlichen Beständen — der angezeigte Wert konnte hin- und herspringen. Ab sofort führt für Artikel beim Fulfillment-Dienstleister dessen Bestand; BIS ERP erkennt diesen Sonderfall automatisch und lässt den JTL-Abgleich sie nicht mehr überschreiben.

Wer über einen Fulfillment-Dienstleister (JTL-Fulfillment-Network) versenden lässt, kann jetzt pro Standort die Konditionen des Dienstleisters hinterlegen. BIS ERP berechnet daraus für jeden versendeten Auftrag die tatsächlichen Fulfillment- und Versandkosten und zieht sie in der Gewinnübersicht ab — bisher fehlten sie und die Marge wirkte zu gut.

In den Schnittstellen lässt sich einstellen, wer die Artikel führt — Kasse oder Warenwirtschaft. Diese Einstellung wurde bislang nur teilweise befolgt: Preise, Bestand und Stammdaten überschrieb die Kasse immer, selbst wenn die Warenwirtschaft führt. Umgekehrt schlug eine an der Kasse vorgenommene Löschung bei kassengeführten Betrieben nicht durch. Beides ist behoben.

Im Zahlungsabgleich lässt sich jetzt der Kontoauszug von N26 direkt als CSV importieren — zusätzlich zur Revolut-Vorlage. Die Datei wird beim Import automatisch als N26 erkannt, das Format muss nicht von Hand gewählt werden.

Der Abgleich drehte sich im Kreis: rund um die Uhr, alle 66 Sekunden, ging der komplette Artikelbestand an die Kasse, wurde bestätigt und in der nächsten Runde erneut geschickt. Auslöser war eine Zählprüfung, die bei einer Differenz alle Empfangsbestätigungen verwarf — auch wenn nur ein einziger Artikel fehlte.

Zwei Fehler auf derselben Rechnung: Positionsrabatte wurden nicht berücksichtigt — aus einem Verkauf über 473,00 € wurde eine Rechnung über 483,00 €, obwohl der Kunde den niedrigeren Betrag bezahlt hatte. Und der Beleg trug gleichzeitig den Stempel „BEZAHLT" und ein Zahlungsziel mit Überweisungsaufforderung.

Auf der Rechnung war nicht erkennbar, ob bar oder unbar gezahlt wurde. Die Angabe wurde zwar mitgeführt, aber nur als interne Notizzeile — im Feld „Zahlungsart" stand unabhängig davon immer „Rechnung", selbst bei einer Barzahlung.

Wurde ein Artikel an der Kasse gelöscht, tauchte er kurze Zeit später wieder auf. Der Grund: Bei jedem Abgleich meldete die Kasse ihre Artikel an die Warenwirtschaft — auch unveränderte wurden dort als „soeben geändert" markiert. Die Warenwirtschaft hielt daraufhin den kompletten Katalog für neu und schickte ihn zurück, mitsamt der gerade gelöschten Artikel.

Auf der A4-Rechnung stand gelegentlich ein Cent weniger als auf dem Kassenbon: Aus „459,00 € × 1" wurden 458,99 €, aus einem Verkauf über 778,00 € eine Rechnung über 777,99 €. Der Kunde hatte den vollen Betrag bezahlt. Ursache war, dass die Kasse vom Bruttopreis aus rechnet, die Rechnung dagegen zuerst den Nettobetrag ermittelte und die Umsatzsteuer wieder daraufschlug.

Manche Rechnungen brauchen von Gesetzes wegen einen zusätzlichen Satz — etwa beim Verkauf gebrauchter Geräte („Differenzbesteuerung"), bei einer Lieferung ins EU-Ausland oder wenn Sie Kleinunternehmer sind. Dieser Satz wurde zu jeder Rechnung korrekt hinterlegt, erschien aber auf keinem Ausdruck. Gerechnet war die Rechnung richtig — auf dem Papier fehlte jedoch eine Pflichtangabe.

Nach dem Neuaufsetzen einer Kasse konnte für neue Verkäufe kein digitaler Bon mehr erstellt werden. An der Kasse war davon nichts zu sehen — der Verkauf lief normal durch. Scannte der Kunde den QR-Code, bekam er stattdessen einen älteren Beleg desselben Geschäfts zu sehen, mit falschem Datum und falschem Betrag. Der Grund: Die Belege wurden intern über die Verkaufsnummer des Geräts zugeordnet, und die beginnt nach einem Neuaufsetzen wieder bei 1.

Nehmen Sie ein Gerät zur Reparatur an oder kaufen eines an, erfassen Sie Gerät/Schaden, IMEI/Seriennummer und Vertragsnummer als eigene Felder. Diese Angaben begleiten den Vorgang jetzt lückenlos bis auf die Rechnung — vorher mussten sie behelfsweise über Zusatzartikel erfasst werden und fehlten auf der A4.

Sobald der erste Lieferschein angelegt war, ließ sich die Lieferschein-Übersicht nicht mehr öffnen — sie antwortete mit einem Serverfehler. Solange noch gar kein Lieferschein existierte, fiel das nicht auf: Der fehlerhafte Programmteil wird erst durchlaufen, wenn es etwas anzuzeigen gibt.

Wurde ein Lieferschein aus einer Sendung erzeugt, blieb das Empfängerfeld leer — kein Name, keine Anschrift. Die Positionen stimmten, aber der Beleg war unbrauchbar. Die Adresse war die ganze Zeit da: Sie steht an der Bestellung, gelesen wurde sie an der Sendung, wo es diese Felder gar nicht gibt. Ein leerer Empfänger sieht dabei aus wie „der Kunde hat keine Adresse hinterlegt" und nicht wie ein Fehler — deshalb fiel es so lange nicht auf.

Unter Einstellungen → Versandaktionen gab es seit jeher den Haken „Lieferschein drucken". Er tat nichts. Schlimmer: Die Oberfläche meldete anschließend „gedruckt" — es entstand aber nie ein Druckauftrag. Wer sich darauf verlassen hat, stand ohne Lieferschein im Paket da, ohne es zu merken.

Ob ein Paket noch durch das Paketnetz läuft oder bereits auf dem Zustellfahrzeug ist, machte die Bestellung nicht sichtbar — beides hieß „Unterwegs". Und DHL liefert Ereignisse gelegentlich außer der Reihe: Erst kommt die Zustellung, danach trudelt noch ein Scan „befindet sich im Zustellfahrzeug" ein — der konnte eine bestätigte Zustellung zurückdrehen.

Liegt ein Paket in der Filiale oder Packstation zur Abholung bereit, ist das für den Kunden die entscheidende Information — die Bestellung zeigte aber nur „Unterwegs". Die Sendungsverfolgung kannte den Zustand längst, er kam nur nicht an der Bestellung an.

Zwischen „Versendet" und „Zugestellt" fehlte an der Bestellung die Zwischenstufe: Ob ein Paket nur elektronisch angekündigt ist oder bereits durch das DHL-Netz läuft, war nur an der Sendung erkennbar. Das blaue „Unterwegs"-Badge war in beiden Bestellansichten schon vorbereitet — es wurde nur nie gesetzt.

Die Vorab-Marge im Artikel rechnete mit einem Schätzwert: einer allgemeinen Auffangzeile je Marktplatz (bei eBay 12 %). Die tatsächliche Provision hängt aber an der Kategorie — für unsere eigenen Feinschmecker-Artikel sind es 14,05 %. Wer nach dieser Schätzung kalkulierte, sah seine Marge um gut zwei Prozentpunkte zu gut. Und Marktplätze ändern ihre Gebühren mehrmals jährlich, eBay allein zweimal im Jahr 2026.

Seit 0.0.0.278 erkennt die Sendungsverfolgung die Zustellung — aber nur an der Sendung. Die Bestellung blieb dauerhaft auf „Versendet" stehen, auch wenn alle ihre Pakete längst beim Kunden waren: Für die Übertragung von der Sendung auf die Bestellung gab es keinen Mechanismus. Der Status „Zugestellt" war in der Bestellansicht sogar schon vorgesehen — es kam nur nie ein Auftrag dort an.

Wohin ein Ausdruck geht, hing an einer Kennung, die im Browser gespeichert wird. Ging die verloren — gelöschte Browserdaten, anderes Profil, anderes Gerät —, war die Arbeitsplatz-Zuordnung weg und der Druck landete auf dem Standarddrucker. Nebenwirkung: Die Liste der Arbeitsplätze füllte sich mit Karteileichen, in einem Fall 88 Einträge für ein und denselben PC.

Jeder Kanal liefert die Versandart als freien Text. BIS ERP zeigte diesen Text an, verknüpfte ihn aber nie mit den gepflegten Versandarten — Picklisten-Vorlagen mit Versandart-Filter fanden nie einen Auftrag, der Packtisch wählte immer die Standardversandart vor, die Einstellungen pro Versandart griffen nie, und beim Direktversand wurde jedes Mal neu nachgefragt.

Die Gewinn-/Kostenaufstellung meldete bei älteren Aufträgen „Position ohne bekannten Einkaufspreis" und rechnete mit 0,00 € Wareneinsatz, obwohl der Einkaufspreis im Artikel gepflegt war — der ausgewiesene Gewinn war dadurch zu hoch. Der beim Auftragseingang festgehaltene Einkaufspreis existiert für Bestandsaufträge nicht, und die Aufstellung sah nicht im Artikel nach.

Im Versand-Modul blieb die Sendungsverfolgung leer — zu jeder Sendung stand „Noch keine Tracking-Events verfügbar", auch Tage nach dem Versand und bei ganz normalen DHL-Paketen. Der Abruf bei DHL funktionierte die ganze Zeit; was fehlschlug, war das Speichern des Ergebnisses. Weil die Sendung damit nie als geprüft vermerkt war, stand sie 30 Minuten später wieder ganz oben auf der Liste.

Der Artikel zeigte Marge und Gewinn — aber die des eigenen Verkaufs. Was ein Marktplatz davon abzieht, stand nirgends. Ob sich ein Artikel auf eBay überhaupt lohnt, wenn Provision und Fixbetrag abgehen, ließ sich nur im Kopf überschlagen.

Die Marktplatz-Auswertung zeigte Umsatz pro Kanal — aber nicht, was davon übrig bleibt. Ob eBay mehr einbringt als der eigene Shop, ließ sich daraus nicht ablesen. Der Gebührenbericht wiederum kannte nur Zahlungsgebühren; Marktplatz-Provisionen tauchten gar nicht auf, obwohl sie meist der größere Posten sind.

Ein Auftrag zeigte nur den Umsatz. Was davon übrig bleibt — nach Einkauf, Marktplatzgebühren und Versand — stand nirgends. Gerade bei Marktplatz-Verkäufen ist das die eigentliche Frage: Ein Artikel kann sich gut verkaufen und trotzdem Geld kosten.

Ein über eBay verkaufter, aber noch nicht versendeter Artikel blieb dort mit dem vollen Bestand im Angebot — wer 5 Stück auf Lager hatte und 2 verkaufte, bot weiterhin 5 an. Zwei Ursachen: BIS ERP merkte sich bei eBay-Bestellungen nicht, dass die Ware bereits vergeben war (bei JTL-Wawi, Shopify, Amazon und Etsy geschah das längst), und den Marktplätzen wurde grundsätzlich der Lagerbestand statt des verfügbaren Bestands gemeldet.

Die Einstellung „Rechnung bei Auftragseingang erstellen" wirkte nur für von Hand angelegte Aufträge. Kam eine Bestellung über eBay, Shopify oder Amazon herein, passierte nichts — auch nicht bei bezahlten und abgeschlossenen Aufträgen. Die Automatik hing an der Stelle, an der ein Auftrag manuell angelegt wird; Marktplatz-Aufträge nehmen einen anderen Weg ins System und kamen dort nie vorbei.

Meldete BIS ERP eine Bestandsänderung nach JTL-Wawi, wurde dort nur der Bestandszähler des Lagers hochgesetzt. Die einzelnen Lagerposten, der Gesamtbestand des Artikels und die Bestandshistorie blieben unberührt — Angaben, die JTL normalerweise deckungsgleich hält. Im belegten Fall wich danach genau ein Artikel von 1.056 ab, nämlich der gemeldete.

Wenn Sie am MDE-Gerät einen Bestand korrigiert, einen Wareneingang gebucht oder eine Inventur gezählt haben, konnte die Buchung kurz darauf wieder verschwinden. Zwei unabhängige Ursachen: Die Buchung änderte nur den Gesamtbestand des Artikels, nicht die Lagerbestände dahinter — wer danach auf „Bestand neu berechnen" klickte, holte sich den alten Wert zurück. Und beim JTL-Abgleich holte BIS ERP erst den Stand aus JTL und schickte die eigene Korrektur danach hoch, sodass beide Systeme hinterher vertauscht dastanden.

Wer mit einem Fulfillment-Dienstleister arbeitet und Gebinde verkauft — einen 40er-Karton, ein Sechserpack, ein Set —, bekam diese Aufträge nicht ausgeliefert: Sie blieben als „nicht lieferbar" stehen, obwohl reichlich Ware im Lager lag. BIS ERP führt für ein Gebinde keinen eigenen Bestand, sondern rechnet ihn aus den Einzelartikeln aus — diese Rechnung lief bisher nur für die eigenen Lager. Beim Dienstleister stand für jedes Gebinde dauerhaft „0". Hinzu kam: Der Dienstleister kennt das Gebinde meist gar nicht als Artikel, bei ihm liegt die lose Einzelware.

BIS ERP überwacht im Hintergrund, ob jede Bestandsbuchung auch wirklich in JTL-Wawi ankommt. Eine dieser Prüfungen meldete täglich hunderte angeblich „blockierte" Buchungen, obwohl nichts blockiert war: Sie konnte Buchungen, die absichtlich nicht nach JTL gehen (weil JTL sie längst kennt — jeder Kassenverkauf, jeder Bestandsimport), nicht von echten Blockaden auf einem lagerplatzgeführten JTL-Lager unterscheiden. In jedem Betrieb mit aktiver Kasse schlug die Überwachung dadurch dauerhaft Alarm.

Wenn Sie für Artikel eine Mindestabnahme pflegen — etwa „nur im 6er-Tray" —, hat die Kasse diese Sperre gelegentlich nicht angewendet. Nicht dauerhaft, sondern in kurzen, kaum reproduzierbaren Momenten. Die Ursache: Der Abgleich mit JTL-Wawi löschte die Mindestabnahmen bei jedem Durchlauf komplett und baute sie neu auf. Fragte eine Kasse ausgerechnet in diesem Fenster ihre Artikeldaten ab, bekam sie den Artikel ohne Mengenvorgabe.

Der große Abgleich mit JTL-Wawi brauchte zuletzt fast fünf Minuten pro Durchlauf — bei einem Takt von ebenfalls fünf Minuten. Er war dauerhaft am Anschlag und lief dadurch nur noch alle zehn bis dreizehn Minuten. Eine eingebaute Abkürzung, die den aufwendigen Teil überspringen sollte, wenn sich in JTL nichts geändert hat, hat dabei nie funktioniert: Der Abgleich machte sich seinen eigenen Vergleichswert kaputt, weil er nach dem Merken noch die Lagerbestände aktualisierte — und die zählten mit.

Wenn Sie in JTL-Wawi einen neuen Artikel angelegt haben, konnte es bis zu einer Dreiviertelstunde dauern, bis er an der Kasse zu finden war — ein Kunde stand mit der Ware am Tresen, und der Artikel ließ sich nicht scannen. Am Abgleich selbst lag es nicht: Der ist in rund zwei Minuten fertig. Es lag am Warten davor. Neue und geänderte Artikel laufen jetzt auf einer eigenen, schnellen Spur.

Wenn unser Support Sie um eine Freigabe für die Fernwartung gebeten hat, führte der Knopf „Genehmigen" in der E-Mail auf unsere Startseite statt auf eine Bestätigung. Die Freigabe kam nie an — man konnte klicken, so oft man wollte. Der Knopf „Ablehnen" hatte denselben Fehler. Jetzt öffnet der Link eine richtige Bestätigungsseite.

Wenn Sie für einen Artikel eine eigene eBay-Beschreibung gepflegt haben, wurde sie beim Anlegen des Angebots stillschweigend verworfen. eBay zeigte stattdessen immer die allgemeine Artikelbeschreibung — ohne Fehlermeldung, ohne Hinweis. Aufgefallen ist es beim Ausverkauf von Restposten mit überschrittenem Mindesthaltbarkeitsdatum, wo der Hinweis „MHD überschritten am …" rechtlich verpflichtend ist.

BIS ERP hatte über die Jahre zwei Listen von Warengruppen angesammelt: die, die Sie pflegen und an der Ihre Artikel hängen — und eine zweite, ältere, die nie befüllt wurde. Neun Stellen im System haben in der falschen nachgeschlagen. Da sie immer leer war, kam nie ein Fehler, sondern einfach nichts. Aufgefallen ist das nicht, weil „keine Warengruppe gefunden" genauso aussieht wie „keine Warengruppe gepflegt".

Zum MHD-Ausverkauf gehörte von Anfang an die Idee, ihn pro Warengruppe automatisch starten zu lassen — „Saucen ab 30 Tagen Restlaufzeit". Diese Regel hat nie funktioniert: Sie war intern an die falsche Kategorienliste geknüpft und hätte selbst dann nichts getan, denn es gab überhaupt keine Stelle, an der man sie hätte einschalten können. Aufgefallen ist das nie, weil nichts kaputtging — die Vorschlagsliste sah ohne greifende Regel genauso aus wie ohne eingerichtete Regel.

BIS ERP erledigt im Hintergrund rund 64 wiederkehrende Aufgaben — aufräumen, abgleichen, buchen, Berichte holen. Bei genau drei davon war überhaupt feststellbar, ob sie noch laufen. Die Überwachung musste man für jede Aufgabe von Hand eintragen; wer das vergisst, bekommt exakt dann keine Warnung, wenn er sie bräuchte. Zweimal hat das gekostet: Das Aufräumen der Protokolle stand zehn Wochen still, die Ausverkaufs-Automatik lief seit ihrer Einführung nie — beides unbemerkt.

Die Buchungsautomatik schaute nur 45 Tage zurück — gemessen am Belegdatum. Ein Beleg, der beim Erfassen älter war, wurde deshalb nie gebucht: nicht später, nicht irgendwann. Und gemeldet wurde es auch nicht. Das traf jede Papierrechnung, die spät auftaucht, jeden Steuerberater-Nachlauf und jeden Jahreswechsel. Aufgefallen ist es an einem echten Fall: eine Rechnung vom 30. April, im Juli erfasst, blieb ungebucht — während ihre Gutschrift vom 16. Juli anstandslos gebucht wurde.

Seit 0.0.0.255 erkennt BIS ERP Gutschriften Ihrer Lieferanten korrekt und zieht sie richtig ab. Ein Ort blieb ausgespart: die Buchhaltung. Die Buchungsautomatik hat jede Gutschrift stillschweigend übersprungen — kein Buchungssatz, keine Fehlermeldung, kein Zähler. Grund war eine alte Schutzregel: Das Journal lässt keine negativen Beträge zu, denn in der doppelten Buchführung steckt die Richtung nicht im Vorzeichen, sondern in Soll und Haben.

BIS ERP erledigt nachts Wartungsaufgaben: Protokolle aufräumen, Bestände abgleichen, Buchungen erzeugen. Diese fielen immer wieder aus — teils über Wochen, ohne dass es auffiel. Der Grund lag in der Zeitplanung: Jede Aktualisierung startet den Server neu, dabei ging der Merkzettel verloren, welche Aufgabe zuletzt lief. Eine Aufgabe, die genau in diesen Moment fiel, wurde übersprungen statt nachgeholt — und fast alle lagen ausgerechnet in der Zeit, in der am häufigsten aktualisiert wird.

Bestellungen wurden pausiert mit dem Hinweis, ein Artikel sei nicht lieferbar — obwohl die Ware beim Dienstleister im Regal lag. Wir hatten bisher nur nach Veränderungen gefragt; ein Artikel, der ruhig liegt, verändert sich nie und war für uns damit bestandslos. Ausgerechnet die Ladenhüter blieben so unsichtbar. Jetzt holen wir zusätzlich täglich den kompletten Bestand.

Bisher entschied allein der aufgerufene Link, ob am Tisch oder von zu Hause bestellt wird. Der Restaurant-Code steht aber in jedem Tisch-QR — wer ihn kannte, konnte immer eine Abholbestellung aufgeben, auch bei einem Betrieb, der ausschließlich am Tisch bedient. Jetzt schalten Sie die drei Bestellwege einzeln und frei kombinierbar.

Eine Gutschrift trägt fast immer zwei Nummern: ihre eigene und die der stornierten Rechnung. Unsere KI wurde nur nach „der Rechnungsnummer" gefragt und nahm die falsche — die Gutschrift belegte damit den Platz der echten Rechnung, die daraufhin als „bereits erfasst" abgewiesen wurde und nie in den Büchern ankam. Gemeldet wurde das nirgends. Zusätzlich wurde bei E-Rechnungen das Gutschrift-Kennzeichen beim Import weggeworfen, sodass eine solche Gutschrift addiert statt abgezogen wurde.

Der Verkaufs- und Einkaufspreis wurde intern an zwei Stellen geführt — ein Altlast-Erbe aus einer Feld-Umbenennung. Beide liefen auseinander, weil verschiedene Programmteile jeweils nur eine davon lasen. Folge: Ein Preis, den Sie in BIS ERP änderten, erreichte JTL unter Umständen nie, und die Margen-Auswertung zählte Artikel als „ohne Einkaufspreis", obwohl einer gepflegt war.

Ein eigener eBay-Festpreis, ein eigener Titel, eine eigene Beschreibung — all das ließ sich längst eintragen und speicherte brav. Nur gelesen hat es beim Übertragen niemand: Wer 7 € einstellte, verkaufte weiter für 9 € und bekam keinen Hinweis darauf. Das ist behoben.

Sie haben Ihre Bankverbindung in der Kasse gepflegt — und auf der Rechnung blieb der Zahlungsteil trotzdem leer. Kein Bedienfehler: Die Daten waren vollständig da, landeten aber in einem anderen Ablagefach als dem, aus dem die Rechnung liest. Dass die USt-IdNr. immer korrekt erschien, machte es besonders tückisch.

Der QR-Link ohne Tischangabe war längst ein Abhol-Link — nur wusste niemand, wer die Bestellung abholt, und bezahlt wurde erst an der Theke. Jetzt fragt die Bestellseite nach Name, E-Mail und Telefon, auf Wunsch nach einer Lieferadresse, und der Gast zahlt sofort per PayPal oder wie bisher bei der Abholung.

Die Ausverkaufs-Automatik sah fertig aus, tat aber nie etwas: Der Knopf änderte nur die Anzeige, und der nächtliche Lauf war nirgends eingeplant. Jetzt läuft sie — und sie kennt endlich Ihre Mindesthaltbarkeitsdaten, auch die aus JTL übernommenen, die der MHD-Warnung bisher komplett entgingen.

Im Artikel auf „Marktplätze" zu klicken, konnte bis zu einer Minute dauern. Die Ursache lag nicht bei den Marktplätzen, sondern beim Protokoll der Kassen-Synchronisierung: Es sollte nach sieben Tagen automatisch aufgeräumt werden, was über Wochen ausblieb — der Tab wertete dann jedes Mal Hunderttausende Zeilen aus, für Zahlen, die er gar nicht anzeigt.

Fragt ein Käufer bei eBay etwas, landete das bisher außerhalb von BIS ERP — man musste sich bei eBay anmelden, um überhaupt zu sehen, dass jemand wartet. Wie schnell dabei etwas liegenbleibt, zeigte sich beim Bau selbst: In einem echten Postfach wartete eine Anfrage seit Tagen (doppelte Lieferung, Bitte um Rücksendelabel). Jetzt gibt es dafür einen eigenen Menüpunkt.

Kasse und Warenwirtschaft waren bei den Lizenzen vermischt: dieselbe Lizenz „Zusätzlicher Benutzer" zählte doppelt — einmal fürs ERP und zusätzlich für die Kasse —, berechnet wurde sie aber nur einmal. Jetzt ist beides sauber getrennt.

Jeder Verkaufskanal nennt Zahl- und Versandarten anders — die Kasse schreibt „bargeld", ein Shop „Barzahlung", eBay meldet „eBay". Bisher übernahm BIS ERP das ungeprüft: neun verschiedene Zahlarten in den Aufträgen, keine einzige angelegt, und die Spalte „Zahlungsart" blieb leer. Jetzt ordnen Sie diese Bezeichnungen Ihren eigenen Arten zu.

Jede automatische Verlängerung einer Anmeldung zählte bisher als komplett neue Anmeldung und belegte 30 Minuten lang einen weiteren Benutzer-Platz — ein einzelner Mitarbeiter sperrte sich damit selbst aus. Das ist behoben.

Mehrere Verbesserungen in der Auftragsansicht rund ums Fulfillment — plus eine korrekte Preisübergabe an den Dienstleister.

Beim „Jetzt versenden" mussten Versandart und Gewicht von Hand eingetippt werden, obwohl beides bekannt ist — und ein Lager ließ sich gar nicht wählen. Jetzt ist beides vorausgefüllt, und das gewählte Lager bestimmt den Weg.

Ein bereits ans Fulfillment-Network übergebener Auftrag ließ sich aus BIS ERP nicht mehr zurückziehen — selbst wenn der Dienstleister noch gar nicht mit dem Packen begonnen hatte. Jetzt stornieren Sie ihn direkt aus BIS und holen ihn zur Bearbeitung zurück.

Bisher hing der Versandweg am Verkaufskanal — Aufträge gingen automatisch ans Fulfillment-Network, und wer manche selbst versenden wollte, musste sie von Hand herausnehmen. Jetzt bestimmt das gewählte Ziel-Lager den Weg: eigenes Lager → Sie versenden selbst, Fulfillment-Lager → ans Fulfillment-Network. Ein Lager ist ein Lager, egal was danach kommt.

Ihr Fulfillment-Dienstleister nennt seine Versandarten anders als Sie. Wählte ein Käufer „Deutsche Post Warenpost", konnte BIS ERP das nicht sicher der passenden Versandart des Dienstleisters zuordnen — es wurde die falsche übertragen. Jetzt ordnen Sie sie selbst zu.

Wer mit mehreren Fulfillment-Dienstleistern arbeitet, hatte ein stilles Risiko: Ein Auftrag konnte an ein Lager übergeben werden, in dem die Ware gar nicht liegt. Das Fulfillment-Network meldet das nicht zurück — es nimmt den Auftrag an, kann ihn aber nicht versenden, und er bleibt unbemerkt liegen. Jetzt wird vor jeder Übergabe der Bestand geprüft.

Bei jedem eintreffenden Auftrag passierte bisher immer dasselbe — egal, was für ein Auftrag es war. Wer mit zwei Fulfillment-Dienstleistern arbeitet, konnte nur einen festen wählen: Alle Aufträge gingen ans selbe Lager, auch wenn die Ware dort gar nicht lag. Jetzt bauen Sie Ihre eigenen Regeln per Drag & Drop.

Wer seine Ware von einem Fulfillment-Dienstleister im JTL-Netzwerk lagern und versenden ließ, brauchte dafür bisher zwingend eine JTL-Wawi — auch dann, wenn er sie sonst für nichts mehr benutzte. BIS ERP schrieb den Auftrag hinein, und die JTL-Wawi reichte ihn ans Fulfillment-Network weiter: ein System in der Mitte, das nichts tat außer weiterreichen. Jetzt geht der Auftrag direkt, und Bestand, Sendungsverfolgung und Retouren kommen automatisch zurück.

Eine eBay-Bestellung kam rein und war nirgends zu finden — weder als Auftrag in BIS ERP noch in der JTL-Wawi. Der Grund: Es gab überhaupt keinen automatischen eBay-Bestellimport. Bestellungen kamen nur, wenn jemand den Knopf drückte; Amazon, Shopify und Gambio holten sich ihre längst allein. Dasselbe beim Bestand — er ging nur auf Klick zu eBay zurück, während der Artikel an der Kasse längst verkauft war. Beides läuft jetzt automatisch. Und Marktplatz-Bestellungen landen erstmals als echter Auftrag in der JTL-Wawi.

Ein Etikett aus den USA oder Asien ist nach anderen Regeln beschriftet als die EU sie verlangt: Werte je Portion statt je 100 Gramm, Natrium statt Salz, Kohlenhydrate inklusive Ballaststoffe. Die KI-Artikelanlage hat diese Angaben bisher eins zu eins übernommen — formal falsch, und ohne Warnung. Jetzt erkennt sie, wie das Etikett gemeint ist, und rechnet nachvollziehbar auf die EU-Vorgaben um. Dazu neu: ein Lebensmitteletikett nach LMIV.

Der EÜR-Ausdruck sah nicht aus wie eine Gewinnermittlung, die man der Steuerberatung vorlegt — eine flache Kontenliste, und zwischen den Auswertungen standen leere Seiten. Seite 1 ist jetzt eine gegliederte Überschussrechnung mit nummerierten Positionen, Konten darunter und „Gesamt"-Zeile; die Anlage-EÜR-Seite nennt zu jedem Betrag Zeile und Kennziffer des amtlichen Vordrucks.

Wer eine Eingangsrechnung öffnet, prüft und speichert, hat sie faktisch geprüft — trotzdem stand sie danach weiter auf „Eingegangen" und musste extra freigegeben werden. Der neue Button erledigt beides in einem Klick und springt im Stapel direkt zur nächsten Rechnung.

Wer den Haken „Bezahlt" entfernen wollte, sah ihn sofort zurückspringen. Beim Abhaken verschwindet das Feld für das Bezahldatum — und genau dieses Verschwinden löste im Hintergrund erneut ein „als bezahlt markieren" aus. Ausserdem wurde das Bezahldatum beim Öffnen nicht in das Feld geladen, sodass ein leeres Datum das echte überschreiben konnte.

Ordnete man einer Eingangsrechnung eine Bankzahlung zu, blieb die Rechnung trotzdem offen — und liess sich sogar ein zweites Mal zuordnen. Der automatische Abgleich kannte ausserdem nur Geldeingänge. Jetzt schliesst die Zahlung die Rechnung, mit dem Buchungsdatum der Bank als Bezahldatum, und Zahlungsausgänge werden automatisch gegen offene Eingangsrechnungen geprüft.

Eine frisch importierte Rechnung, die noch auf Freigabe wartet, verschwand bisher in der nach Datum sortierten Liste weiter hinten, sobald ihr Rechnungsdatum älter war — im schlimmsten Fall auf der letzten Seite. Alles, was noch nicht freigegeben ist, steht jetzt ganz oben: farblich abgesetzt, mit Überschrift „Wartet auf Freigabe" und Anzahl.

Eine bei Stripe stornierte Rechnung blieb in BIS ERP auf „finalisiert" stehen und zählte weiter als Betriebseinnahme, obwohl nie Geld geflossen ist — die Storno-Meldungen von Stripe wurden gar nicht verarbeitet, und der Rechnungs-Abgleich schrieb im Storno-Fall sogar einen ungültigen Status. Zusätzlich wurden Gutschriften in den Auswertungen als positive Einnahme gezählt statt abgezogen, sodass ein Storno über BIS ERP die Einnahmen gar nicht senkte. Beides ist behoben: Stripe-Stornos werden automatisch übernommen (per Meldung und über den selbstheilenden Rechnungs-Abgleich), und Gutschriften mindern die Einnahmen in EÜR, BWA, Anlage EKS und Umsatzsteuer-Voranmeldung. Außerdem rundet die EKS-Hochrechnung jetzt auf volle Euro (Ist-Werte bleiben centgenau), und die große Position „Weitere bisher nicht erfasste Betriebsausgaben" lässt sich wie alle anderen auf ihre Einzelbelege aufklappen.

Die Liste der Eingangsrechnungen sortierte bisher nur die Zeilen der gerade angezeigten Seite — welche Rechnung auf welcher Seite landete, entschied dagegen der Zeitpunkt des Imports. Bei „Datum, absteigend" standen deshalb auf der letzten Seite Rechnungen aus 2026 zwischen denen aus 2025. Die Sortierung wirkt jetzt über den gesamten Bestand, für jede Spalte.

BIS ERP führte den Bestand, aber keine Bestandshistorie. Rund 45 Stellen im System änderten den Lagerbestand, nur etwa 10 hinterließen überhaupt eine Spur — und keine einzige notierte den Einkaufspreis. Am schwersten wog: Der Kassenverkauf, der häufigste Vorgang überhaupt, wurde gar nicht protokolliert; ebenso wenig die Stücklisten-Abbuchung, die Retoure, die Kommissionierung oder der Auftragsversand. Damit ließ sich nicht sagen, wie hoch der Lagerbestand an einem vergangenen Tag war — und erst recht nicht, was er wert war. Jetzt erzeugt jede Bestandsänderung einen Eintrag im Bewegungsjournal, mit Menge, Bestand vorher und nachher sowie dem Einkaufspreis zum Zeitpunkt der Bewegung. Ein einmaliger Lauf schreibt den heutigen Bestand als Eröffnungsbestand fest; ab diesem Zeitpunkt lässt sich der Bestand und sein Wert zu jedem beliebigen Stichtag zurückrechnen. Drei Protokoll-Buchungen, die seit jeher still scheiterten, funktionieren wieder, und bei sechs Mandanten war die Bewegungstabelle versehentlich mit einer völlig anderen Tabelle belegt — dort konnte nie etwas protokolliert werden.

Mit 0.0.0.225 rechnen FIFO und LIFO korrekt — nur hatten sie nichts zu rechnen: Der Wareneingang speicherte gar keinen Einkaufspreis, und ohne Preis entsteht keine Preis-Schicht. Auch der Weg „Preise buchen" führte nicht zum Ziel, er lief in einen Serverfehler. Kein einziger Betrieb hatte daher Preis-Schichten, und alle drei Bewertungsmethoden lieferten zwangsläufig dasselbe Ergebnis. Jetzt übernimmt der Wareneingang den Einkaufspreis automatisch aus der Bestellung (ohne Bestellung: den zuletzt bekannten Einkaufspreis des Artikels) und legt die Preis-Schicht direkt beim Einbuchen an — Bestand, Schicht und neuer Durchschnitts-Einkaufspreis entstehen in einem Vorgang. Der Durchschnitts-Einkaufspreis wird endlich fortgeschrieben (das Update traf den Artikel bisher nie), und die Einkaufspreis-Historie wird wieder befüllt. Nachgerechnet an einem echten Wareneingang: 100 Stück zu 0,79 €, dann 100 Stück zu 1,58 € — bei 120 Stück Restbestand ergibt FIFO 173,80 € und LIFO 110,60 €.

Vier Fehler, die nichts abstürzen ließen, sondern schlicht falsche Zahlen lieferten — oder gar keine. Erstens waren FIFO und LIFO in der Bestandsbewertung vertauscht: FIFO bewertete den Lagerbestand mit den ältesten Einkaufspreisen, richtig sind die jüngsten (bei FIFO geht die älteste Ware zuerst raus, übrig bleibt die zuletzt gekaufte). Zweitens teilten sich Kunden Debitorenkonten: Das Personenkonto wurde bei jeder Buchung neu aus der Kundennummer errechnet, sodass bei Nummern wie K-2024-001 und K-2024-002 alle Kunden eines Jahres auf demselben Konto landeten und ihre Forderungen zu einem Mischsaldo verschmolzen. Beim Prüfen kamen zwei weitere Fehler ans Licht: Die Bestandsbewertung ließ sich überhaupt nicht aufrufen, sobald Artikel vorhanden waren, und der Wareneingang konnte nie eine Einkaufs-Charge speichern — weshalb kein Betrieb Chargen hatte und FIFO, LIFO und Durchschnitt allesamt dasselbe Ergebnis lieferten. Alles behoben und geprüft: 120 Stück bei Einkäufen zu 5 €, 7 € und 9 € ergeben nach FIFO 1.040 € und nach LIFO 640 €; Personenkonten werden einmal vergeben und festgehalten, Kollisionen sind technisch ausgeschlossen; und in Summen- und Saldenliste, GuV und Bilanz steht jetzt der Kundenname statt einer nackten Kontonummer.

Die Einnahmenüberschussrechnung ließ sich bisher nur als CSV exportieren — nichts, was man einem Steuerberater in die Hand drücken möchte. Schwerer wog aber ein zweites Problem: Die EÜR zog ihre Betriebseinnahmen ausschließlich aus den Rechnungen. Kassenbons, zu denen keine Rechnung erzeugt wurde, fehlten damit vollständig — bei einem Kassenbetrieb schnell der halbe Umsatz (im Test-Mandanten wurden 2.853,70 € statt der tatsächlichen 5.844,13 € ausgewiesen). Beides ist jetzt behoben: Kassenumsätze und Rechnungen werden entdoppelt zusammengeführt (Kassen-Rechnungen zählen nicht doppelt) — dieselbe Datenbasis wie BWA und Anlage EKS. Und es gibt ein dreiseitiges PDF im DATEV-Layout: Gewinnermittlung nach § 4 Abs. 3 EStG mit Kontenaufriss, Prozentanteilen und Vorjahresvergleich; Monatsübersicht mit Einnahmen, Ausgaben, USt, Vorsteuer, Gewinn und Zahllast; sowie die Zuordnung zur amtlichen Anlage EÜR mit den Kennziffern des Vordrucks (z. B. Kz 112, Kz 100, Kz 185) für die ELSTER-Übermittlung. Umsatzsteuer und Vorsteuer sind durchlaufende Posten und fließen nicht mehr in den Gewinn ein; Kleinunternehmer (§ 19 UStG) rechnen automatisch brutto gegen brutto. Auch der EÜR-Export in den Kassenberichten liefert jetzt dasselbe DATEV-PDF — vorher wies er die Betriebsausgaben schlicht mit 0,00 € aus und nannte den Nettoumsatz „Gewinn".

Die EKS-Hochrechnung rechnete mit dem Durchschnitt der letzten Monate. Bei einem wachsenden Betrieb liegt der Durchschnitt zwangsläufig unter dem letzten Monat (aus 1.000 → 6.000 wird ein Ø von 3.500) — die Prognose sah dadurch aus wie ein Einbruch, obwohl der Betrieb wächst. Zusätzlich zählte der laufende, noch nicht abgeschlossene Monat als vollwertiger Basismonat und drückte den Schnitt weiter nach unten. Jetzt schreibt die Hochrechnung standardmäßig den Trend fort: Wächst der Umsatz um 1.000 € pro Monat, wird das auch so prognostiziert; Rückgänge werden genauso realistisch abgebildet, aber nie ins Negative gerechnet. Das Verfahren ist frei wählbar (Trend, Durchschnitt, letzter Monat), der Faktor bleibt zusätzlich nutzbar. Als Basis zählen nur abgeschlossene Monate, und ein angebrochener Monat im Bewilligungszeitraum bekommt die Prognose statt seines unvollständigen Teil-Werts. Über der Tabelle steht nachvollziehbar, worauf die Prognose beruht.

Die Anlage EKS konnte bisher nur Vergangenheitswerte ausweisen. Für einen Antrag bzw. eine vorläufige Erklärung verlangt das Jobcenter aber die voraussichtlichen Einnahmen und Ausgaben der kommenden Monate. Jetzt schaltest du im EKS-Tab zwischen „Abschließend (Ist)" und „Vorläufig (Plan)" um — genau die beiden Erklärungsarten des amtlichen Formulars, inklusive passendem Kreuz im PDF. Im Planwerte-Editor trägst du je Monat die voraussichtlichen Werte pro Position ein (Umsatz, Umsatzsteuer, Wareneinkauf, Personal, Raumkosten, Versicherungen, Werbung, Kfz, weitere Ausgaben, Vorsteuer); der voraussichtliche Gewinn wird live berechnet. Liegen bereits Vergangenheitswerte vor, schlägt BIS ERP die Werte automatisch vor — der Durchschnitt der letzten 3, 6 oder 12 Monate mit Bewegung, optional mit einem Faktor (z. B. 110 % für erwartetes Wachstum). Ohne Historie bleibt die Tabelle leer und wird manuell gefüllt. Jeder Wert ist frei überschreibbar, und der PDF-Export übernimmt die Planwerte ins amtliche Formular.

Seit dem 01.01.2025 muss jedes Unternehmen elektronische Rechnungen empfangen können. Erlaubt sind zwei Bauformen — BIS ERP verstand bisher nur eine. Kam eine XRechnung im UBL-Format (eine reine XML-Datei, wie sie etwa Telefonanbieter verschicken), wies der Upload sie ab, und im Rechnungs-Postfach wurde der XML-Anhang stillschweigend übersprungen. Jetzt liest BIS ERP alle gängigen E-Rechnungen: XRechnung (UBL) und ZUGFeRD/Factur-X (CII), als eigene XML-Datei oder eingebettet im PDF, auch Gutschriften.

Wer einen Artikel in BIS ERP löschte, fand ihn wenige Minuten später wieder in der Artikelliste — plötzlich als neuer Artikel, angelegt „von der Kasse". Besonders ärgerlich beim Aufräumen einer Speise- oder Getränkekarte. Ursache war ein Zusammenspiel zweier Seiten: Eine Kasse, die die Löschung (noch) nicht übernommen hatte, meldete den Artikel beim nächsten Abgleich als ihren eigenen zurück; BIS ERP suchte ihn anhand der Artikelnummer, fand ihn — weil gelöscht — nicht mehr und legte ihn neu an. BIS ERP merkt sich gelöschte Artikelnummern jetzt und ignoriert solche Rückmeldungen.

Ein in JTL neu angelegter und für die Kasse freigegebener Artikel tauchte dort erst nach dem übernächsten Abgleich auf — bis zu zehn Minuten später, und zwischenzeitlich meldete BIS ERP ihn den Kassen sogar als gelöscht. Grund war die Reihenfolge im Abgleich: Die Zuordnung „welcher Artikel gehört auf welche Kasse" wurde vor dem Artikel-Import berechnet und konnte einen Artikel, den es in BIS ERP noch nicht gab, nicht berücksichtigen. Jetzt werden die Kassen-Zuordnungen nach dem Import ein zweites Mal nachgezogen — im selben Durchlauf.

Ein Artikel hatte bisher nur eine Beschreibung für alle Verkaufskanäle, und die Langbeschreibung musste als roher HTML-Code getippt werden. Jetzt kannst du im Beschreibung-Tab zwischen „Global" und deinen aktiven Verkaufskanälen umschalten und pro Kanal eine eigene Kurz- und Langbeschreibung hinterlegen — lässt du einen Kanal leer, wird automatisch der globale Text verwendet. Die Langbeschreibung lässt sich zudem in einem visuellen Editor formatieren (Fett, Listen, Überschriften, Links), mit Umschalter zwischen Visuell, HTML-Code und Vorschau.

Die Anlage EKS fürs Jobcenter wird als amtliches Original-Formular ausgefüllt — bisher nur mit den Kopfdaten. Jetzt deckt die EKS-Stammdaten-Maske alle deklarativen Felder des Vordrucks ab, gegliedert nach Abschnitten: Person und selbständige Person, Art der Erklärung, Betrieb (Rechtsform, Beginn/Ende), weitere Angaben mit allen Ja/Nein-Fragen (gewerbliche Räume, Personal, Zuschüsse, Darlehen), Kfz-Kilometer, personenbezogene Ausgaben (Unterhalt, Fahrten, Verpflegung), Anmerkungen und die Tabelle C (Absetzungen vom Einkommen). Ja/Nein-Fragen werden per Auswahl gesetzt und im PDF an der richtigen Stelle angekreuzt; die Umsatzsteuerpflicht wird automatisch aus dem Kleinunternehmer-Status (§19) übernommen. Einmal ausgefüllt landet alles beim PDF-Export im echten Formular — nichts muss mehr von Hand nachgetragen werden.

Nach dem JTL-Abgleich blieben in den Artikeln Hersteller und Marke leer (obwohl der Name in der Übersicht stand), Produktgewicht und Mindestbestand wurden nicht übernommen, und bei Lieferanten fehlte die Adresse im Bearbeiten-Formular. Jetzt legt der Abgleich Hersteller und Marke als echte Einträge an und verknüpft sie mit dem Artikel (auch rückwirkend), übernimmt Produktgewicht (Nettogewicht) und Mindestbestand aus den richtigen JTL-Feldern, und die Lieferantenadresse wird wieder angezeigt — die Daten waren vorhanden, wurden nur nicht dargestellt.

Die BWA im DATEV-Layout (0.0.0.212) entsprach der Form „Kurzfristige Erfolgsrechnung" (ein Monat + kumuliert, mit Prozentspalten). Viele Steuerberater-BWAs sind aber die DATEV-Jahresübersicht: alle 12 Monate nebeneinander mit Jahressumme und der vollständigen Zeilenliste. Diese Jahresübersicht ist jetzt die Standard-Ansicht — von Umsatzerlösen über Gesamtleistung, Rohertrag und sämtliche Kostenarten bis zu Betriebsergebnis, neutralem Bereich, Ergebnis vor Steuern und vorläufigem Ergebnis, exakt im DATEV-Aufbau. Über einen Umschalter wechselt man zur Kurzfristigen Erfolgsrechnung (Berichtsmonat + kumuliert, mit % der Gesamtleistung/Gesamtkosten). Auch Positionen, die BIS ERP nicht separat führt, erscheinen mit 0,00 — für maximale Deckungsgleichheit mit der DATEV-Vorlage. Beide Ansichten gibt es als PDF, jede Position ist je Monat auf die Einzelbelege aufklappbar.

Bei Händlern mit langer JTL-Historie brach der Abgleich von Lieferscheinen und Sendungsverfolgung ab — der Sync versuchte, die komplette Historie (teils Hunderttausende Datensätze) auf einmal zu übertragen, lief in eine Zeitüberschreitung und meldete den Gesamtabgleich als fehlgeschlagen. Jetzt holt der Abgleich Versand-/Lieferscheindaten standardmäßig nur aus den letzten 180 Tagen (über die JTL-Einstellungen anpassbar) und lädt sie portionsweise. So läuft auch ein sehr großer Bestand zuverlässig durch, und die Sendungsverfolgung aktueller Bestellungen kommt sauber in BIS ERP an.

Wer seine Artikel über die JTL-Anbindung synchronisiert hat, bekam in BIS ERP zwar Namen, Preise und Hersteller — aber die Artikelbeschreibungen blieben leer, obwohl sie in JTL gepflegt waren. Kurz- und Langbeschreibung wurden beim Abgleich schlicht nicht übertragen. Jetzt kommen sie mit: gesteuert über die Einstellung „Beschreibungen" in der JTL-Anbindung (z. B. „Kurz- und Langbeschreibung 1:1" oder „Langbeschreibung in beide Felder"). Ihre eigenen, in BIS ERP gepflegten Texte bleiben geschützt — ein leeres JTL-Feld überschreibt keinen vorhandenen Text.

Die betriebswirtschaftliche Auswertung (BWA) war rechnerisch korrekt, sah aber nicht aus wie eine „richtige" BWA vom Steuerberater. Jetzt folgt sie der vertrauten DATEV-Gliederung (Form 01, „Kurzfristige Erfolgsrechnung"): die Positionen stehen untereinander — von Umsatzerlösen über Gesamtleistung, Wareneinsatz und Rohertrag über die einzelnen Kostenarten bis zum Betriebsergebnis und vorläufigen Ergebnis. Wie im Original stehen der wählbare Berichtsmonat und die kumulierten Jahreswerte nebeneinander, jeweils mit den Prozentspalten „% der Gesamtleistung" und „% der Gesamtkosten". Jede Position lässt sich auf die Einzelbelege aufklappen, und der PDF-Export bildet dieselbe Gliederung ab (plus Monatsverlauf auf Seite 2).

Der QR-Code auf dem digitalen Kassenbon führte ins Leere (weiße Seite beim Scannen) — er öffnet den Beleg jetzt wieder zuverlässig, auch alle bereits gedruckten Bons rückwirkend. Zusätzlich wies der digitale Beleg bei Kleinunternehmern (§ 19 UStG) fälschlich Umsatzsteuer aus; jetzt zeigt er keine USt und keine USt-IdNr. mehr, sondern den gesetzlichen Hinweis „Kein Ausweis von Umsatzsteuer gem. § 19 UStG (Kleinunternehmerregelung)." — sofort auch für früher erstellte Belege.

Die Anlage EKS (für das Jobcenter bei Bürgergeld/Aufstockung) wird jetzt als der originale amtliche Vordruck „Anlage EKS" (Stand 04/2026) ausgegeben — 1:1 das Blatt, das das Jobcenter kennt, statt eines vereinfachten Eigenbaus. Betriebseinnahmen, Umsatzsteuer, die einzelnen Ausgabenpositionen (Wareneinkauf, Personal, Raumkosten, Werbung, Kfz, Vorsteuer …) und der Gewinn je Monat kommen automatisch aus den erfassten Rechnungen und Kassenumsätzen. Umsatz-/Vorsteuer werden nach dem Zufluss-/Abflussprinzip behandelt, sodass der Gewinn cent-genau aufgeht; Kleinunternehmer erhalten die Brutto-Darstellung.

In EÜR, UStVA, BWA und Anlage EKS zeigten die Berichte bisher nur Summen. Jetzt lässt sich jeder Betrag anklicken — darunter erscheinen die einzelnen Rechnungen, aus denen er besteht (Nummer, Geschäftspartner, Datum, Betrag), und ein Klick öffnet die zugehörige Ausgangs- oder Eingangsrechnung. Verfügbar in allen vier Berichten, jeweils pro Monat/Zeitraum und als Gesamtsumme; bei den Betriebseinnahmen wird der Kassenanteil als eigene Zeile ausgewiesen, damit die Summe lückenlos aufgeht.

Beim Rechnungsimport (KI und ZUGFeRD) werden die Lieferanten-Adressdaten jetzt strukturiert ausgelesen (Straße, Hausnummer, PLZ, Stadt, Land, USt-IdNr., E-Mail) und direkt in die GPSR-Pflichtfelder des Lieferanten geschrieben — die Warnung „GPSR-Daten unvollständig" verschwindet von selbst. Bei bestehenden Lieferanten werden nur leere Felder nachgezogen; manuell gepflegte Angaben bleiben unangetastet. Zusätzlich füllt ein Ein-Klick-Button die Felder bestehender Lieferanten aus bereits gespeicherten Rechnungsadressen.

Der Upload von Eingangsrechnungen nimmt die PDF jetzt sofort an und wertet sie serverseitig im Hintergrund aus — kein Warten pro Beleg, kein Verlust beim Verlassen der Seite. Kurzzeitige KI-Aussetzer werden automatisch wiederholt (keine leeren Belege mehr); scheitert die Auswertung dauerhaft, entsteht ein klar markierter „(KI-Auswertung fehlgeschlagen)"-Beleg samt PDF statt einer leeren 0,00-Hülle. Auch bei vielen gleichzeitigen Uploads bleibt die App flüssig (Warteschlange).

Die KI übernimmt jetzt nur noch echte, berechnete Rechnungspositionen (keine Null-/Info-/Summenzeilen, keine Duplikate) und schlägt je Position direkt das passende Buchungskonto aus deinem Kontenrahmen (SKR03/04) + den Steuerschlüssel vor — bei bekanntem Lieferanten dessen zuletzt genutztes Konto. Der DATEV-Export bucht eine Warenrechnung mit vielen Artikeln als eine Zeile (nicht 60) und teilt gemischte Rechnungen sauber je Konto/Steuersatz auf.

Die Guthaben-Historie im Kundencenter zeigte bei KI-Abbuchungen nur einen allgemeinen Text. Jetzt trägt jede Buchung den konkreten Bezug: Rechnungs-KI mit Lieferant, Rechnungsnummer, Datum und Beleg-Nr. (+ Link zum Beleg), Artikel-KI mit Artikelname und SKU (+ Link zum Artikel). Dublette-Rechnungen werden zudem nicht mehr abgebucht.

Rechnungen mussten bisher als PDF selbst hochgeladen werden. Neu überwacht BIS ERP ein Postfach, holt die PDF-Anhänge selbstständig ab, liest sie per KI aus und legt sie als Eingangsrechnung (Entwurf zur Prüfung) an — Sie geben nur noch frei. Zwei Wege zur Wahl: ein eigenes IMAP-Postfach oder eine dedizierte BISpicy-Adresse (rechnungen-…@bispicy.com). Bei jeder neuen Rechnung gibt es eine Benachrichtigung im Dashboard und optional per E-Mail. Nichts wird automatisch verbucht (GoBD-konform); die Abrechnung ist dieselbe wie beim Upload.

Eingangsrechnungen ohne strukturierte E-Rechnung mussten von Hand erfasst werden. Neu liest die KI Lieferant, Beträge und alle Positionen automatisch aus einem hochgeladenen PDF (aktuellstes Claude-Modell). Bezahlt wird fair übers Guthaben: 5 Belege pro Monat gratis, danach nach Nutzung — mit optionalen Monats-Tarifen, die sich am Monatsende automatisch aufs günstigste Optimum herunterrechnen und zu viel Gezahltes als Gutschrift zurückbuchen (nie zu viel, nie zu wenig). Der Guthaben-Stand steht jetzt direkt unter dem Namen in der Navigation.

BIS ERP kannte den Umsatzsteuer-Status Kleinunternehmer (§19 UStG) bisher nicht — Rechnungen wiesen immer USt aus, der Pflicht-Hinweissatz fehlte, und die Anlage EKS rechnete netto. Neu steuert ein einziger Schalter in den Firmeneinstellungen das ganze System: Rechnungen ohne Umsatzsteuer inkl. gesetzlichem §19-Hinweissatz (auch als E-Rechnung ZUGFeRD/XRechnung), Anlage EKS brutto, und automatische Synchronisierung an die Kasse. Standardmäßig aus (regelbesteuert), damit sich für bestehende Betriebe nichts ändert.

Belege in Fremdwährung (z. B. Thai Baht oder US-Dollar) wurden in den Auswertungen bisher 1:1 als Euro gezählt — dadurch waren BWA, EÜR, UStVA, Anlage EKS und die DATEV-Exporte bei internationalen Belegen zu hoch. Jetzt werden Fremdwährungsbeträge in allen Auswertungen sauber in die Betriebswährung umgerechnet, und zwar mit dem EZB-Kurs zum Belegdatum. Die Ausgaben in der Anlage EKS stimmen damit wieder mit der Eingangsrechnungs-Übersicht überein. Zusätzlich lässt sich die EKS-Monatstabelle am Handy jetzt sauber seitlich scrollen.

Die Artikelliste ließ sich bisher nicht nach dem Anlagedatum sortieren, und beim Preisschild-Druck bekam jeder Artikel dieselbe Standard-Vorlage. Jetzt gibt es die sortierbare Spalte „Erstellt am" (auch in den Artikeldetails sichtbar), und pro Artikel lässt sich eine bevorzugte Preisschildvorlage hinterlegen, die beim Einzel- und Sammeldruck automatisch genutzt wird — mit Fallback auf das Standard-Etikett. Die Vorlage lässt sich auch per Massenänderung setzen, beim Duplizieren übernehmen und per „Details kopieren" übertragen.

Die betriebswirtschaftliche Auswertung (BWA) gab es bisher nur als Bildschirmansicht, und die Anlage EKS (die das Jobcenter von Selbständigen im Bürgergeld-Bezug regelmäßig verlangt) musste komplett von Hand ausgefüllt werden — außerdem fehlten in BWA und EÜR die Barumsätze aus der Kasse. Jetzt lässt sich die BWA als PDF in DATEV-Gliederung herunterladen, die vorausgefüllte Anlage EKS wird auf Knopfdruck als PDF erzeugt, und beide rechnen Kassen-Barumsätze und Rechnungen zusammen — ohne Doppelzählung. Zu finden unter Berichte → Finanzberichte (Teil von BIS Insights).

Wenn Ihr Team einen Kunden direkt an der Kasse neu anlegte und ihm einen Verkauf zuordnete, konnte der zugehörige Auftrag (und die Rechnung) in der Warenwirtschaft trotzdem auf dem anonymen „POS-Laufkunden" landen — mit leerer Rechnungsadresse. Jetzt werden direkt an der Kasse angelegte Kunden zuverlässig dem echten Kundenkonto zugeordnet: Auftrag und Rechnung tragen Namen und Anschrift des Kunden statt „Laufkunde". Bereits falsch gebuchte Aufträge lassen sich nachträglich umhängen. Der Fix wirkt serverseitig, ohne Update der Kassen-App.

Die Browser-Kasse (pos.bispicy.com) lief bisher im normalen Browser-Tab — mit Adressleiste oben und Browserleiste unten. Jetzt lässt sie sich als App auf den Startbildschirm legen und startet dann im Vollbild ohne Browser-Chrome, genau wie die native Kassenapp. Auf Android genügt ein Tipp auf „Als App installieren"; auf iPhone/iPad führt eine kurze, bebilderte Anleitung durch „Teilen → Zum Home-Bildschirm". Eigenes Kassen-Icon (identisch zur nativen Kasse), dunkles Design und saubere Ränder um Notch, Statusleiste und Home-Indikator.

Bisher konnte den Reparaturstatus nur die Kasse am Tablet ändern. Jetzt trägt die interne Werkstattkopie einen zweiten QR-Code: Ihr Mitarbeiter scannt ihn mit dem Handy und ändert den Status ohne Login — bis „abholbereit", inkl. Kundennotiz und Benachrichtigung. Die Kundenseite und die Mail laufen sofort; die Kasse zieht die Änderung beim nächsten Abgleich automatisch nach. Der Mitarbeiter-Token ist vom Kunden-Token getrennt und kommt nie auf den Abholbeleg; interne Notizen bleiben intern.

Die Vorlagen-Community (Druckvorlagen teilen & übernehmen) gab es bisher nur in BIS ERP. Jetzt stehen „In Community teilen" und „Aus Community übernehmen" auch im Dokumentendesigner des Kundencenters bereit — dieselbe Funktion, dieselbe Community. Geteilt wird weiterhin ausschließlich das Layout, niemals Kunden- oder Preisdaten.

Bisher ließen sich nur Preisschild-Vorlagen mit anderen Betrieben teilen. Jetzt gibt es im Dokumentendesigner „In Community teilen" und „Aus Community übernehmen" für ALLE Vorlagenarten — Rechnung, Lieferschein, Angebot, Gutschrift, Auftragsbestätigung, Zahlungserinnerung, Proforma, Preisschild, Lagerplatzetikett und mehr. Übernommene Vorlagen landen als eigene, frei anpassbare Kopie; freigeben lässt sich öffentlich für die ganze Community oder gezielt privat per Empfehlungscode. Künftige neue Vorlagenarten sind automatisch dabei.

Wer an der Kasse eine DIN-A4-Rechnung drucken oder per E-Mail/BISPrint versenden wollte, konnte je nach Betrieb die Meldung „keine Vorlage" erhalten — der Druck wurde dann nicht ausgeführt. Grund: Die Rechnungs-Werksvorlage entstand erst, sobald jemand den Rechnungsdesigner einmal geöffnet hatte. Jetzt hat jeder Betrieb von Anfang an eine fertige Werksvorlage — bestehende Betriebe bekommen sie automatisch beim nächsten Kassen-Abgleich, neue ab der Einrichtung. Anpassbar bleibt sie wie gewohnt im Rechnungsdesigner.

Beim Verkauf über Gebinde (z. B. ein 12er- oder 18er-Karton) konnte es an der Kasse zu zwei Problemen kommen: Manche Artikel zeigten ihr hinterlegtes Gebinde gar nicht an, und bei Artikeln mit mehreren Karton-Barcodes für dieselbe Verpackungsgröße (etwa weil verschiedene Lieferanten unterschiedliche Barcodes vergeben) stimmte je nach gescanntem Karton der Preis nicht. Beides ist jetzt behoben: Gebinde erscheinen zuverlässig mit dem passenden Preis je Kundengruppe, und jeder Karton-Barcode wird als Gebinde erkannt — egal welchen der Kassierer scannt.

Das Empfehlungsprogramm „Freunde werben Freunde" funktioniert jetzt durchgängig: Neukunden tragen ihren Empfehlungscode direkt im Anmeldeformular ein (über den Einladungslink bereits vorausgefüllt und live geprüft — mit Name des Werbenden und 20 % Rabatt für 3 Monate). Verdientes Guthaben (bis zu 50 € pro Empfehlung) lässt sich im Kundencenter mit einem Klick mit der nächsten Lizenzrechnung verrechnen — der nächste Monat wird automatisch günstiger — oder ab 10 € gegen Rechnung auszahlen.

Betriebe, die ausschließlich BIS ERP + Kasse nutzen (ohne JTL), erhalten jetzt einen vollständigen DATEV-Export: Ein Rechnungskauf an der Kasse wird als „Forderung an Umsatzerlös" gebucht (echte Rechnungsnummer), der spätere Zahlungseingang als „Bank/Kasse an Forderung" (umsatzsteuerfrei). Die Standard-Buchungskonten sind voreingestellt (SKR03) und in den DATEV-Einstellungen anpassbar. Betriebe mit JTL-Anbindung sind nicht betroffen.

Bei angebundener JTL-Warenwirtschaft wird die Rechnung für einen Bar- oder Kartenverkauf jetzt eindeutig nur einmal erzeugt: über die Kasse als belegechte Rechnung (per E-Mail an den Kunden), während der Umsatz sauber über den Z-Bon läuft — nicht zusätzlich als zweite JTL-Rechnung mit eigenem Erlös. Das Begleichen offener Aufträge ohne Rechnung an der Kasse stößt die Rechnungserstellung weiterhin zuverlässig im JTL-Workflow an. Damit ist die im Steuerberater-Review beanstandete Doppelbuchung strukturell ausgeschlossen.

Im Mehr-Kassen-Betrieb trägt jeder Kassenbeleg jetzt eine geräteübergreifend eindeutige Kennung. Das Kassenjournal ordnet Belege dadurch eindeutig der richtigen Kasse zu — keine doppelten oder verlorenen Belege mehr, selbst wenn mehrere Kassen identische oder ähnliche Bonnummernkreise nutzen. Die kundensichtbare Bonnummer auf dem Bon bleibt unberührt und darf sich (z. B. bei täglichem Reset) wiederholen.

Multi-Lager-Betrieb: Über einen Lager-Umschalter wählen Sie Ihr aktuelles Arbeitslager (bei nur einem Lager ausgeblendet, Auswahl bleibt erhalten). In der Lagerverwaltung ordnen Sie jedem BIS-Lager das passende JTL-Warenlager zu — Bestandsbuchungen landen dann genau dort (WMS-konform oder Standardlager). Pro Mitarbeiter legen Sie in der Benutzerverwaltung fest, welche Lager er nutzen darf. Auch die MDE-Lager-App hat jetzt einen Lager-Umschalter. Zusätzlich nutzen die JTL-Einstellungsseiten in BIS ERP und Kundencenter dieselben Bausteine und bleiben dauerhaft identisch.

Neue Belegart „Proforma-Rechnung": steuerneutral (keine Rechnung im Sinne des § 14 UStG), mit eigenem Nummernkreis (PF-), klarer Kennzeichnung im PDF und ohne Umsatzsteuer-/DATEV-Wirkung. Für Auslandssendungen mit Export-/Zollfeldern (EORI, Incoterm, Gewicht, Ausfuhrgrund sowie HS-Code und Ursprungsland pro Position). Per Klick wandeln Sie eine Proforma in eine echte Rechnung um; bei Zahlungseingang (manuell oder per Bankabgleich) entscheiden Sie per Einstellung, ob automatisch eine Rechnung entsteht.

Eine Inventur ließ sich bisher nur nach Lagerplatz anlegen. Jetzt wählen Sie zuerst die Basis — nach Lagerplatz oder nach Artikel. Bei Artikel-Basis stehen vier Methoden bereit: manuell, Stichprobe, Umschlagshäufigkeit und Zyklusinventur (ABC). Zusätzlich lässt sich beim Kommissionieren eine Stichprobenzählung mit fester Obergrenze pro Lauf einstellen (log-only, kein automatischer Bestandseingriff).

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: zusätzlich E-Mail und Telefon sowie Adresszusatz, Bundesland und getrennte Hausnummer.

Neuere JTL-Versionen erlauben Lieferscheine nur noch über JTLs eigene interne Routine. Die Versand-Rückmeldung nutzt jetzt diese Routine (mit Rückfall auf das direkte Schreiben bei älteren Versionen) — damit Lieferschein, Versanddaten, Lagerabgang und Auslieferstatus auch auf aktuellen JTL-Versionen sauber nach JTL geschrieben werden.

Die Rückmeldung versendeter Aufträge an JTL ging von einem festen Datenbankaufbau aus und scheiterte auf Konten mit abweichendem JTL-Stand. Jetzt erkennt sie den tatsächlichen Aufbau und schreibt nur die vorhandenen Felder (inkl. korrekter Behandlung automatisch vergebener Nummern) — zuverlässig über JTL-Versionen hinweg.

Auf bestimmten älteren Konten brach die Rückmeldung versendeter Aufträge an JTL beim ersten Schritt ab, weil eine nicht vorhandene Datenbankspalte abgefragt wurde — es wurde kein Versand zurückgemeldet. Die Abfrage verzichtet jetzt auf die nicht benötigte Spalte; Lieferschein, Lagerabgang und Auftragsstatus laufen wieder durch.

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 — über dieselbe schnelle Spur wie die Kassenverkäufe — und steht in Sekunden in JTL.

Beim Zurückbuchen eines Verkaufs/Versands in die JTL-WMS-Lagerverwaltung konnte eine einzelne nicht buchbare Position die gesamte Lagerbuchung des Belegs scheitern lassen (Beleg blieb hängen). Jetzt wird nur diese eine Position übersprungen, der Rest korrekt gebucht.

Versendet die Warenwirtschaft einen aus JTL stammenden Auftrag, wird der Lagerabgang seit 0.0.0.176 nach JTL zurückgebucht. Trat direkt danach eine kurze JTL-Verbindungsstörung auf, konnte ein Wiederholungslauf den Abgang theoretisch ein zweites Mal buchen — das ist jetzt ausgeschlossen.

Die BISPrint-Druckerverwaltung konnte bisher jeder Mitarbeiter ändern, und die Zuordnung „dieser PC nutzt diesen Drucker" musste an jedem PC einzeln gewählt werden. Jetzt ist die Verwaltung standardmäßig Administratoren vorbehalten (frei vergebbar), und jeder PC erscheint automatisch zentral, wo der Admin ihm den Drucker zuordnet.

Wurde ein importierter JTL-Auftrag in BIS ERP versendet, wurde der JTL-Lagerbestand bisher nicht ausgebucht und der Auftrag nicht als erledigt markiert. Jetzt führt der Versand in BIS ERP den Lagerabgang lagertyp-sicher in JTL nach, meldet Lieferschein/Tracking zurück und markiert den Auftrag als komplett ausgeliefert.

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

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. Die bisherige betriebsweite Zuweisung bleibt als Standard-Drucker (Fallback) erhalten.

Eine manuelle Bestandskorrektur (Plus-/Minus-Buchung mit Grund) wurde in BIS ERP verbucht, aber nicht an ein angebundenes JTL-Wawi weitergegeben — Bestände liefen auseinander. Jetzt werden manuelle Korrekturen automatisch und lagertyp-sicher nach JTL übertragen, und die Buchung läuft atomar.

Wareneingang, Bestandskorrektur und Inventur über die Lager-/MDE-App wurden in BIS ERP verbucht, aber nicht an ein angebundenes JTL-Wawi weitergegeben — Bestände liefen auseinander. Jetzt werden MDE-Buchungen automatisch und lagertyp-sicher nach JTL übertragen.

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, und eine Benachrichtigung in der Glocke meldet offene Aufträge ohne Client inkl. Restlaufzeit.

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 — ein rohes Überschreiben der Gesamtmenge konnte den WMS-Bestand verfälschen. Jetzt erkennt BIS ERP den Lagertyp automatisch und behandelt beide korrekt.

Liefen zwei BISPrint-Druck-Clients gleichzeitig im selben Konto auf denselben Druckern, konnte ein Dokument doppelt gedruckt werden, weil beide denselben Auftrag holten. Jetzt übernimmt jeden Druckauftrag nur ein Client — exakt ein Druck, mit automatischem Failover.

In den Listenansichten ließen sich Spalten zwar ein-/ausblenden und neu anordnen, aber die Breite konnte man nicht selbst bestimmen — lange Inhalte wurden abgeschnitten oder verschwendeten Platz. Jetzt lässt sich die Spaltenbreite per Maus ziehen und wird wie die übrigen Spalteneinstellungen geräteübergreifend pro Benutzer gespeichert.

Kartenzahlungen (EC-/Kartenterminal) an der Kasse tauchten in JTL teils als „BAR" auf, weil keine Zuordnung der Zahlungsarten hinterlegt war und die Auto-Erkennung im Zweifel „Bar" buchte. Jetzt bleibt Karte = Karte und Bar = Bar.

Holte man an der Kasse einen Kunden über die Suche aus JTL und verkaufte damit, erschien im JTL-Auftrag und auf der Rechnung die interne Nummer der Kasse/des BIS ERP (z. B. „KD-00018") statt der gewohnten JTL-Kundennummer (z. B. „1073") — vereinzelt sogar „POS-LAUFKUNDE". Jetzt wird durchgängig die echte JTL-Kundennummer verwendet.

Beim Klick auf „Artikel anlegen" konnte das Speichern bisher 5–13 Sekunden dauern, bis sich das Fenster schloss — besonders bei größeren Artikelbeständen. Jetzt ist ein neuer Artikel in der Regel in 1–2 Sekunden gespeichert.

Tagesabschlüsse (Z-Bons), deren Upload an der Kasse wegen kurzzeitig fehlender Internetverbindung scheiterte, werden jetzt garantiert nachgereicht — kein Abschluss geht mehr verloren. Gleichzeitig werden in der Cloud keine Kassendaten mehr gelöscht: Alle Verkäufe und Abschlüsse bleiben als unsichtbares Backup erhalten. Die bequeme Sicht auf die komplette Berichte-Historie am PC ist ab jetzt das Premiumfeature von BIS Insights.

In der Buchhaltung unter „Eingangsrechnungen" zählten die Kennzahl-Karten („Gesamt", „Bezahlt", „Ausstehend", „Genehmigt") alle Beträge einfach zusammen — ohne die Währung zu beachten. Eine Rechnung über z. B. 259 THB wurde wie 259 € behandelt, wodurch die Summen bei US-Dollar- oder Thai-Baht-Rechnungen viel zu hoch waren. Jetzt wird jeder Betrag vorher in Euro umgerechnet.

In der Bestellübersicht stand die Kennzahl-Zeile (Anzahl und Umsatz) fest auf „heute" — unabhängig vom gewählten Tag, Monat oder Jahr im Datums-Navigator. Beim Blick auf einen anderen Tag wirkte sie dadurch leer („0 Bestellungen heute • 0,00 € Umsatz"), obwohl die Liste darunter die Aufträge des gewählten Zeitraums zeigte. Jetzt folgt die Kennzahl dem Navigator.

Aktualisierte oder neu installierte Kassen luden beim ersten Start ihre Verkaufshistorie der letzten Tage mitunter erneut hoch. Die Anbindung erkannte diese Wiederholungen nicht zuverlässig — sie stützte sich auf eine Kassen-Kennung, die sich nach einer Neuinstallation ändert. Dadurch entstanden doppelte Aufträge in der JTL-WaWi (mit Original-Datum) und der Lagerbestand wurde doppelt abgebucht.

Bei Kassenverkäufen mit Pfand konnte die Bestellung in der angebundenen JTL-WaWi als „teilbezahlt" erscheinen, obwohl alles bezahlt war — der Pfand wurde doppelt berechnet. Zusätzlich markierte JTL Aufträge als „fehlerhaft", weil Pfand-/Sonderzeilen ohne hinterlegten Artikel („Div. Artikel") übergeben wurden. Beides ist behoben.

BIS ERP, das Kundencenter und das BIS Archiv liefen bisher unter einer gemeinsamen Adresse mit Unterpfaden (bispicy.com/app, bispicy.com/app/my) — unübersichtlich für Lesezeichen und zum Weitergeben. Im BIS Archiv (dms.bispicy.com) ging zudem nur die Anmeldung per E-Mail/Passwort; der „Mit Google anmelden"-Knopf aus BIS ERP und Kundencenter fehlte dort. Beides ist jetzt gelöst.

Nach dem Kundencenter (0.0.0.155) war die Haupt-Anwendung auf dem Smartphone noch nicht durchgängig sauber: In der Buchhaltung und in Kundendetails überlappten die Reiter, Kopfzeilen mit Aktions-Buttons (z. B. „An Kunden senden", „Bearbeiten") liefen aus dem Bild und breite Tabellen schnitten Spalten ab. Über 150 Seiten der Haupt-App wurden jetzt auf schmale Displays optimiert.

Mehrere Bereiche im Kundencenter (z. B. BIS Remote, JTL-Schnittstelle, Lizenzen, Steuer-Berichte, Kundenliste) liefen auf dem Smartphone nicht sauber: Die Seite ließ sich seitlich verschieben, Bedienelemente wie „Speichern" rutschten aus dem Bild, Tabellen schnitten die rechten Spalten (inkl. Bearbeiten/Löschen) ab und einzelne Eingabemasken waren stark gequetscht. Über 40 Seiten wurden jetzt auf schmale Displays (ab ~360 px) optimiert.

Im Artikel unter Preise gab es als Verkaufspreis bisher nur das Brutto-Feld — Händler, die mit Netto-Preisen arbeiten, mussten den Nettopreis selbst hochrechnen. Neu ist ein gekoppeltes Feld „Verkaufspreis (netto)": Sie tippen netto, der Brutto-Preis wird automatisch über den Steuersatz errechnet (und umgekehrt). Maßgeblich bleibt der Brutto-Preis; der Nettowert wird stets daraus abgeleitet.

Beim Hinzufügen einer dritten Kasse ließ sich unter Schnittstellen → JTL-Wawi → POS-Verkaufskanäle der Name des Verkaufskanals nicht mehr ändern — Tippen im Feld der dritten Kasse hatte keine Wirkung, während die ersten beiden funktionierten. Ursache: zwei interne Namens-Einträge für dasselbe Gerät, sodass Anzeige und Speicherung auseinanderliefen. Doppelte Einträge werden jetzt automatisch zu einem zusammengeführt.

Kassenverkäufe mit Pfand (Einweg-/Mehrweg-/Kistenpfand) wurden in der JTL-Wawi als „fehlerhaft" markiert, sodass sich keine Rechnung erstellen ließ (Button ausgegraut). Ursache: die Pfand-Zeile wurde als „Artikel ohne Artikelstamm" übertragen, was JTL als Fehler wertet. Pfand-Positionen werden jetzt als freie Position übertragen — der Auftrag bleibt fehlerfrei.

Wurde an der Kasse ein Kunde direkt aus der JTL-Suche gewählt und unmittelbar danach ein Verkauf gebucht, konnte dieser in der JTL-Wawi fälschlich als Laufkunde erscheinen — die Verknüpfung zum JTL-Kundenkonto wurde erst vom nächsten Hintergrund-Sync (Minuten später) hergestellt. Jetzt erfolgt die Verknüpfung sofort beim Übertragen.

Im Kundencenter unter POS-Geräte ließ sich eine Kassen-/TSE-Lizenz nicht entkoppeln, und eine bereits zugewiesene Lizenz konnte keinem anderen Gerät zugewiesen werden. Beides funktioniert jetzt zuverlässig.

Bei manuell über das Rechnungsformular erstellten Rechnungen blieben Zwischensumme, MwSt. und Rechnungsbetrag bei 0,00 € stehen, obwohl die Positionen korrekt waren (Kassen-/Auftrags-Rechnungen waren nicht betroffen). Die Summen werden jetzt zuverlässig aus den Positionen berechnet.

Auf der Rechnung wurde der Einzelpreis netto, die Gesamtsumme aber brutto ausgewiesen — uneinheitlich. Jetzt werden beide Preise durchgängig netto oder brutto angezeigt, automatisch passend zum Kundentyp.

Auf dem Rechnungs-PDF blieb die Spalte „Pos." leer, und auf Kassen-Belegen stand ein neben dem TSE-Block überflüssiger KassenSichV-Zusatz. Beides ist bereinigt.

Auf dem fertigen Rechnungs-PDF konnten lange Artikelnamen und Spaltentitel über ihre Spalte hinauslaufen, und der Steuerblock stand nicht bündig. Jetzt werden Spalten sauber eingepasst.

Der Belegvorlagen-Designer war faktisch nur für Administratoren nutzbar, und der Überfällig-Status wurde nur einmal täglich gesetzt. Jetzt können auch Manager Vorlagen bearbeiten, und überfällige Rechnungen werden sofort angezeigt.

Drei Korrektheits-/Sicherheitspunkte aus dem GoBD-Audit (keiner hat ausgegebene Belege verändert): mehrdeutige Standardvorlagen, drei nicht an die Dokument-Berechtigung gebundene Designer-Funktionen und ein schreibender Überfällig-Statuswechsel beim Öffnen der Statistik.

Einzelne Mandanten mit aktiver BIS-Insights-Lizenz (ehemals „BIS Remote Accounting") sahen im Kundencenter unter Berichte nur den heutigen Geschäftstag und kamen nicht an Kassenjournal, UStVA, EÜR, BWA, DATEV-Export und DSFinV-K — obwohl die Lizenz aktiv war. Ursache: Die Lizenz war intern nicht eindeutig mit dem Mandanten verknüpft, sodass die Berichts-Freischaltung sie nicht fand; zusätzlich blieb der Free-Hinweis sichtbar. Jetzt werden aktive Lizenzen zuverlässig erkannt (auch wenn sie nur über das Benutzerkonto hinterlegt waren), der volle Berichtszugriff steht offen und neue Lizenzen werden dauerhaft korrekt zugeordnet.

In bestimmten Konstellationen konnten SMTP-, Firmenlogo- und Rechnungsdesigner-Einstellungen beim Speichern still verloren gehen — ein Schreibfehler mit Notfall-Fallback, der den Datensatz im Konfliktfall sogar löschen konnte. Zudem konnten bei Mandanten, die WaWi-Rechnungen UND den JTL-Rechnungsabgleich nutzen, je nach interner Tabellen-Reihenfolge Datenbankfehler („Spalte fehlt") auftreten. Beides ist behoben.

Beim Stornieren einer Rechnung wurde die Gutschrift nur als Entwurf angelegt — ohne endgültige Nummer, PDF und E-Rechnung. Außerdem konnte in seltenen Fehlerfällen beim Festschreiben eine Rechnungsnummer „verbraucht" werden, ohne dass ein Beleg entstand (Lücke im Nummernkreis). Jetzt entsteht beim Storno ein revisionssicherer Korrekturbeleg, und Nummern gehen nicht mehr verloren.

Der DIN-A4-Kassenbeleg konnte je nach Layout-Einstellung ohne den vorgeschriebenen TSE-Block ausgegeben werden, und fehlende TSE-Daten blieben unsichtbar. Im Belegdesigner ließen sich die KassenSichV-Pflichtangaben zudem versehentlich abschalten. Jetzt trägt jeder Kassenbeleg immer den TSE-Block, und Notbelege werden korrekt gekennzeichnet.

Finalisierte Rechnungen wurden bisher nur flüchtig im Server-Dateisystem abgelegt (bei jedem Update weg) und beim erneuten Öffnen mit dem AKTUELLEN Layout/Logo neu gerendert — ein bereits ausgestellter Beleg konnte sich also unbemerkt ändern, und ein reines Ansehen mutierte den Datensatz. Das verletzte die GoBD-Belegunveränderbarkeit. Jetzt: Layout, Branding und Logo werden beim Finalisieren eingefroren, die fertige PDF landet privat + mit SHA-256-Prüfsumme in revisionssicherer Cloud-Ablage und wird unverändert ausgeliefert. Lesen/Mailen/Drucken verändert den Beleg nicht mehr. Ein Backfill sichert Bestandsrechnungen originalgetreu.

Eine Tiefenprüfung des Rechnungs-Designers (GoBD/Korrektheit/Usability) deckte drei Fehler auf: Der GiroCode/QR-Code kodierte einen falschen Überweisungsbetrag (Cent fehlten, ab 1.000 € massiv zu niedrig — z. B. 1,23 € statt 1.234,56 €); eine Vorlage konnte über Bearbeiten/Duplizieren/Migration leer gespeichert werden; und im Fehlerfall bei Werks-Reset/Layout-Modus kam eine technische Fehlerseite. Alle drei sind behoben — verifiziert und per Code-Sweep auf Geschwister-Stellen geprüft.

Als digitale Zahloption bot die Rechnung bisher nur den SEPA-GiroCode; ein PayPal-Zahllink ließ sich nicht direkt auf die Rechnung bringen. Auch war nicht auf einen Blick erkennbar, ob eine Rechnung bezahlt, storniert oder überfällig ist, E-Mail/Website im Fuß waren nicht klickbar und Datumsangaben teils im technischen Format. Jetzt: optionaler PayPal-Zahllink (PayPal.Me-Adresse oder PayPal-E-Mail) mit klickbarem Block + QR-Code und vorausgefülltem Betrag, automatisch ausgeblendet bei bezahlten/stornierten Belegen (Doppelzahlungs-Schutz). Dazu ein diagonaler Status-Stempel, prominente Fälligkeit neben dem Endbetrag, klickbare Footer-Links und einheitliches deutsches Datumsformat.

Kaufte ein Kunde an der Kasse „auf Rechnung" und der Betrieb hatte eine JTL-Anbindung, unterdrückte BIS ERP den eigenen Rechnungsdruck in der Annahme, JTL erzeuge und liefere die Rechnung automatisch. War in JTL aber kein Rechnungs-Workflow eingerichtet, entstand nur ein offener Auftrag ohne Beleg — der Kunde bekam in seltenen Fällen gar keine Rechnung. Jetzt überspringt BIS ERP den eigenen Druck nur noch, wenn in der JTL-Anbindung tatsächlich ein Rechnungs-Workflow hinterlegt ist; sonst stellt die Kasse / BIS ERP die Rechnung selbst aus. Die DATEV-Trennung bleibt unverändert — jeder Vorgang wird genau einmal gebucht.

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 und automatischer Eingangsbestätigung mit exaktem Zeitstempel. Für Shopify-Shops gab es bisher keine an BIS ERP angebundene Lösung. Jetzt: die eigenständige Shopify-App „BISWiderruf" (rechtskonformer Theme-Block, zweistufiges Formular, automatische Bestätigungs-E-Mail mit PDF, Händler-Benachrichtigung, Audit-Log) plus optionale Bridge, die jeden bestätigten Widerruf automatisch als Retoure in den Mandanten überträgt.

Auf finalisierten Rechnungen (besonders aus Kassen-Verkäufen) blieben Felder leer, obwohl die Daten vorhanden waren: Steuer-Block „MwSt. gesamt 0,00 €" trotz 7%-Position, leerer Käuferblock, Lieferadresse als „, , , DE", fehlende Auftragsnummer/Zahlungsbedingungen, Bearbeiter als Login-E-Mail. Ursache war eine entkoppelte Daten-Aufbereitung zwischen Rechnungs-Erzeugung und PDF-Renderer. Jetzt: USt-Aufschlüsselung pro Satz aus den Positionen, alle Käufer-/Adressfelder zuverlässig gezogen, kein Separator-Salat, „Laufkunde" bei Barverkauf, Mitarbeitername statt E-Mail, Firmendaten-Fallback aus der Rechnungs-Absenderadresse.

In der Bestellübersicht erschien beim Markieren einer Bestellung in der Aktionsleiste immer der Button „Rechnung" — auch wenn längst eine Rechnung existierte. Ein erneuter Klick führte in den Erstellungs-Dialog und konnte versehentlich einen zweiten Beleg anstoßen. Jetzt: Hat eine markierte Bestellung bereits eine Rechnung, verschwindet der „Rechnung erstellen"-Button; stattdessen erscheint „Rechnung ausgeben" und lädt die vorhandene Rechnung direkt herunter (einzeln als PDF, mehrere als ZIP). Bei gemischter Auswahl sind beide Buttons sichtbar. Das Verhalten entspricht jetzt der Einzel-Zeilenaktion und dem Rechtsklick-Menü.

Wenn ein Tenant JTL nutzt, ein Kassenkunde „Rechnungskauf" wählt und der Kassierer zusätzlich den DIN-A4-Toggle aktivierte, entstanden zwei Rechnungen mit unterschiedlichen Nummern für denselben Vorgang — eine aus BIS ERP, eine aus dem JTL-Workflow. Jetzt erkennt das System die Konstellation automatisch: Die BIS-ERP-Rechnung wird weiterhin für Audit/Backoffice erzeugt und als interner Beleg markiert, der Versand an den Kunden (E-Mail/BISPrint) wird aber blockiert (412) und die POS-App überspringt den lokalen Druck. Der Kunde erhält nur die JTL-Rechnung. Die DATEV-Trennung bleibt sauber, JTL bucht den Umsatz genau einmal.

Das Bestellungs-Kontextmenü hatte bisher nur wenige Aktionen; „Bestellung per E-Mail an den Kunden" gab es gar nicht. Beim Erstellen einer Rechnung aus einer Bestellung musste man nach dem Speichern erneut auf die Rechnung gehen, um sie zu versenden oder zu drucken. Und die Rechnungsliste (Buchhaltung → Ausgangsrechnungen) hatte überhaupt keine Mehrfachauswahl. Jetzt: Kontextmenü um „Pickliste erstellen" und „Bestellung per E-Mail senden" ergänzt. Der Modaldialog beim Rechnung-Erstellen bietet Folgeaktionen (E-Mail, PDF, Druck) als Checkboxen direkt mit. Bulk-Bar in Bestellungen kennt Sammel-E-Mail, ZIP-Download und Druck. Rechnungsliste hat Selection + Sticky Bulk-Bar mit Versenden / ZIP / Drucken / Bezahlt markieren / Sammel-Storno. Pro Beleg eigener Audit-Log-Eintrag.

Vier zusammenhängende Verfeinerungen am POS-DIN-A4-Workflow: das Firmenlogo lässt sich jetzt direkt vom Tenant unter Einstellungen → Allgemein → Unternehmen hochladen (vorher nur SuperAdmin). Neuer Endpoint POST /pos/transactions/{saleId}/tse-data reicht TSE-Counter/Serial/Client-ID/QR-Code nach Finalize an die DIN-A4-Rechnung nach. Die POS-App prüft per GET /bisprint/status, ob ein BISPrint-Client online ist, und schaltet den Pfad nur dann aktiv — kein 412-Frust mehr. Neue End-to-End-Walkthrough-Doku unter docs/audit/POS_KASSENKUNDE_RECHNUNG_WALKTHROUGH.md.

Tenants konnten bisher keine eigenen SMTP-Daten hinterlegen — alle teilten sich die zentrale Master-SMTP. Wer ohne Setup eine Rechnung mailen wollte, bekam still „SMTP not configured" zurück. Neue Sektion „E-Mail & SMTP" unter Allgemein lässt jeden Tenant Host/Port/User/Passwort/Encryption/Absender/Reply-To pflegen, inkl. Test-Mail-Button mit Override (auch ohne Speichern testbar). Wenn keine eigene Konfig aktiv: automatischer Fallback auf die System-Mail [email protected] — neue Tenants können sofort Rechnungen mailen, ohne erst SMTP einzurichten. Klares UI-Banner zeigt den Fallback-Status. Tenant-SMTP-Daten liegen sauber isoliert in der Tenant-DB (tenant_settings.smtp JSON), Master-SMTP-Repository bleibt unangetastet als Fallback.

Mit 0.0.0.117 wusste der Steuerblock, welche Sätze landesüblich sind — er hat sie aber alle angezeigt, auch wenn die Rechnung nur einen davon enthielt. Jetzt entscheidet ein neuer Element-Typ taxSummaryBlock zur Render-Zeit anhand der tatsächlichen vatSummary, welche Spalten angezeigt werden. Default showOnlyUsedRates=true. Eine DE-Rechnung mit nur 19% zeigt 4 Spalten statt 6. Schriftgröße passt sich der Spaltenanzahl an (8 pt bei 1-2 Sätzen, 6,5 pt bei 4+). Builder deutlich schlanker — statt 12+ statischer Spalten-Elemente jetzt 1 Element mit availableRates-Pool.

Drei Ergänzungen, die die Werks-Vorlage von „DE-only" zu „europaweit ready" machen. Steuersätze für 31 Länder hartcodiert und automatisch erkannt aus der Firmenanschrift — Steuerblock-Spalten passen sich an (1-4 Sätze, automatisch schrumpfende Schrift bei vielen Sätzen). Logo wird automatisch aus tenant_settings.system.companyLogoUrl bezogen (lokaler Pfad, data-URL oder HTTPS-URL mit 4s-Timeout). DIN-676-konforme Falt- und Lochmarken bei 105/148,5/210 mm am linken Rand — für saubere DIN-Lang-Kuvertierung. Land-Override im Designer für Sonderfälle.

Adressblock sitzt jetzt nach DIN 5008 Form B (45-85 mm von oben, 20 mm vom linken Rand) — passt in Standard-DIN-Lang-Briefumschläge mit Fenster und C4-Umschläge ohne Knicken. Spalten überarbeitet: SKU statt Artikelnummer, Hersteller raus, Bezeichnung 30% breiter, Einzelpreis netto + Gesamt brutto. Wenn das PDF-File fehlt (z. B. nach Deploy mit flüchtigem Storage), wird es automatisch on-the-fly neu erzeugt — keine 404er mehr. Billing-Overview-Endpoint liefert bei Service-Ausfall partielle Daten statt 500. „Werks-Vorlage neu erstellen"-Button im Designer für sofortiges Layout-Update.

Die Werks-Vorlage rückt näher an etablierte Geschäftsbrief-Vorlagen: Code128-Barcode der Rechnungsnummer zwischen Logo und Titel im Briefkopf (Pickerei/Versand-Workflows + automatische Belegerkennung), klassischer Hinweis „Bitte bei allen Rückfragen angeben!" unter der Meta-Box, Akzentfarbe pro Tenant frei wählbar im Designer (Default dunkelblau, asia-in nutzt z. B. Orange) — wirkt auf die Linie unter dem Logo und auf den Endbetrag in der Steuerleiste. Das moderne „AN"-Label vor dem Empfänger ist optional. Wer eine dieser Einstellungen ändert, bekommt die Werks-Vorlage automatisch neu gebaut — User-bearbeitete Templates bleiben unangetastet.

Rechnung, Lieferschein, Auftragsbestätigung, Gutschrift, Angebot, Mahnung und POS-Rechnung bekommen ein modernes A4-Layout — Mini-Absender-Zeile oben, klar abgesetzter Empfänger-Block, Logo mit Akzent-Linie rechts, gesperrter Titel, Meta-Box mit dezenten Trennlinien, kompakter Steuerblock in einer Zeile (Netto/USt pro Satz + Endbetrag in Akzentfarbe), optional GiroCode QR für Sepa-Überweisung, 4-Spalten-Footer mit ZUGFeRD-Hinweis. Neu: globaler Modus — eine gemeinsame Vorlage für alle A4-Dokumente, Titel/Felder/Spalten passen sich pro Typ automatisch an. Toggle im Designer entscheidet zwischen globalem Layout und individuellen Vorlagen pro Dokumenttyp.

Mit 0.0.0.112 stand der DIN-A4-Workflow für den lokalen A4-Drucker am POS-Tablet plus Mail-Versand. Jetzt ergänzt um BISPrint als drittes Druck-Szenario: Cloud-Druck auf entfernten Druckern. Funktioniert mit USB (Windows-Client über Print Spooler — alle Treiber-installierten Drucker), Netzwerk (TCP Port 9100, Windows + Android) und Bluetooth (Android-Client BT-SPP). Im Checkout zusätzliche Checkbox "Über BISPrint-Drucker" neben "A4-Drucker (lokal)" und "E-Mail" — alle Kombinationen erlaubt. Backoffice-Modal im Kassenjournal hat jetzt drei Buttons (Anzeigen / BISPrint / Mail). Neuer Endpoint POST .../invoice/bisprint legt den Druck-Job in die BISPrint-Queue, idempotent gegen die Rechnungs-Erzeugung (kein neuer Rechnungsnummer-Verbrauch).

Mit 0.0.0.111 stand der serverseitige Renderer; jetzt sind die Auslöser dran. Im POS-Checkout gibt es einen ausklappbaren Toggle „DIN-A4-Rechnung" mit den Optionen Druck / Mail / beides (Stammkunden-Mail vorausgefüllt). Nach erfolgreichem Sync holt die Kasse das fertige PDF und übergibt es an den lokalen A4-Drucker oder versendet es per Tenant-SMTP. Im Backoffice-Journal jetzt pro Verkauf ein „DIN-A4"-Button für Nachforderungen — idempotent gegen den Endpoint. Wird ein Verkauf mit ausgestellter Rechnung storniert, legt BIS ERP automatisch die Gutschrift an. Im Invoice-Designer steht das tseBlock-Element jetzt als platzierbares Sidebar-Element.

Pro Kassenverkauf optional eine vollständige DIN-A4-Rechnung mit TSE-Block (Signatur-Zähler, Serial, Zeitstempel, QR-Code) — gerendert vom bestehenden BIS-ERP-Formulardesigner. Druck lokal an der Kasse oder Mail an den Kunden. JTL ist nicht involviert (vermeidet die TSE-Bezugnahmen-Lücke der JTL-Rechnungsfunktion). DATEV-Doppelbuchung strukturell ausgeschlossen: POS-Rechnungen tragen source=pos und werden in allen invoice-basierten DATEV-Pfaden ausgefiltert — der Erlös läuft weiterhin nur einmal über den POS-DATEV-Export. Audit-Doku zur Steuerberater-Vorlage in docs/audit/.

Sonderpreise lassen sich jetzt pro Verkaufskanal × Kundengruppe pflegen — direkt im Artikel, mit Tab pro Kanal (BISpicy POS, B2B Kasse, B2C Kasse, Onlineshop, Marktplatz) und einer Tabelle pro Tab mit Basispreis, Sonderpreis und Aktion-ab/bis-Datum je Kundengruppe. Änderungen im BIS ERP landen automatisch in JTL zurück (tArtikelSonderpreis / tSonderpreise / tPreis). Die Kasse zieht den passenden Kanal-Preis serverseitig — kein App-Update nötig. Lokale Pflege im BIS ist vor JTL-Pull-Overwrite geschützt.

Detail-Berichte in BIS ERP (Sales, Kunden, Artikel, Lager, Marktplätze, Gebühren) und alle POS-Auswertungen (Kassenjournal, UStVA, EÜR, BWA, DATEV, DSFinV-K) leben jetzt in einem eigenständigen Paket „BIS Insights" (15 €/Monat, 30 Tage gratis testen) — Cloud-Historie inklusive. Davon getrennt: „BIS Remote" (10 €/Monat) für die Remote-Steuerung der Kasse. Beide Pakete sind unabhängig buchbar. Dashboard-Quickviews auf den Startseiten bleiben für alle frei. Wer BIS Insights später bucht, dessen POS-App lädt die lokale Sales-Historie automatisch nach. Bestandskunden bleiben transparent freigeschaltet.

Bisher wurden Gebinde vorrangig über Funktionsattribute erkannt. Artikel mit Gebinden nur in der nativen JTL-Gebindeverwaltung (Artikel → Gebinde/EAN) bekamen an der Kasse keinen bepreisten Gebinde-Eintrag. Jetzt liest BIS ERP die Gebinde direkt aus der JTL-Gebindeverwaltung — flächendeckend, ohne Funktionsattribute. Der Gebindepreis wird automatisch hochgerechnet (Einzelpreis × Menge je Kundengruppe); FA-Preise gelten weiter als Override, manuelle Preise haben Vorrang. Funktioniert auch ganz ohne JTL.

Je Kundengruppe lässt sich jetzt eine Mindestabnahme (und ein optionales Abnahmeintervall) hinterlegen — z. B. „Händler kaufen mindestens ein Tray = 24 Stück". Die Mindestabnahme wird bidirektional mit der JTL-Wawi abgeglichen und an der Kasse durchgesetzt: Liegt die Menge darunter, weist die Warenkorbzeile darauf hin und beim Abschluss erscheint eine Sperre. Beim Antippen des Preises einer Gebinde-Position rechnen Stück- und Tray-Preis (netto) automatisch ineinander.

Hatte ein Artikel je Verkaufskanal (z. B. „Kasse 2", Onlineshop) unterschiedliche Kundengruppenpreise, konnte an der Kasse versehentlich der Preis eines anderen Kanals landen statt des Standard-(Global-)Preises aus JTL — z. B. ein Händlerpreis von 1,18 € statt der korrekten 1,1305 €. Jetzt erhält die Kasse zuverlässig den JTL-Global-Preis je Kundengruppe (Kundengruppen- wie Staffelpreise).

Hatten Sie für ein Gebinde (z. B. Tray, Karton, Sixpack) einen kundengruppenspezifischen Preis hinterlegt — etwa einen eigenen Händler- bzw. Geschäftskundenpreis — wurde an der Kasse trotzdem nur der Standard-/Endkundenpreis angewendet. Die Gruppenpreise waren in BIS ERP korrekt sichtbar, erreichten die Kasse aber nicht. Jetzt werden Händler-, VIP- und andere kundengruppenspezifische Gebindepreise korrekt an die Kassen übertragen und dort je nach Kundengruppe angewendet. Veraltete, doppelte Gebinde-Preiszeilen werden beim Sync automatisch entfernt.

Befristete Support-Zugriffe gelten jetzt strikt nur im gewählten Zeitfenster. Genehmigte, aber abgelaufene Freigaben werden serverseitig blockiert und korrekt als „Abgelaufen" geführt — der Einlog-Knopf verschwindet, und eine laufende Sitzung kann den gewährten Zeitraum nicht überdauern.

Neue Seite „Aktionen (POS)" im Kundencenter: 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 und „An Kassen senden"-Button. Bei pfandpflichtigen Artikeln bleibt das Pfand an der Kasse voll berechnet, nur der Artikelpreis der Gratis-Einheit ist 0 €. 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 und bis_promo_deposit) — beim JTL-SQL-Sync wird daraus automatisch eine Aktion erzeugt und verteilt. Die Kassen-App ab Version 1.1.13 löst die Aktionen automatisch im Warenkorb aus.

Im Kundencenter (JTL-Integration) ließ sich die Standard-Kundengruppe für die Kasse — für die Verbindung wie auch pro einzelner Kasse — bisher nur auswählen, wenn der BISConnect-Client gerade online war und die JTL-Wawi live antwortete. War die lokale JTL nicht erreichbar (Client offline, PC aus), bot das Auswahlfeld nur „Standard (Connection)" an, obwohl im Konto bereits mehrere Kundengruppen angelegt bzw. aus JTL synchronisiert waren. Jetzt bezieht das Auswahlfeld die Kundengruppen aus den im Konto gespeicherten Gruppen — immer verfügbar, ganz ohne aktive JTL-Verbindung. Ist JTL gerade online, werden zusätzlich frisch in JTL angelegte, noch nicht synchronisierte Gruppen ergänzt. Die gespeicherte Auswahl nutzt denselben Kundengruppen-Schlüssel wie JTL, sodass Preise an der Kasse unverändert korrekt aufgelöst werden und bestehende Einstellungen gültig bleiben.

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. Außerdem waren ab Werk alle Zahlungsarten aktiv. Jetzt wird die Zahlart „girocard" ü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 und einmalig umbenannt (der DATEV-Export ist nicht betroffen, er nutzt Kontonummern). Zusätzlich aktivieren neu angelegte Tenant-Konfigurationen ab Werk nur noch den Barverkauf — sowohl „aktiv in der Kasse" als auch „in der Kundenanlage"; jede weitere Zahlungsart schaltet der Betreiber bewusst frei. Bestehende Konfigurationen bleiben unverändert. Spielt mit Kasse 1.1.12 zusammen, die denselben Klartextnamen verwendet.

Wenn das Kartenterminal nicht direkt mit der Kasse verbunden ist — Stand-alone-Gerät, Anbindungsproblem, Schnittstellenausfall — gab es bisher keine offizielle Anleitung, wie der Kassierer den Vorgang sauber verbucht. Genau dafür existiert in der Kasse seit langem der Zahlungstyp „Individuelle Zahlungsart", er war aber nicht prominent dokumentiert. Jetzt gibt es unter bispos.app/docs/zahlungsart-manuell.html eine vollständige Schritt-für-Schritt-Anleitung mit Screenshots in Deutsch und Englisch (Tab-Umschalter pro Schritt). Workflow: Eigene Zahlart anlegen (Name frei wählbar, z. B. „Kartenzahlung"), DATEV-Konto (typisch 1200 EC-Karten) eintragen, fertig. An der Kasse drückt der Kassierer den neuen Button, die Kasse zeigt „Terminal bereit für Zahlung", die Kartenzahlung wird manuell am Terminal abgewickelt, abschließend signiert die Kasse den Bon TSE-konform mit vollwertigem Signatur-Block (Transaktionsnummer, Zähler, QR-Code). Die Doku argumentiert ausdrücklich auch die GoBD-/KassenSichV-Konformität (Bon ist TSE-signiert, Terminal-Beleg = Zahlungsfluss) und gibt einen klaren Tagesabschluss-Abgleich-Hinweis.

Bisher ließ sich Scan-to-Order nur komplett ein- oder ausschalten. Wer den QR-Code am Tisch nur für eine digitale Speisekarte nutzen wollte (Bedienung läuft klassisch ans Tablet), konnte das Bestellen über den QR-Code nicht gezielt unterbinden. Jetzt gibt es den Schalter „Nur digitales Menü" in den Scan-to-Order-Einstellungen — sowohl in der POS-App selbst als auch zentral über BISRemote im Kundencenter. Gäste sehen über den QR-Link weiterhin die volle Karte mit Bildern, Beschreibungen, Preisen und Modifier-Gruppen — der „Bestellen"-Button ist aber abgeschaltet. Stattdessen zeigt das Gastfrontend einen Hinweis „Dies ist eine digitale Speisekarte. Bitte bestelle direkt beim Personal." (übersetzt in DE/EN/FR/IT/NL/TH). Die Bestellung wird zusätzlich serverseitig blockiert (HTTP 403), falls jemand die API direkt aufruft. Ideal für Pop-up-Stände, Bars/Cafés mit reiner Karten-Anzeige oder Friseure/Praxen, die eine Behandlungsübersicht statt Bestellung zeigen möchten.

System-Mails (Willkommen, Passwort-Reset, TSE-Willkommen, Support-Zugriff, Lieferanten-Berichte) und Admin-Marketing-Kampagnen aus BIS ERP landeten bei Empfängern mit Freemail-Adressen — Gmail, GMX, web.de, Outlook/Hotmail, Yahoo, iCloud, T-Online — wegen der strengen Reputations-Filter dieser Anbieter überdurchschnittlich oft im Spam-Ordner. Jetzt werden Admin-Mails an Freemail-Empfänger automatisch über den verbundenen Master-Gmail-Account verschickt, unabhängig vom sonst konfigurierten Routing. 22 typische Freemail-Domains sind voreingestellt und unter Super-Admin → Gmail-OAuth → „Freemail-Spam-Schutz" frei pflegbar (Toggle, Tag-Editor, Standard-Reset). Mails an Geschäfts-Domains folgen unverändert dem normalen Routing; Branding (Absender-Name, Reply-To) bleibt erhalten.

Denselben Artikel in verschiedenen Zuständen zu verkaufen — neu, gebraucht, B-Ware/„zweite Wahl" — war bisher nicht sauber abbildbar: Artikel mit derselben EAN lösten eine „doppelte EAN"-Warnung aus, und an der Kasse wurde beim Scannen immer nur der erste Treffer genommen. Jetzt hat jeder Artikel ein Feld „Zustand" (aus JTL-Wawi übernommen). Mehrere Artikel desselben Produkts dürfen sich dieselbe EAN teilen, solange ihr Zustand unterschiedlich ist — je mit eigenem Preis und Bestand. Wird an der Kasse eine EAN gescannt, hinter der mehrere Zustände stecken, fragt die Kasse kurz nach, welcher Zustand verkauft wird; gibt es nur einen Artikel zur EAN, läuft alles ohne Rückfrage. Der Zustand wird bidirektional mit JTL-Wawi abgeglichen.

Die Amazon-Anbindung bewarb globale Vorlagen, Design-Vorlagen und die ASIN-Suche — die Oberflächen dazu waren zwar fertig, aber in keiner Ansicht eingebunden. Jetzt sind sie als zwei neue Tabs erreichbar: „Vorlagen" bündelt die drei Vorlagen-Editoren (Global, Design, Listing), „ASIN-Suche" schlägt Amazon-Produkte per ASIN nach (Produktdetails, Bewertungen, bestehende Angebote). Alle Editoren sind vollständig in Deutsch, Englisch und Thai übersetzt.

Preise ließen sich bisher nur pauschal oder pro Kundengruppe festlegen — ein Sonderkonditionspreis für einen einzelnen Stammkunden war nur über eine eigene Kundengruppe machbar. Jetzt lässt sich pro Einzelkunde direkt ein eigener Artikelpreis hinterlegen, in der Artikel-Detailansicht („Individuelle Kundenpreise") oder auf der Kundenkarte im Tab „Preise". Auch Mengenstaffeln pro Kunde sind möglich. An der Kasse — Web-Kasse wie POS-App — greift der individuelle Preis automatisch, sobald der Kunde dem Verkauf zugeordnet ist, und hat Vorrang vor Kundengruppen- und Standardpreis. Individuelle Kundenpreise werden bidirektional mit JTL-Wawi abgeglichen.

Beim Anbinden von JTL-Wawi konnten Artikel ausbleiben, obwohl die Synchronisation „erfolgreich" meldete: Wer Artikel in JTL erst nach dem ersten Abgleich dem Verkaufskanal „BISpicy POS" zuwies, wartete vergebens — denn der Abgleich übertrug nur seit dem letzten Lauf bearbeitete Artikel, und eine Verkaufskanal-Zuweisung zählt in JTL nicht als Bearbeitung. Jetzt kommen neu zugewiesene Artikel beim nächsten Abgleich automatisch an der Kasse an, ohne sie extra zu bearbeiten oder einen vollständigen Neu-Abgleich anzustoßen. Außerdem werden Gebinde mit ungewöhnlich langen EAN-/Barcode-Werten (z. B. GS1-Codes) jetzt korrekt importiert, statt den Abgleich mit einem Fehler zu beenden.

Die Amazon-Kachel auf dem Dashboard zeigte bisher nur Nullen. Jetzt zeigt sie echte 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 Kacheln. Außerdem sind die Tabs „FBA-Einlieferung" und „Berichte & Gebühren" sowie alle Amazon-Meldungen jetzt vollständig in Deutsch, Englisch und Thai verfügbar, und die Amazon-Funktionsübersicht nennt nun auch Berichte, Finanzen und die DATEV-Kontierung.

Der DATEV-Export prüft jetzt vor dem Erzeugen des Buchungsstapels, ob alle Umsätze vollständig erfasst sind. Der Export ist ein zweistufiger Assistent: Schritt 1 wählt Zeitraum und Export-Typ, Schritt 2 zeigt eine Gesundheitsprüfung je Marktplatz/Kanal — mit Ampel und 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 bzw. finalisieren), danach wird automatisch neu geprüft. Der Export bleibt jederzeit möglich — wer offene Punkte nicht beheben will, exportiert mit „Trotzdem exportieren".

Mit 0.0.0.84 wurde ein „Global-B2B"-Preis eingeführt, der pauschal für alle Kundengruppen mit B2B-Kennzeichen galt. Das war falsch: Eine Gruppe wie „B2B Staffel 1", die gar keinen eigenen Gebinde-Preis hat, bekam trotzdem den B2B-Preis — obwohl sie wie in der JTL-Wawi den normalen Preis bekommen müsste. Das Gebinde-Preismodell ist jetzt sauber zweistufig: ein Global-Preis und optional ein Preis je einzelner Kundengruppe. Das Funktionsattribut „preis_b2b" gilt nur noch für die Kundengruppe, die exakt „B2B" heißt; alle anderen Gruppen ohne eigenen Gebinde-Preis bekommen den Global-Preis. Der „Preise bearbeiten"-Dialog hat dadurch nur noch „Global" und „Preis je Kundengruppe" — kein separates „Global-B2B"-Feld mehr.

Mit 0.0.0.85 kam die Amazon-Anbindung — verbinden, Listings, Bestellungen, Bestand. Diese Iteration ergänzt vier Bereiche: Ware lässt sich jetzt ins Amazon-Lager einliefern (FBA-Versandpläne erstellen, Sendungen anlegen, Versandetiketten abrufen), inklusive Pan-EU-Übersicht des FBA-Bestands je EU-Land. Finalisierte Rechnungen aus BIS ERP lassen sich per Klick an die jeweilige Amazon-Bestellung übertragen; nutzt das Konto Amazons Rechnungsservice (VCS), wird der eigene Upload automatisch unterdrückt. Ein neuer Tab „Berichte & Gebühren" fordert Amazon-Berichte an und liest Amazon-Gebühren, Werbekosten und Erstattungen ein. Und: jede Amazon-Gebührenart lässt sich einem DATEV-Konto zuordnen — der DATEV-Export weist jeden Posten mit Konto, Auftrags- und Rechnungsnummer aus, jeder Cent ist sauber zuordenbar für Buchhaltung und Bilanzierung.

BIS ERP brachte Artikel bisher auf eBay — eine in der Praxis nutzbare Amazon-Anbindung fehlte. Die vorhandene Amazon-Seite ließ sich faktisch nicht verwenden: Verbindungen kamen nicht zustande, Bestellungen wurden nicht importiert. Diese Iteration vollendet die Amazon-Selling-Partner-API-Schnittstelle. Konten lassen sich auf zwei Wegen verbinden — mit einem Klick über „Mit Amazon verbinden" (Zustimmung direkt bei Amazon) oder klassisch mit eigener SP-API-App über den 6-Schritt-Assistenten. Neue Amazon-Bestellungen werden alle 20 Minuten automatisch importiert (inklusive Lieferadresse) und lassen sich in lokale Aufträge umwandeln. Artikel können als Amazon-Listing angelegt, mit ASINs verknüpft und mit Preis und Bestand zu Amazon übertragen werden. Hinzu kommen Amazon-Berichte (z. B. Abrechnungen) zum Anfordern und Herunterladen sowie das Einlesen von Amazon-Gebühren und Erstattungen mit Auswertung nach Gebührenart. Mehrere Verkäuferkonten lassen sich parallel betreiben. Die Amazon-Anbindung ist eine kostenpflichtige Schnittstelle (ab Plan Business).

Das in 0.0.0.83 ausgelieferte Gebinde-Preismodell war starr zweistufig: ein Standardpreis und ein B2B-Preis, der pauschal für alle B2B-Kundengruppen galt. Echte Kundengruppen wurden nicht genutzt — eine einzelne Gruppe (z. B. Gastro oder eine bestimmte B2B-Staffel) konnte kein abweichendes Gebinde-Preis bekommen, und der Preise-Tab war nur ansehbar. Diese Iteration macht das Gebinde-Preismodell dreistufig: Global-Preis, optionaler Global-B2B-Preis und beliebig viele kundengruppenspezifische Preise. Aufgelöst wird je Kunde: eigener Gruppenpreis, sonst Global-B2B (bei B2B-Gruppen), sonst Global. Im Preise-Tab öffnet je Gebinde ein Button eine Preis-Matrix mit Auswahl aus den tatsächlichen Kundengruppen, je inkl. Sonderpreis und Zeitfenster. Die Funktionsattribut-Konvention wurde um bis_gebinde_N_preis_{kundengruppe} erweitert; der bidirektionale JTL-Sync schreibt die Gruppenpreise mit.

Gebinde (bis_gebinde_*) und Pfand (bis_pfand_*) kamen über JTL-Funktionsattribute bisher nur in eine Richtung nach BIS ERP — bearbeiten ging nur in der JTL-Wawi. Zwei Bugs fielen dabei auf: Das Pfandart-Feld auf der Artikel-Detailseite war bei allen Pfandartikeln leer, weil der Sync den Wert großgeschrieben speichert (EINWEG), das Auswahlfeld aber nur kleingeschriebene Werte kannte; und ein Gebinde mit getrenntem B2C-/B2B-Preis erzeugte eine eigene Staffelpreis-Zeile pro B2B-Kundengruppe (bis zu 12 fast identische Zeilen). Diese Iteration vereinheitlicht die depositType-Schreibweise systemweit auf GROSS und macht den Funktionsattribut-Sync bidirektional: Gebinde und Pfand lassen sich direkt in BIS ERP pflegen und werden als Funktionsattribute nach JTL zurückgeschrieben — sofort beim Speichern, bei nicht erreichbarem JTL-Rechner per nächstem Sync-Lauf. Der Gebinde-Editor kann jetzt B2B-Preis und Sonderpreise; der Preise-Tab zeigt Gebinde als kompakte Übersicht. Gebinde und Pfand werden außerdem beim Duplizieren, in der Massenbearbeitung und beim CSV-Import mitgeführt.

Eine Kundengruppe wurde bisher nur an die POS-Kasse übertragen, wenn das Flag syncToPos gesetzt war. Das war ein Konstruktionsfehler: Die Kasse braucht jede Kundengruppe, die ein Kunde haben kann, um Preis, B2B-Status und Brutto/Netto-Anzeige korrekt aufzulösen. War nur die Gruppe B2B markiert, fiel ein Endkunde an der Kasse auf den Tenant-Default zurück — falsches Pfand (netto statt brutto), falsche Preisanzeige. Fix: getCustomerGroups liefert ab sofort ALLE aktiven Kundengruppen. Die DB-Spalte customerGroups.syncToPos wurde zu showInPosCustomerCreation umbenannt (Migration automatisch) und bedeutet jetzt nur noch: in der POS-Kundenanlage als wählbare Gruppe anbieten. Die Checkbox in der Kundengruppen-Verwaltung heißt jetzt Kundenanlage statt An Kasse. Die POS-Kasse filtert das Kundenanlage-Dropdown auf dieses Flag (Room-Migration 215→216).

Wurde ein POS-Verkauf als Bestellung in BIS ERP gespiegelt, zeigte die Bestellung den Kunden unvollständig. createOrderFromPosSale setzte den Bestell-Namen auf Firma ODER Vorname+Nachname — sobald eine Firma hinterlegt war, fiel der Personenname komplett weg (die Bestellung zeigte nur „asia-out" statt „asia-out / Bernhard Binder"), und die Spalten shippingCompany/billingCompany/billingVatId/shippingPhone blieben leer. Die Anschrift wurde nur aus dem server-seitigen Kundendatensatz kopiert — fehlte der (z. B. wegen einer Dublette ohne Adresse), blieb die Bestellung ohne Straße/PLZ/Ort. Diese Iteration mappt Personenname und Firma getrennt und füllt Telefon + USt-IdNr. Zusätzlich liefert die POS-Kasse mit jedem Verkauf einen vollständigen Kunden-Snapshot — createOrderFromPosSale nutzt vorrangig diesen, die Bestellung ist damit self-contained. Der Kundensync erkennt einen vorhandenen Kunden außerdem über die Kundennummer sowie über Vorname+Nachname+Firma — so entstehen für Kunden ohne E-Mail/Telefon keine neuen Dubletten mehr.

Die JTL-Direktsuche der POS-Kasse (searchJtlCustomersDirect) leitete das isB2B-Kennzeichen aus dem Firmennamen ab — sobald in JTL das Feld Firma befüllt war, galt der Kunde als B2B. Bei vielen Endkunden steht dort aber z. B. der Nachname. Folge: Endkunde wurde an der Kasse als B2B behandelt, Pfand netto statt brutto gerechnet. Der Artikelpreis blieb korrekt, weil die Preisermittlung die Kundengruppe direkt auswertet — das B2B-Flag war eine zweite, falsch befüllte Quelle. Fix auf zwei Ebenen: searchJtlCustomersDirect löst isB2B jetzt aus customerGroups.isB2B auf (JTL-Gruppen-ID 1:1 zu BIS-groupKey); resolveIsB2B in der POS-Kasse priorisiert die Kundengruppe und nutzt das Flag nur noch als Fallback.

Pfand-Werte für die Kiste konnten bisher in zwei Stellen gepflegt werden: am Basisartikel über bis_kistenpfand_betrag (seit 0.0.0.76) und am Gebinde über das alte bis_gebinde_N_pfand_betrag. Das war doppelte Wahrheit — bei Artikeln mit mehreren Gebinden (Sechserträger + Kasten) war unklar, welcher Gebinde-Pfand für die Kistenautomatik genommen wird. Zusätzlich stand der Wert „Kasten-Eigenpfand" konzeptionell am Artikel, nicht am Gebinde. Diese Iteration räumt auf: 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 auf articles.crateDepositThreshold/Amount aus dem Gebinde ist entfernt. Pfand pflegt man ausschließlich über die Artikel-FAs bis_pfand_typ + bis_pfand_betrag (Flaschenpfand) und bis_kistenpfand_betrag + bis_kiste_ab (Kistenautomatik). Quellenpriorität auf zwei Stufen zurechtgestutzt: BIS-ERP-UI > JTL-FA. Tenants mit altem Setup müssen einmalig umpflegen.

Wer mehr als eine Kasse am selben Tenant betreibt, hat bisher zwei Schmerzpunkte gehabt: erstens vergaben die einzelnen Kassen parallel dieselben Bonnummern (z. B. WEB-2026-0001 auf K1 und K2 — fiskal über TSE eindeutig, in DATEV/Kassenbericht aber verwirrend), zweitens aggregierten DATEV-Export, UStVA, EÜR und Kassenjournal stets alle Kassen zusammen, eine Filialauswertung pro Kasse gab es nicht. Diese Iteration fügt jeder posDevices-Zeile ein 1–8 Zeichen langes shortCode-Feld hinzu, das beim Anlegen automatisch aus dem Geräte-Namen abgeleitet wird (Kasse 1 → K1, Bar → BAR) und tenant-weit eindeutig ist. Die WebPOS-Bonnummer enthält ab sofort dieses Kürzel (WEB-K1-2026-0001), bestehende Belege bleiben unverändert. DATEV-Export, POS-Berichte und die DSFinV-K-Vorschau bekommen einen Geräte-Filter — als interne Kontrolle. Der gesetzliche Export ans Finanzamt bleibt KassenSichV-konform aggregiert.

Beim ersten Sync-Lauf legt JtlWawiSqlSyncService::ensureBisFunktionsattribute() die zwölf BISpicy-POS-Funktionsattribute idempotent in der JTL-DB an (Gruppe „BISpicy POS"). Neue Tenants müssen die FAs nicht mehr manuell unter Artikel → Funktionsattribute anlegen. Zusätzlich: pullGebindeViaSql skippt tGebinde-Einträge für Artikel, die bereits bis_gebinde_*-FAs haben — verhindert Duplikate in articlePackagingUnits. Die FAs sind ab sofort Single-Source-of-Truth für VPE-Preis + Pfand, tGebinde wirkt nur noch als Fallback (reine Stammdaten zum Scannen) für Artikel ohne FA-Pflege. tGebinde bleibt in JTL für die Lagerverwaltung unverändert relevant.

Kistenpfand wurde bisher über bis_gebinde_1_pfand_betrag gepflegt — semantisch verwirrend, weil es eigentlich nicht am Gebinde, sondern am Artikel hängt. Mit dieser Iteration zwei neue JTL-Funktionsattribute am Artikel: bis_kistenpfand_betrag (Pfand für die Kiste selbst) und bis_kiste_ab (Schwelle ab wieviel Flaschen automatisch eine Kistenpfand-Position kommt). Beide können alternativ direkt im BIS ERP unter Artikel-Detail → Pfand gepflegt werden. JTL-Sync arbeitet only-if-empty — manuelle Pflege im UI hat Vorrang. Bestandstenants müssen nichts ändern: die alten Gebinde-FAs werden als Fallback weiter unterstützt. An der POS-Kasse darf der Kassierer die automatisch hinzugefügte Kistenpfand-Position bei Bedarf aus dem Warenkorb entfernen — Flaschenpfand bleibt zwingend.

Die Tisch-Cloud-Sync aus 0.0.0.74 übertrug bisher nur Tisch-Stammdaten (Tischnummer, Anzeigename, Form, Kapazität). Status-Mutationen am POS-Tablet — also Tisch belegen, freigeben, reinigen, Gästezahl ändern, Mitarbeiter zuweisen, deaktivieren — blieben rein lokal. Mit dieser Iteration löst jede Status-Mutation am Tablet automatisch einen Push gegen POST /api/pos/sync/tables/upsert aus (fire-and-forget über einen privaten CoroutineScope im TableRepository, damit die UI nicht blockiert). Backend triggert daraufhin den FCM-Push settings/tables für alle Tenant-Geräte. Das Backend wurde zusätzlich um das Feld assigned_employee erweitert (im Upsert nur dann mit-updaten, wenn der Key im Body steht — verhindert Null-Überschreibungen bei Status-Pushes ohne Mitarbeiter-Info). Status-Pushes übertragen ausdrücklich keine Order/Sale-Daten — POS-Bestellungen und Verkäufe bleiben lokal und DSFinV-K-konform, Kundencenter zeigt nur die visuelle Tisch-Statusansicht.

Bisher pflegte die Android-POS-App Tische nur lokal auf dem Tablet — das Kundencenter und der Browser-POS arbeiten dagegen mit der webpos_tables-Tabelle in der Cloud-DB. Beide Welten kannten einander nicht: Tisch im Kundencenter angelegt → POS sah ihn nicht. Tisch am Tablet angelegt → Kundencenter sah ihn nicht. Mit dieser Version stellt das Backend zwei neue Endpoints bereit (GET /api/pos/sync/tables und POST /api/pos/sync/tables/upsert), die POS-App lädt Tische beim Öffnen des Tischplans aus der Cloud, reagiert auf den FCM-Push category=tables mit einem sofortigen Pull und schickt jede neue oder geänderte lokale Tisch-Anlage automatisch ans Backend. Match-Strategie: tableNumber als Natural Key (UNIQUE auf beiden Seiten) plus eine cloudId-Spalte in der lokalen Room-DB für stabile Identitäts-Bindung. Kundencenter bleibt bewusst manuell (Refresh-Button), wie in 0.0.0.72 festgelegt.

Neue Sektion „POS-Zahlungsarten konfigurieren" im Kundencenter unter /my/jtl-integration. Pro Zahlungsart steuerbar: Sichtbarkeit in der POS-Kundenanlage, DATEV-Konto SKR03 + SKR04 sowie das Rechnungskauf-Flag. Eine neue Master-DB-Tabelle posPaymentMethodConfig wird beim ersten Aufruf automatisch mit sinnvollen Defaults geseedet. Der DATEV-Export im POS-Reporting löst pro Transaktion das Konto über die Konfiguration auf und überspringt Rechnungskauf-Verkäufe korrekt — die Erlösbuchung erfolgt beim Rechnungslauf in JTL/BIS ERP (Ansatz B, verhindert Doppelbuchung). Die POS-App filtert die Kunden-Zahlart-Dropdown anhand der availableInCustomerCreation-Liste aus dem BISRemote-Sync. Z-Bon und Kassenjournal nutzen jetzt einen einheitlichen PaymentMethodNormalizer als Single Source of Truth für die kanonischen Zahlungsart-Schlüssel (bar, card, ec, girocard, sumup, zettle, rechnung, vorkasse, paypal, gutschein, lastschrift, ueberweisung).

Im Kundencenter unter Kassenverwaltung → Tischverwaltung warfen Aktualisieren und Neuen Tisch anlegen bislang 500-Fehler, weil das Tabellen-Schema (webpos_tables, webpos_table_orders) nur im POS-Backend angelegt wurde und der Kundencenter-Endpoint es nicht kannte. Schema-Definitionen in DatabaseSchemaService nachgezogen — beide Buttons funktionieren. Zusätzlich: bei mehreren POS-Tablets im Restaurantbetrieb bekommt jetzt jedes Tablet via FCM-Push eine Echtzeit-Benachrichtigung, wenn an einem anderen Tablet ein Tisch belegt, gezahlt, freigegeben, umgezogen, gesplittet, einem Mitarbeiter zugewiesen, reserviert oder neu angelegt wird. Das Kundencenter bleibt bewusst manuell (Steuerung/Kontrolle/Auswertung, keine Echtzeitnutzung).

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/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.

Bisher wirkte der JTL-Verkaufskanal-Haken am Artikel (Reiter „Verkaufskanäle") nur als globaler An/Aus-Schalter: sobald mindestens eine POS-Kasse gehakt war, sah jede Kasse den Artikel. Jetzt wertet der Sync pro Kasse aus und schreibt die Zuordnung als targetType=device in posArticleAssignments — passend zum bestehenden Pro-Gerät-Lookup. Mapping erfolgt über das vorhandene posDeviceShops-Mapping (Match-Reihenfolge id_hex → androidId → legacyFingerprint → deviceName). Setups ohne Mapping bleiben unverändert (globaler Modus als Backward-Compat-Pfad). Manuell gepflegte Channel-Preise (fixedPrice / channelSpecialPrice) bleiben durch Filter beim Cleanup unberührt.

Aus den bis_gebinde_*-Funktionsattributen schreibt der Sync jetzt automatisch die Kistenpfand-Konfig auf den Artikel (crateDepositThreshold/Amount/Sku). Bestehende Werte werden nicht überschrieben (manuelle Konfig hat Vorrang). POS-App-Logik wertet diese Felder aus und fügt bei sortenreinen 12er/24er-Vielfachen automatisch eine Kasten-Pfand-Position dazu — beim VPE-Scan (1 Kiste = 12 Flaschen-Äquivalent) korrekt umgerechnet. Override Ohne Kiste durch manuelles Entfernen des Kasten-Items im Cart.

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: Pfand-Nominalwert als Brutto verbucht (MwSt enthalten). B2B: Nominalwert als Netto (MwSt kommt drauf). Steuersatz 19% (in DE üblich). Pseudo-Artikelnummer PFAND-EINWEG-025 / PFAND-KISTE-150.

Pfand pro Artikel und pro Gebinde direkt in JTL als Funktionsattribut pflegen: bis_pfand_typ (EINWEG/MEHRWEG/KEIN), bis_pfand_betrag (Nominalwert — brutto bei B2C, netto bei B2B) und bis_gebinde_X_pfand_betrag für Kistenpfand. Kein eigener Pfand-Typ am Gebinde, da Kisten immer Mehrweg sind. BIS ERP synchronisiert die Werte automatisch in articles.depositType/depositAmount und articlePackagingUnits.depositAmount — POS-Kasse zieht beim Verkauf automatisch Pfand-Positionen auf den Bon, brutto oder netto je nach Kundengruppe. Plus: vollständiges Funktionsattribute-Kompendium auf beiden Marketing-Sites und als interner Guide.

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". Der Auftrag kam dank try/catch weiterhin durch, der Lieferschein fehlte aber. Fix: Die Trigger akzeptieren INSERTs wenn CONTEXT_INFO 0x5113 (tLieferschein) bzw. 0x5115 (tLieferscheinPos) gesetzt ist. BIS ERP setzt jetzt diese Bypass-Werte vor den INSERTs. tLieferscheinEckdaten wird durch den tLieferschein-Trigger automatisch angelegt und dann auf nVersandStatus=2 (komplett versendet) hochgeUPDATEt.

Der 0.0.0.64-Versuch packte den Lieferschein-INSERT in denselben Transaktionsbatch wie den Auftrag und nutzte spGetNextNummer @cName=Lieferschein. Bei Tenants ohne konfigurierten Lieferschein-Nummernkreis warf die SP einen Fehler — der gesamte Batch wurde zurückgerollt: kein Auftrag, kein Lieferschein, kein Workflow-Queue-Eintrag. POS-Verkäufe kamen gar nicht mehr in JTL an. Fix: Lieferschein-Insert ist jetzt separater Relay-Call in eigenem try/catch — wenn er scheitert, bleibt der Auftrag erhalten und nur eine Warnung geht ins Sync-Log. Lieferschein-Nummer wird selbst generiert (POS-<receiptNr>), spGetNextNummer entfällt.

JTL aggregiert fAnzahlGeliefert aus tLieferscheinPos und verknüpft Rechnungen über tRechnungLieferscheinPosition mit Lieferschein-Positionen — nicht direkt mit Auftragspositionen. Ohne Lieferschein-Verknüpfung setzte die JTL-Stored-Procedure spAuftragEckdatenBerechnen nach dem Rechnungs-Workflow den Lieferstatus zurück auf "ausstehend" (nKomplettAusgeliefert=0, nLieferstatus=1, dLetzterVersand=null). BIS ERP legt jetzt im selben Batch zusammen mit dem Auftrag einen Lieferschein an (tLieferschein + tLieferscheinPos + tLieferscheinEckdaten mit nVersandStatus=2). Damit erkennt JTL den Auftrag als sauber ausgeliefert, der Rechnungs-Workflow läuft durch und der Lieferstatus bleibt nach Workflow-Run stabil.

Der 0.0.0.62-Versuch (UPDATE setzt fAnzahlGeliefert = p.fAnzahl) kollidierte mit dem nachfolgenden Stock-Booking, das fAnzahlGeliefert = fAnzahlGeliefert + qty rechnet — Resultat war 2*qty. Sobald der JTL-Workflow Rechnung erstellen lief, erkannte JTL die Inkonsistenz und setzte beim Auftragsabgleich alles zurück auf 0. Fix: INSERT in tAuftragPositionEckdaten startet jetzt mit fAnzahlOffen=qty, fAnzahlGeliefert=0; Stock-Booking baut das danach korrekt auf geliefert=qty, offen=0 auf. Das nachträgliche UPDATE auf Position-Eckdaten wurde komplett entfernt.

Nach dem 0.0.0.61-Fix blieben POS-Aufträge in JTL fälschlich auf Lieferstatus "ausstehend". Das nachträgliche UPDATE auf tAuftragPositionEckdaten setzte fAnzahlGeliefert=0, woraufhin die JTL-Stored-Procedure Verkauf.spAuftragEckdatenBerechnen den Auftrag auf nLieferstatus=1, nKomplettAusgeliefert=0 zurückrechnete und den vorher gesetzten Lieferstatus-5-Update überschrieb. Fix: UPDATE setzt jetzt fAnzahlGeliefert=qty, fAnzahlOffen=0 — die JTL-SP berechnet Lieferstatus=5 und nKomplettAusgeliefert=1 korrekt.

Zwei Bugs nach dem 0.0.0.60-Release: (1) Der neue Workflow-Trigger feuerte beim regulären POS-Sync nicht, weil vier buildConfig()-Stellen die drei neuen jtlConnections-Felder nicht ins Config-Array übernommen haben — pushPosOrdersToJtl() sah invoiceWorkflowId nicht und übersprang den Code-Pfad. (2) Ein nachträgliches UPDATE auf tAuftragPositionEckdaten überschrieb fAnzahlAufRechnung mit qty auch bei Rechnungskauf — der korrekte INSERT-Wert 0 ging verloren, und JTL meldete beim "Rechnung Drucken"-Workflow keine offenen Positionen.

Im Kundencenter unter /my/jtl-integration kann pro Tenant ein JTL-Workflow ausgewählt werden, der nach jedem POS-Verkauf mit Zahlart "Rechnung" automatisch in der JTL ausgelöst wird (z.B. "Rechnung Drucken"). Die Workflow-Liste wird live aus der eigenen JTL geladen — kein Tippen von IDs. Verzögerung wahlweise sofort oder 1 Minute nach Auftragsanlage. Technisch: BIS ERP legt nach erfolgreichem Verkauf.tAuftrag-INSERT einen Eintrag in dbo.tWorkflowQueue an (nEvent=1, kBenutzer=1) — der JTL-Worker arbeitet die Queue ab und führt den Workflow aus.

Reduktion der Long-Polling-Intervalle im BISConnect-Relay (Brücke zwischen ERP-Cloud und lokaler JTL-Datenbank) — gleiche bewährte Architektur wie BISPrint, aber engmaschigeres Polling. Backend-Wartezeit auf Job-Result: 250ms → 100ms. Cloud-Relay-Wartezeit auf neue Jobs für Client: 500ms → 200ms. Bei ~5 Relay-Calls pro POS-Verkauf spart das 2-3 Sekunden reiner Polling-Latenz. DB-Last hochskaliert auf 1000 Tenants vernachlässigbar (~30 Polls/sec mehr).

Zwei kleine Anpassungen am POS-Push-Pfad gegen Pickup-Latenz: (1) Der 5-Min-JTL-Scheduler prüft jetzt zuerst per einfachem COUNT(*), ob überhaupt unsynchronisierte POS-Verkäufe da sind, bevor er den teuren pushPosOrdersToJtl-Setup ausführt. Damit blockiert der scheduler-Worker den jtl_pos_push Transport nicht mehr 10-20s mit no-op-Setups. (2) Der Queue-Sweep läuft jetzt alle 15s statt 30s.

bookStockForPosOrder bündelt jetzt die bisher 3-5 separaten Relay-Lookups (SKU-Resolve, FEFO-Bestand, Retouren-Originaldaten, Fallback-Lagerplatz) in eine einzige Abfrage mit FOR JSON PATH. SQL Server liefert mehrere logische Ergebnis-Sets als JSON-Spalten zurück, PHP zerlegt sie lokal. Spart 2-3 Sekunden pro Verkauf, End-to-End-Latenz POS → JTL fällt auf ~10-12s.

Auftragsnummer-Holen (spGetNextNummer), Auftrag schreiben und Verifizieren laufen jetzt in einem einzigen T-SQL-Batch über die BISConnect-Verbindung. Vorher: drei separate Relay-Roundtrips pro Verkauf (~8-15s). Jetzt: ein Batch mit @cNeueNummer OUTPUT (~3-5s). Bei UNIQUE-KEY-Kollision retried der Code automatisch bis zu 3× — jedes Mal mit frischer Nummer aus dem selben Batch.

Eigene Express-Spur für POS → JTL Order Pushes mit Master-DB-Warteschlange (posJtlPushQueue), dediziertem Worker-Container und robuster Retry-Logik. Die Kasse erhält ihre Sync-Antwort in unter einer Sekunde, der Auftrag landet in wenigen Sekunden in JTL. Die Architektur skaliert horizontal: Worker können mit SELECT ... FOR UPDATE SKIP LOCKED parallel pullen, ohne sich gegenseitig zu blockieren.

Eine geänderte Sortierreihenfolge in der Bestellliste (Spalte + Richtung) wird jetzt im Browser gespeichert und überlebt einen Reload sowie den nächsten Besuch. Vorher wurde nach jedem Neuladen wieder die Standardsortierung (neueste oben) verwendet.

Die Bestellliste ist ab Werk so eingestellt, dass das Erstellungsdatum die erste Spalte ist und neue Bestellungen automatisch oben stehen. Bei POS-Verkäufen ohne ausgewählten Kunden steht jetzt „Laufkunde" in der Kunden-Spalte — analog zur JTL-Wawi-Konvention — statt einer leeren Zelle.

JTL-Trigger blockierten direkte UPDATE-Statements auf tKunde — Zahlungsart, Zahlungsziel und Rabatt wurden beim Update bestehender Kunden still verschluckt. Alle drei Update-Stellen nutzen jetzt den offiziellen Stored-Procedure-Weg über Kunde.spKundeUpdate.

An der Kasse angelegte Kunden werden jetzt mit ihrer Standard-Zahlungsart und ihrem Zahlungsziel vollständig in den JTL-Kundenstamm (tKunde) übertragen. Die Zuordnung erfolgt über den Original-Zahlungsart-Namen aus JTL — wählt der Kassierer „Rechnung Kasse" als Standard-Zahlart, landet das in JTL als kZahlungsart-ID der gleichen Zahlart.

JTL-Zahlungsarten erscheinen jetzt als eigenständige Zahlarten in der Kassen-App — mit ihrem Original-JTL-Namen, nicht auf eine Standard-Zahlart gemappt. Per Checkbox „An Kasse" pro JTL-Zahlungsart aktivierbar. Bestehende Kassen-Zahlarten (Bargeld, EC, SumUp, etc.) bleiben wie gewohnt erhalten.

Die KI erfindet keine Maße, Gewichte oder Materialien mehr, die nicht aus den Produktbildern erkennbar sind. Neuer optionaler Wizard-Schritt: Material, Maße und weitere Eigenschaften vor der Analyse angeben. Plattform-Optimierung für OTTO (Keywords fett, Stichpunkte), eBay, Amazon und eigenen Shop. Individuelle KI-Anweisungen per Freitext.

Wenn der Kunde an der Kasse auf Rechnung kauft und die Rechnung später in der Warenwirtschaft (BIS ERP / JTL) erstellt wird, entstand bisher ein doppelter Erlös in DATEV. Ab sofort bucht die Kasse für Rechnungskauf-Zahlarten keinen Erlös mehr — der Umsatz wird ausschließlich beim Rechnungslauf gebucht. GoBD-, KassenSichV- und DSFinV-K-konform, analog zu JTL-POS, ready2order und protel.

Pro Zahlungsart (Bar, Karte, Rechnung, SumUp, Zettle, Vorkasse …) lassen sich jetzt DATEV-Konten SKR03/04 hinterlegen und gezielt steuern, welche Zahlungsarten POS-Mitarbeiter bei der Kundenanlage anbieten. DATEV-Export, Z-Bon, X-Bon und Kassenjournal nutzen die Konfiguration konsistent.

Tenants mit mehreren Kassen können jetzt direkt im Kundencenter mehrere TSE-Lizenzen auf einmal bestellen — für jede Einheit wird automatisch ein eigener Fiskaly-TSE-Client erstellt.

Die KI-Artikelanlage nutzt jetzt das globale Credit-System. Pro Analyse wird ein konfigierbarer Betrag vom Guthaben abgezogen — transparente Kosten vor und nach jeder Analyse.

Dashboard-Widgets laden jetzt über einen einzigen API-Call statt 15 separater Anfragen. Polling-Intervalle wurden überall optimiert — ~90% weniger wiederkehrende API-Aufrufe.

Artikel per KI anlegen: Produktbilder hochladen, die KI erkennt automatisch Name, Beschreibung, Zutaten, Nährwerte, Allergene, EAN, Herkunftsland und mehr. 3-Schritte-Wizard mit Confidence-Scores für volle Kontrolle.

Alle Kundenfelder aus der POS-App werden jetzt vollständig an BIS ERP und JTL übertragen. Bisher fehlten u.a. Firmenname, Rabatt, USt-IdNr und Bankdaten beim Sync.

Kunden-Zahlungsart wird im POS-Payment-Dialog automatisch vorausgewählt und hervorgehoben. Individuelle Zahlungsziele für B2B-Kunden werden durchgängig berücksichtigt — von POS über BIS ERP Rechnungen bis JTL-Sync.

Versanddaten werden automatisch an JTL synchronisiert. Wareneingang mit vollständigem Workflow (Entwurf → Bearbeiten → Abschließen) und lückenloser Bestandsbuchung auf allen Ebenen.

Pfandrückgabe berücksichtigt jetzt den B2B-Status (25ct netto + MwSt). Pfandarten sind konfigurierbar im Kundencenter und per BISRemote fernverwaltbar.

JTL-Zahlungsarten direkt aus der JTL-Datenbank importieren und den POS-Zahlungsarten zuordnen. Individuelles Zahlungsziel und Skonto-Konditionen pro Zahlungsart konfigurierbar.

Jede Kundengruppe kann jetzt als B2B markiert werden mit eigener Netto-Preisanzeige. Kundengruppen-Einstellungen direkt im Kundencenter konfigurierbar. JTL-Sync liest die Nettopreise-Einstellung automatisch.

Kundengruppen zentral unter Einstellungen → Order Desk verwalten. JTL-Gruppen werden automatisch synchronisiert. Staffelpreise und Kundengruppenpreise nutzen jetzt Dropdown-Auswahl statt Freitext.

Kategorien unterstützen jetzt beliebig viele Verschachtelungsebenen. JTL-Kategoriebäume werden 1:1 übernommen, WebPOS und POS-App navigieren hierarchisch.

Verpackungseinheiten (Kiste, Träger, Palette) werden direkt als Staffelpreise verwaltet — mit Sonderpreisen und Kundengruppenpreisen pro Gebinde.

Pfand wird bei B2B-Kunden als Nettobetrag behandelt (25ct + MwSt = 29,75ct). Standard-Kundengruppe als B2B markierbar mit automatischer Pfand-Neuberechnung beim Kundenwechsel.

Alle JTL-Kundengruppen-Preise und Staffelpreise werden synchronisiert — mit konfigurierbarer Standard-Kundengruppe für B2B-Betriebe auf POS und WebPOS.

POS-Stornos buchen den Lagerbestand in JTL automatisch zurück — mit optionalem WMS-Rücklagerplatz und lückenloser Storno-Verknüpfung.

Automatische Log-Bereinigung mit OPTIMIZE TABLE, effizienteres POS-Sync- und Regel-Logging.

Tische direkt im Kundencenter verwalten — mit Live-Status, Gästeanzahl und offenem Bestellwert. Sofortige Synchronisation per Push an alle POS-Geräte.

Alle Pfandfelder (Einweg, Mehrweg, Kasten) per JTL-Funktionsattribute steuerbar. Kistenpfand jetzt auch auf POS-Geräten verfügbar.

Alle POS-Berichte (Kassenbuch, UStVA, EÜR, DATEV) lassen sich nach B2B- und B2C-Kunden filtern. Dashboard und WebPOS inklusive.

Robusterer Auftrags-Sync mit Fallback-Werten für Zahlungs- und Versandarten. Automatische JTL-Spaltenerkennung mit sicheren Defaults.

Jeder E-Mail-Typ individuell auf Gmail/SMTP konfigurierbar. Gmail-Account als Support-Posteingang mit automatischem Ticket-Import.

E-Mail-Versand pro Kategorie konfigurierbar: System-Mails, Kunden-Mails und Support-Antworten jeweils über Gmail oder SMTP.

Gewinn und Marge werden jetzt korrekt auf Netto-Basis berechnet. Rechnungen speichern den Einkaufspreis als Stichtag-Snapshot.

E-Mails (Rechnungen, Benachrichtigungen) über die Gmail API mit OAuth2 versenden — sicher und ohne App-Passwort.

Stripe-Produkte direkt aus den Einstellungen als WaWi-Artikel importieren, Rechnungs- und Auftragspositionen mit Artikeln verknüpfen.

Alle DATEV-Konten für 26 Kanäle (Zahlungsanbieter, Marktplätze, Shop-Systeme, Zahlungsarten) zentral konfigurierbar — Erlöskonten nach Steuersatz jetzt editierbar.

Gewinnkalkulation immer sichtbar, Stripe-Auszahlungsbetrag, E-Mail-Versand an Kunden, fehlende Absender nachgetragen und Filter sessionübergreifend gespeichert.

Vier separate Designer in einem einzigen Design Studio konsolidiert — Dokumente und Etiketten im einheitlichen WYSIWYG Drag & Drop Editor.

Neue Berichtsseite für Transaktionsgebühren mit aufklappbaren Gebührendetails pro Zahlung — aufgeschlüsselt nach Anbieter und Gebührenart.

Rechtsklick-Kontextmenüs für Zahlungen, Aufträge, Rechnungen und Lieferscheine mit direkter Navigation zur 360°-Kundenansicht.

Stripe-Gebühren als KPI im Dashboard, Gewinnkalkulation pro Rechnung und DATEV-Export direkt in der Buchhaltung erreichbar.

Über 130 Tabellen jetzt per Klick auf die Spaltenüberschrift sortierbar — mit intelligenter Erkennung von Zahlen, Datum und Text sowie korrekter deutscher Umlaut-Sortierung.

Stripe-Rechnungen per Sync importieren, Transaktionsgebühren für DATEV erfassen, und physische Waren-Abos mit Auftragserstellung verwalten.

Neuer Protokoll-Tab in der Stripe-Integration: Webhook-Events mit Status und Fehler-Details, Sync-Protokoll für alle Stripe-Operationen.

Finanzberichte passen sich jetzt automatisch an den Firmensitz an — EÜR/UStVA/BWA für Deutschland, PP.30/WHT/Einkommensteuer für Thailand.

Jeder Tenant kann seinen eigenen Stripe-Account anbinden — mit Kunden-Sync, Abo-Übersicht, Zahlungsimport, zwei Rechnungsmodi und DATEV-Export für Zahlungseingänge.

Eingangsrechnungs-PDFs werden jetzt sicher in der Cloud gespeichert (DigitalOcean Spaces) — sie gehen bei Server-Updates nicht mehr verloren.

Fremdwährungs-Rechnungen (USD, GBP, CHF, …) mit automatischer EUR-Umrechnung via ECB-Tageskurse. PDF-Vorschau und DATEV-Workflow für Eingangsrechnungen.

Eingangsrechnungen erhalten automatisch eine interne Belegnummer. Lieferanten können direkt im Dropdown erstellt werden. Mehrere PDFs gleichzeitig hochladen funktioniert jetzt korrekt.

Buchungskonten und Kostenstellen sind jetzt sofort verfügbar. Lieferanten aus Eingangsrechnungen werden automatisch mit dem zentralen Lieferantenstamm verknüpft.

Eingangsrechnungen werden jetzt wie bei lexoffice oder sevDesk bearbeitet — Bruttobetrag eingeben, MwSt-Satz wählen, Buchungskonto auswählen, fertig. Die umständliche Positions-Tabelle erscheint nur noch bei ZUGFeRD-Rechnungen mit mehreren Positionen.

Datenschutz, AGB und Impressum auf den aktuellen Stand gebracht. Neu: eigene Auftragsverarbeitungsvertrags-Seite (AVV) gemäß Art. 28 DSGVO mit vollständiger Subprozessoren-Liste und konkreten technischen Maßnahmen.

BIS ERP zeigt seine Entwicklung jetzt nach außen. Auf der Startseite gibt es einen "Was ist neu"-Block, dazu diese komplette Verlauf-Seite — analog zur BISpicy Kasse.