Versionsverlauf von BISpicy ERP

BISpicy (bisher BIS ERP) zeigt auf einem Preisschild einen durchgestrichenen Vergleichspreis nur, wenn der niedrigste Preis der 30 Tage vor Beginn des Sonderpreises lückenlos belegt ist. Dafür hält BISpicy jetzt zusätzlich fest, wann die Preise erfasst wurden.

Das Versandprotokoll unter CRM → Marketing → System-Kampagnen bewahrt Ihre Kundendaten jetzt nur noch so lange auf, wie es nötig ist. Das E-Mail-Versandprotokoll mit seinen eigenen Fristen bleibt davon unberührt.

Haben Sie eine Kasse auf ein neues Gerät übertragen („Dieses Gerät ersetzt die Kasse …“), ordnet BISpicy (bisher BIS ERP) die Tagesabschlüsse, Bargeldbewegungen und Bons des alten Geräts jetzt überall derselben Kasse zu.

Auf der Artikelseite im BISpicy Shop folgt am Handy jetzt auf das Bild sofort der Kaufbereich mit Artikelname, Preis, Pfand und „In den Warenkorb“. Beschreibung und Artikeldaten stehen darunter. Bisher kamen sie vor dem Kaufbereich, und man musste erst an ihnen vorbei scrollen. Am Rechner ändert sich nichts.

Hat ein JTL-Kunde neben seiner Rechnungsanschrift eine eigene Lieferanschrift, erschien er in der Kundensuche der Kasse bisher zweimal. Wählte man den zweiten Treffer, wurde der Kunde in BISpicy (bisher BIS ERP) mit der Lieferanschrift als Rechnungsanschrift angelegt. Die Suche zeigt jetzt jeden Kunden genau einmal, mit seiner Rechnungsanschrift – dieselbe Anschrift, die auch der Kundenabgleich aus JTL übernimmt.

Mehrere vorgegebene Buchungskonten trugen bisher Bezeichnungen, die nicht zu ihrer Bedeutung im DATEV-Kontenrahmen SKR03 passten. Zum Beispiel stand 4960 als „Software und IT“ in der Liste, obwohl DATEV darunter Mieten für Einrichtungen führt. 4800 hieß „Porto und Versandkosten“, ist bei DATEV aber das Konto für Reparaturen und Instandhaltung. Die automatische Kontierung von Eingangsrechnungen hat sich an diesen Namen orientiert.

Seit dem 13.11.2026 tragen die vorgegebenen Buchungskonten der Eingangsrechnungen ihre DATEV-Bedeutung. Wählen Sie in EÜR, BWA oder Anlage EKS einen Zeitraum davor, zeigt der Bericht einen Hinweis, wenn Positionen auf einem dieser Konten liegen. Die Aufteilung auf die Kostenblöcke kann dann von einem früher heruntergeladenen Bericht abweichen, die Summe bleibt gleich.

Pflegen Sie Kunden in BISpicy (bisher BIS ERP) und steht die Kunden-Richtung Ihrer JTL-Anbindung auf „zu JTL“ oder „in beide Richtungen“, können Änderungen an mit JTL verknüpften Kunden jetzt nach JTL übertragen werden – und zwar nur die Felder, die Sie tatsächlich geändert haben.

Die Aufstellung zur Umsatzsteuer-Voranmeldung unter Berichte → Finanzen → UStVA enthält jetzt neben den Rechnungen auch den Umsatz der Kasse, und jeder Umsatz zählt nur einmal:

Die Sicherheitsrückfrage vor **Einstellungen → System → Gefahrenzone → Alle Artikel löschen** meldete bisher „Falsches Passwort“, auch wenn Sie Ihr richtiges Passwort eingegeben hatten. Sie prüft jetzt gegen dasselbe Passwort, mit dem Sie sich anmelden.

In Ihrem BISpicy Shop sehen Artikelbilder und mehrere Seiten jetzt ruhiger und professioneller aus. Hinweis: Im Layout „OEZ B2C“ erscheinen die weiße Kachelfläche und die „Sie“-Anrede im leeren Warenkorb erst, nachdem das Layout erneut hochgeladen wurde.

Verkaufen Sie an der Kasse steuerfrei an ein Unternehmen in einem anderen EU-Land (innergemeinschaftliche Lieferung) und erstellen dazu keine Rechnung, steht der Bon jetzt in der Zusammenfassenden Meldung.

Manche Wareneingangskonten rechnen in DATEV die Steuer selbst: SKR03 3300–3309, 3347, 3400–3409 und 3418 (SKR04 5300–5309, 5347, 5400–5409, 5418) für die Vorsteuer, 3420–3429 (SKR04 5420–5429) für den innergemeinschaftlichen Erwerb und 3120 für die Steuerschuld des Leistungsempfängers. BISpicy (bisher BIS ERP) setzt auf diesen Konten keinen Steuerschlüssel mehr, wenn Konto und Buchung zusammenpassen. Beim Import in DATEV entfällt damit der Hinweis je Buchung. Passt eine Position nicht zum Konto, zum Beispiel 7 % auf einem 19-%-Konto, eine Rechnung ohne Steuer oder ein innergemeinschaftlicher Erwerb auf einem Vorsteuerkonto, bucht der Export auf das Wareneingangskonto ohne Automatik (3200 bzw. 5200): mit dem passenden Steuerschlüssel, bei 0 % ohne. Ein Hinweis zum Export nennt jede solche Umbuchung. Gespeicherte Exporte bleiben unverändert. Ältere Exporte ohne gespeicherte Datei werden beim Herunterladen neu berechnet und sind dann als Neuberechnung gekennzeichnet.

Artikel, für die kein Verkaufspreis über 0 € hinterlegt ist, erscheinen im BIS Shop nicht mehr und lassen sich nicht in den Warenkorb legen oder bestellen. Das gilt auch dann, wenn Sie die Pflichtdaten-Sperre ausgeschaltet haben. Sobald der Artikel einen Preis hat, erscheint er automatisch wieder im Shop. In der Liste „Pflichtangaben für den Webshop“ sehen Sie solche Artikel weiterhin mit dem Hinweis „Preis fehlt oder ist 0 €“. Die Zahlen bei ausgeschalteter Sperre nennen jetzt getrennt, wie viele Artikel sichtbar sind und wie viele abgeschaltet bleiben.

„Bestand neu berechnen“ ist jetzt bei jedem weiteren Klick ohne Wirkung, wenn sich nichts geändert hat. Stücklisten (Sets) ohne Bestandsführung bekommen keinen aus den Bestandteilen errechneten Bestand mehr. Bisher stand bei ihnen nach jedem Klick und nach jeder Bewegung eines Bestandteils abwechselnd ein Abgang und ein Zugang im Bestandsjournal, und der Bestand des Sets sprang zwischen 0 und dem errechneten Wert. Die Zahl „In Aufträgen“ bleibt bei Artikeln ohne Bestandsführung stehen, statt bei jedem Klick genullt und kurz darauf wieder gesetzt zu werden. Die Meldung nach dem Klick nennt deshalb nur noch echte Korrekturen.

Geht eine Lieferantenbestellung an ein Lager, das Ihr Fulfillment-Dienstleister führt, zeigt die Lager-App beim Wareneingang gleich den Hinweis „Dieses Lager führt der Fulfillment-Dienstleister – hier kann kein Wareneingang gebucht werden.“ Der Knopf „Wareneingang buchen“ ist für diese Bestellung gesperrt, und die App schlägt kein Umstellen des Geräts auf dieses Lager vor. Für alle anderen Bestellungen bleibt der Lagerabgleich wie beschrieben. Die Anzeige kommt mit der nächsten Version der Lager-App.

Die Zusammenfassende Meldung enthält jetzt auch innergemeinschaftliche Lieferungen aus JTL-Wawi, bei denen die USt-IdNr. des Kunden nur in JTL gepflegt ist.

In der Umsatzsteuer-Voranmeldung der Kasse (Kundencenter › Berichte › Umsatzsteuer und BISpicy › Kassenberichte) stehen 0-%-Umsätze ohne erkennbaren Befreiungsgrund jetzt in einer eigenen Zeile „0 % ohne Kennzahl – bitte prüfen“. Bisher standen sie unter Kennzahl 48 (steuerfreie Umsätze), was eine falsche Angabe sein kann.

Datenschutz: IP-Adressen von Online-Buchungen werden nach spätestens 7 Tagen gelöscht

Wenn Sie in JTL-Wawi einen Sonderpreis anlegen oder ändern, erscheint er jetzt binnen weniger Minuten an der Kasse. Dasselbe gilt für geänderte Staffelpreise und Kundenpreise. Auch sonstige Preis- und Artikeländerungen aus JTL-Wawi erreichen die Kasse jetzt deutlich schneller, statt erst beim nächsten regelmäßigen Abgleich der Kasse. In JTL-Wawi deaktivierte oder gelöschte Sonderpreise verschwinden jetzt auch in BISpicy und an der Kasse. Die Kassen werden dafür automatisch zum Abgleich aufgefordert, Sie müssen nichts tun.

Löschantrag: Kundencenter und Bestätigungsseite nennen den richtigen Löschtermin

Wer BISpicy (bisher BIS ERP) mit JTL-Wawi und einem JTL-Shop nutzt und Sendungen an der BISpicy Parcel Station (bisher Packtisch) oder in der Lager-App abschließt, sieht den Lieferschein jetzt auch im Shop, nicht nur den Status „Versandt“. BISpicy meldet ihn dafür über den normalen Shop-Abgleich der Wawi, und zwar vor dem Status – genau wie bei einem Versand aus der Wawi selbst. Zahlungsanbieter im Shop, die erst mit dem Lieferschein abbuchen (zum Beispiel Klarna über Mollie), finden ihn damit rechtzeitig vor. Es entsteht kein zweiter Lieferschein und kein zweites Paket.

Fehlbeträge und Überschüsse beim Kassenabschluss stehen jetzt in der EÜR und in der BWA. Es zählen nur gezählte Abschlüsse. Doppelte Buchungen und Ihre Umkontierungen im DATEV-Kassenexport werden genauso berücksichtigt wie dort.

Der Versandbereich ist aufgeräumt. Die ganze Seite scrollt jetzt normal, nur die Reiterleiste bleibt oben stehen. Die wartenden Bestellungen und die Picklisten beginnen gleich unter dem Kopf.

Auftragsdetail auf dem Tablet und freie Aktionsleiste am Handy

Registergericht und Registernummer aus den Firmendaten erscheinen jetzt auf neu erzeugten Rechnungen und Lieferscheinen. Bisher blieb diese Angabe leer, obwohl sie in den Firmendaten gepflegt war. Für GmbH, UG, AG und KG ist sie auf Geschäftsbriefen Pflicht.

Gutscheincodes aus dem Newsletter erkennen Kasse und BISpicy Shop noch nicht. Damit Ihre Kunden keinen Rabatt versprochen bekommen, der beim Einkauf nicht funktioniert, sind Newsletter-Gutscheine vorerst gesperrt.

Die Umstellung von BIS ERP auf BISpicy geht weiter: Der Packtisch heißt jetzt „Parcel Station“ (BISpicy Parcel Station), und auch die Meldungen, die BISpicy beim Speichern, Prüfen oder Versenden zeigt, nennen den neuen Namen. Funktionen, Daten und Zugänge bleiben unverändert.

Sind Sie Kleinunternehmer (§ 19 UStG), zeigen Auftrag, Angebot und der Dialog „Neuer Auftrag“ in BISpicy (bisher BIS ERP) die Preise jetzt als Endpreis, so wie an der Kasse und auf Rechnung, Auftragsbestätigung und Angebot. Jede Position hat ein Feld „Endpreis“, die Spalte und die Zeile für die Umsatzsteuer entfallen. Unter den Summen steht stattdessen der Hinweis auf die Kleinunternehmerregelung. Auch die Versandkosten geben Sie als Endpreis ein. Bisher zeigten diese Masken den Preis ohne Steueranteil und rechneten Umsatzsteuer dazu, die später auf keinem Beleg stand. Wählen Sie in einer neuen Rechnung einen Artikel aus, übernimmt die Rechnung jetzt seinen Endpreis statt des Preises ohne Steueranteil, und die Rechnungsmaske zeigt keine Umsatzsteuerzeile mehr. Aufträge aus dem Kundenportal und von Marktplätzen mit Endpreisen je Stück zeigen weiter die vereinbarten Preise.

„Bestand neu berechnen“ (Kommissionierung) gibt Ware, die für einen noch nicht versendeten Auftrag gegriffen ist und auf dem Kommissionierwagen oder am Packplatz liegt, nicht mehr frei. Vor dem Lauf fragt BISpicy jetzt nach.

Viele Getränke drucken statt einzelner Nährwerte den Satz „Enthält geringfügige Mengen von Fett, gesättigten Fettsäuren, Eiweiß und Salz“. Das ist eine vollständige Nährwertangabe. Die Bildanalyse in BISpicy (bisher BIS ERP) und in der Lager-App wertet sie jetzt auch so.

Unsere Warenwirtschaft heißt ab sofort BISpicy (bisher BIS ERP). In den Hinweisen, Einstellungen und Meldungen steht jetzt dieser Name, auf Deutsch, Englisch und Thai. Funktionen, Daten und Zugänge bleiben unverändert.

In Versand › Sendungen gibt es für versendete Sendungen den neuen Menüpunkt „Gewicht oder Versanddienst ändern“. Dort tragen Sie ein neues Gewicht für das Packstück ein und/oder wählen eine andere Versandart, zum Beispiel von DHL auf DPD. BISpicy (bisher BIS ERP) kauft dann zuerst das neue Etikett und druckt es. Erst danach wird das alte Etikett storniert. Scheitert der Kauf, bleibt alles beim Alten und das vorhandene Etikett gilt weiter. Lässt sich das alte Etikett nicht stornieren, zum Beispiel bei DHL nach dem Tagesabschluss, zeigt BISpicy die Nummer deutlich an, damit Sie es im Portal des Versanddienstes stornieren können. Bei einem Wechsel der Versandart werden alle versendeten Packstücke der Sendung umgestellt. In JTL entsteht kein neuer Lieferschein, keine zweite Rechnung und keine Bestandsbuchung: Sendungsnummer, Versanddienst und Gewicht des vorhandenen Versands werden beim nächsten Abgleich nachgezogen. Der Kunde bekommt die neue Sendungsnummer in der Versandmail. Hinweis: Das alte Etikett kann BISpicy derzeit nur bei DHL selbst stornieren. Bei anderen Versanddiensten, zum Beispiel DPD, ist ein Wechsel des Versanddienstes oder eine Gewichtsänderung deshalb nicht möglich: BISpicy zeigt das vorab an und kauft nichts. Brauchen Sie dort nur ein neues Etikett desselben Versanddienstes, stornieren Sie das alte im Portal des Versanddienstes und wählen danach in der Sendungsliste „Label neu erstellen“. Bei einer Änderung geht genau eine Versandmail mit der neuen Sendungsnummer an den Kunden, auch bei mehreren Packstücken.

Sind Sie Kleinunternehmer (§ 19 UStG), steht Ihre Steuernummer bzw. USt-IdNr. jetzt auch auf dem digitalen Bon – so wie auf dem gedruckten Bon. Bisher blendete der digitale Bon sie aus. Umsatzsteuer wird weiterhin nicht ausgewiesen. Auf dem gedruckten Bon der Web-Kasse ist die Kennung jetzt richtig beschriftet: Eine USt-IdNr. steht als „USt-IdNr.“, eine Steuernummer als „St.-Nr.“.

Nach einem Verkauf an der Web-Kasse führt der Link bzw. QR-Code zum digitalen Bon wieder auf den Beleg. Bisher endete er auf der Seite „Bon nicht gefunden“. Der digitale Bon der Web-Kasse entsteht jetzt auf demselben Weg wie an der Kassen-App, mit Positionen, Steueraufstellung, Zahlart und den Angaben der Sicherheitseinrichtung.

Sind Sie Kleinunternehmer (§ 19 UStG) und erstellen eine Rechnung aus einem Auftrag, übernimmt die Rechnung jetzt den Endpreis aus dem Auftrag – denselben Preis wie an der Kasse und, für Aufträge ab dem 8. November 2026, auf der Auftragsbestätigung. Umsatzsteuer wird weiterhin nicht ausgewiesen; der Hinweis auf die Steuerbefreiung für Kleinunternehmer steht wie bisher auf der Rechnung. Bisher übernahm die Rechnung den Preis ohne den Steueranteil aus dem Auftrag und lag damit unter dem Auftragsbetrag. Das gilt auch für Sammelrechnungen. Aufträge aus dem Kundenportal behalten den dort vereinbarten Preis. Bereits erstellte Rechnungen bleiben unverändert. Außerdem rechnet die Vorschau im Design Studio die Steueraufstellung jetzt wie die echte Rechnung, mit Beispielpositionen zu 19 % und 7 %. Rechnungen von Kleinunternehmern zeigen weiterhin keine Steueraufstellung.

Der Versandbereich beginnt jetzt mit einer Übersicht. Oben sehen Sie auf jedem Reiter des Versandablaufs die wichtigsten Zahlen. „Wartend“ und „In Kommissionierung“ gelten wie die Kommissionierung für das gewählte Lager, die übrigen wie Packtisch und Sendungen für alle Läger: Ein Klick auf eine Zahl führt in den Reiter, aus dem sie stammt. Der neue Reiter „Übersicht“ zeigt den Weg einer Bestellung in fünf Schritten, von „Wartend“ bis „Versendet“. Mit „Pickliste aus wartenden Bestellungen“ springen Sie direkt zur Auswahl in der Kommissionierung. Die Sendungsliste finden Sie wie bisher im Reiter „Sendungen“. Am Handy stehen vier Kennzahlen in zwei Spalten, die Reiter sind runde Knöpfe zum Wischen.

Lager: Reservierung auf einem leeren Kommissionierwagen wird angezeigt und lässt sich freigeben

Ändern Sie einen Auftrag, dessen Pickliste schon in Arbeit ist, und fällt dabei bereits gesammelte Ware weg oder wird weniger, müssen Sie die Pickliste nicht mehr zurückrufen.

Eigene Auslieferung: Fahreransicht im Browser für jedes Handy

CRM: Kundenakte mit Kopf, Kennzahlen und gruppierten Reitern

Packtisch: Vollständig kommissionierte Aufträge lassen sich auch bei leerem Regal öffnen

Packtisch: Gewichtsprüfung beim Scannen – zu schwere Packstücke werden sofort erkannt

Kasse: Bargeld verschwindet nicht mehr an allen Kassen, wenn es an einer Kasse entfernt wird

CRM: Neue Übersicht mit Bereich, Kennzahlen und Arbeitslisten

Lager: Kommissionierwagen und Packplatz werden nach Storno, Rückgabe und Versand außerhalb von BIS richtig geleert

Wird in BIS ERP die Menge einer Position gesenkt, während die Pickliste an einem Lagergerät offen ist, kann dort nicht mehr versehentlich zu viel gesammelt werden. Greift jemand noch die alte, höhere Menge, bucht BIS ERP nichts und das Gerät meldet „Die Menge dieser Position wurde im Büro geändert (jetzt …). Bitte die Pickliste neu öffnen“. Schon gesammelte Ware bleibt auf dem Wagen; nach dem Neuöffnen zeigt die Liste die neue Menge.

Ein Artikel, den Sie an der Kasse angelegt und vor der ersten Übertragung deaktiviert haben (zum Beispiel ein gebrauchtes Gerät, das schon verkauft ist), wird nicht mehr als aktiver Artikel in BIS ERP angelegt und erscheint damit auch nicht mehr an Ihren anderen Kassen.

Rechnen Sie Scan-to-Order nach Nutzung ab, zählt eine Gästebestellung erst einen Tag nach dem Absenden und nur, wenn Sie sie nicht storniert haben. Bestellungen, deren Online-Zahlung abgebrochen wurde, zählen nie. So kostet Sie eine untergeschobene Bestellung nichts, wenn Sie sie bis zum nächsten Tag an der Kasse stornieren. Außerdem bremst die Bestellseite ungewöhnlich viele Bestellungen in kurzer Zeit.

Auftrag auf Handy und Tablet

Versand: Packstück hinzufügen an eine schon versendete Sendung

Einkaufsportal: Anmeldung mit eigenem Passwort und Zwei-Faktor

Ändern Sie in BIS ERP die Positionen eines Auftrags, dessen Pickliste schon in Arbeit ist, passt sich die Pickliste jetzt direkt an. Sie müssen sie dafür nicht mehr zurückrufen.

Eigene Auslieferung: Touren planen

Kommissionierung: Picklisten bis zu den Positionen aufklappen

Lager: Storno und Rückgabe leeren Kommissionierwagen und Packplatz auch bei mehreren Lagern

Packtisch: Ein Auftrag wird nur noch in einem Fenster gepackt

CRM: Anruflisten und Kennzahlen zeigen nur Geschäftskunden

Auftrag: Verlauf zeigt die Person und verständliche Angaben

Einlagen, Entnahmen und Geräte-Ankäufe, die Sie an der Browser-Kasse von BIS ERP erfassen, stehen jetzt im DATEV-Export der Kassenbewegungen, genauso wie die der Kassen-App, und lassen sich dort auch umkontieren. Geräte-Ankäufe der Browser-Kasse zählen außerdem im Wareneinsatz von EÜR, BWA und Anlage EKS.

Auftragsverarbeitungsvertrag: Aufbewahrungsfristen und Sicherung nach Vertragsende klar beschrieben

Offene Erstattungen: Kassen-Stornos zu einem Kauf auf Rechnung, die von Hand zu prüfen sind

CRM: Der Menüpunkt öffnet die Übersicht

Ausgangsrechnungen: Liste lädt wieder, auch ohne eingerichteten Zahlungsabgleich

Buchungsexport: im hellen Modus gut lesbar

Eigene Auslieferung: Versandlabel je Packstück am Packtisch

Versand: Kein doppeltes DHL-Label mehr, wenn DHL nicht rechtzeitig antwortet

OSS: Lieferschwelle, Registrierung und Quartalsmeldung aus Ihren Rechnungen

Verfahrensdokumentation der Kasse beschreibt den Zwischenbon für Gäste

„Als bezahlt markieren“ fragt jetzt, wann und wie viel bezahlt wurde. So steht eine Überweisung vom August auch in EÜR, BWA und DATEV im August, und Teilzahlungen lassen sich festhalten.

Löschantrag: gleich nach der Einrichtung selbst stellen, Abbruch-Link in der Bestätigung

Aktion MASSAGEBRIEF27: Terminplaner Online 3 Monate kostenlos

Lager-App „Fotos offen“: Artikel auch über die Karton- oder Gebinde-EAN finden

Versand: Nach „Label neu erstellen“ steht die neue Trackingnummer auch in JTL

Kasse: Eigene Sicherung auf demselben Gerät einspielen setzt die Kasse fort

DATEV-Kassenexport: Tagessumme je Steuersatz und klare Meldung ohne Berater- und Mandantennummer

Packtisch: Packen nach Pickliste, Packstück wählen, Knopfseite und Vollbild

Aufträge: Kopie mit vollständiger Anschrift, Status „Entwurf“ lesbar

Preisschilder: Streichpreis nur mit belegtem niedrigsten Preis der letzten 30 Tage

Auftrag: Änderungen speichern sofort, ohne Speichern-Knopf

Anlage EKS: Abo-Prüfung gegen die letzte Rechnung und offene Rechnungen ohne Kasse

„DHL Paket International“ bei einem Versand im Inland. Speditionssendungen stehen auf „Spedition“ statt auf einer DHL-Versandart, und eine Sendung ohne Versanddienst übernimmt die Versandart des Auftrags. Wird ein Etikett neu erstellt, zieht die Versandart mit.

Ankaufsbuch: Korrekturen bleiben nachvollziehbar

DHL-Versand mit mehreren Paketen), blieben die Pfandpositionen offen, und der Auftrag stand in JTL auf „teilversendet“. Jetzt geht das Pfand immer mit der gelieferten Ware mit, bei einer Teillieferung anteilig.

Auftrag: Reiter statt einer langen Seite, Verlauf und Belege auf einen Blick

Packtisch: Aufträge mit mehreren Versandarten

Preisschilder: neue Liste „Preise und Schilder“ zeigt, welche Schilder zu tauschen sind

Auftrag: neuer Kopf mit Übersicht, E-Mail und Telefon und einer Hauptaktion

Packtisch: Verpackung abschaltbar

Packtisch am Handy: nichts mehr abgeschnitten

Packtisch: Versandetiketten mehrerer Pakete kommen ohne halbe Minute Pause aus dem Drucker

Kasse: Artikeländerungen kommen bei großen Sortimenten wieder an

Aufträge: jeder Auftrag steht nur noch einmal in der Liste

Versand: fertig gepickte Listen direkt versenden, ohne Packtisch

Preisschilder: Streichpreis nur noch mit dem niedrigsten Preis der letzten 30 Tage, UVP nie durchgestrichen

Kasse mit JTL-Wawi: Kanal- und Sonderpreise kommen nach der Kanal-Zuordnung zuverlässig an der Kasse an

Versand: Zahlen an den Reitern, Weg einer Bestellung und klarere Sendungsliste

Packtisch: verpackte Liste mit fehlendem Etikett steht unter „Wird verpackt“

Kommissionierwagen: Listen, Gewicht und „Sperre lösen“ am Wagen

Ankaufsbuch: Korrekturen alter Ankäufe nach einem Kassentausch kommen an

Packtisch: Teillieferung mit „Rest entfällt“

Packtisch und Kommissionierung: klarere Arbeitsansicht und Gewicht je Bestellung

Kasse: neu angelegte Artikel und angekaufte Geräte zeigen ihren Bestand

JTL: Wareneingänge und Ankauf-Stornos der Kasse erreichen JTL

Kommissionierung: Warengewicht je Liste und je wartender Bestellung

Webshop: Datenexport und Annahme von AGB und AVV

Bank-Import: große Revolut-Dateien schneller, Hinweise zur Zuordnung sichtbar

Artikelliste: Hinweise per Klick und auf dem Tablet lesbar

Packtisch: Kommissionierlisten zeigen ihren Stand, Packstand und Gewicht

Web-Kasse für Kleinunternehmer: Bons ohne Umsatzsteuer mit Pflichthinweis, Nachdruck als Kopie

Kassen: Belege bleiben nach einem Gerätetausch sicher bei ihrer Kasse

Kasse mit JTL-Wawi: Sonder- und Kanalpreise kommen auch an Kassen an, die keine Bons an JTL-Wawi geben

Packtisch: Vollbild zeigt nur noch den Packtisch

Packtisch: Teillieferungen und Wellen mit Fehlmenge werden richtig abgeschlossen

Kasse: Durchschnittssatz 5,5 % für forstwirtschaftliche Erzeugnisse bleibt erhalten

Kommissionierung: Aufträge mit offener Vorkasse stehen nicht mehr unter „Bereit“

Gutschriften zu einer Rechnung werden an DATEV Online und Lexware jetzt nach einer festen Regel übermittelt: Ist die Rechnung schon dort, geht auch ihre Gutschrift hinaus.

BIS Shop: Beispieldaten im Verkaufskanal werden erkannt, Widerruf ohne doppelten Grund

Amazon: Verbindungen werden nur noch gezielt erneuert

Kommissionierung: Änderungen am JTL-Auftrag erreichen auch die laufende Pickliste

Kommissionierung: Rabatt- und Freipositionen gelten nicht mehr als fehlender Bestand

Konnte BIS ERP einen Artikel beim Abgleich eines Kassenbons kurz nicht lesen, wurde ein Verkauf bisher still nicht gebucht, und ein Storno konnte den Bestand auf die zurückgegebene Menge setzen. Jetzt bleibt der Bestand dann unverändert, der Vorgang steht sichtbar im Fehlerprotokoll, und die Web-Kasse weist darauf hin. Die Buchung an den Lagerplätzen läuft ganz oder gar nicht, und eine gescheiterte Set-Komponente hält die übrigen Komponenten nicht mehr auf.

Scannen und Zurücknehmen am Packtisch (Lager-App und Browser) sowie das Picken im Browser buchen jetzt ganz oder gar nicht. Konnte ein Teil der Buchung nicht gespeichert werden, bleibt nichts halb gebucht stehen: Sie sehen „Buchung nicht ausgeführt – es wurde nichts gebucht“ und scannen den Artikel einfach noch einmal. Bisher konnte in seltenen Fällen die Ware schon umgebucht sein, ohne dass Karton oder Reservierung davon wussten.

JTL-Übertragung: Steuerschlüssel und Pfandsatz kommen aus JTL und der Pfandart

Kassenjournal: Öffnungsdifferenz unabhängig vom gewählten Zeitraum

Artikelseite zeigt, wer die Reservierung hält – Packtisch sperrt nicht lieferbare Positionen, Lager-App öffnet verwaiste Sammellisten

Beim ersten Öffnen von Einstellungen › EAN-Pool fehlten manchmal die EAN-Listen und es erschien ein Fehler, erst nach dem Neuladen war alles da. Die Seite lädt jetzt beim ersten Mal vollständig.

BIS Archiv: Gmail-Postfächer per IMAP

Kommissionierung: „Teilweise lieferbar“ nur noch bei echtem Fehlbestand

Auto-Kanalregeln für Marktplätze funktionieren

Handrechnung: Steuersatz nach Lieferland für Warenlieferungen ins Ausland

Lexware Office: Ausfuhren mit der richtigen Erlöskategorie

Kommissionierung: Reservierungen von extern versendeten Aufträgen werden frei, keine doppelten Picklisten mehr

Wer sich zum ersten Mal mit Microsoft anmeldet und dabei die Zwei-Faktor-Bestätigung einrichtet, braucht oft ein paar Minuten. Lief in dieser Zeit ein Update von BIS ERP, endete die Anmeldung bisher mit „Sitzung abgelaufen“. Die Anmeldung übersteht solche Updates jetzt, das gilt auch für die Anmeldung mit Google. Wird eine in BIS ERP gestartete Anmeldung trotzdem einmal unterbrochen, zeigt die Anmeldeseite den Knopf „Erneut mit Microsoft anmelden“: ein Klick, und es geht weiter, ohne die E-Mail-Adresse neu einzugeben. Die Meldung selbst sagt jetzt klar, was passiert ist.

Uhrzeiten in der Zeitzone Ihres Betriebs

Preisschilder drucken: Zielgerät und Drucker richtig beschrieben

Websites: „Zum Hauptinhalt springen“ funktioniert überall

An der Web-Kasse gelten jetzt dieselben Rechte der Mitarbeiterrollen wie an der Android-Kasse. Wer zum Beispiel nicht stornieren, kein Bargeld entnehmen oder keinen Rabatt gewähren darf, sieht diese Knöpfe nicht mehr. Versucht er es trotzdem, lehnt die Kasse die Aktion mit einem Hinweis ab. Inhaber und Administratoren dürfen weiterhin alles, Manager alles außer der Mitarbeiterverwaltung. Kassierer verkaufen, geben Rabatt, öffnen die Kasse und wechseln Geld; Stornos, Bargeld-Einlagen und -Entnahmen sowie der Tagesabschluss gehören wie an der Kasse zu Manager und Administrator. Ein gescannter Reparaturauftrag kommt jetzt über den Reparaturweg in den Warenkorb und wird beim Bezahlen als abgerechnet vermerkt.

Amazon: Marktplatz Frankreich mit der richtigen Kennung

Wurde eine Zahlung aus der Kasse erst Tage oder Wochen nach dem Verkauf an JTL übertragen (zum Beispiel nach einer Unterbrechung der Verbindung), stand in JTL das Datum der Übertragung als Zahlungsdatum. Rechnungen galten damit am falschen Tag als bezahlt, über den Jahreswechsel sogar im falschen Jahr. Jetzt übernimmt JTL das Datum und die Uhrzeit des Kassenbons (in der Ortszeit Ihres Betriebs). Ist die Bonzeit nicht lesbar, bleibt es wie bisher beim Zeitpunkt der Übertragung.

Meldet die Kasse einen Wareneingang oder einen Abgang (zum Beispiel den Storno eines Ankaufs) und bricht die Verbindung genau in diesem Moment ab, sendet die Kasse die Meldung später noch einmal. BIS ERP erkennt eine schon gebuchte Meldung jetzt an ihrer Kennung und bucht den Bestand nicht ein zweites Mal. Dafür ist die neue Version der Kasse nötig.

Wird ein BIS-Auftrag an der Kasse bezahlt und mitgenommen, bucht BIS ERP den Warenausgang jetzt immer vollständig oder gar nicht. Bisher konnte ein Fehler mitten in der Buchung einen Auftrag halb ausgebucht zurücklassen, der sich danach nicht mehr nachbuchen ließ.

Firmendaten: Speichern in BIS ERP überschreibt keine Änderungen der Kasse mehr

Lange E-Mail-Adressen: Belegvorlagen, Bankverbindungen, Wareneingang und Ansichten speichern wieder

Browser-Kasse: Kartenzahlung über die SumUp-App auf Handy und Tablet

Browser-Kasse: Teilzahlung mit Bar und Karte getrennt gebucht

Browser-Kasse: Zahlarten der Kasse im Bezahldialog

JTL-Abgleich: Teillieferungen aus JTL bleiben in BIS ERP „teilversendet“

Artikeländerungen, die in derselben Sekunde wie ein Kassenverkauf gespeichert werden, kommen jetzt zuverlässig in JTL an. Eine unveränderte Kassenmeldung hakt außerdem keine noch offene Änderung aus BIS ERP mehr als übertragen ab.

In Ihrer Lizenz für BIS Shop bzw. BIS ERP Max ist ein eigener Webshop enthalten, und ab BIS ERP Plus bzw. BIS Pro je Betrieb ein Einkaufsportal für Ihre Geschäftskunden. Jeder weitere Webshop kostet als Zusatzmodul 29,90 € im Monat oder 299 € im Jahr, jedes weitere Einkaufsportal 49,90 € im Monat oder 499 € im Jahr (jeweils netto zzgl. MwSt.). Die Preisseite und die Beschreibungen im Kundencenter nennen das jetzt ausdrücklich. Die beiden Zusatzmodule sind noch nicht im Kundencenter buchbar; wenn Sie einen weiteren Webshop oder ein weiteres Einkaufsportal brauchen, schreiben Sie uns an support@bispicy.com. Wer unter Einstellungen → BIS Shop → „Shop anlegen & Status“ einen zweiten Shop beantragt, sieht statt „besteht bereits“ diesen Hinweis.

Empfehlungsprogramm: Prämien werden jetzt automatisch gutgeschrieben

Versand mit DPD: Schnellversand, Verbindungstest und ehrliche Retourenlabels

Gutscheine: klare Meldung bei nicht ausstellbaren Typen, Hinweis an Vorlagen-Artikeln

Archiv „Altdaten aus Vorsystem“: Sehr große Dateien gelten nicht mehr als „unlesbar“

Die Shopify-App BISTranslate zeigt ihre Oberfläche jetzt in der Sprache Ihres Shopify-Admins: auf Deutsch, wenn Ihr Admin auf Deutsch eingestellt ist, sonst auf Englisch. Zahlen, Beträge und Daten erscheinen im passenden Format, Meldungen von BIS ERP ebenfalls in Ihrer Sprache, soweit sie zweisprachig vorliegen. Außerdem meldet sich die App jetzt direkt über Shopify an, ohne Zwischenschritt außerhalb des Admins.

Beim Kommissionieren mit der Lager-App ließen sich manche Kartons und Kästen nicht scannen, nur die einzelne Flasche oder Packung. Das betraf Karton-Codes, die in der Warenwirtschaft zusätzlich an einem zweiten Artikel hinterlegt sind, und Codes, die in einer anderen Schreibweise gespeichert sind (13 statt 14 Stellen oder als GS1-Etikett). Diese Kartons werden jetzt erkannt, und die Lager-App bucht wie gewohnt die ganze Kartonmenge. Steht derselbe Karton-Code bei zwei Artikeln derselben Kommissionierliste, nimmt die aktualisierte Lager-App die gerade gewählte Position oder fragt nach, welche gemeint ist.

Anmeldung mit Google und Microsoft: Konten werden nur noch über eine bestätigte Firmenadresse verbunden

Datenschutzerklärung: Gmail-Postfach in BIS Archiv

Legt das Büro in JTL selbst einen Lieferschein an, blieb in BIS die schon gelieferte Ware zum Packen stehen, und ein „Abschließen“ hätte sie ein zweites Mal gebucht. Jetzt gleicht BIS die gelieferten Mengen aus JTL von selbst ab.

Rechte bei Gutscheinen, Rabatten, Aktionen, Treue und Pfandarten

Lager-USt und ZM: Überschrift in heller Ansicht lesbar

Kassenbewegungen nur einmal beim Steuerberater

Wenn Sie einen Artikel speichern, der bei eBay eingestellt ist, überträgt BIS ERP die Menge jetzt genauso wie der Bestandsabgleich: Bestellte und reservierte Stücke sowie für eBay gesperrte Lager werden abgezogen, Teilmengen abgerundet. Ist nichts mehr frei, steht bei eBay 0 statt 1 – bei eingeschalteter Out-of-Stock-Control bleibt das Angebot dann bestehen, sonst beendet es der Bestandsabgleich. So lässt sich ein ausverkaufter Artikel nach dem Speichern nicht mehr weiterverkaufen. Das gilt auch für Variantenangebote. Beim Einstellen über BISLaunch wird ein Artikel mit Bestandsführung und 0 freien Stück nicht mehr mit 1 eingestellt, sondern mit einer Meldung abgelehnt.

Das Zusatzmodul „BIS EDI – Lieferanten-EDI“ (alle Lieferanten und Nachrichtenarten inklusive) können Sie jetzt selbst im Shop buchen, die ersten 14 Tage sind kostenlos. Unter Einstellungen → Verkaufskanäle & Anbindungen → EDI führt der Knopf „Zum Shop“ direkt dorthin; bisher hat der BISpicy-Support die Lizenz freigeschaltet.

DATEV-Export und Eröffnungsbeleg in BIS ERP: Trinkgeld an den Betrieb und Kassenbewegungen bei der Öffnung

BIS Shop: Steuerhinweise für Gebrauchtware und Kleinunternehmer, Versandkosten ins EU-Ausland

Wird eine Retoure eingelagert, meldet BIS ERP den Zugang nur noch an JTL, soweit JTL den zugehörigen Versand kennt. War der Versand noch nicht in JTL angekommen, heben sich Versand und Retoure in BIS ERP auf, und JTL bekommt weder das eine noch das andere. So steht der JTL-Bestand nach einer Retoure nicht mehr zu hoch. Im Artikeljournal steht bei der Retoure, was nach JTL ging und was in BIS ERP geblieben ist.

Zählen Sie beim Öffnen der Kasse und buchen eine Abweichung zum letzten Abschluss als Kassendifferenz, steht sie im Kassenjournal von BIS ERP als „Öffnungsdifferenz“. Derselbe Betrag erscheint dort jetzt nicht mehr ein zweites Mal als „Sitzungssprung“ – weder im Kassenjournal noch in der Zusammenfassung oder in der Berichtsmail. Ist nur ein Teil gebucht, nennt der Hinweis den nicht erklärten Rest und den gebuchten Teil.

Der Probelauf der Rechnungsumstellung vergleicht Proberechnung und JTL-Rechnung jetzt auch bei der Steuer: Ist nur eine der beiden eine innergemeinschaftliche Lieferung, fehlt auf der Proberechnung die USt-IdNr. oder weicht sie ab, steht der Beleg als „Abweichung“ mit dem Grund darunter – auch wenn die Beträge übereinstimmen. So fallen fehlende Pflichtangaben vor der Umstellung auf.

Versand: Bearbeiten nur noch mit dem passenden Recht

Wareneingang ansehen

Unter Einstellungen > Aufträge zusammenführen kannst du jetzt „Automatisch zusammenfassen“ einschalten. BIS ERP fasst dann neue Bestellungen aus Marktplätzen und Shops zu einer Gruppe zusammen, wenn sie vom selben Kunden stammen und an genau dieselbe Lieferadresse (Name, Straße, PLZ, Ort, Land) gehen. Du bekommst eine Meldung, prüfst die Gruppe unter Aufträge und gibst sie frei.

BISTranslate rechnet jetzt über deinen Shopify-Tarif ab, nicht mehr über Guthaben bei BISpicy. Du wählst in der App unter „Tarif wählen“ den Tarif, der zu deinem Shop passt: Monatstarife rechnet Shopify alle 30 Tage ab, den Jahrestarif von BYOK einmal im Jahr. Die inklusiven Zeichen gelten für diesen Abrechnungszeitraum und verfallen an dessen Ende. Brauchst du mehr, werden die zusätzlichen Zeichen über Shopify abgerechnet (Starter $24, Premium $20, Business $16 je Million), und zwar in ganzen Einheiten zu 1.000 Zeichen. **Probezeit:** In den Tarifen Starter, Premium und Business kannst du 14 Tage lang bis zu 200.000 Zeichen der BISpicy-KI ausprobieren, ohne Zusatzkosten. Danach geht dein Tarif automatisch in die Abrechnung über. Der Tarif BYOK hat ebenfalls 14 Tage Probezeit, enthält aber keine BISpicy-KI: Du übersetzt auch dort nur mit deinem eigenen API-Schlüssel. **Deine Grenze für Zusatzzeichen:** Standardmäßig liegt sie bei $50 je Abrechnungszeitraum. Du kannst sie im Dashboard der App im Abschnitt „Verbrauch“ jederzeit selbst ändern, auch auf $0, dann entstehen ab diesem Zeitpunkt keine weiteren Zusatzkosten. Würde eine Übersetzung die Grenze überschreiten, hält sie vorher an und sagt dir, wie du die Grenze erhöhst. Laufen mehrere Übersetzungen gleichzeitig, kann die Grenze um einen kleinen Rest überschritten werden. Über Shopify bekommst du nie mehr Zusatzzeichen berechnet, als deine Grenze erlaubt. Erhöhst du die Grenze im selben Abrechnungszeitraum, werden bis zur neuen Grenze auch diese Zeichen abgerechnet. Das Dashboard zeigt dir im Abschnitt „Verbrauch“, wie viele Zeichen du schon verbraucht hast, wie viele davon über deinem Tarif liegen und was sie bisher kosten. Gut zu wissen:

Herkunftsland nur aus der Länderliste

Kassenabschluss-PDF: Anzahl je Zahlart erklärt

Nordirland: Lieferungen an Unternehmer mit XI-USt-IdNr. sind steuerfreie innergemeinschaftliche Lieferungen

Sie können sich jetzt per E-Mail melden lassen, wenn sich etwas an Ihren Kunden, Artikeln, Preisen oder Lieferanten ändert. Sie finden die Einstellung unter „Einstellungen“ → „E-Mail & SMTP“ → „Änderungsmeldungen“.

Schnellversand bucht den Bestand nicht mehr doppelt ab

Browser-Kasse: TSE-Signatur für Verkäufe, Stornos und Bargeldbewegungen

Am Morgen des 9. November blieben BIS ERP, das Kundencenter und der Admin-Bereich nach einem Update komplett weiß, auch die Anmeldeseiten. Ursache war das Laden der Texte für die Hinweise zu fehlenden Artikelrechten vor dem Start der Sprachunterstützung. Die Texte werden jetzt sicher nachgeladen; alle Seiten starten wieder normal.

Nach dem Update vom 9. November blieb BIS ERP bei manchen Aufrufen komplett weiß, auch die Anmeldeseite. Die Ursache war ein Fehler beim Laden der Texte für den Hinweis „Dafür fehlt Ihnen das Recht“. BIS ERP startet wieder normal; der Hinweis bei fehlenden Rechten bleibt erhalten.

Qualitätsprüfung im Wareneingang

Bewertungsklasse für den Buchungsexport an Artikel und Warengruppe

Unter Einstellungen → Firmendaten stand die Branche immer auf „Einzelhandel“, auch wenn Sie Gastronomie, Dienstleistung oder eine andere Branche gewählt hatten. Die Auswahl zeigt jetzt die gespeicherte Branche, auch nach dem Neuladen.

Lieferungen nach Nordirland sind keine Ausfuhr mehr

Wer kein Recht zum Bearbeiten oder Löschen von Artikeln hat, sieht die Knöpfe für eBay-Titel, eBay-Angebote und -Vorlagen, den Abgleich mit eBay und Shopify, „Beenden“ im eBay-Abgleich sowie das Übernehmen von Shopify-Änderungen jetzt ausgegraut – mit einem Hinweis, welches Recht fehlt. Statt der englischen Meldung „Access Denied.“ erscheint bei fehlendem Recht überall ein verständlicher deutscher Hinweis (auch auf Englisch und Thai).

Wer eBay, Shopify, Shopee oder Etsy anbindet, trennt oder deren Einstellungen ändert, braucht jetzt das Recht „Schnittstellen bearbeiten“. Aufträge von Marktplätzen abrufen und als versendet melden geht mit dem Recht „Aufträge bearbeiten“, Angebote, Vorlagen und Zuordnungen pflegen mit „Artikel bearbeiten“. Bisher reichte dafür jede Anmeldung. Prüfen Sie unter Einstellungen → Benutzer & Rollen, ob Ihre Rollen die nötigen Rechte haben.

Ein im Tab „Verkaufskanäle“ eingestellter Kanalpreis (Sonderpreis, Fixpreis oder Aufschlag) wird jetzt auch an Ihren Shopify- und Gambio-Shop übertragen – bisher ging dorthin immer der normale Verkaufspreis. Das gilt für den Preisabgleich ebenso wie für das normale Aktualisieren eines Artikels, und bei mehreren Verbindungen je Kanal für jede Verbindung mit ihrem eigenen Preis.

Umsatzsteuer nach dem Land des Lagers

Browser-Kasse: Verkauf, Tischzahlung und Storno nur mit geöffneter Kasse

Ein Auftrag, den Sie in der Maske „Neuer Auftrag“ für einen Firmenkunden aus dem EU-Ausland anlegen, berücksichtigt jetzt die USt-IdNr. aus der Kundenakte: Ist sie formal gültig, rechnet BIS ERP die steuerfreie innergemeinschaftliche Lieferung statt 19 % Umsatzsteuer. Die Pfand- und Summenvorschau in der Maske rechnet mit derselben Nummer. Die Nummer wird am Auftrag gespeichert und erscheint auf der Rechnung. Maßgeblich ist die USt-IdNr. in der Kundenakte; dort pflegen Sie sie wie bisher. BIS ERP prüft nur das Format der Nummer; die Bestätigung beim Bundeszentralamt für Steuern holen Sie wie bisher selbst ein. Unter dem gewählten Kunden zeigt die Maske die USt-IdNr. aus der Kundenakte an. Bereits angelegte Aufträge ändern sich nicht; Aufträge aus Angeboten, über die Schnittstelle, aus dem Kundenportal und Ersatzaufträge bleiben unverändert.

Reparaturaufträge: einmal kassiert ist einmal kassiert

Firmenkunden mit Microsoft 365 können ihre Personen jetzt automatisch mit dem Einkaufsportal abgleichen lassen:

Ein Kauf auf Rechnung an der Browser-Kasse (BIS ERP) wird an der TSE jetzt so signiert wie an der Kasse-App: In der TSE-Signatur steht die Ware mit ihrem Steuersatz, der offene Rechnungsbetrag als Forderung daneben, und als Zahlung erscheint kein Betrag, weil an der Kasse kein Geld geflossen ist. Bisher stand der volle Betrag in der TSE-Signatur als unbare Zahlung („Unbar“). Der gedruckte Bon ändert sich nicht, er zeigt weiter die Zahlart Rechnung. Ein Storno wird spiegelbildlich signiert, auch der Storno eines älteren Rechnungskauf-Bons schon in der neuen Form. Bereits ausgestellte Bons bleiben unverändert. Die Bezahlung der Rechnung erfassen Sie wie bisher in BIS ERP oder an der Kasse-App (dort als Forderungsausgleich).

Unter Einstellungen → Rechnungen konnte für eine eigene Absender-Anschrift nur Deutschland, Österreich oder die Schweiz gewählt werden. Jetzt stehen alle Länder zur Auswahl, mit Namen in Ihrer eingestellten Sprache und den häufigsten Ländern oben. Solange Sie die Firmenanschrift verwenden, speichert die Maske keine leere eigene Anschrift mehr mit.

Betriebe außerhalb Deutschlands (zum Beispiel in Österreich oder der Schweiz) standen im Absender einiger Belege mit „DE“, obwohl in den Firmendaten ein anderes Land gepflegt ist. BIS ERP nimmt das Land jetzt überall aus dem gepflegten Ländercode der Firmendaten: im Absender neuer Rechnungen, Lieferscheine und Gutschriften, als Absender auf Versandetiketten und bei der Zustellung von Gutscheinen. Bereits erstellte Belege bleiben unverändert.

Auf den Kategorieseiten Ihres Webshops sehen Ihre Kundinnen und Kunden am Handy jetzt sofort die Artikel. In den Layouts mit Filterspalte (außer „Marktplatz“) liegen Kategorien und Filter hinter dem Knopf **„Filter & Kategorien“** und öffnen sich mit einem Tipp.

Im Bewegungsjournal eines Artikels steht jetzt auch bei Umbuchungen beim Kommissionieren (Lager-App, Sammelkommissionierung und BIS ERP), bei einer Fehlmenge beim Kommissionieren und bei den Umbuchungen am Packtisch der angemeldete Benutzer. Bisher blieb das Feld bei diesen Buchungen leer. Ältere Journalzeilen bleiben unverändert.

EDI mit Lieferanten (Bestellungen, Auftragsbestätigungen, Lieferavise und Rechnungen elektronisch austauschen) gibt es jetzt als Zusatzmodul „BIS EDI“: alle Lieferanten und alle Nachrichtenarten sind enthalten. Die Lizenz schaltet Ihnen der BISpicy-Support frei; danach überträgt Ihr Betrieb sofort echt, ohne weitere Freischaltung. Unter Einstellungen → Schnittstellen → EDI sehen Sie ohne das Modul einen Hinweis mit dem Weg zur Aktivierung. Bereits eingerichtete Verbindungen bleiben erhalten und laufen nach der Aktivierung weiter.

Erzeugen Sie das PDF einer ausgestellten Rechnung neu, steht als Bearbeiter jetzt wieder die Person darauf, die die Rechnung ausgestellt hat, und nicht mehr Sie selbst. Bei Rechnungen, die Sie ab diesem Update ausstellen, bleibt beim Neu-Erzeugen auch der Ansprechpartner so, wie er auf dem Original stand. Auf neuen Proforma-Rechnungen steht im Hinweisfeld ein kürzerer Satz, der in eine Zeile passt: „Proforma-Rechnung: keine Rechnung im Sinne des § 14 UStG, kein Vorsteuerabzug, keine Zahlungsaufforderung.“ Haben Sie die mitgelieferte Proforma-Vorlage im Belegdesigner angepasst, zeigt er „Neue Werksfassung verfügbar“; den neuen Satz übernehmen Sie dort. Eine selbst angelegte Proforma-Vorlage behält ihren Text, den Satz tragen Sie dort bei Bedarf selbst ein. Schon ausgestellte Belege ändern sich dadurch nicht.

Wird die PayPal-Zahlung eines online gekauften Gutscheins erstattet oder per Käuferschutz zurückgebucht, sperrt BIS ERP den Gutschein jetzt automatisch. An der Kasse kann er dann nicht mehr eingelöst werden, und Sie bekommen in BIS ERP eine Benachrichtigung mit Bestellnummer und Betrag. War es nur eine Teilerstattung oder haben Sie den Fall bei PayPal gewonnen, entsperren Sie den Gutschein unter Einstellungen → Verkauf & Kasse → Gutscheine; bleibt das Geld zurückgezahlt, stornieren Sie ihn dort. Voraussetzung ist ein registrierter PayPal-Webhook in den PayPal-Einstellungen; steht dort „Nicht registriert“, klicken Sie auf „Erneut registrieren“. Für Rückbuchungen geben Sie bei bereits eingerichteten Konten einmal das Secret neu ein und speichern. Testkäufe mit einer PayPal-Sandbox erzeugen nur noch gesperrte Testgutscheine, die nicht als Verkauf zählen.

Im Webshop lassen sich die Artikel jetzt nach **„Nur auf Lager“** und – bei eingeschaltetem Herkunftszeichen – nach **Herkunft** eingrenzen, jeweils mit der Zahl der Treffer.

Das PDF einer Proforma-Rechnung enthält jetzt kein maschinenlesbares E-Rechnungs-XML (ZUGFeRD) mehr, auch nicht bei Proformas aus JTL. Bisher steckte darin ein XML, das die Proforma als Handelsrechnung mit Umsatzsteuer auswies. Buchhaltungsprogramme Ihrer Geschäftskunden hätten sie deshalb als Rechnung einlesen können, und zusammen mit der späteren echten Rechnung hätte die Steuer doppelt dagestanden. Die Proforma bleibt ein reines PDF mit dem Hinweis, dass sie keine Rechnung ist, und der XML-Download gibt bei einer Proforma kein XML aus. Bereits erzeugte Proforma-PDFs bleiben unverändert. Ihre Rechnungen und Gutschriften tragen das E-Rechnungs-XML wie bisher.

Können Gäste zur Abholung oder mit Lieferung bestellen, zeigt die Speisekarte jetzt schon über den Gerichten den Hinweis „Alle Preise inkl. MwSt.“ und, wenn Sie liefern, „Für die Lieferung fallen keine zusätzlichen Kosten an“. Direkt über dem Bestellknopf stehen alle bestellten Positionen mit Preis. Dazu kommt der gesetzliche Hinweis, dass für Speisen und Getränke, die zubereitet werden oder schnell verderben, kein Widerrufsrecht besteht. Die Bestellbestätigung per E-Mail nennt diesen Hinweis ebenfalls, dazu Ihre Anbieterangaben aus den Firmendaten und die richtige Lieferart (vorher stand bei einer Lieferung „Abholung“). Sind Sie in den Firmendaten als Kleinunternehmer eingetragen, entfällt „inkl. MwSt.“. Auf Englisch heißt der Bestellknopf jetzt „Order with obligation to pay“. Bitte berechnen Sie für Lieferungen keine Gebühr außerhalb der Bestellung, und pflegen Sie Name und Anschrift Ihres Betriebs in den Firmendaten. Bei Bestellungen am Tisch ändert sich nichts.

Geräte-Ankauf: PayPal-Auszahlung wird nach dem Senden weiter überwacht

Wer BIS ERP mit JTL-Wawi verbindet, sah nach einer Plus-Korrektur des Bestands (zum Beispiel einer manuellen Bestandskorrektur, einer Korrektur an der Lager-App oder bei Stücklisten-Komponenten) in JTL oft einen geänderten letzten Einkaufspreis und Durchschnitts-EK, obwohl gar keine Ware geliefert wurde. BIS ERP übergab jede Zubuchung als Wareneingang. Jetzt setzt nur ein echter Wareneingang (im Browser, an der Lager-App oder aus einer Bestellung) den Einkaufspreis in JTL. Eine Plus-Korrektur bucht JTL als Korrektur, eine Kundenretoure weiter als Wareneingang, aber ohne neuen Einkaufspreis. Der Bestand stimmt in beiden Fällen, der Einkaufspreis bleibt, wie er ist.

Whatnot: Preise, Löschen und erneutes Anlegen zuverlässiger

### BIS ERP

### BIS ERP und Kasse

### Web-Kasse

Auf jeder Produktseite der BISpicy Produktdatenbank gibt es jetzt „Fehler melden“, an jeder Bewertung den Link „Melden“. Ein Hinweis zu Allergenen, zu den Zutaten oder zu einem falschen Barcode nimmt das Produkt bis zur Prüfung aus der Anzeige. Bei einer gemeldeten Bewertung ist bis zur Prüfung nur der Text ausgeblendet, die Sterne zählen weiter. Wer eine E-Mail-Adresse angibt, bekommt eine Eingangsbestätigung und unsere Entscheidung mit Begründung. Die Kontaktstelle nach dem Gesetz über digitale Dienste steht in der Fußzeile.

### BIS ERP und Kasse ### Scan-to-Order und Gutschein-Shop ### PayPal-Konto

Die Lieferzeit stellen Sie jetzt an jeder Versandart ein, als minimale und maximale Lieferzeit in Werktagen (BIS ERP, Einstellungen → Versandarten). Die maximale Lieferzeit ist die Frist, die Ihr Kunde zugesagt bekommt; eine minimale Lieferzeit allein speichert BIS ERP deshalb nicht. Ihr BIS Shop zeigt die Lieferzeit auf Deutsch bei der Auswahl der Versandart und in der Bestellbestätigung per E-Mail, in der einseitigen Kasse zusätzlich direkt über dem Bestellknopf. Ihre Versand- und AGB-Texte können darauf verweisen, statt eine feste Lieferzeit zu nennen. Leeren Sie die Felder, entfernt BIS ERP die Lieferzeit wieder.

Landete im Gewichtsfeld des Packtischs ein sehr großer Wert, zum Beispiel weil versehentlich ein Barcode hineingescannt wurde, brach die Seite mit „Die Anwendung wurde aktualisiert“ ab oder reagierte nicht mehr. Jetzt bleibt der Packtisch stehen und zeigt den Hinweis „Gewicht prüfen“. Sie korrigieren das Gewicht und packen weiter. Für sehr schwere Sendungen bleibt der Versand als Spedition.

Öffentlicher Bug-Tracker: Behebungszeit genauer, Handy-Menü reagiert sofort

Lager: Materialbelege – jede Bestandsbewegung auf einen Blick

Wer BIS ERP direkt nach der Registrierung öffnete, sah statt der Startseite teils mehrfach die Meldung „Die Anwendung wurde aktualisiert“. Jetzt erscheint das Dashboard sofort. Gibt es für eine Kachel noch keine Daten, steht dort ein kurzer Hinweis, zum Beispiel bei „Forderungen nach Alter“ bis zu Ihrer ersten Rechnung. Kann eine einzelne Kachel einmal nicht angezeigt werden, betrifft das nur diese Kachel, und Sie können sie mit „Erneut versuchen“ neu laden. Alle anderen Kacheln und die Navigation arbeiten weiter.

Die Allergenerkennung im Zutatenverzeichnis von BIS ERP und in der Produktdatenbank erkennt jetzt auch Mehrzahlformen wie „Haselnüsse“ oder „Kaschunüsse“, Ei in Zusammensetzungen wie „Volleipulver“ oder „Frischei 30 %“, Sardellen, Rahm und Sulfite als E-Nummer (E 220 bis E 228). Falsche Treffer fallen bei neu erfassten Zutaten weg: „Salbei“, „glutenfrei“, „Kakaobutter“, „Kokosmilch“, „Buchweizen“ oder „Austernpilze“ gelten nicht mehr als Allergen, „Milcheiweiß“ zählt als Milch statt als Ei und „Tintenfisch“ als Weichtier. Bereits gespeicherte Zutaten behalten ihre Markierung; Sie können sie in der Zutaten-Maske selbst entfernen. Beim Tippen eines Zutatennamens zeigt die Maske die Markierung nach derselben Erkennung, die auch beim Speichern gilt. In der Produktdatenbank trägt ein Name mit mehreren Allergenen wie „Milch- und Sojaeiweiß“ alle in die Liste „Enthält“ ein. Die Produktdatenbank verlangt jetzt die vollständige Nährwerttabelle mit allen sieben Pflichtangaben (Energie, Fett, gesättigte Fettsäuren, Kohlenhydrate, Zucker, Eiweiß, Salz), sofern das Lebensmittel eine tragen muss oder freiwillig eine trägt. Fehlt eine davon, nennt der Hinweis genau, was fehlt. Die Produktseite rundet die Nährwerte wie das Etikett nach dem EU-Leitfaden, etwa Salz unter 1 g auf zwei Stellen. Auf Etiketten erscheinen gesättigte Fettsäuren erst unter 0,1 g als „< 0,1 g“, darüber mit ihrem Wert.

Interne Entnahme: Kostenstelle und Aufwandskonto direkt am Artikel

Übernimmt der Kassenexport Berater- und Mandantennummer aus BIS ERP (Buchhaltung → DATEV), gilt jetzt auch der Kontenrahmen von dort. Eine Änderung des Kontenrahmens unter Buchhaltung → DATEV kommt damit im Kassenexport an. Der Hinweis im Reiter DATEV der Kassenberichte nennt jetzt die richtige Stelle im Kundencenter: Berichte → DATEV, Abschnitt „DATEV-Einstellungen“.

Wenn Sie an der Kasse einen Umtausch oder eine Erstattung mit Neuware buchen, wird die Seriennummer der zurückgenommenen Ware wieder frei, die der neuen Ware gilt als verkauft. Hat die Kasse bei einem Storno entschieden, die Ware nicht in den Bestand zurückzubuchen, bleibt auch die Seriennummer verkauft – selbst wenn der ursprüngliche Bon erst nach dem Storno bei BIS ERP ankommt. BIS ERP und JTL-Wawi bleiben dabei gleich; ein bereits wieder verkauftes Stück wird durch das erneute Senden eines alten Belegs nicht mehr freigegeben.

Lieferscheine: Teillieferungen und Bestellnummer

Einkaufsportal: Katalog im Einkaufssystem Ihres Kunden (OCI-Punchout)

Ist BIS Insights nicht gebucht, zeigt die Seite „Buchhaltung“ jetzt einen klaren Hinweis mit dem Weg zum Freischalten. Vorher sah sie aus wie ein leeres, eingerichtetes Journal mit einem Knopf, der nicht funktionierte.

Steht im Import eine Zeile für den Hauptartikel, die wegen eines Fehlers nicht übernommen wird (zum Beispiel eine ungültige EAN), übernehmen neue Ausführungen jetzt die gespeicherte Bestandsführung des Hauptartikels und nicht den Wert aus der fehlerhaften Zeile.

Verkauft die Kasse ein Set, dessen Bestandteil im Bestand schon im Minus steht, hebt BIS ERP den Bestand dieses Teils nicht mehr auf 0 an. Wie bei einem einzelnen Artikel wird dann nichts abgebucht, und die fehlende Menge steht im Fehlmengen-Buch.

Unter Berichte → Kassenberichte zeigte der Reiter „Berichtsversand“ bei Betrieben, die noch keinen automatischen Versand eingerichtet hatten, nur die Meldung „Die Anwendung wurde aktualisiert.“. Jetzt erscheint dort die Maske, und Sie können den monatlichen Versand an Ihre Steuerkanzlei direkt einrichten. Das gilt auch im Kundencenter.

Unter der Monatsauswahl der Umsatzsteuer-Voranmeldung stand zum Beispiel „30.9.2026 – 31.10.2026“ statt „01.10.2026 – 31.10.2026“. Das war nur die Anzeige: Die Zahlen des Monats waren richtig. Jetzt zeigt die Zeile den Zeitraum so, wie er gerechnet wird.

In der Historie eines Artikels stehen Bestandsbewegungen jetzt mit Nachkommastellen. Wer teilbare Ware wie 0,5 kg verkauft oder einbucht, sieht die Bewegung und den Bestand vorher und nachher genau, statt einer abgeschnittenen 0.

Einkaufsportal: Katalog für Einkaufssysteme (BMEcat)

Web-Kasse: Reparaturaufträge mit denselben Stufen wie im BIS ERP

Wenn Sie in BIS ERP eine Ausführung (Variante) mit der Option „Varianten“ duplizieren, erscheint die Kopie jetzt im Reiter „Varianten“ des Vaterartikels. Kopieren Sie die Bestandseinstellungen nicht mit, übernimmt die Kopie die Bestandsführung des Vaterartikels.

Legen Sie an der Kasse eine Ausführung (Variante) zu einem vorhandenen Artikel an, erscheint sie jetzt in BIS ERP im Reiter „Varianten“ des Vaterartikels und wird mit den übrigen Ausführungen an JTL-Wawi übergeben.

Wer einen deaktivierten Artikel oder eine Ausführung wieder aktiviert und dabei gleich eine neue EAN einträgt, kann jetzt in einem Schritt speichern. Bisher meldete BIS ERP einen Konflikt mit der alten, gerade ersetzten EAN, und man musste zweimal speichern.

Ihr BIS Shop legt die Grunddaten für Pfand jetzt selbst an, auch in neuen Shops und ohne Zutun. Die Meldung „Pfand wird im Shop nicht berechnet“ verschwindet damit von allein, und Pfandartikel kommen wieder in den Shop. Fehlt dafür noch ein Steuersatz, ergänzt der Shop das Pfand, sobald die Steuerklassen aus BIS ERP übertragen sind.

Als doppelt erkannte Kassenbelege bleiben in BIS ERP erhalten, zählen aber nicht als eigener Verkauf. Das gilt jetzt auch für den Hinweis zum Forderungsausgleich in den Geschäftszahlen des Dashboards, für die durchschnittliche Dauer je Verkauf im Kassenbericht, für die Zahl der Kassenverkäufe, die nur als Beleg gespeichert sind (Hinweis beim Einschalten der Übertragung an JTL und Abgleich), und für die Prüfhinweise zu Rückgaben bei Rechnungskauf. Bisher hätte ein doppelt gespeicherter Beleg dort zweimal gezählt.

In der Webhook-Verwaltung (BIS ERP und Kundencenter) stand das Ereignis „Kassenabschluss abgeschlossen“ zur Auswahl. Dieses Ereignis gab es nie, das Speichern schlug fehl. Es ist jetzt aus der Auswahl entfernt. Die API-Dokumentation listet alle Ereignisse, die BIS ERP tatsächlich meldet, darunter neu „inventory.transfer“ für Umbuchungen zwischen Lagerplätzen.

Das Protokoll Ihrer Webhook-Zustellungen enthält je nach Ereignis auch Kundendaten. Es wird jetzt automatisch aufgeräumt: Erfolgreich zugestellte Meldungen nach 30 Tagen, nicht zustellbare nach 90 Tagen.

Das Geheimnis, mit dem BIS ERP Ihre Webhooks signiert, wird jetzt verschlüsselt gespeichert. Bestehende Webhooks laufen unverändert weiter, ihr Geheimnis wird beim nächsten Speichern umgestellt. Der Test eines Webhooks zeigt jetzt nur noch, ob er ankam, und den HTTP-Status Ihres Servers. Hängt Ihr Server, wartet die erste Zustellung höchstens 10 Sekunden; danach versucht BIS ERP es automatisch erneut.

Wenn Sie aus der Kundenliste eine Kundenakte öffnen und danach zurückgehen, steht die Liste jetzt auch auf Laptop-Bildschirmen wieder so wie vorher: Der zuletzt geöffnete Kunde ist an derselben Stelle im Bild und kurz markiert. Bisher rutschte die Liste kurz nach dem Zurückgehen ein Stück nach oben, und der Kunde lag unter dem sichtbaren Bereich. Sobald Sie selbst scrollen, klicken oder tippen, bleibt die Liste dort, wo Sie sie hinbewegen.

Aufträge, die aus JTL übernommen werden, zeigen jetzt die richtige Uhrzeit und landen in den Tagesauswertungen am richtigen Tag. Bisher stand bei ihnen die Uhrzeit Ihres JTL-Rechners, die BIS dann um ein bis zwei Stunden verschoben angezeigt hat; spät am Abend angelegte Aufträge rutschten dadurch auf den Folgetag. Neue Aufträge werden ab sofort richtig übernommen. Ältere JTL-Aufträge stellen wir nach Absprache um.

Wenn Sie in Ihrem BIS Shop eine weitere Sprache einschalten, überträgt BIS ERP ältere Artikel jetzt wie gewohnt. Bisher konnten einzelne Artikel, die schon vor der neuen Sprache im Shop standen, bei jedem Abgleich mit einer Fehlermeldung hängen bleiben. Ihre Änderungen an Preis, Pfand oder Beschreibung kamen dann nicht mehr im Shop an. Die fehlende Übersetzung legt BIS ERP jetzt selbst an.

Einen Kunden, den Sie nach DSGVO anonymisiert haben, kann man nicht mehr bearbeiten, nicht wieder aktiv setzen und ihm keine Adresse mehr hinzufügen. Das gilt in BIS ERP, im Kundencenter, in der Web-Kasse und über die Schnittstelle. Er bleibt nur als Platzhalter für alte Belege stehen. Auch ein CSV-Import überschreibt ihn nicht mehr, und er wird nicht mehr an JTL-Wawi übertragen.

Ein Whatnot-Angebot lässt sich nur noch mit einem BIS-Artikel verknüpfen, der eine Artikelnummer (SKU) hat. Ohne Artikelnummer konnte BIS ERP Verkäufe dieses Angebots weder übernehmen noch reservieren. Ist ein Angebot schon mit einem Artikel ohne Artikelnummer verknüpft, meldet BIS ERP dort keinen Bestand mehr an Whatnot und zeigt am Angebot einen Hinweis. Vergeben Sie im Artikel eine Artikelnummer, dann läuft alles wieder wie gewohnt.

Beim Geräteankauf können Sie jetzt eine eigene SKU (Artikelnummer) für das angekaufte Gerät eintragen. Lassen Sie das Feld leer, vergibt BIS ERP die nächste freie Nummer aus Ihrem Artikel-Nummernkreis, statt wie bisher die IMEI als Artikelnummer zu nehmen. Die IMEI bleibt als Barcode und IMEI am Artikel, das Gerät lässt sich weiter per IMEI-Scan finden. Ist die eingetragene SKU schon an einem Artikel vergeben oder wird sie gerade bei einem anderen Ankauf verwendet, nennt die Kasse den Grund und der Ankauf wird mit dieser SKU nicht gespeichert. Die Prüfung läuft auf dem Server, auch wenn zwei Kassen gleichzeitig ankaufen. Ohne Verbindung gibt es keine eigene SKU; der Ankauf bekommt dann wie bisher die IMEI als Artikelnummer. Das gilt an der Web-Kasse sofort, an der Android- und Windows-Kasse mit dem nächsten Kassen-Update.

Eine Whatnot-Bestellung, die noch auf die Übernahme wartet, hält ihre Menge wie eine Reservierung vom Whatnot-Bestand zurück. Das gilt jetzt auch für Angebote, die Sie von Hand mit einem Artikel verknüpft haben und die bei Whatnot keine Artikelnummer (SKU) tragen. Bisher zeigte Whatnot dort bis zur Übernahme kurz zu viel Bestand.

Wenn Sie in CRM → Kunden einen Kunden weiter unten öffnen und danach zurückgehen, steht die Liste jetzt auch auf kleineren Bildschirmen wieder an derselben Stelle. Der zuletzt geöffnete Kunde ist kurz markiert.

In BIS ERP unter Einstellungen → Verkauf & Kasse → Gutscheine (POS) und im Kundencenter steht jetzt bei jeder Vorlage, ob sie einen Einzweck- oder einen Mehrzweck-Gutschein erzeugt, und beim Bearbeiten, was das für die Umsatzsteuer bedeutet.

Google-Anmeldung: Einladung erst nach Ihrer Entscheidung

Haben Sie eine Bankbuchung im Bankabgleich einem Auftrag zugeordnet (zum Beispiel eine Vorkasse) und markieren die Rechnung dazu später als bezahlt, übernimmt BIS ERP jetzt diese Bankzahlung, statt zusätzlich eine Zahlung von Hand anzulegen. So steht der Zahlungseingang nicht doppelt im DATEV-Zahlungsabgleich. In EÜR und Anlage EKS zählt er am Tag der Bankgutschrift – bei einer Vorkasse kann das ein früherer Monat sein als das Rechnungsdatum; die Meldung nennt Ihnen dann den Tag. Haben Sie für diesen Monat schon Zahlen abgegeben, fragen Sie bitte Ihre Steuerberatung, ob etwas zu berichtigen ist. Deckt die Bankzahlung nur einen Teil der Rechnung, wird der Rest wie bisher erfasst. Hat der Auftrag mehrere Rechnungen (auch später erstellte), liegt der Tag der Gutschrift in einem festgeschriebenen Zeitraum oder ist dem Auftrag eine Rücklastschrift zugeordnet, bleibt es beim bisherigen Ablauf; die Meldung sagt Ihnen dann, dass Sie die Zuordnung prüfen bzw. Ihre Kanzlei informieren sollten.

Der alte Weg über die JTL REST API wird nicht mehr abgeglichen. Im Kundencenter unter JTL-Wawi richtet der Assistent neue Verbindungen nur noch über BISConnect (SQL) ein. Eine bestehende Verbindung im alten REST-Modus zeigt einen Hinweis; mit „Auf BISConnect (SQL) umstellen“ stellen Sie sie in einem Schritt um. Bitte prüfen Sie danach, dass BISConnect auf dem Rechner mit Ihrer JTL-Wawi läuft.

Kundenliste: Zurück aus der Kundenakte auch auf Laptop-Bildschirmen an derselben Stelle

EÜR im Kundencenter: Bildschirm und PDF zeigen dieselben Zahlen

Z-Bon: MwSt je Zahlungsart

Ein Artikel lässt sich jetzt auch dann nicht deaktivieren, wenn er in einem zurückgehaltenen, noch nicht bestätigten oder teilweise versandten Auftrag steht; das sind genau die Aufträge, die die Artikelseite unter „Offene Aufträge“ zeigt, dazu Aufträge in der Kommissionierung. Ein Artikel im Status „Entwurf“ gilt nicht mehr als veröffentlicht. Beim Bearbeiten einer nicht vorhandenen Ausführung meldet BIS ERP einen Fehler statt eines Erfolgs.

Kann die Kasse eine Kassendifferenz, Entnahme oder Einlage nicht sofort mit der TSE signieren, hält sie Grund und Zeitpunkt fest und übermittelt beides an BIS ERP. Gelingt die Signatur später doch noch, trägt BIS ERP sie an derselben Bewegung nach, statt eine zweite Zeile anzulegen. So ist der TSE-Ausfall an der Bewegung in BIS ERP festgehalten. Der Z-Bon zeigt weiter den Stand beim Abschluss („ohne TSE-Signatur“) und nennt den Nachtrag. Wirkt mit dem nächsten Kassen-Update.

Wer Produkte über die Schnittstelle (`PUT /v1/products/{id}`, Feld `is_active`) aktiviert oder deaktiviert, bekommt jetzt dieselben Prüfungen wie in der Artikelmaske: Ein Produkt mit offenen Aufträgen lässt sich nicht deaktivieren, und ein Produkt, dessen EAN inzwischen ein anderes aktives Produkt trägt, lässt sich nicht aktivieren. Die Schnittstelle antwortet dann mit 409 und dem Code `offene_auftraege` bzw. `ean_vergeben` und ändert nichts. Bleibt der Zustand gleich, gibt es keine Sperre.

Wir haben den Auftragsverarbeitungsvertrag (BIS ERP Fassung 1.27, BISpicy Kasse Fassung 1.24) und die Datenschutzerklärung an die neue Kassen-Sicherung angepasst und die Angaben zum Drittlandbezug ergänzt. Außerdem beschreiben beide jetzt die Bestell-App „BISpicy Einkauf“ und das Änderungsprotokoll der Stammdaten.

Das Kreditorkonto eines Lieferanten ist im DATEV-Export jetzt dasselbe wie in der Buchhaltung von BIS ERP und bleibt über alle Exporte gleich. Bisher konnten zwei Lieferanten mit ähnlicher Nummer (zum Beispiel L-001 und L-0001) im Export auf demselben Kreditorkonto landen. Lieferanten, die schon ein eigenes Konto hatten, behalten es. Steht ein Lieferant deshalb auf einem anderen Konto als bisher, weist der Export (auch die Vorschau) darauf hin und sagt, was Ihre Steuerberatung dazu tun sollte. Eingangsrechnungen ohne Lieferant und Lieferanten ohne Lieferantennummer laufen wie bisher gemeinsam auf dem ersten Kreditorkonto.

Geben Sie beim Anlegen eines Kunden über die Schnittstelle oder beim CSV-Import eine eigene Kundennummer mit, prüft BIS ERP sie jetzt zusätzlich auf Tippfehler: Liegt sie im Format Ihres Kundennummernkreises mehr als 10.000 über der höchsten bisher vergebenen Nummer, wird sie abgelehnt, damit Ihre Nummernfolge nicht dauerhaft springt. Legen Sie den Kunden dann ohne Nummer an, vergibt BIS ERP die nächste freie. Werden zwei Kunden gleichzeitig mit derselben Nummer in unterschiedlicher Schreibweise angelegt (zum Beispiel KD-043 und KD-0043), entsteht nur noch einer. Bei der Übernahme aus Odoo und beim Bestellimport aus einer CSV-Datei wird kein Kunde abgewiesen: Passt die mitgebrachte Nummer nicht zu Ihrem Kundennummernkreis, bekommt der Kunde die nächste freie eigene Nummer, und eine bestehende Kundennummer wird bei einem erneuten Abgleich nicht mehr gelöscht.

Kassenkonten: Anmeldeadresse vergibt BIS ERP selbst

Kassen-UStVA: Kauf auf Rechnung an der Kasse ab 01.12.2026 nur bei den Rechnungen

Kommt ein Stücklisten-Auftrag aus JTL, dessen Bestandteile alle noch keinen Artikel in BIS ERP haben, behandelt BIS ERP den Satz jetzt wie einen normalen Artikel: Er erscheint auf Pickliste und Packtisch und wird beim Versand vom Bestand abgebucht. Bisher wurde in diesem Fall weder der Satz noch ein Bestandteil gebucht. Sobald mindestens ein Bestandteil einen Artikel hat, gilt wie bisher die Stückliste.

BIS Archiv: Gmail-Postfach sicherer verbinden

Meldung bei fehlendem Tagesabschluss

Wer als Kleinunternehmer (§ 19 UStG) arbeitet, bekommt Auftragsbestätigungen und Angebote jetzt ohne Umsatzsteuer: Die Positionen zeigen den Endpreis, es gibt keine Spalte „MwSt.“ und keine Steueraufstellung mehr, und der vorgeschriebene Hinweis zur Steuerbefreiung steht auf dem Beleg. Das gilt für Aufträge und Angebote ab dem 8. November 2026; ältere Belege bleiben unverändert.

BIS ERP rechnet die Kassenumsätze in EÜR, BWA und Anlage EKS jetzt nach derselben Regel wie der DATEV-Kassenexport. Berichte und Export stimmen damit überein: Das Trinkgeld Ihrer Mitarbeiter zählt nicht mehr als Einnahme, ein Rabatt auf die Bonsumme mindert die richtigen Steuersätze, und Pfandrückgaben, Stornos und Differenzbesteuerung (§ 25a) werden wie im Export aufgeteilt. Eine Anzahlung zählt in der EÜR, wenn sie bezahlt wird, in der BWA erst, wenn die Ware abgeholt wird. An der Kasse bezahlte Rechnungen zählen genau einmal. In der EÜR und der Anlage EKS zählt ein Gutschein beim Verkauf; beim Einlösen bleibt die Umsatzsteuer der Ware stehen. Lässt sich ein Kassenbeleg nicht eindeutig aufteilen, zeigt der Bericht einen Hinweis. Bereits erstellte Auswertungen können sich dadurch leicht ändern – erstellen Sie EÜR, BWA oder Anlage EKS für noch offene Zeiträume bitte neu. Die Ansicht „EÜR der Kassenumsätze“ im Kundencenter bleibt vorerst unverändert.

Aufträge: Retoure, Ersatzversand, Umtausch und Rückläufer direkt im Auftrag

BISPix: Ausschalten stoppt auch das automatische Freistellen

Beim Hochladen von Artikelbildern (auch aus der Lager-App) und Artikel-Anhängen prüft BIS ERP jetzt, ob der Artikel zum eigenen Betrieb gehört. Eine ungültige Artikel-Kennung wird mit einer klaren Meldung abgelehnt.

Reparatur-Sendungen und Ersatzlieferungen mit JTL-Anbindung

Haben Sie eine Rechnung von Hand als bezahlt markiert und ordnen danach im Bankabgleich die passende Bankbuchung zu, übergibt BIS ERP den Zahlungseingang nur noch einmal an DATEV. Ist die von Hand erfasste Zahlung noch in keinem DATEV-Export, liegt die Bankgutschrift im selben Monat und ist keiner der beiden Tage schon übergeben oder festgeschrieben, ersetzt die Bankbuchung sie: Der Zahlungseingang zählt dann am Tag der Bankgutschrift. Sonst bleibt die von Hand erfasste Zahlung maßgeblich, und die Bankbuchung wird nicht zusätzlich an DATEV übergeben; liegen die beiden Tage in verschiedenen Monaten, nennt Ihnen die Meldung beide. Lösen Sie die Zuordnung wieder, gilt die von Hand erfasste Zahlung wie vorher, und die Rechnung bleibt bezahlt. Lässt sich nicht sicher erkennen, dass es dieselbe Zahlung ist (zum Beispiel bei mehreren von Hand erfassten Zahlungen oder abweichenden Beträgen), wird wie bisher nur zugeordnet, und Sie erhalten einen Hinweis mit dem Grund.

Hinweise, die sich an Händler und Wiederverkäufer richten, erscheinen in Ihrem BIS Shop nicht mehr in der Artikelbeschreibung. Gemeint sind etwa Abschnitte wie „Fragen aus dem Handel“, Aufrufe zum Händlerkonto oder Angaben zur Bestellung im Gebinde. Ihre Kundinnen und Kunden sehen so nur noch, was zum Kauf im Shop passt. Die Beschreibung in BIS ERP bleibt unverändert, und andere Verkaufskanäle sind nicht betroffen.

Storno nach Spedition oder Abholung: kein Phantombestand mehr

BIS Archiv: Löschvorschlag statt automatischer Löschung

Wer in einer eigenen Belegvorlage den Baustein „Summen“ nutzt, sieht auf neuen Rechnungen dort wieder die tatsächliche Umsatzsteuer je Steuersatz. Bisher stand in diesem Baustein „MwSt. 19 % 0,00 €“, obwohl die Steuer richtig berechnet war. Auftragsbestätigungen und Angebote zeigen den Betrag ab sofort richtig; bereits ausgestellte Rechnungen bleiben unverändert, wie sie verschickt wurden.

Der kombinierte DATEV-Export enthält jetzt nur noch Belege: Ausgangs- und Eingangsrechnungen, Gutschriften und Kassenbelege. Die Zahlungen stehen im Export „Zahlungsabgleich“: in BIS ERP erfasste Zahlungseingänge zu Rechnungen (von Hand oder über die Bankanbindung), Stripe-Zahlungen, Auszahlungen und Bankbuchungen. Bisher standen manche Zahlungen in beiden Exporten und konnten in DATEV doppelt gebucht werden; in BIS ERP erfasste Zahlungseingänge fehlten dagegen im Zahlungsabgleich. Wenn Sie bisher nur den kombinierten Export an Ihre Kanzlei geben, erzeugen Sie bitte für neue Zeiträume zusätzlich den Zahlungsabgleich – er braucht keine Zusatzlizenz, und der kombinierte Export weist Sie darauf hin, solange im Zeitraum Zahlungen liegen. Zeiträume, die Sie schon mit dem bisherigen kombinierten Export übergeben haben, exportieren Sie bitte nicht erneut: Dort sind die Zahlungen bereits enthalten. Bereits erzeugte Exporte bleiben unverändert. Wer einen Zeitraum erneut exportiert, bekommt eine Warnung, wenn es dafür schon einen Export gibt – jetzt auch beim Zahlungsabgleich und bei den Stripe-Transaktionen.

Die EÜR der Kasse rechnet einen Kauf auf Rechnung jetzt wie die EÜR im BIS ERP: Er zählt nicht mehr am Tag des Kassenbons, sondern an dem Tag, an dem die Rechnung bezahlt wird. Bezahlt jemand an der Kasse eine schon bestehende Rechnung, ist das keine Kasseneinnahme mehr; die Einnahme gehört zur Rechnung und steht in der EÜR im BIS ERP. Noch offene Rechnungen aus Käufen auf Rechnung nennt die Auswertung mit Anzahl und Betrag in einem Hinweis. Die Kassen-EÜR kann dadurch niedriger ausfallen als bisher, bis diese Rechnungen bezahlt sind; das gilt auch für frühere Jahre.

Wenn Sie in BIS ERP einen Auftrag von Hand anlegen und versenden, bevor er an JTL-Wawi übertragen wurde, kommt er dort jetzt als geliefert an. Die Ware wird in JTL nicht mehr ein zweites Mal abgebucht, auch wenn der Auftrag dort später geöffnet wird. Bei einem Teilversand gilt nur der versendete Teil als geliefert. Wurde ein Teil vor und ein Teil nach der Übertragung versendet, bucht BIS ERP den Rest nicht selbst nach. Das Sync-Protokoll meldet den Fall, damit Sie den Bestand in JTL prüfen können. Dasselbe gilt, wenn der Auftrag nur über den Statusknopf auf „versendet“ gesetzt wurde: Er bleibt in JTL offen, und das Sync-Protokoll weist darauf hin.

Wird ein Guthabenkauf im Kundencenter erstattet oder die Kartenzahlung von der Bank zurückgebucht (Chargeback), bucht BIS das dafür gekaufte Guthaben jetzt automatisch zurück, bei einer Teilerstattung genau den erstatteten Anteil. Ist das gekaufte Guthaben schon verbraucht, wird der Betrag mit Ihrem übrigen Guthaben verrechnet. Jede Buchung steht mit Begründung in Ihrem Guthabenverlauf. Endet eine Rückbuchung zu Ihren Gunsten, wird alles wieder gutgeschrieben, Ihr eigenes Guthaben wieder als auszahlbares Guthaben. Solange eine Rückbuchung läuft oder ein zurückzubuchender Betrag offen ist, sind Auszahlungen gesperrt; das Kundencenter zeigt dann keinen auszahlbaren Betrag an.

PayPal: „Synchronisieren“ holt auch die Zahlungen von heute

Keine nächtlichen Aussetzer mehr während der Datensicherung

Kassenbuch: Saldo je Kasse, Übertrag am Monatsanfang und Trinkgeld im Storno

Steuersätze für Thailand und Großbritannien hinterlegt

Rechnungen aus der Kasse: an der Kasse bezahlt heißt nie „überfällig“

Kassen-Rechnung (DIN A4) nennt wieder die Bonnummer

Ab der nächsten Version der Bestell-App sehen Sie schon beim Bestellen, wann die Ware kommt, und entscheiden Freigaben direkt in der App. BIS ERP liefert die Angaben dafür ab sofort.

Die Auswertungen unter Berichte → „Performance“ (Pick & Pack, Vertriebs-Scorecard) zeigen Leistungsdaten der Kolleginnen und Kollegen. Ab Werk sehen sie jetzt nur Administrator und Manager. Der Reiter erscheint nur noch für Rollen mit dem Recht „Mitarbeiter-Leistung“; bisher war er für jede Rolle mit Zugriff auf die Berichte sichtbar, die Seite blieb aber leer. Wer weiteren Rollen die Auswertung geben möchte, schaltet unter Einstellungen → Benutzer & Rechte das Recht „Mitarbeiter-Leistung“ zusammen mit „Berichte ansehen“ frei. Bereits gespeicherte Rechte Ihrer Rollen und einzelner Benutzer bleiben unverändert.

Wird ein Auftrag in BIS ERP storniert und die Ware dabei zurück ins Lager gebucht, überträgt BIS ERP seine noch nicht versendeten Sendungen nicht mehr an die JTL-Wawi. Die JTL-Wawi bucht die Ware dann nicht mehr aus, und Ihr Bestand stimmt in beiden Systemen. Holen Sie einen stornierten Auftrag zurück, geht seine Sendung wie gewohnt wieder mit. Für einen stornierten Auftrag lassen sich außerdem keine Versandetiketten oder Internetmarken mehr anlegen, keine Sendungsnummern nachtragen und kein Wiederversand starten. BIS ERP zeigt dann einen Hinweis.

Steht die Hausnummer schon im Straßenfeld und zusätzlich im Feld „Hausnummer“, erscheint sie auf Rechnung (auch in der Lieferanschrift), Gutschrift, Lieferschein, Angebot, E-Rechnung (ZUGFeRD), Bestellung beim Lieferanten, Tourenliste, Lebensmittel-Etikett und im Kundenportal jetzt nur noch einmal („Mürnsee 27“ statt „Mürnsee 27 27“). Das gilt auch für das DPD-Retourenetikett und für Anschriften, die an JTL-Fulfillment und JTL übergeben werden. Kunden, die über die ältere JTL-Anbindung übernommen werden, behalten keine alte Hausnummer mehr neben einer neuen Straße, der Adresszusatz steht im eigenen Feld statt hinter der Straße, und eine Übertragung ohne Anschrift löscht die gespeicherte Anschrift nicht mehr. Gespeicherte Anschriften werden dabei nicht verändert.

Wenn Sie BIS ERP ohne JTL-Wawi nutzen, können Sie Marktplatz- und andere externe Aufträge (zum Beispiel von eBay oder Shopify) wieder über den Statusknopf „Versendet“ abschließen. Bisher erschien dort fälschlich die Meldung „Dieser Auftrag wird in JTL geführt“. Mit angebundener JTL-Wawi bleibt es dabei: Den Versand solcher Aufträge buchen Sie über Sendung oder Packtisch, damit JTL Lieferschein und Bestand erhält.

Spielen Sie eine Sicherung zurück, hält BIS ERP jetzt alle ausgehenden Übertragungen an JTL-Wawi, Ihre Verkaufskanäle, das Fulfillment-Lager, Lexware und Odoo an, bis ein Administrator sie bestätigt. Auch die Abholung durch JTL-Wawi ruht in dieser Zeit. So gehen Bestandsbewegungen, Kunden, Sendungen und Aufträge, die schon übertragen waren, nicht ein zweites Mal hinaus. Auf jeder Seite weist ein Hinweis darauf hin, und unter Einstellungen > Datensicherung sehen Sie in Klartext, was abgeglichen wurde: was als bereits übertragen weiter gilt, welche Aufträge nicht mehr im Datenbestand stehen und beim erneuten Import ihrer früheren Übertragung zugeordnet werden und wie weit die Rücksicherung ist. Bestände und Preise in den Verkaufskanälen stehen bis zur Bestätigung auf dem Stand vor der Rücksicherung und springen danach auf den aktuellen Stand. Neue Aufträge werden während des Halts weiter importiert. Verbindungen und Zugänge zu Ihren Verkaufskanälen, JTL-Wawi, Ihre API-Schlüssel und angemeldete Sitzungen bleiben bei einer Rücksicherung unverändert; ein widerrufener Zugang wird nicht wieder gültig. Die Bestätigung ist erst möglich, wenn die Rücksicherung abgeschlossen ist. Ist beim Einspielen oder beim Abgleich ein Fehler aufgetreten, verlangt BIS ERP eine zweite, ausdrückliche Bestätigung. Sie wird mit Namen und Zeitpunkt protokolliert. Danach laufen die Übertragungen wieder. Die Rücksicherung selbst und ihre Mitteilung per E-Mail weisen auf den Halt hin, auch wenn das Einspielen fehlgeschlagen ist.

Bei Lebensmitteln zeigt Ihr BIS Shop die Länderflagge an der Produktkachel, die Länder-Kacheln „Woher soll's kommen?“, die Länderseiten, das Menü und die Sitemap nur noch, wenn bei dem Artikel ein passender Ursprung gepflegt ist, der das Land nennt. Den Ursprung pflegen Sie in den Lebensmittel-Pflichtangaben des BIS Shop unter „Ursprungsland oder Herkunftsort“; in BIS ERP ist er noch nicht pflegbar. Ohne diese Angabe, oder wenn sie ein anderes Land nennt, bleiben Flagge und Länderzuordnung bei diesem Lebensmittel weg, und die Länderseite gibt es nur, solange mindestens ein Artikel dort stehen darf. So behauptet der Shop keine Herkunft, die nicht belegt ist. Andere Artikel verhalten sich wie bisher. Auf der Regal-Produktseite erscheint das Ursprungsland nur noch bei Artikeln, die sicher keine Lebensmittel sind.

Erhält Ihr Betrieb (nicht das Personal) bei einer steuerfreien innergemeinschaftlichen Lieferung an der Kasse ein Trinkgeld, bucht BIS ERP dieses Trinkgeld jetzt wie die Lieferung: steuerfrei auf dem Erlöskonto für innergemeinschaftliche Lieferungen (SKR03 8125, SKR04 4125). Bisher landete es mit 0 % ohne Befreiungsgrund auf dem allgemeinen Erlöskonto, und der DATEV-Export zeigte einen Hinweis zur Prüfung. Fehlt die gültige USt-IdNr. des Käufers, ist das Trinkgeld wie die Lieferung steuerpflichtig und wird mit dem Regelsteuersatz gebucht. Das gilt für Belege, die BIS ERP selbst aufbereitet, und für Belege aus der nächsten Kassenversion; bereits von der Kasse festgeschriebene Belege bleiben unverändert.

Änderungsverlauf zeigt jetzt auch Änderungen aus JTL

Ab der nächsten Version der Bestell-App scannen Sie im Kühlraum oder Lager auch ohne Empfang weiter. Die Scans warten auf dem Gerät und gehen in den Warenkorb, sobald wieder Netz da ist. BIS ERP nimmt diese Scans ab sofort an.

Im Kundencenter gibt es unter Berichte den neuen Reiter „Küche & Theke“. Er zeigt aus den Küchenzeiten Ihrer Hauptkasse, wie lange Bons an Küche, Theke und eigenen Stationen auf den Start warten, wie lange die Zubereitung dauert, wie lange es vom Senden bis „Fertig“ und von „Fertig“ bis zum Servieren braucht – mit Durchschnitt, Median und dem Anteil über 10 und über 20 Minuten, je Station, je Stunde und je Wochentag. Bons an Stationen ohne Display zählen getrennt als „ohne Rückmeldung“.

Bisher konnte jedes angemeldete Konto Inventuren anlegen, zählen und Differenzen als Bestand buchen. Jetzt gilt: anlegen, abschließen und Differenzen buchen mit dem Recht „Lager erstellen“, zählen, starten und ändern mit „Lager bearbeiten“, löschen und abbrechen mit „Lager löschen“. Administrator, Manager und Lager haben diese Rechte ab Werk und arbeiten wie gewohnt; ohne Recht sind die Knöpfe gesperrt und ein Hinweis nennt das fehlende Recht. Nach der Genehmigung kann eine Position nicht mehr umgezählt werden, und den Wert der Differenzen samt Einkaufspreis sieht nur, wer Einkaufspreise sehen darf. Neu unter Lager → Lagerstandorte: Wer Lagerrechte, aber kein Recht für die Einstellungen hat, pflegt Lager jetzt dort.

Wurde ein Kassenbeleg vollständig mit einem Gutschein bezahlt, zeigt der digitale Bon als Zahlart jetzt „Gutschein“ statt „Bargeld“. Das gilt auch für bereits ausgegebene digitale Bons. Auf dem Kassenbon und der A4-Rechnung der Kasse erscheint „Gutschein“ mit dem nächsten Update der Kassen-App.

Wenn an einer Kasse die Bonnummern am selben Tag von vorn begannen (zum Beispiel nach einem Zurücksetzen der App oder beim Wechsel des Mandanten), hielt BIS ERP beim Nachladen der Belege einen anderen Beleg mit gleicher Nummer für bereits gespeichert. Der Beleg fehlte dann in den Berichten und in der Buchhaltung. Jetzt erkennt BIS ERP einen anderen Beleg an seiner eigenen Kennung und übernimmt ihn, auch wenn Nummer, Betrag und Uhrzeit zufällig gleich sind. Bei älteren Belegen ohne Kennung zählt er als eigener Beleg, wenn Betrag und Uhrzeit abweichen. Wird derselbe Beleg zweimal gesendet, wird er weiterhin nur einmal gespeichert. Bereits fehlende Belege tauchen auf, sobald die Kasse ihren Belegverlauf erneut hochlädt.

Beim CSV-Import von Kundenklassen wird eine Zelle „A“ mit einem Leerzeichen am Ende jetzt als A gelesen. Bisher wurde sie zu A+ und die Einstufung gesperrt. Konnte BIS ERP die gespeicherten Einstellungen zur Kunden-ABC einmal nicht lesen, sperrt die Maske das Speichern und zeigt einen Hinweis, statt still das Pareto-Verfahren zu speichern. Wer unter „Pareto“ speichert, behält seine zuletzt gespeicherten Rhythmus-Grenzen. Die Zusammenfassung zeigt Beträge mit Tausenderpunkt (10.000 €), und der Filter „Ø Monatsumsatz ab“ in der Kundenliste wird nicht mehr abgeschnitten.

Wer aus einer Kundenakte zur Kundenliste zurückgeht, landet jetzt auch mit derselben Seitengröße und demselben Suchtext wieder an der richtigen Stelle. Wird ein Betreuer in der Liste gewählt und gleich danach eine Kundenakte geöffnet, speichert BIS ERP die Auswahl sofort und meldet Erfolg oder Fehler auch dann noch, wenn die Liste schon geschlossen ist. Die geöffnete Akte zeigt danach den neuen Betreuer.

Aufträge, die aus JTL-Wawi in BIS ERP kommen, übernehmen jetzt die USt-IdNr. Ihres Kunden. Bei steuerfreien Lieferungen an Firmen im EU-Ausland steht die Nummer damit auch auf der Rechnung, wie es das Umsatzsteuergesetz verlangt, und sie erscheint in der Zusammenfassenden Meldung. Ändern Sie die Nummer in BIS ERP selbst, bleibt Ihre Änderung bis zum nächsten Abgleich erhalten; ein Platzhalter wie „beantragt“ wird durch die echte Nummer aus JTL ersetzt. Auch bei Aufträgen, die Sie in BIS ERP selbst anlegen, übernimmt die Rechnung jetzt die USt-IdNr. des Auftrags, sofern sie formal gültig ist, sonst die aus dem Kundenstamm.

Die E-Rechnung (ZUGFeRD/XRechnung) wird von Empfängern jetzt seltener abgelehnt: Schon ausgestellte Rechnungen bleiben unverändert, auch wenn ihr PDF neu erzeugt wird.

Wurde ein Kassenbeleg ganz oder teilweise mit einem Gutschein bezahlt, steht auf der A4-Rechnung dazu jetzt der Hinweis „Davon mit Gutschein bezahlt“ mit dem Betrag. Der Rechnungsbetrag bleibt der volle Warenwert, denn ein Gutschein ist ein Zahlungsmittel und kein Rabatt. Der Gutscheincode erscheint nicht auf der Rechnung.

Wer im Dashboard auf die Kachel „Offene Rechnungen“ (oder „Überfällig“ bzw. eine Fälligkeitsklasse) klickte, sah in der Rechnungsliste bei teilbezahlten Rechnungen den vollen Rechnungsbetrag, während die Kachel nur den noch offenen Rest zählt. Jetzt zeigt die Liste in diesem Fall den offenen Betrag und darunter klein den Rechnungsbetrag, so dass Kachel und Liste zusammenpassen.

Hatte die Kasse beim Abgleich viele Artikel nachzuladen, konnten Änderungen an Rabatten, Aktionen, Gutscheinen oder am Bestand, die BIS ERP genau während dieses Abgleichs bekam, an der Kasse ausbleiben, bis sie erneut geändert wurden. Ab diesem Stand holt die Kasse beim nächsten Abgleich alles nach, was sich seit Beginn des vorherigen Abgleichs geändert hat. An der Kasse ist dafür kein Update nötig.

Die Kachel „Newsletter“ im Dashboard zeigte bisher feste Platzhalterwerte. Sie zeigt jetzt die echten Zahlen Ihres Newsletters: aktive Empfänger, im laufenden Monat versendete Kampagnen, Abmeldungen im laufenden Monat, die Öffnungs- und Klickrate Ihrer letzten Kampagnen und die letzten Kampagnen selbst. Fehlt das Recht für den Newsletter oder lassen sich die Zahlen nicht laden, steht statt einer Zahl ein Strich.

Bisher fehlte bei mehreren Buchungen aus der Lager-App und der Inventur der Name der Person, oder das Artikeljournal zeigte nur eine lange Gerätekennung. Ab diesem Stand stehen bei der Direktzählung, beim Ausbuchen und bei der Platzkorrektur aus Kommissionierung, Sammelkommissionierung und Packtisch, bei der Inventurbuchung in BIS ERP und beim Wareneingang zur Lieferantenbestellung in der Lager-App der angemeldete Mitarbeiter und der Name des Geräts im Journal.

Wurde das Herkunftsland eines Artikels an der Kasse gesetzt, war es in BIS ERP im Feld Herkunftsland, im BIS Shop und auf der Produktseite nicht zu sehen, und in manchen Fällen stand dasselbe Land doppelt am Artikel. Ab diesem Stand übernimmt BIS ERP das Herkunftsland aus der Kasse so, dass es an allen drei Stellen erscheint; ein an der Kasse geändertes Land ersetzt das bisherige. Arbeiten Sie mit Änderungsvorschlägen der Kasse, gilt das neue Land erst, wenn Sie den Vorschlag annehmen. Ältere Zuordnungen bringen wir für betroffene Betriebe nach und nach in Ordnung.

Ein Positionsrabatt, der mit einem Auftrag aus JTL-Wawi kommt, steht in BIS ERP jetzt als Rabattzeile und nicht mehr als Artikel. Pickliste, Packtisch und Lieferstand sehen dort keine Ware mehr, die es nicht gibt, und ein vollständig versandter Auftrag wird dadurch nicht mehr zur Teillieferung. Das gilt für neu übernommene Aufträge.

Legen Sie einen Artikel ausdrücklich ohne Bestandsführung an, übernimmt BIS ERP einen eingegebenen Anfangsbestand nicht mehr. Bisher entstand dafür trotzdem eine Lagerzeile, die nach dem nächsten Abgleich mit JTL wieder verschwand, während am Artikel weiter der eingegebene Bestand stand. Jetzt zeigt BIS ERP für solche Artikel überall einheitlich keinen Bestand.

Laufen Kasse und Lager-App auf demselben Handgerät, führt BIS ERP sie jetzt als zwei getrennte Geräte. Bisher hat die zuletzt angemeldete App die andere abgemeldet, und die Kasse ließ sich danach oft nur mit einem Administrator-Konto wieder verbinden. Bestehende Lager-Geräte behalten bei der nächsten Anmeldung ihren Namen und ihren Verlauf. Wird die Lager-App auf einem Gerät eingerichtet, das schon eine Kasse ist, erscheint sie einmalig als neues Gerät. Das Einrichten erledigt ein Administrator oder Manager.

Sammellisten aus der Zeit vor der Umstellung auf echte Picklisten (Mitte August 2026), die längst abgeschlossen sind, standen dauerhaft in der Kommissionierungs-Übersicht, als warteten sie noch auf den Packtisch, und ließen sich nicht löschen. Solche Sammellisten enthalten keine Picklisten und halten keinen Bestand mehr. Sie stehen jetzt nur noch unter „Erledigte anzeigen“ und lassen sich dort löschen. Aufträge und Bestand bleiben dabei unverändert.

Bei Bestellungen zur Abholung oder Lieferung müssen Ihre Gäste keiner Datenschutzerklärung mehr per Häkchen „zustimmen“. Auf allen Gästeseiten – Bestellen am Tisch, Abholung und Lieferung sowie Tischreservierung – steht stattdessen ein kurzer Hinweis, dass Ihr Betrieb die Angaben zur Abwicklung verwendet. Unten auf der Seite erscheinen Ihr Firmenname, Ihr Impressum und Ihre Datenschutzerklärung sowie der Vermerk „Technisch bereitgestellt von BISpicy“. Hinterlegen Sie dafür die Links zu Impressum und Datenschutzerklärung unter Einstellungen → Kundenportal (im Kundencenter: Verkauf → Kundenportal); das geht auch ohne gebuchtes Kundenportal. Ihre Datenschutzerklärung sollte Bestellungen und Reservierungen über diese Seiten mit abdecken, mit BISpicy als technischem Dienstleister. Fehlen die Links, zeigt die Seite Ihre Firmendaten und nennt Ihren Betrieb als Ansprechpartner für Datenschutzfragen. Außerdem steht der Name Ihres Restaurants jetzt oben auf der Bestellseite, und das Anmerkungsfeld fragt nicht mehr nach Allergien.

Wenn Sie einen Kunden in BIS ERP anonymisieren oder löschen, entfernt die Kasse jetzt auch ihre gespeicherte Kopie: Name, Anschrift und Kontaktdaten werden dort geleert, sobald die Kasse das nächste Mal abgleicht (spätestens nach einigen Stunden). Für anonymisierte Kunden gilt das auch rückwirkend, für gelöschte Kunden ab diesem Update. Bereits erstellte Belege bleiben unverändert. Voraussetzung ist die neue Kassen-Version.

Die Verfahrensdokumentation der Kasse erklärt in Abschnitt D.2 jetzt, dass die Kasse den Tagesabschluss (Z-Bon) seit Version 1.3.6 (Oktober 2026) nicht mehr mit der TSE signiert. Der Z-Bon fasst die einzeln aufgezeichneten Belege nur zusammen. Für ältere Kassenstände steht dort auch, warum der TSE-Export je Abschluss eine zusätzliche Transaktion über den Tagesumsatz enthält und dass dies kein zusätzlicher Umsatz ist. Das hilft bei einer Kassen-Nachschau.

Wird an der Web-Kasse ein Bon storniert, der vollständig mit einem Gutschein bezahlt wurde, zählt der Storno in der Umsatzsteuer-Voranmeldung der Kasse jetzt als Gegenbuchung zum ursprünglichen Bon. Bisher konnte er den Umsatz dieses Bons ein zweites Mal hinzuzählen, statt ihn aufzuheben. Außerdem verteilt die EÜR-Auswertung stornierte Bons mit Rabatt- oder Leergutzeilen jetzt genauso auf 7 % und 19 % wie die Umsatzsteuer-Voranmeldung. Kassenumsatz und Z-Bon ändern sich dadurch nicht.

Wird eine Bestellung in Shopify oder in der JTL-Wawi storniert oder versendet, übernimmt BIS ERP das jetzt mit den passenden Folgen für Ihren Bestand.

Storno: Ware kommt mit Charge und MHD zurück ins Lager

Startseite: Niedrigbestand-Kachel ohne Platzhaltertext

Die Zuordnung „Wo darf dieser Mitarbeiter arbeiten?“ verwendet für jede Kasse jetzt überall dieselbe Schreibweise, an der Kasse, in BIS ERP und im Kundencenter. Eine Auswahl, die im Kundencenter gespeichert wird, gilt damit auch an der Kasse.

CRM-Kundenliste: Filter bleiben, Kundenprofil per Tastatur

Buchhaltung: Reiter „Differenzbesteuerung (§ 25a)“ richtig beschriftet

Kundencenter: Belegarchiv nur mit Buchhaltungsrecht

Die Rechte für Gefahrgut, Gebinde, Bilder, eBay-Vorlagen und die Preiskalkulation (BISCalc) gelten jetzt auch beim Speichern. Wer ein Recht nicht hat, sieht die Knöpfe gesperrt, mit einem Hinweis auf das fehlende Recht. Ohne das Recht „Artikelpreise ändern“ berechnet BISCalc neue Preise nur als Vorschlag (im BISCalc-Verlauf), der Artikelpreis bleibt unverändert. Einkaufspreise bei Gebinden und bei neuen Artikeln erfassen nur Benutzer mit dem Recht „Einkaufspreise & Gewinn“. Neu in der Rechteverwaltung: die Module „Gefahrgut“ und „Preiskalkulation“. Für selbst angelegte Rollen, die Gefahrgut pflegen sollen, vergeben Sie dort bitte das Recht „Gefahrgut“.

Änderungsverlauf jetzt auch bei Importen, Odoo und Kunden-Zusammenführungen

Bestand: Sets werden überall nur über ihre Bestandteile gebucht

Rückverfolgung: Versand vom Kommissionierwagen bucht genau die Chargen des eigenen Auftrags ab

Kassenjournal: Kauf auf Rechnung getrennt von den Kasseneinnahmen

AGB 2.4: Datenexport und Anbieterwechsel ohne Wechselentgelt, Löschantrag schneller umgesetzt

Erstatten Sie an der Kasse einen Forderungsausgleich, dessen Erlös in der Rechnung steht, bucht der DATEV-Kassenstapel die Erstattung jetzt wie den Ausgleich selbst: als Rückbuchung der Forderung auf das Konto Ihres Kontenrahmens, ohne Umsatzsteuer, statt als Erlös mit Umsatzsteuer. Damit stimmen Kassenstapel, BWA und Umsatzsteuer-Voranmeldung für diesen Fall überein. Bereits übergebene Stapel bleiben unverändert; exportieren Sie einen betroffenen Monat neu, ändert sich die Buchung. Stimmen Sie das bitte mit Ihrer Steuerberatung ab. Außerdem bucht ein zweiter Ausgleichsbon zum selben BIS-Auftrag die Ware nicht noch einmal aus dem Lager aus.

Buchungsexport: eigener Steuerschlüssel je Kunde oder Kundengruppe

Mehr Sicherheit bei den Benutzerrechten: Lagerstandorte

Melden Sie im Kundencenter eine Kasse oder ein Lager-Gerät ab, zum Beispiel nach Verlust oder Diebstahl, bleibt es abgemeldet, bis Sie es ausdrücklich wieder freigeben.

Im BIS Shop stand bei Artikeln mit Umsatzsteuer ein zu hoher Preis: Ein Artikel zu 5,00 € in BIS ERP kostete im Shop 5,95 €, einer zu 7,19 € sogar 8,56 €. Die Umsatzsteuer wurde im Shop ein zweites Mal aufgeschlagen. Das ist behoben: Der Shop zeigt und berechnet jetzt den Verkaufspreis aus BIS ERP. Wo sich ein Preis wegen der Steuerrundung nicht centgenau abbilden lässt, steht im Shop ein Cent weniger, nie mehr. Liegt ein Aktionspreis nur einen Cent unter dem regulären, kann die Aktion im Shop deshalb entfallen. Der durchgestrichene Preis im Shop ist der niedrigste Preis der letzten 30 Tage; der Grundpreis wird aus dem richtigen Preis gebildet, das Pfand ändert sich nicht. Artikel ohne Umsatzsteuer-Aufschlag (Differenzbesteuerung nach § 25a, steuerfreie Artikel, Gutscheine) behalten ihren Preis unverändert. Alle bereits übertragenen Artikel bekommen ihren Preis automatisch im laufenden Abgleich neu, Artikel mit Aktionspreis zuerst. Bei großen Sortimenten kann das einige Stunden dauern; schalten Sie einen neuen Shop erst frei, wenn alle Artikel übertragen sind. Bis dahin stehen im Shop alte und neue Preise nebeneinander. Eine Aktion, die genau bei der Umstellung schon läuft, zeigt bis zur nächsten Preisänderung keinen durchgestrichenen Preis; später startende Aktionen zeigen ihn wie gewohnt. Bestellungen, die schon im Warenkorb liegen, werden mit dem Preis berechnet, der beim Bezahlen gilt.

Aktivitätsprotokoll: Jeder sieht nur seine eigenen Einträge

Länderkacheln, der Knopf „Nach Land stöbern“ und der Punkt „Länder“ erscheinen nur, wenn es dort mindestens einen lieferbaren Artikel gibt; Kategorien in Kopfleiste und Themenkacheln verschwinden, wenn sie keinen darstellbaren Artikel haben. Layouts können eine Infoleiste einbinden, die nur nachgerechnete Angaben zeigt (zum Beispiel „Über 300 Artikel aus 6 Ländern“); das OEZ-Layout nutzt sie, alle anderen Shops behalten ihre Hinweisleiste mit eigenen Texten. Das technische Pfand-Produkt taucht in der Shop-Schnittstelle nicht auf.

Lager: Charge und MHD bleiben auf dem Kommissionierwagen erhalten

Änderungsverlauf jetzt auch bei Lieferanten, an der Kasse und in der Lager-App

Ein Klick auf „Hilfe“ oben rechts öffnet jetzt ein kleines Menü, statt direkt Ihre Anfragen zu zeigen.

Einkaufsportal: Bestellungen mit Freigabe gehen wieder zur Freigabe

Wer die Pflichtdaten-Sperre des BIS Shops nicht ausschalten darf, sah unter Einstellungen → BIS Shop → Verkaufskanäle bisher nur den Zustand und keinen Knopf. Dort steht jetzt: „Ausschalten kann nur ein Administrator oder der Lizenzinhaber dieses Kontos.“ So ist klar, wer die Sperre aufheben kann.

Eine DIN-A4-Rechnung zu einem Kassenbon bekommt jetzt immer eine Nummer aus Ihrem Rechnungsnummernkreis, auch ohne Rechnungskauf. Bisher stand dort die Bonnummer. Bei mehreren Kassen konnten so zwei Rechnungen dieselbe Nummer tragen. Die Bonnummer steht weiter als Verweis auf der Rechnung (in neuen Rechnungsvorlagen als „Bon-Nr.“). Bereits ausgestellte Rechnungen behalten ihre Nummer. Kommt eine Rechnungsnummer mehrfach vor, zeigt die Rechnungsübersicht einen Hinweis mit den betroffenen Nummern; über die Suche finden Sie dort auch Rechnungen aus der Kasse.

Wenn die Verbindung zu JTL kurz ausfiel, konnte BIS ERP im Abgleich einen zweiten, leeren Verkaufskanal für die Kasse in JTL anlegen. Das passiert nicht mehr: Bei einem Verbindungsfehler wird nichts angelegt, der Fehler erscheint im Abgleich-Protokoll, und beim nächsten Lauf wird der vorhandene Kanal weiterverwendet.

Einkaufspreise und Gewinn nur noch mit dem Recht „Einkaufspreise & Gewinn“

Die Umsatzsteuer-Voranmeldung (auch die UVA für Österreich) und die Kassen-EÜR im Kundencenter enthalten jetzt die Verkäufe aller Kassenkonten Ihres Betriebs, wie Kassenjournal und DATEV-Kassenexport. Bisher zählten sie nur die Verkäufe des Kontos, mit dem Sie angemeldet waren. Betriebe mit mehreren Kassenkonten sahen dadurch zu niedrige Umsätze.

E-Mail-Versand über BISpicy: Tagesgrenze je Betrieb

Die Artikelliste und die Aufträge zeigen Preise und Summen jetzt einheitlich in deutscher Schreibweise mit Währungszeichen, also „12,90 €“ statt „12.90 €“ oder „12.90 EUR“. Das gilt für die Preisspalten der Artikelliste, die Summen in der Auftragsliste, den Tagesumsatz über der Liste sowie die Beträge beim Anlegen und Bearbeiten eines Auftrags. Fehlt ein Preis, steht dort ein Strich statt einer fehlerhaften Angabe.

Lieferanten: Löschen geschützt, stattdessen deaktivieren

Lager: Gescannte Charge wird abgebucht

Rückrufliste: Datum und MHD gut lesbar

Im Kundencenter gibt es unter Kassen › BIS Remote im Abschnitt „Küchendruck“ den neuen Schalter „Küchenzeiten erfassen“. Ist er eingeschaltet, meldet Ihre Hauptkasse je Bon und Station (Küche, Theke oder eigene Station), wann er gesendet, begonnen, fertig und serviert wurde. Das ist die Grundlage für eine spätere Statistik zu den Durchlaufzeiten Ihrer Küche.

Der Abgleich der Kunden aus JTL bleibt nicht mehr an einer doppelt vergebenen Kundennummer hängen. Trägt ein zweiter JTL-Kunde dieselbe Nummer wie ein bereits vorhandener Kunde, wird er trotzdem übernommen: Er erscheint unter der Ersatznummer „JTL-" mit seinem JTL-Kundenschlüssel, die echte JTL-Nummer bleibt im Kundenstamm hinterlegt. Bei bestehenden Kunden werden alle übrigen Angaben wie Name, Adresse und Kontakt weiterhin aktualisiert. Hängen an einem JTL-Kunden mehrere Kunden in BIS ERP, wird immer derselbe aktualisiert; zusammengeführt wird nichts automatisch. Im JTL-Sync-Protokoll steht dazu eine Warnzeile, welche Kunden in JTL zusammengeführt oder umnummeriert werden sollten.

PayPal an der Kasse: Storno erstattet direkt über PayPal

Im Bestellschritt steht neben „AGB ansehen“ jetzt auch „AGB als PDF speichern“: beim Nachbestellen im Kundenportal, bei der Annahme eines Angebots, an der Kasse des Einkaufsportals und bei der Freigabe einer Bestellung. Ihr Kunde kann Ihre AGB damit schon vor dem Absenden speichern, auch wenn die Eingangsbestätigung per E-Mail einmal nicht ankommt. Es ist dieselbe Datei, die der Eingangsbestätigung anhängt. Lässt sich Ihre AGB-Seite gerade nicht abrufen, sagt ein Hinweis, dass Ihr Kunde die AGB über „AGB ansehen“ speichern kann.

Bestellt ein Geschäftskunde über das Kundenportal, das Einkaufsportal oder die Bestell-App, enthält die Eingangsbestätigung jetzt alle bestellten Positionen. Das gilt auch für die Bestätigung nach einer Freigabe im Einkaufsportal. Nimmt ein Kunde ein Angebot im Kundenportal an, hängen Ihre AGB ebenfalls an. So hat Ihr Kunde seine Bestellung und Ihre AGB als Nachweis in seinem Postfach.

Wird ein Reparaturauftrag an der Kasse storniert, weil das Gerät nicht reparierbar ist oder der Kunde die Kosten ablehnt, kann die Kasse eine Diagnose- oder Prüfpauschale vorschlagen. Diese Voreinstellung pflegen Sie jetzt auch in den Kassen-Einstellungen unter Verkauf, Betriebsfunktionen, „Reparatur: Pauschale bei Rückgabe ohne Reparatur“. Sie gilt für alle Kassen Ihres Betriebs.

Kassenmenü: Reihenfolge unter „Weitere“ selbst festlegen

Bei vielen Betrieben war die Artikeltabelle so voll, dass neue Artikelfelder nicht mehr angelegt werden konnten. Einige Felder ließen sich bedienen, speicherten aber nichts, zum Beispiel die Wahl der Steuerklasse, die Seitenvorlage und der eigene Text der Produktseite oder die Verwiegepflicht. Mit diesem Stand kann BIS ERP die Artikeltabelle umstellen und so Platz schaffen; danach werden die fehlenden Felder angelegt und speichern wieder. Die Umstellung führen wir nach und nach für alle Betriebe durch. Ihre Artikel und Bestände bleiben erhalten; während der Umstellung Ihres Betriebs können Artikel kurz nicht gespeichert werden.

Bisher hat Ihr Webshop jeden Artikel abgeschaltet, dem eine Pflichtangabe fehlt, zum Beispiel Zutaten, Nährwerte, Füllmenge oder Grundpreis. Die Sperre bleibt ab Werk an. Sie können sie jetzt selbst ausschalten; dann stehen alle Artikel Ihrer freigegebenen Kategorien im Shop, auch solche mit Lücken. Sie finden den Schalter unter Einstellungen, Webshop, Verkaufskanäle, im Abschnitt „Pflichtdaten-Sperre“.

Produktdatenbank: Fotos ohne Standortdaten, Scanner ohne fremde Server

Gehört ein Kunde (zum Beispiel eine Einrichtung) zu einem übergeordneten Kunden (dem Träger), können Sie in der Kundenakte unter „Organisation“ → „Rechnung“ festlegen, dass die Rechnung an den Träger geht. Der Träger ist dann Rechnungs- und Leistungsempfänger. Die Einrichtung bleibt Besteller und Lieferanschrift.

Benutzer mit der Rolle **Buchhalter** (oder einer eigenen Rolle mit dem Recht „Exportieren“ im Bereich Buchhaltung) erzeugen den DATEV-Export unter Buchhaltung → DATEV jetzt selbst. Bisher ging das nur als Administrator. Wer seinem Steuerbüro einen Zugang gibt, muss ihn dafür nicht mehr zum Administrator machen.

Die Zahlungsübersicht in der Buchhaltung, PayPal und Stripe in den Einstellungen sowie die Stripe-Abos zeigen ihre Daten jetzt nur noch Mitarbeitenden mit dem Recht „Banking ansehen“. Bisher konnte jedes angemeldete Konto diese Zahlen abrufen, auch ein Kassen- oder Lagerkonto.

Legt BIS ERP neue Artikel in JTL an, entsteht ein Vaterartikel nicht mehr als einfacher Artikel, solange ihm Ausführungen (Größen, Farben) in BIS ERP noch nicht zugeordnet sind. Stattdessen steht im Sync-Protokoll ein Hinweis, welche Familie wartet, wie viele Ausführungen betroffen sind und wie Sie das lösen: Vater und Ausführungen gemeinsam erneut importieren. Bisher entstand der Vater in diesem Fall ohne Varianten, und die Familie war in JTL dauerhaft unvollständig. Ein Vater, den es in JTL schon gibt, wird wie bisher verknüpft.

Beim Zuweisen eines Gebiets an einen Kunden, einzeln in der Kundenakte oder gesammelt in der Kundenliste, prüft BIS ERP jetzt, ob es das Gebiet in Ihrem Betrieb gibt und ob es aktiv ist. Bisher ließ sich auch ein gelöschtes Gebiet speichern; der Kunde fehlte dann ohne Hinweis in der Tourvorschau und in der Anrufliste nach Gebiet. Die Massenzuweisung bietet deshalb nur noch aktive Gebiete an. Der Filter „Gebiet“ zeigt weiterhin alle Gebiete. Lehnt BIS ERP eine Sammelzuweisung von Gebiet oder Betreuer ab, steht der Grund jetzt direkt im Dialog statt nur „Die Vorschau konnte nicht ermittelt werden“.

Artikel-Import: Hinweis bei Lagern mit Lagerplätzen, stabilere große Importe

Artikel anlegen: Bestandsfelder nur mit Recht, Anfangsbestand immer im richtigen Lager

Ist bei Ihrer Amazon-Anbindung „Bestand synchronisieren“ eingeschaltet, meldet BIS ERP Ihren Bestand jetzt alle 15 Minuten von selbst an Amazon. Verkäufe in anderen Kanälen und an der Kasse kommen dadurch bei Amazon an, ohne dass jemand den Knopf drücken muss. Gemeldet werden nur Angebote, deren Menge sich geändert hat. Ihr eingestellter Puffer wird wie bisher abgezogen; Angebote, die Amazon für Sie versendet (FBA), bleiben unberührt. Der Knopf „Bestand synchronisieren“ meldet weiterhin alle Angebote auf einmal.

Schickt BIS ERP Ihre Kassenabschlüsse (Z-Bons) automatisch an die DATEV-Upload-Adresse, wird ein gescheiterter Versand jetzt so lange wiederholt, bis er gelingt. Bisher galt ein Z-Bon nach 48 Stunden ohne Erfolg still als erledigt, etwa nach einem Ausfall des E-Mail-Versands, und kam nie beim Steuerberater an.

DATEV gibt es nur noch für Betriebe mit Sitz in Deutschland; für alle anderen Länder ist es ausgeblendet. Die Kasse warnt vor einem Kassenbewegungs-Export aus dem Kundencenter jetzt genauso wie vor einem Export aus BIS ERP.

Händler melden sich im Backend ihres BIS Shops jetzt über BIS ERP an, solange der Shop angebunden ist. Kunden, die ihr Passwort zurückgesetzt haben, können sich danach sofort wieder anmelden.

Wurden alle Picklisten einer Sammelliste gelöscht oder nach einer Auftragsänderung zurückgerufen, blieb die Sammelliste als leere Hülle stehen. War sie schon abgeschlossen, stand sie dauerhaft in der Kommissionier-Übersicht und ließ sich nicht löschen. Jetzt gilt eine abgeschlossene leere Sammelliste als erledigt und erscheint nur noch unter „Erledigte anzeigen“. Jede leere Sammelliste können Sie löschen, auch eine abgeschlossene. Das Löschen entfernt nur die leere Sammelliste; Aufträge und Bestand bleiben unverändert.

DHL-Einstellungen: Abrechnungsnummern werden erkannt, Speichern behält alle Einstellungen

Versand: Gelieferte Mengen stimmen auch nach Teillieferung und Statuswechsel

Der Versandstatus Ihrer Aufträge springt nicht mehr hin und her, und Aufträge erscheinen nicht mehr fälschlich als „in BIS geändert“, nur weil die Versanddaten aus JTL abgeglichen wurden. Aufträge mit mehreren Lieferscheinen zeigen jetzt dauerhaft alle Sendungsnummern.

Chargen und MHD werden zuverlässiger gebucht

Artikel-Import mit Gebrauchtgeräten: klarere Hinweise

Die ersten Einstellungsseiten speichern jetzt jede Änderung sofort. Betroffen sind Grundpreis, Sendungsverfolgung, Aufträge zusammenführen und Inventur-Zählweise. Die übrigen Einstellungsseiten folgen nach und nach.

Aufträge, die BIS ERP an JTL-Wawi überträgt (etwa aus dem BIS Shop oder in BIS ERP angelegt), blieben dort „offen“, wenn die Zahlung erst später in BIS ERP eingeht, zum Beispiel über den Bankabgleich oder PayPal. In den JTL-Einstellungen gibt es jetzt den Schalter „Zahlungen an JTL übertragen“. Eingeschaltet bucht BIS ERP die dort erfassten Zahlungen (Bankabgleich, PayPal und Zahlungen mit zugeordneter Zahlart) als Zahlung am JTL-Auftrag, mit Betrag, Zahltag und der passenden Zahlart. Zahlungen, die ohne Zahlart von Hand als bezahlt gesetzt wurden, werden nicht übertragen. Es wird nie mehr gebucht, als in JTL-Wawi noch offen ist, und jede Zahlung genau einmal, auch bei Wiederholung oder Teilzahlung. Übertragen werden nur Aufträge, die nach dem ersten Einschalten entstehen (der Zeitpunkt bleibt auch nach dem Ausschalten gemerkt); ältere fasst BIS ERP nicht von allein an. Lässt sich die Zahlart keiner JTL-Zahlart zuordnen, wird nichts gebucht und die Zahlung steht im Synchronisationsprotokoll. Erstattungen und später in BIS zurückgenommene Zahlungen werden in JTL-Wawi nicht zurückgebucht, nur gemeldet.

Das Aktivitätsprotokoll unter Einstellungen dient als lückenlose Spur, wer wann was geändert hat. Einträge lassen sich deshalb nicht mehr von Hand löschen, auch nicht durch Administratoren. Sie werden automatisch nach Ablauf der Aufbewahrungsfrist entfernt, heute nach 12 Monaten. Die Fristen zeigt der Hinweis (?) oben auf der Seite. Brauchen Sie eine kürzere Aufbewahrung, etwa nach einer Betriebsvereinbarung, wenden Sie sich an unseren Support.

In der Kundenakte gibt es den neuen Reiter „Verlauf“. Dort steht jede Änderung an den Kundendaten mit Zeitpunkt, Bearbeiter, altem und neuem Wert: Anschrift, Kontaktdaten, Konditionen wie Zahlungsziel, Kreditlimit und Kundenrabatt, Beleg-Empfänger, Sammelrechnung und die Adressen im Adressbuch. Auch geänderte Kundenpreise erscheinen dort. Beim Artikel finden Sie den Verlauf unter „Auswertung“ → „Verlauf“: Verkaufspreis, Einkaufspreis, Steuersatz und Steuerklasse, Name, Artikelnummer, EAN und Einheit sowie Kunden-, Kundengruppen- und Staffelpreise. Den Verlauf sieht jeder, der den Kunden bzw. Artikel sehen darf. Änderungen am Einkaufspreis sehen nur Benutzer mit dem Recht „Einkaufspreise sehen“. Bei Notizen, Kundenprofil und anderen Freitexten steht im Verlauf nur, dass sie geändert wurden, nicht der Inhalt. Die Einträge lassen sich nachträglich nicht ändern; nur wenn ein Kunde anonymisiert oder gelöscht wird, entfernt BIS ERP seine persönlichen Angaben auch aus dem Verlauf. Sie bleiben gespeichert, solange Ihr Konto besteht, und gehören bei Vertragsende zu Ihrem Datenexport. Erfasst werden zunächst Änderungen in den Eingabemasken, über den Kunden-Import und die Massenbearbeitung. Änderungen über Kasse, Kundencenter, Schnittstelle (API), JTL-Abgleich, automatische Preisläufe, weitere Importe und an Lieferanten folgen schrittweise. Der Verlauf zeigt, wer eine Änderung vorgenommen hat. Er dient der Nachvollziehbarkeit, nicht der Leistungs- oder Verhaltenskontrolle; gibt es in Ihrem Betrieb einen Betriebsrat oder eine Mitarbeitervertretung, beziehen Sie diese ein.

Artikelnummer aus JTL: Umbenennungen werden übernommen, keine doppelten Artikel mehr

Kassen-UStVA rechnet wie der DATEV-Kassenexport

Wurde an der Kasse ein Teil der Ware zurückgegeben, zeigte das PDF der automatisch angelegten Gutschrift bisher fälschlich den Hinweis „TSE-Ausfall … Notbeleg“. Ab diesem Update übernimmt die Gutschrift die TSE-Daten des Rückgabe-Bons, also Signatur-Zähler, Seriennummer, Zeitpunkte und QR-Code, und dazu die Bonnummer.

Aufträge, die Sie in BIS ERP anlegen, gingen schon immer nach JTL-Wawi. Hat BIS ERP zu einem solchen Auftrag bereits die Rechnung geschrieben, stellt JTL-Wawi jetzt keine zweite Rechnung mehr aus. Es bleibt bei der einen Rechnung aus BIS ERP. Aufträge aus dem BIS Shop und von den Marktplätzen, zu denen BIS ERP schon eine Rechnung geschrieben hat, wurden bisher nicht an JTL-Wawi übergeben. Solange sie in BIS ERP noch offen sind, gehen sie jetzt zum Versand nach JTL-Wawi, ebenfalls ohne zweite Rechnung. Ist ein solcher Auftrag in BIS ERP schon in der Kommissionierung, verpackt, versendet, retourniert oder abgeschlossen, bleibt er in BIS ERP, damit er nicht zweimal geliefert wird. Aufträge ohne Rechnung aus BIS ERP laufen wie bisher: JTL-Wawi stellt die Rechnung.

Kassen-Sync: Hinweis auf Verkäufe aus der Zeit ohne Synchronisation

Eine Lieferantenbestellung gehört zu einem Lager. Das Handgerät prüft jetzt, ob es auf dieses Lager eingestellt ist, bevor es die Ware bucht.

Zwei Auswertungen waren bei Betrieben mit Kauf auf Rechnung zu hoch: Kassen-Rechnungen, die neben einer Rechnung aus JTL-Wawi stehen, galten zusätzlich als offen oder überfällig, und Rückgaben ohne Bezug zum ursprünglichen Kauf ließen die Rechnung in voller Höhe offen.

Versandetiketten: Straße und Hausnummer richtig, Etiketten für DPD, GLS, Hermes und UPS am Packtisch

Werden viele Artikel auf einmal an Ihren BIS Shop übertragen (zum Beispiel nach einer neuen Pflichtangabe), überträgt BIS ERP sie jetzt in kurzen Abschnitten. Bisher konnte eine solche Übertragung andere automatische Abläufe wie den Kassenabgleich mit JTL-Wawi oder die Nachsignierung von Kassenbelegen bis zu einer Stunde aufhalten. Große Übertragungen dauern dadurch insgesamt etwas länger, alle anderen Abläufe laufen währenddessen normal weiter.

Eine Warengruppe wie „ohne Kategorie“ oder „Keine Warengruppe“ erscheint im BIS Shop nicht mehr als eigene Kategorie, weder in der Kategorienleiste noch auf der Startseite oder auf der Produktseite. Die Artikel daraus bleiben verkäuflich und sind über „Alle Produkte“ und die Suche zu finden. Die Änderung greift beim nächsten Abgleich mit Ihrem Shop.

Bisher hing eine Lizenz an der Person, die sie gebucht hatte. Jetzt gehört jede Lizenz Ihrem Betrieb. Wer sie gebucht hat, steht nur noch als Vermerk daran.

Während der täglichen Datensicherung in der Nacht stand der Abgleich mit JTL-Wawi bisher bis zu 30 Minuten still. Aufträge, Bestände und Artikel kamen dann verspätet an. Jetzt läuft der Abgleich auch in dieser Zeit im gewohnten 5-Minuten-Takt weiter.

Haben Sie einem Mitarbeiter in einer eigenen Rolle das Recht „Aufträge ansehen“, „Rechnungen ansehen“ oder „Kunden ansehen“ entzogen, sperrt BIS ERP jetzt auch den direkten Abruf: Auftrags- und Rechnungslisten, einzelne Aufträge und Rechnungen, Rechnungen als PDF/XML (auch über den Druckweg), Auftragsbestätigungen, die Belegauswahl im Rechnungsdesigner, und die Rückmeldungen vom Regal. Vorher blendete BIS ERP diese Daten nur in der Oberfläche aus. Dabei gilt jetzt durchgehend dieselbe Regel wie beim Kundenexport: Für Administratoren ändert sich nichts.

Kassenverkäufe landen in JTL auf der richtigen Zahlart – auch nach Umbenennung

Legen Sie in BIS ERP unter Kasse, Gutscheine einen einzelnen Gutschein an, bekommt er jetzt das Ablaufdatum aus der eingetragenen Gültigkeit, so wie an der Kasse: Bei kurzer Gültigkeit taggenau, ab etwa einem Jahr zum Jahresende, ohne Angabe drei Jahre zum Jahresende. Bisher war ein solcher Gutschein unbegrenzt gültig. Das gilt für Betriebe in Deutschland; bereits ausgestellte Gutscheine bleiben unverändert.

Wir haben den Auftragsverarbeitungsvertrag (BIS ERP Fassung 1.25, BISpicy Kasse Fassung 1.22) und die Datenschutzerklärung aktualisiert.

Schalten Sie bei Scan-to-Order unter Bestellregeln „Nachbestellung erlauben“ aus, nimmt ein Tisch über den QR-Code nur noch eine Bestellung an, solange dort eine Rechnung offen ist. Bestellt ein Gast an diesem Tisch noch einmal über den QR-Code, sieht er sofort den Hinweis, sich an das Personal zu wenden. Weitere Wünsche nimmt dann Ihr Team auf. Nach dem Bezahlen ist der Tisch wieder frei für die nächste QR-Bestellung.

Seit Dezember 2024 verlangt die EU-Produktsicherheitsverordnung (GPSR), dass im Onlineangebot der Hersteller mit Anschrift und E-Mail, bei Herstellern außerhalb der EU die verantwortliche Person in der EU, Angaben zur Produktkennung und die Warnhinweise stehen. Ihr BIS Shop zeigt diese Angaben jetzt unter dem Kaufknopf, aus Ihren Stammdaten in BIS ERP, in der Sprache Ihres Shops.

Kommissionieren: Teilgriffe buchen keine Fehlmenge mehr

Mehr Sicherheit bei den Benutzerrechten: Versandetiketten und Internetmarke

BIS Shop: Die Startseiten-Reihe „Zuletzt eingetroffen“ bleibt nie mehr leer

Liest die KI Zutaten oder Nährwerte aus den Fotoaufträgen, vergleicht BIS ERP die Lesung mit einer zweiten, unabhängigen Lesung. Weichen beide ab, landet der Artikel in der LMIV-Prüfliste. Neu: Dort sehen Sie jetzt die Fotos der Verpackung und beide Lesungen übersichtlich nebeneinander – Zutaten Zeile für Zeile, Allergenhinweise und Nährwerte mit markierten Unterschieden. Mit „Erstlesung so in Artikel und Shop übernehmen“ oder „Zweitlesung so in Artikel und Shop übernehmen“ schreibt BIS ERP die gewählte Lesung unverändert in die noch leeren Zutaten- und Nährwertangaben des Artikels und damit in Ihren Shop; ein gelesener Hinweis wie „Kann Spuren von … enthalten“ kommt in den noch leeren Spurenhinweis. Bereits gepflegte Angaben bleiben unangetastet. Hat die Lesung einen Hinweis, für den es am Artikel kein Feld gibt, nennt BIS ERP ihn, und die Zutaten pflegen Sie von Hand. Auch früher schon freigegebene Lesungen lassen sich so noch übernehmen. Unterscheiden sich die Lesungen bei Allergenen, bestätigen Sie vorher, dass Sie die Allergene am Foto geprüft haben. Verantwortlich für die Angaben bleiben Sie als Lebensmittelunternehmer. Außerdem halten reine Formunterschiede eine Lesung seltener auf: dieselbe E-Nummer in anderer Schreibweise oder Allergenhinweise mit anderem Wortlaut. Pflichthinweise an Zusatzstoffen, eine abweichende Bezugsgröße der Nährwerte und jede abweichende Allergenangabe bleiben weiterhin in der Prüfliste.

Lieferanten am Artikel: Zuordnen klappt, Einkaufspreis, Mindestmenge und Verpackungseinheit stimmen

Wird ein Konto mehr als 30 Tage nicht genutzt, legen wir seine Daten sicher und verschlüsselt ab. Beim nächsten Anmelden stellen wir sie automatisch wieder bereit; das dauert etwa eine Minute, ein Hinweis zeigt, dass es gleich weitergeht. Danach arbeiten Sie wie gewohnt weiter, es geht nichts verloren.

Gibt Ihre Kundschaft an der Kasse einen Teil der Ware zurück und gibt es zu dem Verkauf eine A4-Rechnung, legt BIS ERP ab diesem Update eine Gutschrift über die zurückgenommenen Positionen an. Das gilt für Verkäufe, die an der Kasse bar oder mit Karte bezahlt wurden. Nicht automatisch: Bei einem Kauf auf Rechnung, bei Rechnungen, die JTL-Wawi führt, und bei Rechnungen, zu denen es schon eine Retouren-Gutschrift aus BIS ERP gibt, entsteht keine Gutschrift. Ebenso bei Rückgaben aus der Web-Kasse und bei Rückgaben vor diesem Update. Prüfen Sie diese Fälle bitte wie bisher selbst.

Wichtig vorab: Die Teilrückgabe eines Kaufs auf Rechnung gibt die Kasse nur frei, wenn BIS ERP die Rechnung stellt und mit dem neuen Kassen-Update. Bei Rechnungen, die JTL-Wawi stellt, bleibt die Teilrückgabe an der Kasse gesperrt, auch wenn der JTL-Abgleich vorübergehend pausiert ist. Wird ein Kauf auf Rechnung nur zum Teil zurückgegeben, mindert BIS ERP die Kassen-Rechnung mit einer Teilgutschrift. Bisher blieb die Rechnung in voller Höhe stehen.

Bezahlt ein Kunde einen offenen Auftrag an der Kasse und nimmt die Ware gleich mit, stößt BIS ERP die JTL-Rechnung jetzt erst an, wenn Warenausgang und Lieferschein in JTL angekommen sind. So enthält die Rechnung die mitgenommene Ware und nicht nur Pfand und Versand. Fehlt auf einer Rechnung gelieferte Ware, meldet BIS ERP den Fall automatisch an unseren Support.

Wenn an der Kasse eine offene Rechnung zu einem JTL-Auftrag bezahlt wird, bucht BIS ERP in JTL jetzt nur noch den Betrag, der tatsächlich kassiert wurde (bis auf einen Rundungscent), und ordnet ihn der passenden Rechnung zu. Das gilt auch, wenn zu einem Auftrag mehrere offene Rechnungen gehören: Die bezahlte Rechnung wird über den Betrag erkannt, bei Bedarf zusätzlich über die Positionen; die übrigen bleiben offen. Lässt sich die Rechnung nicht eindeutig bestimmen, bucht BIS ERP höchstens den kassierten Betrag am Auftrag und meldet den Fall im Sync-Protokoll. Ein Auftrag gilt in BIS ERP erst dann als bezahlt, wenn er in JTL nach der Buchung vollständig ausgeglichen ist. Wurde etwas kassiert, aber in JTL nichts gebucht, meldet der Abgleich das jetzt. Rechnungen ohne Auftrag in JTL sind von dieser Änderung nicht betroffen.

Wird ein Bon, der einen offenen Auftrag begleicht, an der Kasse storniert, bucht BIS ERP dafür nichts mehr in JTL: keine Zahlung, keinen Warenausgang, keinen Lieferschein. Wurde der Bon schon übertragen, meldet BIS ERP den Fall mit einer Anleitung für JTL, statt automatisch zurückzubuchen. Zusatzartikel, die zusammen mit „offene Rechnung bezahlen“ verkauft werden, werden in JTL zuverlässig ausgebucht, und der Bon gilt erst als übertragen, wenn beide Teile fertig sind.

Wurde ein JTL-Auftrag in BIS nur teilweise versendet, setzt BIS ihn nicht mehr von sich aus auf „versendet“, nur weil JTL ihn als komplett ausgeliefert führt, ohne dass dort ein eigener Lieferschein dazu steht. Die Restmenge bleibt am Packtisch offen, die Zahlung wird weiter nachgezogen, und im Sync-Protokoll erscheint einmal am Tag ein Hinweis, den Auftrag in JTL zu prüfen. Hat das Büro in JTL den Rest per Gutschrift oder „ohne Versand abschließen“ erledigt, übernimmt BIS das wie bisher. Dasselbe gilt für Aufträge, die BIS selbst an JTL übergeben hat; dort steht der Hinweis einmal im Auftragsverlauf.

Wenn Sie einen JTL-Auftrag über den Packtisch versenden, bucht BIS ERP den Warenausgang jetzt im Lager des Auftrags und weist nach, dass die Ware in JTL wirklich abgebucht ist. Ist Ware in JTL durch eine Pickliste reserviert oder liegt sie in einem anderen Lager, erscheint ein klarer Hinweis, statt dass der Bestand unbemerkt stehen bleibt. Lieferschein und Rechnung entstehen wie gewohnt.

Hotels mit Restaurant können an der Kasse „Auf Zimmer buchen“. Voraussetzung ist, dass Restaurant und Hotel zum selben Unternehmen gehören. BIS ERP übernimmt diese Zimmerbuchungen passend dazu:

Verkaufen Sie an der Kasse steuerfrei an einen Firmenkunden in einem anderen EU-Land (innergemeinschaftliche Lieferung), zeigt der digitale Bon jetzt wie der Papierbon den Pflichthinweis zur Steuerbefreiung und die USt-IdNr. Ihres Kunden. Das gilt für Bons aus der nächsten Kassenversion.

Ändern Sie die Kurz- oder Langbeschreibung eines Artikels in BIS ERP (von Hand oder mit der Übernahme aus dem KI-Fotoauftrag), schreibt BIS ERP den neuen Text in die deutsche Standardbeschreibung des Artikels in JTL-Wawi. Der nächste Abgleich setzt Ihre Änderung nicht mehr auf den alten JTL-Text zurück.

Mehr Sicherheit bei den Benutzerrechten: Versanddienstleister und Einzelstücke

Die KI-Auswertung der Fotoaufträge schickt einen Artikel nicht mehr allein wegen der Allergene zurück in die Lager-App, wenn sie das Zutatenverzeichnis sicher gelesen hat. Bisher gingen vor allem Getränke ohne Allergene immer wieder zum Nachfotografieren, obwohl ein neues Foto nichts ändern konnte. Der Hinweis zu den Allergenen bleibt im Befund für Ihre Prüfung sichtbar.

Wenn Sie Ihren Shopify-Shop über BISLink verbinden, richtet BIS ERP den Bestellimport jetzt selbst ein. Sie müssen die Webhooks nicht mehr von Hand anlegen.

Unter Einstellungen → Datensicherung setzen Sie mit „Wiederherstellen“ den Datenbestand Ihres Betriebs auf den Stand einer Sicherung zurück. Das geht jetzt nur noch nachvollziehbar: Sie nennen einen Grund, und BIS ERP hält fest, wer wann zurückgesichert hat.

### BIS ERP

Ändern Sie an einem offenen JTL-Auftrag in BIS ERP Positionen, Mengen oder Preise, überschreibt der automatische Abgleich mit JTL diese Änderung nicht mehr nach wenigen Minuten.

Druckeinstellungen: „Label-Format“ wirkt jetzt, ZPL-Labels lassen sich nicht mehr als kaputte PDF herunterladen

Die DIN-A4-Rechnung, die BIS ERP zu einem Kassenbon erstellt, weist die Umsatzsteuer jetzt nach derselben Regel aus wie der Bon: je Steuersatz aus der Summe der Bruttobeträge. Bisher konnte sie bei mehreren Positionen mit gleichem Steuersatz um einen oder wenige Cent vom Bon abweichen.

Die Seite, auf der Ihre Kundschaft den Stand ihrer Reparatur verfolgt, und die Status-E-Mails nennen jetzt Ihre Anbieterangaben.

Ändern Sie an einem offenen JTL-Auftrag in BIS ERP Positionen, Mengen oder Preise, überschreibt der automatische Abgleich mit JTL diese Änderung nicht mehr nach wenigen Minuten.

Wird in JTL ein Auftrag gelöscht, blieb er in BIS ERP bisher offen und packbar. Jetzt erkennt der Abgleich das: Ein offener, noch nicht bezahlter Auftrag ohne Rechnung, Lieferschein und Sendung wird in BIS ERP automatisch storniert (gelöscht wird nie). Aufträge, die bezahlt oder teilbezahlt sind, einen Beleg haben, in Arbeit sind, deren Ware schon auf dem Pickwagen liegt oder mit einer wartenden Änderung erscheinen unter „Aufträge → Abgleich prüfen“ mit der Kennzeichnung „In JTL gelöscht“; dort entscheiden Sie: „In BIS stornieren“ (nur wenn nichts davon zutrifft) oder „BIS behalten“.

Ist für eine JTL-Rechnung in BIS ERP nicht eindeutig, zu welchem Auftrag sie gehört (mehrere Aufträge mit derselben JTL-Auftragsnummer), wird sie nicht mehr automatisch zugeordnet, sondern im Protokoll gemeldet und kann geprüft werden. Ältere Rechnungen außerhalb des Abgleichfensters werden auf Wunsch einmalig nachgetragen; dabei werden solche mehrdeutigen Fälle nur aufgelistet.

Kassenrechnung (A4): Storno korrekt erkannt, keine Rechnung zu Rückgabe-Bons

Einstellungen durchsuchen

Einstellungen neu geordnet

Der Hinweis zu Cookies und Einwilligung in Ihrem BIS Shop erscheint jetzt in der Sprache, in der Ihre Kunden den Shop besuchen – in den 24 Amtssprachen der EU, sonst auf Englisch. Bisher stand er in jeder Sprache auf Deutsch.

Artikelliste: „Alle Artikel auswählen“ – keine stillen Teilwirkungen mehr

Lieferschein: keine doppelten Fehlmengen-Zeilen mehr

Kassen-Steuerberichte: verständliche Meldung, wenn der PDF- oder CSV-Download nicht klappt

Lager-App: Handhelds zeigen wieder „online“ und ihre letzte Verbindung

Artikelliste: „Alle Artikel auswählen“ hält, was die Anzeige verspricht

Kundenakte: Änderungen an Rechnungs-E-Mail, Beleg-CC und Beleg-BCC sind nachvollziehbar

Storniert die Kasse einen Bon, zu dem es in BIS ERP eine DIN-A4-Rechnung mit bereits ausgestellter Retouren-Gutschrift gibt, bleibt die Rechnung zum Schutz vor doppelter Minderung gültig. Das sehen Sie jetzt als Hinweis in der Glocke: mit Rechnungsnummer, Bonnummer, der Gutschrift und dem Weg zur Klärung (erst die Gutschrift stornieren, dann die Rechnung). Ein erneuter Storno derselben Rechnung aktualisiert den Hinweis, statt einen zweiten anzulegen.

Die automatische Lieferschein-Mail an Ihre Kunden enthält jetzt den Lieferschein als PDF-Anhang, benannt nach Datum und Lieferscheinnummer (zum Beispiel „Lieferschein_2026-11-04_LS-2026-0001.pdf“). Bisher kam nur der Mailtext an.

Bei vielen Konten brachen im Einkauf einige Funktionen mit einem Fehler ab. Betroffen waren „Niedrigbestand“ in der Einkaufsliste und im Beschaffungsbedarf, die Lagerbewertung sowie die ABC- und Umschlagsanalyse. Sie laufen jetzt wieder.

Aufträge: Statuswechsel und Speichern zuverlässiger, Aufträge nur noch mit Berechtigung sichtbar

Das Menü links ist neu aufgebaut und sieht in BIS ERP und im Kundencenter gleich aus:

Retouren, die aus JTL-Wawi übernommen wurden, werden dort samt Gutschrift und Wareneingang geführt. In BIS ERP lassen sie sich deshalb nicht mehr gutschreiben, erstatten, einlagern oder annehmen. In BIS ERP steht stattdessen der Hinweis „Wird in JTL-Wawi geführt“; die Lager-App zeigt beim Scannen einer solchen Retoure denselben Hinweis als Meldung. Bitte legen Sie die Gutschrift und die Einlagerung in JTL-Wawi an. So entsteht keine doppelte Gutschrift mehr. Ältere Retouren, deren Herkunft noch geprüft wird, sind bis zum Abschluss der Prüfung ebenfalls gesperrt. Retouren, die Sie in BIS ERP selbst angelegt haben, funktionieren unverändert.

Wird ein Artikel ohne eigenen Steuersatz angelegt, zum Beispiel über die KI-Artikelanlage, und ist für das Land Ihres Betriebs kein Umsatzsteuersatz hinterlegt (etwa Thailand), legt BIS ERP den Artikel nicht mehr mit 19 % an. Stattdessen erscheint der Hinweis, den Steuersatz anzugeben.

Herkunftsländer erscheinen im Onlineshop nur noch, wenn mindestens ein sichtbarer Artikel aus diesem Land angeboten wird. Ein Land, dessen Artikel alle ausgeblendet sind (zum Beispiel weil ihre Warengruppe nicht im Onlineshop gezeigt wird), verschwindet bei der nächsten Übertragung aus Menü, Kacheln und Länderseite und kommt von selbst wieder, sobald ein Artikel dafür sichtbar wird.

Die Kurzbeschreibung eines Artikels wird jetzt vollständig in den BIS Shop übertragen und nicht mehr nach 255 Zeichen mitten im Wort abgeschnitten. Sie steht im Shop direkt vor dem Bestellknopf. Ein Hinweis am Feld Kurzbeschreibung in der Artikelmaske erinnert daran, dort die wesentlichen Eigenschaften einzutragen (z. B. Material, Maße, Füllmenge). Bereits übertragene Artikel werden nach dem Update einmal automatisch neu übertragen und zeigen dann den vollständigen Text.

Rechnung festschreiben: Rechnungsdatum und Zahlungsreferenz stimmen

In Aufträgen und Rechnungen aus BIS ERP und im BIS Shop trägt Pfand bereits den Steuersatz der Ware. Jetzt können auch Kasse und Web-Kasse so rechnen: Pfand auf eine Milchflasche mit 7 % trägt 7 %, Pfand auf Wasser 19 %.

Ankaufspreis differenzbesteuerter Geräte bleibt beim Wareneingang erhalten

Differenzbesteuerte Artikel aus Marktplatz-Bestellungen richtig übernommen

Die Detailseite eines Artikels ist neu geordnet:

KI-Fotoauftrag: Importeur zurück an die Lager-App, weniger unnötige Nachfotos, Beschreibungen aus dem Foto

Kassenrechnung (A4): keine zweite Rechnung zu einem stornierten Kauf

Die Web-Kasse berechnet das Pfand für Laufkundschaft jetzt immer nach der Standard-Kundengruppe, genau wie die Kasse auf dem Tablet. Stellen Sie Ihre Standard-Kundengruppe zum Beispiel von Händler auf Privatkunde um, rechnet die Web-Kasse sofort mit dem gesetzlichen Pfandbetrag. Bisher geschah das erst, nachdem jemand die JTL-Einstellungen geöffnet und übernommen hatte; bis dahin wurde auf das Pfand weiter Mehrwertsteuer aufgeschlagen.

Erstellen Sie an der Kasse eine A4-Rechnung zu einem Verkauf, den der Kunde bar oder mit Karte bezahlt hat, steht diese Rechnung in BIS ERP jetzt sofort auf „Bezahlt“. Bisher blieb sie offen: Die Kundenakte zeigte sie als offenen Posten, die Kachel „Ausstehend“ zählte sie mit, und manche Rechnung wurde sogar „Überfällig“.

Österreich: 4,9 % für Grundnahrungsmittel, genauer Steuersatz auf Rechnungen

Arbeiten Ihre Geschäftskunden mit Microsoft 365, melden sich deren Mitarbeiter im Einkaufsportal jetzt mit ihrem Geschäfts-, Schul- oder Unikonto von Microsoft an – ohne Code per E-Mail:

Das Guthaben für die KI-Auswertung (Artikel aus Fotos, Rechnungen, KI-Aufträge) gehört jetzt dem ganzen Betrieb. Jede Auswertung wird vom Firmenguthaben beim Inhaber abgebucht, egal welcher Mitarbeiter sie startet. Mitarbeiter ohne eigenes Guthaben können also auswerten, solange die Firma Guthaben hat. In der Guthaben-Übersicht sieht der Inhaber, wer die Auswertung ausgelöst hat. Auch gekauftes Guthaben gehört der Firma: Kauft ein Benutzer mit Adminrechten Guthaben, wird es dem Firmenguthaben gutgeschrieben, nicht seinem eigenen Konto. Den Betrag sehen nur der Inhaber und Benutzer mit dem Recht „Einstellungen bearbeiten“. Alle anderen sehen im Kopf von BIS ERP keinen Betrag. Nach einer Auswertung steht bei ihnen nur „Auswertung ausgeführt“. Reicht das Guthaben nicht, lautet der Hinweis „Firmenguthaben reicht nicht – bitte an den Inhaber wenden“. Fotos, die für eine Auswertung zwischengespeichert wurden, werden nach der Auswertung gelöscht, spätestens nach 14 Tagen.

Kundencenter: Personen und Zugänge an einer Stelle

Für den Kontenrahmen SKR04 liegen die Vorgabekonten jetzt auf freien DATEV-Konten, und die Kasse übernimmt die DATEV-Nummern aus BIS ERP.

Retouren: abgelehnte Ware kommt nicht mehr zurück in den Bestand

Eine DIN-A4-Rechnung zu einem Verkauf an einer österreichischen Kasse trägt jetzt die Angaben der Registrierkasse statt des deutschen TSE-Hinweises.

Aktivitätsprotokoll: Einträge bleiben 12 Monate erhalten

In den Datenschutzerklärungen von bispicy.com und bispos.app steht jetzt genauer, wie Sie Ihre Rechte ausüben:

Im Packtisch im Browser und in der Lager-App standen Kommissionierlisten stornierter Aufträge weiter als „offen“ oder „bereit zum Verpacken“. Diese Listen werden jetzt nicht mehr angezeigt. Bei einer Sammelliste zählen stornierte Aufträge nicht mehr mit; eine Liste, deren Aufträge alle storniert sind, verschwindet. Fertig gesammelte Listen offener Aufträge bleiben wie bisher sichtbar.

Profil: Anmeldung mit Google-Konto bekommt „E-Mail & Passwort einrichten“

Ist eine Lizenz vorübergehend gesperrt (zum Beispiel wegen einer offenen Zahlung), zählt das Konto für die automatische Aufräumung jetzt wie ein Konto mit aktiver Lizenz: Es bekommt keine Inaktivitäts-Erinnerungen und wird nicht gelöscht. Eine bereits laufende Erinnerungskette für ein solches Konto wird beendet.

In einigen Betrieben, die BIS ERP bisher vor allem mit der Kasse und noch nie für Ausgangsrechnungen genutzt haben, konnten Auswertungen über Rechnungen (zum Beispiel EÜR, BWA oder Umsatzsteuer-Voranmeldung) mit einem Fehler abbrechen. BIS ERP richtet den Rechnungsbereich in diesen Betrieben jetzt automatisch im Hintergrund ein, genau so, wie es beim ersten Öffnen der Rechnungen geschieht. Danach lassen sich diese Berichte dort wie gewohnt abrufen.

In manchen Betrieben brach das Speichern eigener Rechte für einen Benutzer (Benutzerverwaltung → Rechte anpassen) mit einem Serverfehler ab, und die bisherigen eigenen Rechte konnten dabei verloren gehen. Das Speichern funktioniert jetzt überall; schlägt es doch einmal fehl, bleiben die bisherigen Rechte unverändert erhalten.

Das Bezahldatum und das Versanddatum der Aufträge aus JTL-Wawi kommen jetzt auch bei neuen Aufträgen sauber an und stehen im Auftragsexport (Spalten „Bezahlt am“ und „Versanddatum“, in der Zeit Ihres Betriebs), im Kundencenter („versendet am“) und in den Kennzahlen zur Versanddauer und zum pünktlichen Versand. Das Bezahldatum übernimmt BIS ERP aus JTL (Tag, an dem der Auftrag voll bezahlt war; Nullbetrags- und Minusaufträge bekommen keins). Als Versanddatum gilt immer der erste Versand, auch bei Aufträgen mit mehreren Lieferscheinen und auch ohne Sendungsnummer (Abholung, Spedition); bisher konnte das Datum je nach Abgleich wechseln oder fehlen. Aufträge, die an der Kasse bezahlt werden, tragen ab jetzt die Uhrzeit des Bons als Bezahldatum. Ältere Aufträge werden in einem eigenen, von Ihnen freigegebenen Schritt nachgetragen, vorhandene Daten werden dabei nie überschrieben. Danach werden Durchlaufzeit und pünktlicher Versand in den Auswertungen für vergangene Zeiträume rückwirkend genauer.

Den Beginn der Debitorenkonten können Sie in den DATEV-Einstellungen nur noch im Bereich der Personenkonten (10000 bis 69999) speichern. Ein Wert wie 1400 (Sachkonto) oder 70000 (Kreditorenbereich) wird sofort mit einem Hinweis abgelehnt, statt gespeichert zu werden und danach jede DATEV-Vorschau und jeden Export mit einem Serverfehler zu blockieren. Stimmt ein schon gespeicherter Wert nicht, nennen Vorschau und Export jetzt verständlich, was zu korrigieren ist.

Sie können eine EAN jetzt von 13 auf 14 Stellen (mit führender 0, zum Beispiel für den Umkarton) oder zurück umstellen, ohne dass BIS ERP die eigene Zeile als „bereits hinterlegt“ ablehnt. Das gilt für die weiteren EANs am Artikel und für Gebinde-EANs in der Lager-App; mit JTL-Wawi verbunden geht die neue Schreibweise auch dorthin. Dieselbe Nummer an einer anderen Zeile oder einem anderen Artikel bleibt weiterhin gesperrt.

In der Kundenakte, auf Belegen, Etiketten, im Kunden-Export und im Kundencenter gilt jetzt die Anschrift, die im Kundenstamm hinterlegt ist, und die wird bei JTL-Kunden mit JTL abgeglichen. Bisher konnte eine ältere, in der Maske eingegebene Anschrift die neuere aus JTL verdecken. Die Rechnungsanschrift von Kunden, die aus JTL-Wawi kommen, wird in JTL-Wawi gepflegt: In BIS ERP ist sie dann schreibgeschützt (Hinweis am Feld), der Abgleich übernimmt Änderungen aus JTL. Die Lieferanschrift und alle anderen Kundendaten bleiben in BIS ERP bearbeitbar. Außerdem tragen Gutschriften aus einer Retoure jetzt die Anschrift des Kunden, und in BIS ERP neu angelegte Kunden gehen mit ihrer Anschrift nach JTL.

An der Web-Kasse findet die Kundensuche einen Kunden jetzt auch über seine E-Mail-Adresse; bisher blieb die Liste dabei oft leer. Die Trefferliste enthält nur noch, was zum Erkennen und Zuordnen nötig ist: Name, Firma, Kundennummer, E-Mail und Telefon. Anschriften, USt-IdNr. und Kundengruppe gehen nicht mehr an die Kasse; der Verkauf übernimmt sie wie bisher direkt aus dem Kundenstamm. Wer an der Kasse Kontaktdaten sehen darf, richtet sich nach denselben Rechten wie die Kunden-Seite der Web-Kasse.

Die Auftragsliste zählt Kassenbons über mehrere Tage jetzt genauso wie die Kachel im Dashboard: je Tag und Bonnummer. Außerdem lassen sich doppelt angelegte Kassenaufträge aus einer früheren Sync-Wiederholung bereinigen; sie erscheinen danach als „storniert“ mit dem Hinweis auf den Originalauftrag, Bons, Bestände und Rechnungen bleiben unverändert.

Schnellversand: Bestand stimmt sofort, Storno bucht zuverlässig zurück

Haben Sie Artikel, die nur in BIS ERP angelegt sind und nicht in JTL-Wawi, und buchen Sie deren Bestand in ein Lager, das mit JTL verbunden ist? Dann hat der Bestandsabgleich mit JTL diesen Bestand bisher beim nächsten Lauf wieder auf null gesetzt. Jetzt bleibt er stehen. Für Artikel, die JTL kennt, ändert sich nichts: Ihr Bestand kommt weiterhin aus JTL.

Wird ein JTL-Auftrag in mehreren Lieferungen versendet, entsteht in JTL für jede Lieferung ein eigener Lieferschein mit genau den versendeten Positionen. Pfand und Freipositionen stehen dabei genau einmal auf einem Lieferschein, und JTL rechnet den Liefer- und Offenstand des Auftrags danach selbst nach. Wiederholt BIS ERP eine Übertragung, entsteht kein zweiter Lieferschein und keine doppelte Position.

Kommissionierung: genauere Buchung beim Picken und richtiger verfügbarer Bestand

BIS Shop: Amazon Pay als eigene Zahlart

Die Umsatzübersicht unter Berichte zählt Rechnungen, deren Umsatz schon im Auftrag steckt, nur noch einmal. Aufträge, die in JTL-Wawi sofort ausgeliefert und berechnet werden, erscheinen jetzt auch in BIS ERP.

Die Suche „Offene Rechnung bezahlen“ an der Kasse bietet auch mit „Auch bezahlte anzeigen“ nur noch Belege an, die sich wirklich kassieren lassen.

Rechnungen, die BIS ERP zu Aufträgen mitschreibt, die JTL-Wawi berechnet, zählen nirgends mehr als offen oder überfällig und werden nie an Kunden versendet.

Ist die Verbindung zu JTL unterbrochen (kein BISConnect-Rechner online), fragt BIS ERP jetzt vor jedem Versand eines Auftrags, der in JTL geführt wird, nach – nicht mehr nur am Packtisch, sondern auch beim Schnellversand (einzeln und als Sammelversand), beim Direktversand aus der Pickliste, bei „Erneut versuchen“ in der Versandübersicht und beim Kauf einer Internetmarke. Die Rückfrage kommt, bevor ein Etikett gekauft oder Bestand gebucht wird: Abbrechen lässt alles unverändert, „Trotzdem versenden“ versendet und vermerkt es im Auftragsverlauf. Im Sammelversand fragt BIS ERP nur einmal für den ganzen Lauf. So geht ein Auftrag nicht versehentlich doppelt raus, weil er zur selben Zeit auch in JTL versendet wird. Aufträge von Marktplätzen, die nicht an JTL übergeben werden, lösen die Rückfrage nicht mehr aus.

Beim Schnellversand mit DHL stand die Sendung zwar auf „versendet“, aber Sendungsnummer und gekauftes Etikett fehlten an der Sendung – das Etikett wurde nicht automatisch gedruckt, und die Sendungsverfolgung fehlte. Jetzt speichert BIS ERP beides wie bei den anderen Versandwegen, und der automatische Etikettendruck funktioniert. Liefert DHL ein gekauftes Etikett nicht lesbar zurück, bietet die Versandübersicht wie gewohnt „Etikett nachladen“ an, statt dass ein zweites gekauft wird.

Verfahrensdokumentation Kasse: zweite TSE-Signatur nach dem Einspielen einer Sicherung

Kundencenter: Herkunftsangabe selbst einsehen und löschen

Wurde ein Auftrag erst per Pickliste auf einen Kommissionierwagen gesammelt und danach am Packtisch (Lager-App oder Browser) gescannt, buchte BIS ERP die Ware ein zweites Mal vom Regalplatz auf den Packplatz. Der Regalbestand sank dadurch doppelt, und nach dem Versand blieb auf dem Packplatz eine reservierte Restmenge stehen. Jetzt erkennt BIS ERP gepickte Positionen: Der Scan zählt die Ware für das Packstück, bucht aber nichts mehr vom Regal, und auch das Zurücklegen eines solchen Scans verändert den Bestand nicht. Betriebe ohne Lagerplatzverwaltung sind nicht betroffen.

Hatte eine Rolle das Recht zum Kommissionieren, aber nicht das Recht für Sammellisten, blieb die Liste in der Lager-App unter „Kommissionieren“ leer („Kommissionierlisten konnten nicht geladen werden (HTTP 403)“ bzw. „Gerade ist nichts offen“) – auch die erlaubten Picklisten fehlten. Jetzt erscheinen die Listen, die die Rolle sehen darf; eine Fehlermeldung kommt nur noch, wenn beide Rechte fehlen. Da neue Kommissionierlisten als Sammelliste angelegt werden, braucht die Rolle zum Arbeiten mit ihnen weiterhin auch das Recht „Sammellisten“ in der Rollenverwaltung.

Guthaben aufladen: Rechnung mit Umsatzsteuer direkt beim Bezahlen

Neu unter Artikel → Fotoaufträge: Mit dem Schalter „KI-Auswertung einstellen“ lassen Sie neu eingereichte Fotos automatisch von der KI lesen. Die Kosten (Preis je Auswertung steht in der Einstellung) werden vom Guthaben des Benutzers abgebucht, der den Schalter einschaltet; ohne Guthaben pausiert die Auswertung und Sie bekommen eine Meldung.

JTL-Stücklisten: Sets werden nur noch vollständig übernommen

Lädt eine Kasse ihre Verkaufshistorie nachträglich an BIS ERP hoch (zum Beispiel nach dem Buchen von BIS Remote), tragen die Belege jetzt ihre Belegnummer und Stornos werden als Storno erkannt – auch bei Kassen mit älterer App-Version. Mit der neuen Kassen-App gehen außerdem der Bezug zum stornierten Original-Bon und die TSE-Signatur mit. So finden die Belegsuche und der Bonnummern-Bericht nachgelieferte Belege, und Auswertungen zählen Stornos richtig. Das gilt für Belege, die ab jetzt hochgeladen werden. Außerdem führt der Bonnummern-Bericht ältere Belege einer Kasse, die noch die frühere Gerätekennung tragen, mit den übrigen Belegen dieser Kasse zusammen – in der Gesamtansicht wie in der Ansicht je Kasse – und meldet dort keine Scheinlücken mehr.

Rechnungen, die über Stripe abgerechnet werden, tragen im DATEV-Buchungsstapel jetzt zusätzlich die Rechnungsnummer aus dem Stripe-PDF (Beleginfo „Stripe-Rechnungsnr.“). So findet Ihre Steuerkanzlei die Buchung auch vom Stripe-Beleg aus. Belegnummer (die Rechnungsnummer aus BIS ERP) und Buchungstext bleiben unverändert.

In der Retourenübersicht von BIS ERP zeigt der Knopf „Nur Widerrufe“ jetzt wirklich nur die Retouren aus einem Widerruf. Bisher erschienen dabei weiterhin alle Retouren. Seitenzahl und Gesamtzahl passen zur gefilterten Liste.

Wenn die Bank eine Lastschrift zurückgibt, erkennt BIS ERP das jetzt selbst: Die Rechnung ist wieder offen und kann gemahnt werden, ohne dass Sie Zahlungen von Hand korrigieren müssen.

KI-Artikelanreicherung: „Mit KI analysieren“ berücksichtigt Ihre Zusatzangaben wieder

KI-Artikelanreicherung: „Mit KI analysieren“ berücksichtigt Ihre Zusatzangaben wieder

BIS Shop: Klarna als eigene Zahlart und Versand bei reservierter Zahlung

Im Reiter **Organisation** eines Kunden mit untergeordneten Kunden sehen Sie jetzt die **Kennzahlen des ganzen Kreises**: Umsatz netto und brutto, Anzahl der Aufträge, letzte Bestellung und offene Posten – zusammen für den Träger und alle Einrichtungen sowie je Einrichtung, für einen frei wählbaren Zeitraum. Jeder Auftrag zählt genau einmal, auch wenn zwei Einrichtungen dieselbe E-Mail-Adresse tragen. Mit dem Recht „Kunden exportieren“ laden Sie die Tabelle als CSV herunter.

Workflows in BIS ERP (Einstellungen → Automatisierung) legen Rechnungen an, senden E-Mails und rufen Webhooks auf. Wer sie anlegen oder ändern darf, regeln jetzt die Benutzerrechte. Außerdem laufen Workflows jetzt für jeden neuen Auftrag zuverlässig an.

BIS ERP und Kundencenter: freiwillige Frage „Wie sind Sie auf uns aufmerksam geworden?“ bei der Registrierung

Bei Betrieben mit sehr großem Sortiment (über 10.000 Artikel an einer Kasse) gleichen sich Kasse und BIS ERP jetzt deutlich schneller ab, auch beim Übertragen von Verkäufen.

Fügen Sie einer neuen Rechnung oder Proforma einen Artikel hinzu, setzt BIS ERP jetzt den Nettopreis ein – wie im Auftrag und im Angebot. Bisher wurde der Bruttopreis des Artikels als Nettopreis übernommen, sodass die Position um die Umsatzsteuer zu teuer war, wenn Sie den Preis nicht von Hand korrigiert haben.

Verkaufen Sie an der Kasse an einen Geschäftskunden aus einem anderen EU-Land, kann der Beleg als steuerfreie innergemeinschaftliche Lieferung gelten. BIS ERP prüft dieses Kennzeichen jetzt selbst: Die USt-IdNr. des Kunden muss aus einem anderen EU-Land als Ihrem Firmensitz stammen und formal gültig sein. Eine deutsche Nummer bei einem deutschen Betrieb, ein Platzhalter wie „BEANTRAGT“ oder eine fehlende Nummer reichen nicht. Trifft das zu, versteuern der DATEV-Kassenexport und das Buchungsjournal den Verkauf normal und zeigen dazu einen Hinweis mit dem Grund; die A4-Rechnung zum Kassenbeleg weist die Umsatzsteuer dann ebenfalls normal aus, mit dem Steuersatz des Artikels. Ein Storno wird dabei mit der USt-IdNr. des ursprünglichen Verkaufs geprüft. Bitte prüfen Sie in diesem Fall die USt-IdNr. im Kundenstamm und das Land Ihres Betriebs in den Firmendaten.

Auf der Druckansicht einer Pickliste ließ sich „Pickliste starten“ bisher auch bei einer abgeschlossenen Liste klicken. Die Liste stand danach wieder auf „in Arbeit“, der Startzeitpunkt wurde überschrieben, und beim nächsten Abschluss konnte die Reservierung anderer Aufträge zu niedrig werden. Jetzt startet der Knopf nur noch eine offene Pickliste. Bei einer laufenden, abgeschlossenen, versendeten oder stornierten Liste ist er ausgegraut, und ein Hinweis daneben nennt den Grund.

Einkaufsportal: Reklamation aus dem Vorbehalt bei der Lieferung, eigener Rügehinweis

BIS ERP bewahrt die Angaben zum Verkäufer beim Geräte-Ankauf jetzt nach festen Fristen auf und entfernt sie danach selbst. Im Ausweisdaten-Dialog sehen Sie, wann was entfernt wird, und können Ausweisdaten auf Wunsch des Verkäufers sofort entfernen.

Das Kunden- und Einkaufsportal Ihres Betriebs heißt künftig **portal.bispicy.com** (dahinter wie bisher die Adresse Ihres Betriebs) statt kunden.bispicy.com. Der neue Name ist auch für internationale Kunden verständlich und gilt für Endkunden wie für Geschäftskunden im Einkaufsportal.

BIS ERP: Gutschrift aus einer Retoure auch bei Monats-Sammelrechnung, Budget der Kostenstelle sinkt

Ist bei einer Einrichtung das Erbe eingeschaltet (Kundenakte, Reiter „Organisation“), gilt jetzt auch: Ohne eingeschaltetes Erbe ändert sich nichts.

Wurde Ihr Betrieb vor dem 06.09.2026 angelegt, sind Marktplatz-Aufträge und Sendungsverfolgung für Sie dauerhaft kostenlos. Die Nutzungsübersicht im Kundencenter hat dafür bisher trotzdem einen Betrag angezeigt, obwohl er nie berechnet wurde. Jetzt steht dort kein Nutzungsbetrag mehr, sondern der Hinweis, dass Ihr Betrieb die bisherigen Konditionen behält; eine gebuchte Auftrags-Pauschale wird weiter als eigenes Abo ausgewiesen. Die Mengen sehen Sie weiterhin.

Wenn Sie in BIS ERP bei einem Gebinde (z. B. „Karton 12“) im Preisdialog alle Preise entfernen und speichern, verkauft die Kasse das Gebinde ab sofort zum Stückpreis × Menge. Kundengruppen- und Staffelpreise greifen dabei wie beim Einzelstück. Bisher konnte der alte Gebindepreis an der Kasse stehen bleiben.

Beim Hochladen eines eigenen Shop-Layouts prüft BIS jetzt, ob eine eingebundene Produktliste die geschützte Standard-Liste von BIS verwendet. Ein Layout, das die Liste ohne diese Vorlage einbindet, wird mit einer verständlichen Meldung abgewiesen, statt dass später ein Artikel ohne Preis die ganze Seite lahmlegt. Mitgelieferte und bereits hochgeladene Layouts sind nicht betroffen.

Beim Hochladen eines eigenen Shop-Layouts prüft BIS jetzt auch die Vorlagen des Warenkorbs (Summenbox) und der Kassen-Seitenleiste. Fehlt dort ein Pflichtbaustein, etwa der Hinweis auf die gesetzliche Gewährleistung, wird der Upload mit einer verständlichen Meldung abgewiesen, statt dass der Hinweis unbemerkt von der Seite verschwindet. Mitgelieferte Layouts sind nicht betroffen.

Ist in der Shopify-Anbindung der automatische Abgleich eingeschaltet, überträgt BIS ERP neue und freigegebene Artikel nur noch vom Server aus, alle zwei Minuten, auch nachts und am Wochenende, wenn niemand angemeldet ist. Geöffnete Browserfenster stoßen keinen eigenen Abgleich mehr an.

Meldet sich ein Programm oder ein Browser ohne gespeichertes Geräte-Cookie wiederholt an, belegt es jetzt nur noch einen Platz Ihrer Benutzer-Lizenzen statt bei jeder Anmeldung einen neuen.

Ihr Online-Shop lädt Skripte von Zahlungsdiensten jetzt nur noch im Bestellabschluss und nur, wenn Sie den jeweiligen Zahlungsdienst eingerichtet haben. Besucher, die nur stöbern, rufen dabei keinen Zahlungsdienst mehr im Hintergrund auf.

Die DATEV-Dateien aus BIS ERP und dem Kundencenter tragen jetzt alle dieselbe Erzeugungszeit in Ihrer Ortszeit.

Wird ein Artikel-Import unterbrochen, etwa durch ein Update von BIS ERP während des Imports, setzt er an derselben Stelle wieder an. Bisher galten Artikel, die gerade neu angelegt worden waren, beim Wiederaufsetzen als „existiert bereits“: Ihr Anfangsbestand blieb 0, Varianten und weitere EANs fehlten ohne Meldung. Jetzt erkennt der Import seine eigenen Neuanlagen und bucht Bestand, Varianten und EANs nach – den Bestand trotzdem nur einmal.

Shop-Bestellungen mit Gutschein oder Aktion erscheinen in BIS ERP mit den richtigen Positionspreisen und der richtigen Mehrwertsteuer, und die bestellte Ware wird sofort als zugesagt gezählt. Kaufabbrüche werden nur noch dem richtigen Kunden zugeordnet: nicht mehr einfach dem ältesten Kunden mit derselben E-Mail-Adresse. Deshalb erscheinen liegengelassene Warenkörbe in der Anrufliste nur noch bei Kunden, die schon einmal im Shop bestellt haben.

Die Maske Einstellungen → Artikel → Modifikatoren erscheint jetzt in der eingestellten Sprache: Überschrift, Erklärtexte, Tabelle, die Dialoge zum Anlegen, Bearbeiten und Zuordnen sowie die Erfolgsmeldungen. Bisher blieb der Inhalt im Englisch- und Thai-Modus deutsch.

Varianten: feste Frage-Reihenfolge beim Import, Mengen mit Einheit richtig sortiert

Rückläufer: neue Sendungsnummer bei eBay und Amazon

Gibt ein Kunde an der Kasse die gesamte Ware eines Bons mit DIN-A4-Rechnung im Umtausch zurück und nimmt dafür etwas Neues, storniert BIS ERP die Rechnung jetzt automatisch per Gutschrift. Bisher blieb sie in diesem Fall stehen und konnte gemahnt werden.

Nach jedem vollständigen Bestandsabgleich mit dem JTL-Fulfillment-Network steht im Reiter „Protokoll“ jetzt eine Zeile mit dem gemeldeten Bestand je Lager: wie viele Artikel und Stück der Dienstleister dort führt und wie viel davon zu Artikeln gehört, die in BIS ERP noch nicht zugeordnet sind. Ein verknüpftes Lager, für das der Dienstleister nichts meldet, erscheint ausdrücklich mit 0 Stück. So sehen Sie auf einen Blick, ob ein Lager wirklich leer ist oder ob dort Ware liegt, die erst über die Bestandsaufnahme übernommen werden muss.

Der Probelauf zur Umstellung der Rechnungen auf BIS ERP schätzt jetzt genauso streng wie der echte Bankabgleich, ob eine Zahlung automatisch zugeordnet würde. Es zählt nur ein Zahlungseingang mit gleichem Betrag, der die Rechnungs- oder Auftragsnummer exakt nennt oder ohne Nummer von der eindeutigen IBAN des Kunden kommt. Bisher galt schon ein gleicher Betrag oder eine ähnliche Nummer als Treffer, sodass der Probelauf mehr automatische Zuordnungen versprach, als es später gab.

Die Pfand-Angaben in BIS ERP nennen jetzt das geltende Recht, denn das Verpackungsgesetz ist seit dem 12.08.2026 durch das Verpackungsrecht-Durchführungsgesetz (VerpackDG) abgelöst. In der Massenänderung und beim Duplizieren eines Artikels heißt der Pfand-Bereich jetzt „Pfand (§ 47 VerpackDG)“.

Legen Sie einen Artikel mit Anfangsbestand an, während die Lager kurzzeitig nicht lesbar sind, meldet BIS ERP das jetzt und legt den Artikel nicht an. Bisher entstand der Artikel mit einem Bestand ohne Lager, und an der Kasse eines Betriebs mit mehreren Lagern erschien er als ausverkauft.

Kann BIS ERP einen neuen Artikel nicht in JTL anlegen, zum Beispiel weil einer Ausführung die Variantenangabe oder eine eindeutige Steuerklasse fehlt, steht jetzt einmal am Tag eine Sammelmeldung im Sync-Protokoll: wie viele Artikel auf eine Korrektur warten und die ersten zehn Artikelnummern.

Das ZUGFeRD-Profil „Minimum“ enthält nicht alle Rechnungsangaben und gilt nicht als E-Rechnung im Sinne des Umsatzsteuergesetzes. Deshalb bietet BIS ERP es nicht mehr an.

Gutscheine aus Ihrem Gutschein-Shop und aus dem BIS Shop liefen bisher tagesgenau ab Kauf ab (Werkseinstellung 365 Tage). Jetzt gilt dieselbe Regel wie an der Kasse: Ab 360 Tagen Laufzeit läuft ein Gutschein bis zum 31.12. des Jahres, in dem die Frist endet.

Ein an der Kasse stornierter Forderungsausgleich wird vom Server jetzt angenommen. Am Auftrag erscheint ein Hinweis im Verlauf, dazu eine Meldung in der Glocke: Bitte die Forderung prüfen und die Zahlung bei Bedarf zurücknehmen; sie wird nicht automatisch zurückgenommen. Ausgleichsbons werden der Kasse außerdem als übertragen bestätigt, damit ein Storno nicht hinter ihnen hängen bleibt.

An der Kasse finden Sie unter „Offene Forderung begleichen“ eine offene Rechnung aus BIS ERP jetzt auch über die Nummer des zugehörigen Auftrags (zum Beispiel „B-00000304“). Bisher fand die Suche sie nur über Rechnungsnummer, Kunde oder Betrag.

Ordnen Sie Einrichtungen, Filialen oder Franchise-Betriebe einem übergeordneten Kunden zu, können sie jetzt dessen Konditionen übernehmen – ohne dass Sie Preise doppelt pflegen.

Nach dem Kauf geht es im Einkaufsportal jetzt weiter:

An deutschen Kassen sichert die Kasse Bestellungen am Tisch, am Kellner-Gerät, auf dem Deckel, beim Imbiss „später kassieren“ und aus der QR-Bestellung jetzt als eigenen TSE-Vorgang ab, wie es der Anwendungserlass zu § 146a AO für Bestellungen in der Gastronomie vorsieht. BIS ERP zeigt die dazugehörige Angabe auf den Belegen.

Die Geräteliste im Kundencenter und in BIS ERP lädt bei Betrieben mit mehreren Kassen deutlich schneller, und die Anzeige „x von y Artikeln“ stimmt jetzt auch bei Gutschein-Vorlagen.

JTL-Einstellungen: „Nach dem Kunden fragen“ je Kasse wieder direkt einstellbar

KI-Auswertung der Fotoaufträge: Pflichtangaben für den Onlineshop und gezieltes Nachfoto

BIS Shop: Pfand mit dem Steuersatz der Ware und vollständig erstattbar

BIS ERP bekommt eine direkte Anbindung an TikTok Shop, ohne Umweg über JTL-Wawi. Die Anbindung ist noch in Vorbereitung: Wir schalten sie frei, sobald TikTok unsere App geprüft hat und die Übergabe der Aufträge an JTL-Wawi fertig ist. Zum Start gilt sie für TikTok Shop Deutschland. Vorgesehen ist:

BIS ERP meldet Sie nur noch ab, wenn Ihre Anmeldung wirklich abgelaufen ist oder Sie sich auf einem anderen Gerät angemeldet haben. Meldet ein einzelner Bereich einer Seite einen Anmeldefehler, prüft BIS ERP zuerst kurz, ob Sie noch angemeldet sind. Sind Sie es, bleiben Sie angemeldet; nur dieser eine Bereich zeigt dann einen Fehler, statt dass Sie mitten in der Arbeit zur Anmeldung zurückgeschickt werden.

Wurde eine Kasse zurückgesetzt oder neu eingerichtet, konnte ein neuer Verkauf bis zu einen Tag lang den digitalen Bon eines früheren Verkaufs bekommen: QR-Code, Link und Beleg-Mail zeigten dann einen fremden Beleg. Jetzt erkennt BIS ERP eine Wiederholung nur noch am selben Verkauf mit gleichem Betrag und gleicher Verkaufszeit. Jeder neue Verkauf bekommt seinen eigenen Bon. Mit dem nächsten Kassen-Update schickt die Kasse dafür zusätzlich eine eindeutige Verkaufskennung mit.

Bisher führte BIS ERP Seriennummern an zwei Stellen: Packtisch, Kommissionierung und Wareneingang auf der einen, Kasse, JTL und die Einzelstücke am Artikel auf der anderen. Eine Nummer aus JTL oder von der Kasse war am Packtisch deshalb „nicht im Bestand geführt“, und ein am Packtisch verkauftes Stück blieb an der Kasse verkäuflich. Jetzt gibt es nur noch ein Seriennummern-Register:

Die offenen Rechnungen eines Kunden zeigen jetzt auf jeder Seite denselben Betrag wie die Kachel „Offene Rechnungen“ auf dem Dashboard und die Auswertung Forderungsalter.

Legt BIS einen Auftrag (zum Beispiel aus dem BIS-Shop oder von eBay) in JTL an und wird er dort bezahlt oder versendet, zieht BIS den Stand jetzt selbst nach. Führt JTL den Bestand, steht ein in JTL versendeter Auftrag danach auch in BIS als versendet und wird am Packtisch nicht mehr zum Packen angeboten (führt BIS den Bestand, meldet BIS den Versand in der Glocke, damit der Warenausgang nicht verloren geht); bei BIS-Shop-Bestellungen wartet nur die Versandmeldung an den Shop kurz auf die Sendungsnummer aus JTL (bei Spedition und Abholung nicht). Lag der Auftrag in BIS gerade in der Kommissionierung oder Verpackung, erscheint eine Meldung in der Glocke. Bereits zurückerstattete oder stornierte Aufträge verändert der Abgleich nie, und eine in BIS zurückgenommene Zahlung bleibt zurückgenommen. Meldet JTL einen Storno, vermerkt BIS das im Auftragsverlauf und meldet es in der Glocke; storniert wird der Auftrag in BIS nicht automatisch.

Die Anlage EKS für das Jobcenter weist bezahlte Anschaffungen, die Sie in BIS ERP auf das Konto „Abschreibungen“ gebucht haben, jetzt dort aus, wo das Formular sie erwartet: in B8 „Investitionen“ im Monat der Zahlung, nicht mehr in B14.5. Summe Ihrer Betriebsausgaben und Gewinn bleiben dabei unverändert.

Kommt ein Versandetikett am Packtisch im Browser nicht beim Drucker an, zeigt BIS ERP jetzt einen Hinweis mit „Im Browser drucken“ und „Herunterladen“, statt still den Abschluss zu melden. Außerdem merkt sich der Packtisch die gewählte Warteschlange; Betriebe ohne Picklisten sehen ihre offenen Aufträge direkt.

Hat eine Kasse im Zeitraum Tagesabschlüsse, aber keine Belege an BIS ERP übertragen, nennt der Hinweis im DATEV-Kassenexport (BIS ERP und Kundencenter) jetzt den Grund und den nächsten Schritt – zum Beispiel „Kassen-App aktualisieren und einmal online gehen“. Ab Version 1.3.7 überträgt die Kasse wartende Belege von selbst; einen eigenen Schalter dafür gibt es nicht. Der Hinweis erscheint jetzt auch bei Betrieben, deren Kasse noch nie einen Beleg übertragen hat.

Auf der Artikelseite gibt es keinen Knopf „Speichern“ mehr. Jede Änderung wird gespeichert, sobald Sie ein Feld verlassen oder Enter drücken. Auswahlfelder und Schalter speichern sofort. Oben im Kopf sehen Sie jederzeit, ob alles gespeichert ist („Alles gespeichert“ mit Uhrzeit). Schlägt ein Speichern fehl, bleibt Ihre Eingabe stehen und Sie können es mit „Erneut“ noch einmal versuchen.

Offene Rechnungen, die Sie in BIS ERP erstellt haben, finden Sie jetzt an der Kasse unter „Offene Forderung begleichen“ und können sie dort kassieren. Bisher fand die Kasse diese Rechnungen praktisch nie.

Bons der Web-Kasse tragen den TSE-QR-Code jetzt im Format, das die Finanzverwaltung für die Belegprüfung vorgibt (DSFinV-K Anhang I), wie die Kassen-App – bei Verkauf und Storno.

Auftragsexport und Exportdateien: Rechte, echtes Excel, aufgeräumt

In der Artikelansicht öffnet ein Klick auf eine offene Pickliste jetzt deren Ansicht (ohne das Picken zu starten), statt auf „Seite nicht gefunden“ zu führen. Im Packplatz-Dashboard bringt „Station öffnen“ Sie zum Packplatz. Alte Lesezeichen auf eine Station führen ebenfalls dorthin.

In der Shop-Liste des Kundencenters steht bei der BIS AI Bridge jetzt „Kostenlos“ statt „15,00 €/Monat“. Der Preis für unbegrenzte Abfragen erscheint darunter als Zusatz „unbegrenzt 15,00 €/Monat“. Der Filter „Nur kostenlos“ zeigt die AI Bridge an. Die Produktbeschreibung im Shop gibt es jetzt auch auf Englisch und Thai.

Wird ein JTL-Auftrag am Packtisch in mehreren Runden versendet, führt JTL ihn jetzt erst nach der letzten Runde als komplett ausgeliefert.

In „Einstellungen → Webshop → Startseite & Bausteine“ können Sie jetzt bis zu sechs Themenkacheln für die Startseite Ihres Webshops zusammenstellen; wo sie dort stehen, bestimmt Ihr Layout. Jede Kachel hat einen Titel, auf Wunsch einen Untertitel und ein Ziel, zum Beispiel eine Kategorie, ein Herkunftsland, eine Sonderseite oder eine Adresse Ihres Shops. Das Ziel wählen Sie aus einer Liste, Sie müssen keine Adresse tippen. Die Kachel folgt der Kategorie, auch wenn diese später umbenannt wird.

Kundencenter: Stand Ihres Support-Kontingents unter „Meine Anfragen“ und Hinweis bei 80 % und 100 %

Die Suche in der Auftragsliste und in der Schnellsuche (Strg + K) antwortet jetzt auch bei vielen Tausend Aufträgen in Sekundenbruchteilen statt nach bis zu einer Minute. Gefunden werden dieselben Aufträge wie bisher: Auftragsnummer, Bestellnummer des Marktplatzes, Name, Firma, Anschrift, E-Mail, Telefon, USt-IdNr., Kundennummer, Artikelnummer, Artikelname und EAN.

Im Shop des Kundencenters steht über „Kostenlos aktivieren“ kein Monatspreis mehr. Die Erklärung zum Häkchen ist überall dieselbe.

BIS ERP Einkauf: Einkaufspreis auf der Lieferanten-Karte am Artikel

Kundencenter: Stornos im Kassenjournal richtig angezeigt

Kassen-EÜR: Pfandrückgaben mindern die Einnahmen

Eine Kommissionierwelle verschwand am Packtisch (Lager-App und Browser) manchmal zu früh aus der Liste, obwohl noch ein Auftrag unverpackt war, nämlich wenn ein bereits verpackter Auftrag mehrere Positionen hatte. Die Welle bleibt jetzt in der Packtisch-Liste, bis jeder ihrer Aufträge verpackt ist.

Tour-Tracking: Schalter zum Einschalten in den Einstellungen (in Vorbereitung)

Das BIS Einkaufsportal hat jetzt zwei Stufen. Der **B2B-Shop** bleibt in BIS Pro bzw. BIS ERP Plus enthalten. Die **Einkaufssteuerung** – Rollen und Selbstverwaltung im Firmenkonto, Kostenstellen mit Monatsbudget und Freigabe ab einer Wertgrenze – ist die Stufe „BIS Einkaufsportal – Einkaufssteuerung“; sie ist in BIS ERP Max enthalten, einzeln schaltet sie der BISpicy-Support frei. Endet die Lizenz, pausiert die Steuerung, statt sich still abzuschalten: Für diese Firmenkunden ruhen Bestellen, Freigeben und Verwalten im Portal, bis die Lizenz wieder gilt, und Rollen, Kostenstellen und Budgets bleiben gespeichert.

BIS ERP Einkauf: Einkaufspreis-Verlauf und neue Einkaufspreise ab einem Datum

CRM: „Wieder aufnehmen“ bei Neukunden wirkt sofort

Rechtstexte: Auftragsverarbeitungsvertrag 1.24, Datenschutzerklärung und AGB 2.3 für Kundenportal, Einkaufsportal, Tour-Tracking und EDI

Ein Marktplatz- oder Shop-Auftrag, zu dem BIS ERP schon die Rechnung geschrieben hat, geht nicht mehr zusätzlich nach JTL-Wawi, wenn JTL die Rechnungen schreibt. So entsteht keine zweite Rechnung. Der Auftrag wird in BIS ERP versendet; im Synchronisationsprotokoll steht eine Warnung mit den Auftragsnummern.

Unter Einkauf → Analysen finden Sie drei neue Auswertungen (mit BIS Insights). Sie zählen alle bestellten Positionen aus BIS ERP – Entwürfe und stornierte Bestellungen bleiben außen vor. Arbeiten Sie mit JTL-Wawi, zählen dort angelegte Lieferantenbestellungen mit, sobald sie beim Abgleich nach BIS ERP übernommen wurden.

Die Verfahrensdokumentation der Kassenführung (Abschnitt D.3) beschreibt jetzt, dass der Kassenabschluss ab der ersten Kassen-Version nach 1.3.20 Pfand als „Pfand“ und die Leergut-Rücknahme als „PfandRueckzahlung“ an den Fiskaly-Dienst meldet und ältere Kassenstände beides als „Umsatz“ geführt haben. Beträge und Steuersätze sind dieselben. Erzeugen Sie die Verfahrensdokumentation nach dem Kassen-Update neu, damit der Wechsel darin festgehalten ist.

DATEV-Debitorkonto: kein dauerhaft gesperrter Kontowechsel mehr durch JTL-Rechnungskopien

War die Standard-Kostenstelle in den DATEV-Einstellungen länger als 20 Zeichen, scheiterte bisher das ganze Speichern mit einer allgemeinen Fehlermeldung. Jetzt nennt BIS ERP den Grund. Die Eingabefelder für Beraternummer (bis 7 Ziffern), Mandantennummer (bis 5 Ziffern) und Kostenstelle (bis 20 Zeichen) nehmen außerdem nicht mehr Zeichen an, als erlaubt sind.

Im Call-Modus des CRM steht auf der Gesprächskarte jetzt auch die jüngste Notiz aus der Kundenakte, mit Datum und Verfasser. So sehen Sie während des Anrufs, was ein Kollege zuletzt zum Kunden festgehalten hat, ohne die Kundenakte zu öffnen. Ist diese Notiz derselbe Eintrag wie der oben gezeigte Kontaktvermerk, erscheint sie nicht doppelt. Alle Einträge finden Sie weiterhin unter „Bisherige Vermerke“.

Auf den Produktseiten Ihres BIS Shops stehen für Suchmaschinen wieder Preis, Währung, Verfügbarkeit und Zustand (neu oder gebraucht) des Artikels. Bisher fehlten diese Angaben im verborgenen Seitenmarkup, sodass Suchmaschinen Ihre Artikel nicht mit Preis anzeigen konnten. Artikel ohne Preis, mit 0,00 € und das Pfand-Produkt bekommen weiterhin keine Preisangabe.

Scan-to-Order: klare Hinweise zur Zahlung auf der Gästeseite

Beim Hochladen eines eigenen Shop-Layouts prüft BIS jetzt auch die Vorlagen des Warenkorbs (Summenbox) und der Kassen-Seitenleiste. Fehlt dort ein Pflichtbaustein, etwa der Hinweis auf die gesetzliche Gewährleistung, wird der Upload mit einer verständlichen Meldung abgewiesen, statt dass der Hinweis unbemerkt von der Seite verschwindet. Mitgelieferte Layouts sind nicht betroffen.

Ist am Artikel als Lebensmittelunternehmer „wie Hersteller (GPSR)“ eingestellt, druckt das Lebensmitteletikett jetzt Name bzw. Firma und Anschrift des Herstellers. Bisher stand dort nur die Anschrift, die Lebensmittelinformations-Verordnung verlangt aber beides. Fehlt beim Hersteller der Name oder die Anschrift, druckt das Etikett wie bei der Standardeinstellung Ihre eigenen Firmendaten.

Erstellt BIS ERP zu einem Kassenverkauf eine DIN-A4-Rechnung, die an der Kasse schon bar oder mit Karte bezahlt wurde, steht sie nicht mehr nach Ablauf des Zahlungsziels auf „überfällig“ und taucht nicht mehr im Mahnwesen auf. Dasselbe gilt für reine Kassenbelege im A4-Format. Rechnungen aus einem Kauf auf Rechnung an der Kasse sind echte Forderungen und werden weiterhin überfällig, wenn sie nicht bezahlt werden.

Verkaufen Sie ein differenzbesteuertes Gebrauchtgerät, zu dem kein Ankaufspreis erfasst ist, gilt der ganze Verkaufspreis als Marge und wird voll versteuert. Der DATEV-Kassenexport weist jetzt darauf hin: wie viele Positionen das sind, zu welchem Verkaufspreis und wie viel Umsatzsteuer darauf entfällt. Legen Sie Gebrauchtgeräte künftig mit Ankaufspreis an oder erfassen Sie sie über den Ankauf an der Kasse, dann wird nur die tatsächliche Marge versteuert.

Die erste Einrichtung der Anbindung an Google Local Inventory (lokale Lagerbestände für Google) brach beim Speichern mit einem Fehler ab, sobald ein Schalter ausgeschaltet war. Das ist behoben. Dasselbe galt für das Zuordnen einer Filiale, die nicht aktiv sein soll.

Entfernt eine Anbindung oder ein eigenes Skript über die Artikel-Schnittstelle die Kategorie eines Artikels, wird jetzt auch der Kategoriepfad geleert. Bisher behielt der Artikel seinen alten Pfad, und die Kasse zeigte ihn weiter in der früheren Kategorie. In der Artikelmaske von BIS ERP war das schon richtig.

Bon-Vorlagen der Kasse können jetzt nur noch Benutzer anlegen, ändern, löschen oder als Standard setzen, die in BIS ERP bzw. im Kundencenter das Recht „Kassen-Abgleich bearbeiten“ haben (Administrator und Manager ab Werk). Vorher genügte jede Anmeldung.

In den Aktivitätslogs wirken Filter, Suche und das Blättern zwischen den Seiten wieder. Im Versandkosten-Abgleich erscheinen Übersicht, die Datensätze eines Imports und die Auffälligkeiten wieder; vorher blieben diese Bereiche leer.

Versand: Lieferscheine wieder in der Liste und in der Ansicht

Wird bei einer Inventur oder Zählung dieselbe Charge mit demselben MHD mehrmals erfasst, zum Beispiel aus zwei Kartons, bucht BIS ERP jetzt die Summe aller Teilmengen als Bestand. Bisher blieb still nur die zuletzt erfasste Teilmenge stehen, obwohl der Inventurbeleg die Summe zeigte.

Wird an der Kasse ein Verkauf mit Kunde storniert oder Ware zurückgenommen, legt BIS ERP dafür keine eigene Rechnung mit Minusbetrag mehr an. Bisher konnte bei eingeschalteter Auto-Rechnung neben der Gutschrift zur ursprünglichen Rechnung zusätzlich eine negative Rechnung entstehen. Der Verkauf war dann doppelt gemindert.

Einkauf: Auftragsbestätigungen und Lieferavise per EDI

Im DATEV-Export steht bei einer Gutschrift aus einer Retoure im Buchungstext jetzt die Nummer der ursprünglichen Rechnung („Gutschrift zu RE-…“), auch bei Rechnungen der Kasse. Bisher stand dort die Nummer der Gutschrift selbst. Ist keine ursprüngliche Rechnung bekannt, lautet der Text „Gutschrift GS-…“.

In BIS ERP legen Sie die Kundengruppe jetzt direkt in der Kundenmaske fest, gleich neben dem Kundenrabatt. Bisher kam sie nur aus JTL-Wawi oder von der Kasse. Die Gruppe entscheidet über Gruppenpreise und -rabatte. Zur Auswahl stehen die aktiven Gruppen unter Einstellungen → Kundengruppen. Ändern darf die Kundengruppe, wer auch den Kundenrabatt ändern darf (Recht „Preise ändern“). Gleichen Sie Kunden aus JTL-Wawi ab, pflegen Sie die Gruppe dieser Kunden weiter in JTL, und für alle anderen Kunden stehen dann nur die Gruppen aus JTL zur Wahl. Sonst würde der nächste Abgleich die Gruppe überschreiben.

Im Kundencenter unter Kassen → BIS Remote → Drucken & Belege stellen Sie jetzt die Größe des Logos auf allen Bons einer Kasse ein, in Millimetern und auf jedem Papier gleich, und die Schrift auf Küchen-, Theken- und Getränkebons getrennt für Kopf, Positionen, Zubereitung und Notizen. Braucht eine Kasse dafür noch ein Update, steht die Einstellung dort nur lesend mit dem Hinweis „Kassen-Update nötig“, statt dass sie wirkungslos als angewandt gemeldet wird. In der Web-Kasse wählen Sie die Schrift des Küchenbons unter Einstellungen → Drucker; ohne Änderung druckt der Küchenbon wie bisher.

Seit dem 31.10. wurden Benutzer beim Klick auf „CRM“ sofort abgemeldet. Ursache war der neue Bereich für Zugangsanträge zum Kundenportal auf der Kundenliste: Er hat angemeldete Benutzer fälschlich als „nicht angemeldet“ abgewiesen, und BIS ERP hat daraufhin die Anmeldung beendet. Die Kundenliste öffnet jetzt wieder normal, und die Zugangsanträge werden angezeigt.

Artikel: Lieferanten zuordnen funktioniert wieder

Einkauf: Lieferantenrechnungen per EDI und automatische Rechnungsprüfung

Beim Ankauf eines gebrauchten Geräts kann die Kasse im Handyshop jetzt festhalten, ob das Gerät zurückgesetzt und vom Konto des Vorbesitzers abgemeldet ist (Apple „Wo ist?“, Google-Konto).

Im Bericht „Bonnummern-Lücken“ (BIS ERP und Kundencenter) steht jetzt ein eigener Abschnitt mit dem, was die Kasse an ihren Zählern protokolliert hat, jeweils mit Zeitpunkt und Grund. Heute sind das Änderungen der Bonnummer von Hand; ab der nächsten Kassenversion kommen das Weiterzählen nach einem Werksreset oder dem Einspielen einer Sicherung und das Öffnen über den Notweg dazu. So haben Sie diese Angaben für eine Kassen-Nachschau griffbereit.

Verlangt Ihr Lieferant oder EDI-Dienstleister AS2 statt eines Postfachs, richten Sie das jetzt direkt in BIS ERP ein (Einstellungen → Integrationen → EDI, Übertragungsweg „AS2“).

Pfandartikel (zum Beispiel „Pfand“ mit Ihrer Pfandartikelnummer) erscheinen nicht mehr als eigenes, kaufbares Produkt im Onlineshop. Das Pfand wird weiter an der Ware berechnet und ausgewiesen.

Im Kundencenter können Sie jetzt die Domain Ihrer Mail-Adressen per DNS-Eintrag nachweisen. Danach bietet die Anmeldeseite jeder Adresse dieser Domain die Anmeldung mit Microsoft an, und neue Mitarbeitende, die Ihre IT bei Microsoft freigegeben hat, werden bei der ersten Anmeldung automatisch in Ihrem Betrieb angelegt, auch ohne den Betriebs-Anmeldelink.

Gebinde, die Sie in der Lager-App oder in BIS ERP löschen, werden jetzt auch in JTL-Wawi gelöscht und tauchen nicht mehr von selbst wieder auf (bei Anbindung in Richtung „zu JTL“ oder „in beide Richtungen“) — auch dann nicht, wenn BISConnect beim Löschen gerade offline war: BIS ERP merkt sich das Löschen und holt es in JTL-Wawi nach, sobald die Verbindung wieder steht. Das gilt auch für den Dubletten-Dialog bei doppelten Gebinde-EANs. Im Gebinde-Tab des Artikels fragt BIS ERP vor dem Löschen noch einmal nach. Führen Sie Ihre Artikel in JTL-Wawi (Richtung „von JTL“), können Gebinde nur dort gelöscht werden; BIS ERP und die Lager-App sagen das jetzt mit einer klaren Meldung, statt ein Gebinde zu löschen, das beim nächsten Abgleich wiederkäme.

Haben Sie an einem Artikel oder Auftrag etwas geändert und noch nicht gespeichert, fragt BIS ERP jetzt nach, bevor Sie die Seite verlassen.

Die Zeile „Heute“ auf der Startseite der Lager-App zeigt jetzt die Tagesleistung am Gerät vollständig.

Lieferanten mit EDI-Anbindung bestellen Sie jetzt direkt aus BIS ERP: Im Bestell-Dialog gibt es den Knopf **Per EDI senden**.

Neue und geänderte Artikel bekommen eine Steuerklasse, die zu ihrem Steuersatz passt.

Die Verrechnungskonten für Stripe und PayPal richten sich jetzt nach Ihrem eingestellten Kontenrahmen.

Verkäufe an der Web-Kasse (auch Tischzahlungen) buchen den Bestand jetzt ab, Stornos buchen ihn nach deiner Einstellung wieder zurück – wie an der Kasse-App.

In „Einstellungen → Webshop → Startseite & Bausteine“ gibt es fünf weitere Kaufhilfen für Ihren Webshop. Jede lässt sich einzeln einschalten und ist ab Werk aus, Ihr Shop ändert sich also erst, wenn Sie es wollen. Eine Ausnahme gibt es: Der Fortschritt „Noch … bis zum kostenlosen Versand“ im Warenkorb erscheint jetzt nur noch, wenn eine passende Rabattaktion „Versandkosten −100 %“ läuft, und ist er eingeschaltet, nennt Ihre Versandkostenseite dazu automatisch die Bedingungen (siehe unten). Was keine Daten hat, erscheint gar nicht. Dazu gibt es einen eigenen Schalter „Band und Hinweis auf der Produktseite“ für „Versandkostenfrei ab“, ab Werk aus. Der Betrag kommt ausschließlich aus Ihrer Einstellung „Versandkostenfrei ab“ und gezählt wird der Warenwert nach Rabatten, ohne Pfand. Band und Hinweis erscheinen nur, wenn eine laufende Rabattaktion „Versandkosten −100 %“ genau diese Grenze trägt und sonst keine Bedingung hat (kein Gutscheincode, kein Lieferland, keine Kundengruppe, kein Nutzungslimit). Läuft eine automatische Aktion, die nicht mit anderen kombinierbar ist, erscheinen Band und Hinweis nicht. Der Fortschritt im Warenkorb folgt derselben Regel: Ohne passende Rabattaktion „Versandkosten −100 %“ erscheint er nicht mehr, auch wenn er bisher eingeschaltet war. Sobald etwas davon angezeigt wird, nennt Ihre Versandkostenseite die Bedingungen automatisch; Band und Hinweis verlinken sie über „Details“.

Privatpersonen, die Ihnen nur ein Gerät verkauft haben, erscheinen nicht mehr in den CRM-Anruflisten (Akquise, Neukunden, Reaktivierung). Ein Werbeanruf bei Verbrauchern ist ohne deren ausdrückliche Einwilligung nicht erlaubt, und die Daten aus dem Ankauf dienen nur dem Ankauf.

Wählen Sie in der JTL-Anbindung bei einer Kasse einen eigenen Lagerplatz für Storno-Rückbuchungen, bucht BIS ERP stornierte Ware jetzt genau dorthin zurück. Bisher galt immer der Platz der Verbindung, auch wenn an der Kasse etwas anderes ausgewählt war. Steht die Kasse auf „Standard“, bleibt alles wie bisher.

Teilbare Artikel (zum Beispiel lose Ware nach Gewicht) verkaufen Sie jetzt auch im Kundenauftrag mit Nachkommastellen. Bisher schnitt BIS ERP eine Menge wie 2,5 kg still auf 2 ab, jetzt bleibt sie genau so stehen.

Unter **Buchhaltung → Buchungsexport** geben Sie Ihre Ausgangsrechnungen und Ihre internen Entnahmen als CSV-Datei an ein anderes Buchhaltungssystem weiter, zum Beispiel an SAP S/4HANA FI.

In der EDI-Einrichtung (Einstellungen → Integrationen → EDI) zeigt jede Verbindung jetzt das Protokoll ihrer Nachrichten und bietet „Verbindung testen“ und „Jetzt abrufen“. Für SFTP erzeugt BIS ERP auf Wunsch ein Schlüsselpaar; Sie geben nur den öffentlichen Schlüssel an Ihren EDI-Dienstleister.

Sendet ein angebundenes System eine Anfrage nach einem Netzfehler mit demselben Idempotency-Key erneut, entstehen keine doppelten Produkte, Kunden oder Bestandsbuchungen mehr – auch nicht, wenn beide Anfragen gleichzeitig ankommen. Die zweite Anfrage bekommt die Antwort der ersten bzw. die Bitte, es in zwei Sekunden noch einmal zu versuchen. Wird derselbe Idempotency-Key versehentlich für eine andere Anfrage verwendet, lehnt die Schnittstelle sie ab (IDEMPOTENCY_MISMATCH), statt sie auszuführen.

Mit BIS ERP Max binden Sie eine externe Einkaufsplattform an: Sie bestellt per Schnittstelle im Namen genau eines Ihrer Firmenkunden (zum Beispiel eines Trägers mit mehreren Einrichtungen). ### BIS ERP und Kundencenter

Wenn Ihre Fahrer die Tour mit der Lager-App scannen, sehen Sie den Stand jetzt in BIS ERP, und Ihre Geschäftskunden sehen ihn im Einkaufsportal. Das Tour-Tracking wird erst nutzbar, wenn es für Ihren Betrieb freigeschaltet ist.

Ein Bestellsystem, das über die BIS-ERP-Schnittstelle bestellt, bekommt jetzt automatisch Bescheid, wie es mit seinen Aufträgen weitergeht.

Für jede Kundengruppe lässt sich jetzt eine Preisregel hinterlegen, zum Beispiel „Einkaufspreis plus 5 %“, „Einkaufspreis brutto“ oder „Standard-Verkaufspreis minus 10 %“. Vor dem Aktivieren zeigt eine Vorschau, welche Artikel sich ändern (auch, wo der Preis unter dem Einkaufspreis läge); danach zieht BIS die Preise automatisch nach, und sie gelten im Auftrag, an der Kasse, in der Web-Kasse und in der Lager-App-Auskunft. Der Preis wird nie teurer als der bisherige Preis der Gruppe, Pfand und Wertgutscheine bleiben unberührt, ein JTL-Gruppenrabatt wird nur angezeigt und gilt in BIS nicht. Preise von Gebinden (Kartons) folgen der Regel noch nicht.

Wenn der Versanddienstleister beim Abschließen langsam antwortet, sagt Ihnen der Packtisch im Browser jetzt, was los ist, und warnt vor einem zweiten Etikett.

Bestellungen, die ein Shop oder ein Bestellsystem über die BIS-ERP-Schnittstelle schickt, entstehen jetzt auf demselben Weg wie ein in BIS ERP angelegter Auftrag.

Sie können den Preis einer Versandart jetzt wahlweise brutto (Endpreis inklusive MwSt.) oder netto (zuzüglich MwSt.) eintragen.

Bestellimport-Quellen per SFTP können jetzt Dateien von Ihrem Anbieter holen. Verbindungen per FTP werden ab Werk verschlüsselt aufgebaut; eine unverschlüsselte Verbindung gibt es nur, wenn Sie sie bei der Quelle ausdrücklich erlauben (dafür ist das Passwort neu einzugeben), und die Maske weist dann deutlich darauf hin.

Für Betriebe mit Kellner-Geräten: Trinkgeld lässt sich jetzt je Mitarbeiter nachvollziehen und aus dem Kundencenter einstellen.

Im Kundencenter unter Geräte → Bildschirm & Bedienung stellen Sie für jede Kasse ein, wie groß die Artikelkacheln im Verkauf sind (Klein, Normal oder Groß) und welche Symbole oben in der Kopfleiste stehen. Ein ausgeblendetes Symbol verschwindet nicht, es steht dann im Menü „…“. Kassenmenü, Abmelden und Selbstbedienung bleiben immer sichtbar. „Normal“ ist die bisherige Ansicht, ohne Ihr Zutun ändert sich nichts. Die Einstellungen wirken ab Kasse 1.3.21; an der Kasse selbst finden Sie sie unter Einstellungen → Darstellung → Verkaufsbildschirm.

Bestellungen, deren Mengen aus JTL mit vier Nachkommastellen kommen (z. B. 2,5005 kg), gelten jetzt als vollständig geliefert, sobald nur noch ein nicht buchbarer Rest unter 0,001 offen ist. Sie bleiben nicht mehr dauerhaft auf „teilweise geliefert“, die Lager-App bietet keinen Scheinrest mehr an, und ist die Teillieferung abgeschaltet, lässt sich die Position mit der gelieferten Menge vollständig einbuchen.

Der Server ist bereit, dass sich Mitarbeitende an der Lager-App künftig mit ihrem Microsoft-Konto anmelden. Die Lager-App selbst folgt mit einer eigenen Version.

Beim schnellen Scannen konnte die Anzeige hinter dem tatsächlichen Stand zurückbleiben, zum Beispiel 5/10, obwohl alle zehn Stück schon im Karton lagen. Jetzt übernimmt der Packtisch den Stand direkt vom System, und Scans werden der Reihe nach verbucht.

In BIS ERP lässt sich unter Versand › Kommissionierung eine Pickliste (Sammelliste) jetzt löschen, solange noch nichts gegriffen wurde, auch wenn ein Handgerät sie gerade geöffnet hat. Die reservierte Ware wird dabei wieder frei.

In einzelnen Shops zeigten Produktseiten und der Warenkorb nach dem Einrichten des Pfands eine Fehlerseite. Ursache war, dass der interne Pfandartikel in der Liste „Neueste Produkte“ auftauchen konnte. Er erscheint dort jetzt nie mehr, und die Seiten laden wie gewohnt.

Ihre Geschäftskunden bestellen im Einkaufsportal jetzt auch direkt am Regal nach:

Im Einkaufsportal wählen Ihre Kunden jetzt oben die Anlieferstelle und den Liefertag:

In der Kundenakte richten Sie für Geschäftskunden mit Einkaufsportal jetzt ein Firmenkonto ein. Sie legen fest, wer bei Ihrem Kunden bestellen darf, und auf Wunsch pflegt Ihr Kunde das selbst. Nachbestellen und beim Annehmen von Angeboten. Ohne Steuerung bleibt alles wie bisher. Anlieferstellen und Kostenstellen und lädt Kolleginnen und Kollegen ein. Budget und Freigabe-Grenze bleiben in dem Rahmen, den Sie setzen.

Unter Einstellungen → Kundenportal schalten Sie jetzt das Einkaufsportal ein (ab BIS Pro bzw. BIS ERP Plus, ab Werk ausgeschaltet). Ihre Geschäftskunden kaufen darin wie in einem Shop ein: nur Artikel aus ihrem Bestellsortiment, zu ihren Kundenpreisen (netto), bezahlt wird per Rechnung. Ins Portal kommt nur, wen Sie einladen.

Eine Preisaktion am Artikel mit festem Betrag (zum Beispiel „5 € günstiger“) senkt den Preis in Ihrem Shop jetzt um den Betrag, so wie Ihre Kunden ihn sehen.

Firmenkunden mit eingeschalteter Einkaufssteuerung steuern ihren Einkauf jetzt selbst mit Budget und Freigabe:

BIS ERP bereitet die Grundlage für das Tour-Tracking vor; die Funktion folgt mit einem der nächsten Updates in der Lager-App und ist bis dahin ausgeschaltet.

In der Bestandskorrektur gibt es jetzt den Grund „Interne Entnahme“: Ware, die Ihr eigenes Unternehmen selbst verbraucht (zum Beispiel Küche oder Werkstatt), wird mit einer eigenen Kostenstelle aus dem Lager ausgebucht.

In der Lager-App gibt es den neuen Menüpunkt „Fotos offen“. Er listet alle aktiven Artikel, von denen noch keine Fotos aus der Lager-App vorliegen, Artikel ganz ohne Bild stehen oben. So lassen sich Produktbilder der Reihe nach erstellen, statt nur zufällig beim Kommissionieren oder im Wareneingang.

Nach einem Werksreset oder „Alle Artikel neu laden“ belastet die Kasse BIS ERP nicht mehr im Verhältnis zur Größe des Artikelkatalogs. Unveränderte Artikel schreiben bei der Synchronisierung nichts mehr.

Für Betriebe außerhalb Deutschlands schlug BIS ERP bei Eingangsrechnungen und in neuen Belegvorlagen teilweise deutsche Steuersätze vor. Jetzt gilt das Land aus Ihren Firmendaten.

Wurde eine Kasse zurückgesetzt oder eine ältere Sicherung eingespielt, konnte sie Bonnummern erneut vergeben. BIS ERP speichert jetzt jeden dieser Belege.

Beim Speichern der Kaufhilfen Ihres Shops (z. B. Marke, Verfügbarkeit, Versandfrei-Balken, Merkzettel, „Neu“-Fahne, Kopfnavigation) erschien bisher immer „Shop nicht erreichbar“, und nichts wurde übernommen. Das ist behoben, Ihre Einstellungen kommen wieder im Shop an.

Im Kundencenter gibt es unter Kassen → Übersicht eine neue Seite: Dort legen Sie fest, was Ihre Mitarbeitenden auf der Übersicht der Kasse sehen. Die Kasse selbst folgt mit dem nächsten Kassen-Update; bis dahin bleibt die Übersicht an jeder Kasse unverändert. Hinweis: Die Einstellungen wirken an der Kasse erst mit dem nächsten Kassen-Update.

Beim Wareneingang ohne Bestellung nimmt BIS ERP für Artikel, die als „Stückzahl teilbar“ geführt werden oder gewogen werden, jetzt Mengen mit Nachkommastellen an, zum Beispiel 0,75 kg Tomaten.

Wenn Ihre Mitarbeitenden eine Microsoft-Identität haben, können Sie sie jetzt automatisch in BIS ERP anlegen und aktuell halten lassen. Scheidet jemand bei Ihnen aus, wird die Person beim nächsten Abgleich deaktiviert und alle ihre Anmeldungen mit dem BIS-Konto enden sofort.

Bei einem Versand mit mehreren Paketen gibt es jetzt genau einen Lieferschein für den ganzen Auftrag und für jedes Paket ein Exemplar zum Beilegen. Der Packstück-Beleg nummeriert richtig („Paket 2 von 2“), zeigt bei Paket 2 „Inhalt mit Paket 1 erfasst“ statt „leer“ und fasst gleiche Artikel zu einer Zeile zusammen. Freie Positionen ohne Artikelnummer gelten auf dem JTL-Lieferschein jetzt als geliefert, und nach dem Abschluss zeigt der Packtisch, was wohin gedruckt wurde – wurde nichts gedruckt, kann der Lieferschein direkt geöffnet werden.

Im Kundencenter stellen Sie unter BIS Remote ein, ob Kellner während der Schicht ihr Soll-Bargeld sehen. Ab Werk ist es ausgeblendet, damit die Zählung möglichst unbeeinflusst erfolgt.

Wenn Sie in BIS ERP den Zahlungseingang einer Shop-Bestellung buchen, die Bestellung versenden oder stornieren, sieht Ihr Kunde das jetzt auch im Kundenkonto des Shops.

Bestellungen aus Ihrem Onlineshop werden jetzt sicherer in BIS ERP übernommen. Jede Shop-Bestellung wird genau einmal zum Auftrag, auch wenn zwei Abrufe gleichzeitig laufen.

Im Webshop lassen sich Zahlungen über Mollie und Stripe vorbereiten, und bei Vorkasse erscheint Ihre Bankverbindung auf der Bestätigungsseite. Die Online-Zahlung (in Vorbereitung) ist noch nicht freigeschaltet: Zugangsdaten tragen Sie in BIS ERP unter Einstellungen, Buchhaltung, Zahlungsanbieter (Webshop) erst ein, sobald der Shop den sicheren Schlüssel dafür bekommen hat. Bis dahin wird nichts gespeichert und die Maske meldet es. Gespeicherte Zugangsdaten sind verschlüsselt und werden nie wieder angezeigt.

Nennt der Name eines Artikels eine Menge nach Gewicht, Volumen, Länge oder Fläche (zum Beispiel „50g“, „1,5L“ oder „6x70m“), aber die Füllmenge ist nicht gepflegt, erscheint er nicht mehr im Webshop für Endkunden. Ohne diese Angabe kann der Shop keinen Grundpreis zeigen, und der ist bei solchen Fertigpackungen Pflicht.

Sobald bei Ihnen Pfand-Getränke im BIS Shop freigeschaltet sind, übernimmt BIS ERP das Pfand aus Shop-Bestellungen vollständig. Bis dahin ändert sich für Ihre Bestellungen nichts.

Im Online-Shop gelten Mindestbestellwerte (zum Beispiel „versandkostenfrei ab 50 €“) und Rabattaktionen mit festem Betrag (zum Beispiel „5 € Rabatt auf die Bestellung“) jetzt für den Warenwert, den Ihr Kunde im Shop sieht.

Bisher stand auf der Versandkostenseite Ihres Shops der Versandpreis ohne Umsatzsteuer, im Bestellvorgang wurde er mit Steuer berechnet. Jetzt zeigt die Seite in Shops mit Bruttopreisen bei Lieferung im Inland denselben Betrag wie der Bestellvorgang, gekennzeichnet mit „inkl. MwSt.“. Der Versandpreis, den Sie in BIS ERP eintragen, ist ein Nettobetrag: Prüfen Sie, ob der angezeigte Betrag Ihrem gewünschten Endpreis entspricht und ob Ihr eigener Text zu Versand und Zahlung feste Beträge nennt.

Ihre Geschäftskunden erledigen im Kundenportal jetzt mehr selbst – Sie behalten die Kontrolle (ab BIS Pro bzw. BIS ERP Plus, ab Werk ausgeschaltet).

Der durchgestrichene Preis bezieht sich jetzt auf den niedrigsten Preis der letzten 30 Tage und steht nur, wenn dieser über dem aktuellen Preis liegt. Gibt es keinen solchen Preis (zum Beispiel weil noch kein Preisverlauf vorliegt), zeigt der Shop den Preis ohne Durchstreichung. „Sie sparen“ rechnet mit demselben Betrag; die Zeile mit dem niedrigsten Preis der letzten 30 Tage bleibt wie bisher stehen.

Ihre Kunden sehen im Warenkorb, in der Kassen-Zusammenfassung, in der Versandart-Auswahl, im Mini-Warenkorb und in der Bestellübersicht dieselben Bruttopreise wie auf der Produktseite. Bei einer Preisermäßigung steht der niedrigste Preis der letzten 30 Tage jetzt auch an der Produktkachel, sofern die Anzeige eingeschaltet ist. Was Ihre Kunden zahlen, ändert sich nicht.

Bisher lief die automatische Synchronisation oft nur etwa alle zehn Minuten, obwohl fünf Minuten eingestellt waren. Jetzt startet sie im eingestellten Takt, sodass Änderungen aus JTL-Wawi schneller in BIS ERP ankommen.

Retouren, die aus JTL-Wawi übernommen wurden, stehen nicht mehr als „Offene Retouren“ auf der Startseite der Lager-App. Die Startseite wird dadurch wieder übersichtlich. In BIS ERP bleiben diese Retouren sichtbar und tragen den Vermerk „Aus JTL übernommen“.

Im BIS Shop trägt das Pfand jetzt denselben Steuersatz wie das Getränk, zu dem es gehört, und wird sauber gerundet. BIS ERP zeigt in den Shop-Einstellungen einen Hinweis, wenn der Shop Pfand anzeigt, es aber noch nicht berechnen kann.

Bei Getränken mit Pfand zeigt der Shop jetzt überall, wo ein Preis steht, auch das Pfand und die Art der Verpackung. Sichtbar wird das, sobald Ihre Pfandartikel im Shop freigeschaltet sind: Das geschieht mit der Übernahme der Pfandpositionen aus Shop-Bestellungen in BIS ERP, bis dahin bleiben Pfandartikel im Shop ausgeblendet.

Sie können jetzt für jeden Kunden und jede Lieferadresse die Kostenstelle und das Aufwandskonto hinterlegen, unter denen Ihr Kunde Ihre Leistung bei sich verbucht. Beide Angaben wandern in den Auftrag, die Rechnung und die E-Rechnung.

Liegt ein Artikel in JTL-Wawi in mehreren Kategorien, ordnen BIS ERP und die Kasse ihn jetzt der Kategorie zu, die in JTL-Wawi für den Kassen-Kanal freigegeben ist.

Im Kundencenter unter Kassen → Küche & Theke hat jede Station einen Stift zum Umbenennen. Der neue Name geht als Auftrag an die Kasse; an der Station steht „Wartet auf die Kasse“, danach das Ergebnis, auch nach dem Neuladen der Seite.

Jedes Artikelbild lässt sich mit „Ersetzen“ in einem Schritt austauschen, auch per Ziehen einer Datei; im Bilder-Import gelingt das für viele Bilder auf einmal, mit Vorschau. Der digitale Bon zeigt die TSE-Angaben jetzt genau wie der Papierbon, auch bei bereits ausgegebenen Belegen.

Unter Einstellungen → Artikel → Gänge bekommt jede Kategorie einen festen Gang, zum Beispiel Getränke „ohne Gangfrage“ und Speisen „Gang wird erfragt“; Unterkategorien erben ihn. Dasselbe gibt es im Kundencenter bei der Fernpflege der Gänge. Der Schalter „Beim Bestellen nachfragen“ steht direkt in der Liste, die fünf Werksgänge lassen sich nicht mehr löschen, nur ausblenden.

„Umbuchen“ in der Lager-App bewegt jetzt wirklich Bestand, mit Charge und MHD, und nur aus freier Menge. Lehnt BIS ERP eine offline vorgemerkte Buchung ab, bleibt sie mit Grund sichtbar und lässt sich erneut senden oder verwerfen. Neu sind ein Beweisfoto je Artikel auf der Palette und Fotoaufträge für Artikel ohne Bild (beide ab Werk aus) sowie das gezielte Kommissionieren über Picklisten-Vorlagen mit „Jetzt zu tun“ auf der Startseite.

Oben auf der Artikelseite stehen jetzt Bild, Name, Artikelnummer, EAN, Status und der Bestand (verfügbar, reserviert, im Zulauf), dazu „Alles gespeichert“ mit dem Zeitpunkt der letzten Änderung. Die vierzehn Reiter sind in acht Bereiche geordnet (Stammdaten, Preise & Kanäle, Lager & Logistik, Einkauf, Varianten, Medien, Compliance, Auswertung), mit einer Navigation rechts und am Handy als Blatt von unten. Der JTL-Schutz speichert sofort beim Umlegen.

Die Geräteliste im Kundencenter (Kassen → Kassen und Geräte) zeigt oben die Geräte in Betrieb, alte, ersetzte und lange nicht gemeldete stehen eingeklappt unter „Nicht mehr aktiv“. Ein schon verbundenes Gerät wird beim Entfernen stillgelegt statt gelöscht, sein Kürzel bleibt für Bonnummern und Belege reserviert. Eine Lager-App belegt keine Kassen-Lizenz mehr, und Kassen-PINs gehen nur noch an verbundene Kassen.

Das Kundencenter ordnet alle Seiten in acht Bereiche (Start, Kassen, Verkauf, Berichte, Team, Anbindungen, Konto, Hilfe) mit Reitern, alte Links und Lesezeichen führen automatisch weiter. Neu ist die Seite „Bestellmaske der Kellner“: Layout der Kellner-Geräte wählen oder selbst zusammenstellen, mit bedienbarer Vorschau, an die Hauptkasse übertragen und je Gerät sehen, ob es angekommen ist. Die Bestellmaske wirkt ab Kasse 1.3.9.

Scheitert das Speichern eines Artikels, bleiben Maske und Eingaben erhalten und der Hinweis steht in der Seite. Zutaten und Nährwerte speichern zusammen mit dem Artikel. Wer Artikel nur ansehen darf, sieht einen Lesemodus. Einkaufspreise und Marge zeigen Preiskalkulation, Artikelexport und Import nur noch mit dem Kostenrecht, Zutaten und KI-Artikelassistent verlangen die passenden Artikelrechte.

Ab Kasse 1.3.9 stehen Einlagen, Entnahmen, Geldtransit und Kassendifferenzen als signierte Belege im Kassenabschluss für die Prüfung (DSFinV-K). BIS ERP wertet eine Kassensitzung, in der nur Geld bewegt wurde, ab dem 19.10.2026 nicht mehr als „leer“.

Beim Geräte-Ankauf mit Zahlart PayPal kann die Kasse den Betrag jetzt direkt über PayPal an die E-Mail-Adresse des Verkäufers senden, statt dass Sie ihn selbst überweisen – nur wenn Sie es in BIS ERP erlauben und eine berechtigte Person mit ihrer PIN freigibt.

Wer Gebrauchtgeräte nach § 25a verkauft, sieht die Umsatzsteuer auf die Marge jetzt auch in EÜR, BWA, Anlage EKS und der Umsatzsteuer-Voranmeldung der Kasse – nach derselben Regel wie im DATEV-Export.

Der Knopf „Jetzt synchronisieren“ im Kundencenter unter BIS Remote wirkt wieder: Die Kasse holt die Einstellungen sofort ab, und die Seite zeigt, ob sie angekommen sind oder die Kasse gerade nicht erreichbar ist.

Anhänge von Support-Anfragen sehen nur noch Beteiligte, Anhänge unveröffentlichter Antworten erst nach dem Versand, und SVG-Dateien kommen als Download.

Artikelbestand und Lagerbestand laufen nicht mehr auseinander: Die Neuberechnung lässt Artikel ohne Bestandsführung und Lagerzeilen gelöschter Artikel aus, die Bestandskorrektur zeigt beide Werte und rechnet mit dem höheren, und beim Einschalten der Bestandsführung übernimmt BIS ERP den Lagerbestand.

Gibt ein Kunde an der Kasse nur einen Teil der Ware zurück, bleibt die zugehörige A4-Rechnung bestehen. Bisher wurde sie komplett storniert; jetzt tut das nur eine vollständige Rückgabe.

Im Kundencenter unter „BIS Remote“ wirkt die Verwaltung Ihrer Kassen jetzt verlässlicher: Überflüssige Kacheln sind weg, vor heiklen Aktionen fragt die Oberfläche nach, und gesperrte Einstellungen greifen sofort an der Kasse.

API-Schlüssel und Webhooks anlegen, ändern, erneuern, löschen und testen dürfen nur noch Administratoren und der Lizenzinhaber des Betriebs. Andere Benutzer sehen die Liste weiter, bestehende Schlüssel arbeiten unverändert.

In der Kundenakte zeigt der neue Reiter „E-Mails“ jede Mail an den Kunden – Rechnung, Lieferschein, Auftragsbestätigung, Angebot, Kassen-Rechnung und mehr – mit Beleg, Versandweg und ehrlichem Status. „Vom Mailserver angenommen“ ist kein Zustellnachweis, Tracking gibt es nicht.

Hat ein Artikel im Verkaufskanal keinen Preis, lässt der Shop ihn in Listen weg, statt die ganze Seite mit einem Fehler abzubrechen. Die Zufallsauswahl zeigt nur kaufbare Artikel, und der Pfand-Artikel erscheint nicht mehr als Kaufempfehlung.

Aus JTL übernommene Kunden werden nicht mehr mit Standardwerten zurück nach JTL geschrieben – Rabatt, Zahlungsziel, USt-IdNr. und Adresszusatz bleiben erhalten. Ältere Kassen (bis 1.3.4) legen beim Artikelabgleich nur noch an, was die Einstellungen erlauben, und bekommen keine unvollständigen Artikelkopien mehr.

Nach falschen Passwörtern wird die Anmeldung kurz gebremst statt das Konto zu sperren, mit Anmeldeprotokoll. EÜR und Anlage EKS zählen auf Ist-Basis jede Zahlung am Zahltag, auch Teilzahlungen. Offene Rechnungen rechnen Gutschriften richtig, Gutschriften aus JTL-Wawi kommen vollständiger, und die Online-Tischreservierung ist gegen Missbrauch abgesichert.

Einen an der Kasse angelegten Kunden verbindet BIS ERP nur noch mit einem bestehenden Kunden, wenn Vor- und Nachname übereinstimmen und ein sicheres Merkmal passt – E-Mail, Telefon, vollständige Anschrift oder Kundennummer. Sonst entsteht ein neuer Kunde. Gepflegte Kundendaten wie Rabatt und Zahlungsziel überschreibt die Kasse nicht mehr, auch nicht in JTL-Wawi.

Die vorläufige Anlage EKS schätzt kommende Monate jetzt aus dem Median der letzten sechs Monate plus Wachstum (höchstens 10 % pro Monat) – für Abos, Aufträge, Kasse und Rechnungen. Sicher bekannte Zahlungen zählen, wenn sie höher sind. Der Wechsel zwischen vorläufiger und abschließender Erklärung zeigt sofort die passenden Zahlen.

Beim automatischen Abruf von Rechnungen aus dem E-Mail-Postfach bleiben die Mails erhalten – gelesen markiert und in den Ordner „Verarbeitet“ verschoben, gelöscht wird nur auf Wunsch. Artikel mit 0 % Mehrwertsteuer behalten in Aufträgen und Rechnungen ihren Satz. In der Web-Kasse entscheidet die PIN-Anmeldung, wer Artikel und Mitarbeiter pflegen darf.

BIS ERP erkennt einen Geräte-Ankauf an einer eigenen, weltweit eindeutigen Kennung. Wird eine Kasse ohne Datensicherung neu eingerichtet, kommen ihre neuen Ankäufe trotzdem vollständig im Ankaufsbuch an. Bestehende Einträge bleiben unverändert; die Kasse sendet die Kennung ab dem nächsten Update.

Vier neue Bausteine für Ihren BIS Shop, alle ab Werk ausgeschaltet und in BIS ERP schaltbar: eine eigene Kopfnavigation, die „Neu“-Fahne aus dem ersten Wareneingang mit der Seite „Neu im Sortiment“, die Startseiten-Reihe „Zuletzt eingetroffen“ und das Ursprungsland als Sticker auf der Artikelkachel.

Die Anlage EKS für das Jobcenter ist neu aufgebaut: Vorläufige und abschließende Erklärung haben je einen eigenen, gespeicherten Bewilligungszeitraum. Abgeschlossene Monate zeigen die echten Zahlen, kommende Monate eine Schätzung aus laufenden Abos, offenen Rechnungen und regelmäßigen Ausgaben – mit Herleitung zu jeder Zahl. Außerdem erkennt der Revolut-Import bereits eingelesene Umsätze.

Rechtstexte Ihres BIS Shops pflegen Sie jetzt direkt in BIS ERP, je Shopsprache, und der Shop zeigt sie als eigene Seiten. Die Bestellbestätigung enthält die beim Kauf gültige Fassung, vor dem Bestellknopf steht der Hinweis auf AGB und Widerrufsbelehrung, und fehlende Pflichttexte meldet eine Glocke.

Storniert die Kasse einen Kauf auf Rechnung, den der Kunde schon bezahlt hat, zeigt BIS ERP jetzt „Erstattung offen“ – in der Glocke, unter Aufträge und im Auftrag. Nummernkreise protokollieren jede Änderung und jeden Sprung, die Vorschau zeigt die tatsächlich nächste Nummer. In der Web-Kasse bekommen Reparaturen den Steuersatz Ihres Landes, steuerfreie Artikel bleiben steuerfrei und das Bearbeiten überschreibt weder Preis noch Bestand.

Gutschriften mindern den Umsatz jetzt auch in EÜR und Anlage EKS (an ihrem Gutschriftsdatum, sobald die Rechnung bezahlt ist) und bei an der Kasse bezahlten Rechnungen auch in BWA und DATEV. Zahlungen, Bezahlt-Datum und aufgehobene Gutschriften aus JTL-Wawi kommen laufend und vollständig an. Die Mails der Online-Terminbuchung und Tischreservierung sind überarbeitet, die Gutschriften-Liste öffnet wieder.

Artikel mit Verwiegepflicht werden an die Kassen jetzt einheitlich als teilbar übertragen. Der CSV-Import setzt bei Verwiegepflicht „Stückzahl teilbar“ automatisch mit, wie die Artikelmaske. Die Anleitung zu Wiegeartikeln ist korrigiert.

BIS ERP übernimmt Einträge ins Ankaufsbuch nur noch von der Kasse, an der der Ankauf stattfand, und leert gespeicherte Angaben nie durch eine unvollständige Übertragung. Kaufzeitpunkt, Kassierer und Storno bleiben nach dem ersten Speichern unverändert. Im Ablauf an der Kasse ändert sich nichts.

Stripe-Zahlungen tragen das richtige Zahldatum und erscheinen damit vollständig in EÜR und Anlage EKS. Jede Zahlung wird der richtigen Rechnung zugeordnet, Stripe-Auszahlungen werden zweimal täglich automatisch mit dem Bankeingang abgeglichen, in Stripe stornierte Rechnungen zählen nicht mehr als Umsatz, und die Abo-Zuordnung funktioniert wieder.

Der BIS Shop verschickt jetzt selbst die Bestellbestätigung mit Widerrufsbelehrung, Muster-Widerrufsformular, AGB und dem amtlichen Gewährleistungshinweis, außerdem die Mails für „Passwort vergessen“ und die Kontobestätigung. In BIS ERP pflegen Sie Widerrufsbelehrung und AGB je Shopsprache; eine Übersicht zeigt, was noch fehlt, und eine Glocke meldet, wenn Shop-Mails nicht ankommen. Der Gewährleistungshinweis steht jetzt direkt sichtbar oben auf der Bestellseite und in der Einseiten-Kasse.

Ein Geräte-Ankauf an der Kasse legt den Verkäufer als Kunden an oder ordnet ihn einem bestehenden Kunden zu – Ankäufe, Verkäufe und Reparaturen hängen dann am selben Kunden. In die Kundenkartei gehen nur Name, Anschrift und Kontakt, die Ausweisdaten bleiben im Ankaufsbuch. Neue Kunden lassen sich an der Kasse per Personalausweis anlegen, in der Branche Handyshop ab Werk eingeschaltet.

Ein noch nicht bezahlter Kauf auf Rechnung lässt sich mit dem nächsten Kassen-Update in der Verkaufshistorie stornieren – immer der ganze Beleg, ohne Auszahlung. BIS ERP storniert dazu den Auftrag und hebt die Rechnung auf. Führt JTL-Wawi Ihre Rechnungen, meldet BIS ERP, was dort von Hand zu stornieren ist.

Ein neuer Filter in der Artikelliste zeigt alle Artikel, bei denen Steuerklasse und Steuersatz nicht zusammenpassen. Ein Hinweis am Artikel erklärt, was nicht passt und mit welchem Satz die Kasse gerade verkauft. BIS ERP stellt nichts automatisch um – Sie entscheiden.

Ist einer Kasse im Zuordnungsmodus noch kein Artikel zugeordnet, zeigt das Kundencenter das jetzt deutlich an – statt still „0 / 0 Artikel“. Mit einem Klick übernehmen Sie das Sortiment einer anderen Kasse. Steuert JTL-Wawi das Sortiment, führt der Hinweis zu den POS-Verkaufskanälen im Kundencenter.

Im Design Studio gibt es die neue Etikettenart „Artikeletikett“ mit Barcode, Artikelname, Artikelnummer und Preis samt Grundpreis, dazu eine Werksvorlage 62 × 29 mm. Alle Etiketten prüfen die EAN-Prüfziffer vor dem Barcode: Bei falscher EAN kommt der Barcode aus der Artikelnummer oder entfällt, der Druck bricht nicht mehr ab. Die Bezeichnungen der Etikettenarten sind übersetzt.

Jede Gutschein-Vorlage bekommt beim Speichern ihren eigenen Artikel mit einer Nummer aus Ihrem Artikelnummernkreis – unter dieser Nummer verkauft die Kasse den Gutschein. Mit dem Schalter „Offener Betrag“ wird der Wert erst an der Kasse eingegeben. Änderungen an anderer Stelle werden nicht überschrieben, und die Gutschein-Artikel tauchen nicht in Web-Kasse, BIS Shop oder der Auswahl in Aufträgen, Angeboten und Rechnungen auf.

Der DATEV-Export der Kassen bucht Pfand und Leergut-Rücknahmen auf ein eigenes Erlöskonto und Ankäufe gebrauchter Geräte auf ein eigenes Wareneingangskonto. Einlagen, Entnahmen, Bankeinzahlungen, Trinkgeld-Auszahlungen und Kassendifferenzen bucht BIS ERP nach derselben Regel wie die Kasse – beide Exporte ergeben dieselben Buchungen. Berater- und Mandantennummer werden beim Speichern geprüft, die Kassenkonten werden nur noch an einer Stelle gepflegt.

Kommen die Artikel aus JTL, ist die Steuerklasse verknüpfter Artikel in BIS ERP gesperrt, statt sich ändern und beim nächsten Abgleich still zurücksetzen zu lassen. Bei Artikeln ohne JTL-Abgleich wechselt die Steuerklasse sofort, und jeder Preis bleibt so, wie seine Kundengruppe ihn anzeigt. Die Massenbearbeitung leitet den Steuersatz wie die Artikelmaske ab. Vorbereitet ist die Übergabe einer geänderten Steuerklasse samt Nettopreisen an JTL, die je Betrieb freigeschaltet wird.

Eine Möglichkeit einer Auswahlgruppe kann jetzt auch den Preis senken: ein Abschlag mit Minus, etwa „-0,50“ für eine kleine Portion – ein Artikel wird dadurch nie günstiger als 0,00 €. Übersteigt ein möglicher Abschlag den Verkaufspreis einzelner Artikel, zeigt die Gruppenliste einen Hinweis. Die Bestellseite für Gäste rechnet Abschläge wie die Kasse und nimmt nur noch Zusatzwünsche an, die zum Gericht gehören.

Bar- und Kartenverkäufe, zu denen JTL zusätzlich eine Rechnung schreibt, und Rechnungskäufe an der Kasse zählen in BWA, EÜR und DATEV nur noch einmal. Lagerbuchungen in BIS ERP und der Lager-App laufen ganz oder gar nicht, neue Rechte schützen Gutscheine, Rabatte, Treue, Terminplaner und archivierte Kassenbelege, und die Steuergebiete Kanaren, Ceuta und Melilla werden erkannt.

Die Web-Kasse druckt Kassenbon und Küchenbon jetzt wirklich über BISPrint, nimmt Leergut mit Ihren eigenen Pfandarten zurück und rechnet Pfand mit dem Steuersatz aus Ihrem Pfandkatalog. Kassen dürfen Beilagen- und Modifikator-Gruppen bei Abgleich in beide Richtungen mitpflegen, ohne dass eine Änderung still überschrieben wird. Ein ausdrücklich am Artikel gespeicherter Steuersatz (19, 7 oder 0 %) bleibt an der Kasse jetzt immer stehen. Dazu: doppelte Z-Bons werden abgewiesen, Trinkgeld wird nur auf die verkaufte Leistung verteilt, der AVV liegt in Version 1.7 vor, und Gutschein-Vorlagen aus BIS ERP blockieren den Kassen-Abgleich nicht mehr.

Die Umsatz-Kachel und der Umsatzverlauf zählen in JTL fakturierte Aufträge nicht mehr doppelt, neue Gutscheine erhalten einen zufälligen Code statt einer fortlaufenden Nummer, und der JTL-Abgleich korrigiert falsche Steuersätze und Steuerklassen von Artikeln und Ausführungen selbst. Ein Bon, den die Kasse nach einem Verkauf ohne Internet nachreicht, trägt Datum und Uhrzeit des Verkaufs, eine Teilrückgabe an der Kasse storniert die A4-Rechnung nicht mehr ganz, der Kundenimport per Datei und der Etsy-Bildupload funktionieren wieder, Shopee-Shops lassen sich erneut verbinden, die Kasse erhält die echten Seriennummern von Kasse und TSE, und Firmeneinstellungen wie Logo, Bankverbindung oder Kleinunternehmer-Regelung gehen beim Speichern der Unternehmensdaten nicht mehr verloren.

Die KI-Artikelanlage (Fotos der Verpackung zu Artikeldaten), die Zutaten-Erkennung aus dem Etikettenfoto und die Bildauswertung der Produktdatenbank laufen ab jetzt automatisch auf dem jeweils neuesten Claude-Modell (heute Claude Sonnet 5.5; die Gegenkontrolle bei KI-Artikelanlage und Zutaten-Erkennung nutzt das neueste Opus-Modell, heute Opus 5.5). In den Einstellungen wählen Sie nur noch die Modellfamilie; neue Fassungen werden ohne Umstellung genutzt, und weist eine neue Fassung eine Anfrage ab, übernimmt automatisch die Vorgängerfassung. Die Preise je Anlage bleiben unverändert.

Gutschriften, Proforma-Rechnungen und Rechnungskorrekturen tragen im PDF und in der E-Mail ihren eigenen Titel und keine Zahlungsaufforderung mehr, die Zahlungsbedingung passt zum Fälligkeitsdatum, und der Lieferschein zeigt jede Auftragszeile mit ihrer eigenen Menge. Versand und JTL-Bestandsabgleich buchen nicht mehr doppelt, Steuerauswertungen und Einkaufspreise sind nur mit dem passenden Recht sichtbar, Pfand-Rückgaben zählen in der EÜR wieder mit, Retourenfotos bleiben dauerhaft gespeichert, und die Online-Terminbuchung richtet sich zuverlässig nach den Öffnungszeiten.

Auftragsformulare blenden keine Browser-Adressvorschläge mehr ein, der CSV-Export im Lagerplatz-Assistenten und die Suche im Lagerplatz-Etikettendruck funktionieren, das Versandgewicht automatisch erzeugter Sendungen stimmt wieder, und die Tageszahlen im Dashboard zählen auch manuell angelegte Aufträge ohne Bestelldatum.

Der öffentliche Bug-Tracker zeigt jetzt auch Fehler, die das BISpicy-Team selbst findet und die Kunden betreffen können – jeweils mit eigenem, neutralem Text. Ihr Stand folgt der Bearbeitung von bestätigt über in Arbeit bis behoben. Sicherheits- und Datenschutzfälle erscheinen dort grundsätzlich nicht.

Datenschutzerklärung und AVV beschreiben den freiwilligen Vorfallbericht bei Kartenzahlungen. Der Händlerbeleg zeigt die Kartennummer gekürzt, gespeicherte Terminalbelege werden mit gekürzter Kartennummer abgelegt.

Im Kundencenter unter Integrationen → PayPal / Zahlungen waren „PayPal-Konto hinzufügen“, Bearbeiten und Löschen für alle Konten gesperrt, auch für den Inhaber. Inhaber und Admins können die Zugangsdaten jetzt wieder hinterlegen; erst danach zeigt die Kasse bei der Zahlart PayPal den QR-Code.

Ankäufe aus der Kasse werden mit Zahlart (bar, PayPal, Überweisung, sonstige unbar) im Ankaufsbuch und in der § 25a-Auswertung angezeigt, korrigierte Zahlart oder Preis und Stornos mit Vermerk und Grund. Der Cloud-Kassenabschluss zeigt unbare Ankäufe getrennt von den Barauszahlungen.

Der Bug-Tracker, die Seiten zur KI-Bridge, die API-Dokumentation und Pay-per-use erscheinen im neuen BISpicy-Design. Gemessen wird der Median der in den letzten 90 Tagen behobenen Bugs, von der Meldung bis zum Fix, ohne Optimierungswünsche; daneben steht der älteste offene Bug.

Was an der Kasse unter „Rückbuchung bei Storno“ eingestellt ist (Nie, Immer, Nur einfache Artikel), gilt ab Kasse 1.3.5 auch in BIS ERP und JTL – für Bestand, Lager, Bestandsjournal und Seriennummern. Die Vorgabe ist „Nie“: Ohne eigene Wahl bucht ein Storno keinen Bestand mehr zurück; bisher wurde in BIS ERP trotzdem immer zurückgebucht.

Den DATEV-Export deiner Rechnungen und Belege nutzt du jetzt in jeder Stufe. Der Kassen-Export aller Kassen gesammelt steht auch in BIS ERP unter Berichte → Steuerberichte (POS) → DATEV und bleibt Teil von BIS Insights.

Bei differenzbesteuerten Gebrauchtgeräten (§ 25a UStG) zeigt der digitale Bon jetzt denselben Hinweis wie der Papierbon, und die irreführende Zeile „0 % · MwSt 0,00“ entfällt – auch bei bereits ausgegebenen Bons. Neue A4-Rechnungen weisen statt einer 0-%-Zeile den Hinweis aus.

Eine Teillieferung über den Schnellversand merkt sich jetzt die gelieferte Menge je Position – Restmenge, Reservierung und Packtisch stimmen, und mit „nur gelieferte Ware berechnen“ enthält die Rechnung nur das Gelieferte. Beim vollen Schnellversand stehen auf dem Lieferschein in BIS ERP und JTL wieder alle Positionen; Mengen mit Nachkommastellen werden genau übernommen.

Whatnot-Angebote legst du jetzt direkt im Artikel an: Kategorie und Versandprofil wählen, als Entwurf anlegen, veröffentlichen, zurückziehen oder löschen. Preise aus BIS ERP gleichen sich auf Wunsch automatisch mit Whatnot ab.

Geht ein Auftrag in mehreren Packrunden oder Paketen raus, bucht JTL je Sendung genau die gepackte Menge – bisher konnte jede weitere Runde die volle Auftragsmenge noch einmal abbuchen. Mehrere Pakete einer Sendung zählen vollständig, Teillieferungen per Schnellversand merken sich die gewählten Positionen, und der Lieferschein kommt in JTL immer an.

Unter „Staffelpreise“ zeigt die Artikel-Info der Lager-App nur noch echte Mengenstaffeln. Bisher standen dort auch die Gebindepreise je Kundengruppe – etwa „ab 1 Stk 240,01 €“ bei einem Artikel zu 0,80 € je Stück. Gebindepreise stehen weiter im Abschnitt „Gebinde“, an der Kasse ändert sich nichts.

Ausführungen, die per Artikel-Import oder an der Kasse neu entstehen, übernehmen jetzt Bestandsführung und Steuerklasse vom Vater – was die Datei ausdrücklich angibt, gewinnt, und der Steuersatz des Bons bleibt immer stehen. Die Kasse bucht teilbare Artikel und Wiegeware exakt (0,5 kg statt bisher nichts), nicht teilbare Artikel immer in ganzen Stück.

Ein an der Kasse angekauftes Gebrauchtgerät behält in BIS ERP IMEI, Zustand „Gebraucht“ und Bestandsführung, und neue Ankäufe sind im Ankaufsbuch wieder mit dem Artikel verknüpft. Die §25a-Marge stimmt jetzt auch bei einem Storno, und ein Einzelstück steht nach Storno und Wiedereinbuchen nie doppelt im Bestand.

Der Lagerplatz-Abgleich mit JTL ist jetzt eine eigene Einstellung (ab Werk aus) und schreibt nie in ein JTL-Standardlager. Sendungen, die schneller zugestellt als übertragen wurden, trägt BIS ERP in JTL nach – ohne Doppelbuchung. Veraltete Stücklisten aus JTL werden nach Prüfung deaktiviert, und Kampagnen-Mails finden ihren Empfänger.

Unter CRM → ABC-Klassen zeigt eine Matrix, wie viele Kunden zwischen zwei Monaten von einer ABC-Klasse in eine andere gewechselt sind, zum Beispiel von B nach A. Ein Klick auf eine Zahl öffnet genau diese Kunden in der Kundenliste. Die Einstufung wird ab jetzt jeden Monat festgehalten, die erste Wanderung ist ab dem zweiten Monat zu sehen.

Händler mit eigenem Whatnot-API-Schlüssel verbinden BIS ERP mit Whatnot: Bestellungen aus Live-Shows und Marktplatz kommen automatisch als Aufträge an, Bestände gleichen sich ab, Sendungsnummern gehen zurück.

Ausführungen (Farbe/Größe) haben jetzt dieselben Schutzregeln wie Artikel, und die Sperre greift nur noch beim echten Statuswechsel. Der Abgleich mit JTL übernimmt Retouren- und Rabattzeilen vollständig und meldet gleiche Warenkörbe nicht mehr fälschlich als Unterschied.

Fällige Wiedervorlagen lassen sich in CRM → Heute und in der Kundenakte mit einem Häkchen als erledigt markieren, auf Wunsch gleich mit einer neuen Wiedervorlage. Sie verschwinden danach aus der Anrufliste, der Glocke und der Dashboard-Kachel. Wer wann abgehakt hat, bleibt sichtbar.

Der Stand gesendeter Etikettenaufträge wird jetzt auch bei vielen Etiketten zuverlässig angezeigt und läuft bis „gedruckt“ weiter; eine Bezugsmenge wie „1 g“ wird als nicht gesetzeskonform gemeldet.

Das Kassenjournal zeigt jetzt, wenn der Anfangsbestand einer Kassensitzung vom gezählten Endbestand der vorherigen abweicht – mit Betrag und beiden Z-Bons. Summen und Salden bleiben unverändert.

Enthält ein Auftrag ein Set aus BIS ERP (Artikel mit Stückliste), stellt die Pickliste die Bestandteile zusammen. Jetzt buchen auch Packtisch, Versand und Storno genau diese Bestandteile. Vorher wurde beim Versand das Set selbst abgebucht, die Bestandteile blieben reserviert und die Verfügbarkeit stimmte nicht mehr.

Führt ein Fulfillment-Dienstleister den Bestand eines Lagers, schreibt BIS ERP für dieses Lager keine Bestandsbuchungen mehr nach JTL. Vorher konnte eine Fulfillment-Sendung in JTL Ware aus dem eigenen Lager ausbuchen, obwohl sie beim Dienstleister lag.

Hat ein Neukunde eine fällige Wiedervorlage, steht er in CRM → Heute nur noch unter „Neukunden“ und nicht zusätzlich in „Akquise“ oder „Reaktivierung“ unter „Meine“. So ruft niemand denselben Neukunden versehentlich zweimal an. Die Dashboard-Kachel „Meine Wiedervorlagen“ zählt dieselbe Menge.

BIS ERP stellt Preisschilder künftig für Kasse und Lager-App bereit: Vorlagenliste und fertig gestaltetes Etikett je Artikel, gestaltet wird nur im Design Studio. Die Geräte brauchen dafür eine App-Version mit PDF-Etiketten, die für Kasse und Lager-App folgt – bis dahin druckt jedes Gerät wie bisher.

Aufträge aus JTL mit Stückliste (Set oder Gebinde) werden jetzt richtig bewertet: Der Wareneinsatz zählt nur einmal als Summe der Bestandteile, gepickt und gebucht werden nur die Bestandteile.

Der automatische Berichtsversand (BIS Insights) schickt jetzt zusätzlich den DATEV-Stapel „Kassenbewegungen“ mit: Geldtransit zur Bank, Einlagen, Entnahmen, Kassendifferenzen und Trinkgeld. Beide Stapel sind je Monat zu importieren, sie überschneiden sich nicht.

Vertriebsmitarbeiter bekommen im Dashboard die Vorlage „Vertrieb“ mit ihren Wiedervorlagen, neuen Kunden, eigenen Kontakten und Kunden mit Potenzial. Umsatz, Auftragsstand, Forderungen und Versandzahlen zeigt das Dashboard nur noch Rollen mit dem neuen Recht „Betriebszahlen im Dashboard“ – ab Werk Administrator, Manager und Buchhaltung.

Stücklisten bearbeiten setzt jetzt das Recht „Artikel bearbeiten“ voraus und wird als Ganzes gespeichert; Mengen müssen größer als 0 sein. Lager, die einem JTL-Lager zugeordnet sind, werden beim Speichern auf Widersprüche geprüft, und Bestandsbuchungen gehen verlässlich ins richtige JTL-Lager. Bestandsbuchungen für Artikel, die JTL ohne Lagerführung führt, werden erkannt und nicht endlos wiederholt.

Packtisch und Pickliste funktionieren wieder bei allen Betrieben, auch bei solchen, die noch nie kommissioniert oder eigene Versandarten angelegt hatten. Die Statusknöpfe im Auftragsdialog führen ihre Änderung wieder aus. Ein beim Buchen angegebener Lagerplatz aus einem anderen Lager wird jetzt verständlich gemeldet, statt still lagerweit zu buchen. Neue Artikel-Ausführungen erben Bestandsführung und Steuerklasse vom Vaterartikel, und der Artikel-Abgleich übernimmt JTL-Einkaufspreise auch für Artikel ohne eigenen Verkaufspreis.

Scheitert in BIS ERP das Speichern eines Kassenbelegs, meldet BIS ERP das jetzt der Kasse zurück, und die Kasse sendet den Beleg automatisch noch einmal. Bisher galt er als übertragen und fehlte im Kassenbericht, in DATEV und in JTL. Eine erneute Übertragung erkennt BIS ERP sicher wieder, ohne zweiten Auftrag. Bei Gutscheinzahlungen an der Kasse zeigt der digitale Bon den Warenwert und darunter „davon Gutschein“, nie einen Gutscheincode.

Die ABC-Einteilung der Kunden lässt sich jetzt auch nach Bestellrhythmus und Umsatz berechnen: A+ für aktive Kunden mit hohem Monatsumsatz, A für Stammkunden, die fast jeden Monat bestellen, B für regelmäßige und C für gelegentliche Besteller. Die Grenzen stellst du unter Einstellungen → Order Desk → Kunden-ABC selbst ein.

Den Betreuer eines Kunden weist du jetzt direkt in der Kundenliste zu – per Rechtsklick auf die Zeile („Betreuer zuweisen“) oder in der Spalte „Betreuer“. In der Kundenakte speichern Betreuer, ABC-Klasse und Gebiet, ohne dass die Seite nach oben springt.

Die Kasse (Hauptkasse und Kellner-Gerät) schickt auf Wunsch des Gastes einen Link auf den digitalen Bon per E-Mail. Es gibt keine Werbung in der Nachricht.

CRM → Heute hat den neuen Bereich „Neukunden“: frisch angelegte Geschäftskunden zum Begrüßen und nach rund einer Woche zum Nachfassen, aus JTL, Kasse, Kundenportal, Marktplätzen und BIS Shop. Die CRM-Übersicht zeigt dazu, wie viele Kunden jeder Mitarbeiter kontaktiert hat.

JTL-Gutscheine werden an der Kasse jetzt über eine eindeutige Belegkennung abgebucht statt über die Bonnummer. Nach einem Kassen-Reset oder auf einer zweiten Kasse konnte eine neue Abbuchung sonst als „schon gebucht“ gelten, ohne dass der Gutschein belastet wurde.

Wird ein Set (JTL-Stückliste) an der Kasse, per Versand oder per Forderungsausgleich verkauft, bucht BIS ERP in JTL immer die enthaltenen Komponenten ab, nie das Set selbst. Das gilt jetzt fest für alle Betriebe und braucht keine Einstellung mehr.

Deaktivierst oder reaktivierst du im Varianten-Bereich eines Artikels eine Ausführung (Farbe/Größe), bleibt das jetzt bestehen. Vorher drehte ein interner Abgleich den Status still zurück.

Legt BIS ERP einen Artikel in JTL an, wird der Bestand jetzt je Lager, Lagerplatz, Charge und MHD so übernommen, wie er in BIS steht, statt als eine Summe im Standardlager. Kann JTL eine Buchung nicht annehmen, wartet der Artikel mit einem Hinweis.

Artikel mit Belegen (Aufträge, Rechnungen, Retouren, Eingangsrechnungen, Seriennummern, Inventur, Kassenbons) werden beim Löschen nicht mehr endgültig gelöscht, sondern nur deaktiviert. So bleiben Belege und Auswertungen vollständig (GoBD). Artikel ohne Belege werden weiter gelöscht.

Bons, die vollständig mit Gutschein bezahlt wurden, Forderungsausgleich-Bons ohne Restbetrag und Ware zu 0 € galten fälschlich als Pfandrückgabe. Sie erscheinen jetzt korrekt in Kassenbericht, Belegzahl, Kassenjournal, EÜR, Verkaufsanalyse, Dashboard und im DATEV-Kassenexport.

Löschen und Deaktivieren eines Artikels folgen jetzt der Artikel-Richtung zu JTL, in beide Richtungen. In JTL wird ein Artikel nur gelöscht, wenn es dort keine Belege, kein Lagerjournal und keinen Bestand gibt, sonst wird er deaktiviert. Ab Werk läuft alles im Probelauf, scharf wird je Mandant geschaltet.

Wurde ein Kassenabschluss erneut übertragen, standen Entnahmen, Einlagen und Differenzkorrekturen mehrfach im Kassenbuch. Jede Bewegung zählt jetzt nur noch einmal – im Kassenbuch, im Abschluss und im Berichtsversand, nach derselben Regel wie der DATEV-Export.

Bei sehr großen Artikelkatalogen schützt BIS ERP ältere Kassen-Versionen vor Abstürzen durch aufwendige Fernbefehle. Außerdem zeigen die Kassen-Sync-Einstellungen laufende Fernbefehle jetzt korrekt an, und Cloud-Backups der Kasse gibt es nur noch mit Lizenz.

Löschanfragen nach DSGVO über die Schnittstelle (Kunde löschen) funktionieren wieder: Personenbezogene Kundendaten werden zuverlässig anonymisiert, Belege bleiben unverändert. Bei offenen Rechnungen wird die Löschung mit Begründung abgelehnt.

Der Server lädt Bilder beim Import aus einer URL-Liste nur noch von öffentlichen Adressen über die üblichen Web-Ports (80/443). Adressen im internen Netz werden abgelehnt.

Wurde ein Bon an der Kasse storniert, bevor er hochgeladen war (z. B. nach Offline-Zeit), zogen Kassenbericht, Kassenbuch, EÜR/BWA und der Kassenanteil der UStVA den Betrag doppelt ab. Jetzt heben sich Original und Storno auf.

In BIS ERP angelegte Artikel, auch mit Ausführungen, werden in JTL-Wawi angelegt, sofern die Artikel-Richtung „bidirektional“ oder „BIS ERP → JTL“ lautet. Auch bestehende BIS-Artikel werden jetzt nachgezogen.

Umsatz-Analyse und Dashboard ziehen stornierte Kassenbons und Gutschriften jetzt vom Umsatz ab. Belegzahl und Durchschnittsbon stimmen wieder.

Der Reiter „Journal“ am Artikel lädt wieder bei allen Betrieben. Bestandsbewegungen werden dort wieder vollständig protokolliert, mit Bestand vorher/nachher, Charge und MHD.

Stellen Sie einen Auftrag von Hand auf „versendet“, wird die Ware jetzt genau einmal ausgebucht, auch vom Kommissionierwagen und mit offenem Rest. Ein Storno vor dem Versand bringt gepickte oder verpackte Ware zurück ins Regal.

Im Kundencenter gibt es den neuen Bereich „Altdaten aus Vorsystem“. Dort laden Sie die Originalexporte Ihres früheren Kassensystems hoch (DSFinV-K-Export, TSE-Export, Journale, Z-Bons, Verfahrensdokumentation, bis 150 MB je Datei). Jede Datei wird unverändert gespeichert, mit Prüfsumme und automatischer Lesbarkeitsprüfung, und der Eingang wird per E-Mail bestätigt. Enthalten für jeden zahlenden Betrieb, auch ohne BIS-Archiv-Lizenz.

Kunden, die vor der Übernahme nach BIS ERP in JTL bestellt haben, gelten nicht mehr als „nie bestellt“: „Letzte Bestellung“ zeigt das JTL-Datum, und sie erscheinen in der Reaktivierung statt in der Akquise. In der Kundenliste öffnet ein Klick auf das Datum unter „Letzter Kontakt“ den Vermerk direkt. CRM → Heute, Tourvorschau und Anruf-Modus zeigen Telefon- und Mobilnummer anklickbar in der Zeile. Neu ist das Feld „Kundenprofil“ am Kunden.

Wurde ein Auftrag auf einen Kommissionierwagen oder ohne Lagerplatz gepickt und danach im Browser versendet (Sendung anlegen, Label neu erstellen, „Erneut versuchen“), blieb der Bestand bisher unverändert und die Ware stand weiter auf dem Wagen-Platz. Jetzt bucht BIS ERP sie beim Versand korrekt ab, genau wie am Handheld.

Berichte (Umsatz, Artikel, Kunden, Lager, Marktplätze, Lieferanten, Kassenauswertung) verlangen jetzt das Recht „Berichte anzeigen“. Gewinn, Marge, Wareneinsatz und Lagerwert zu Einkaufspreisen sieht nur, wer „Einkaufspreise/Kosten sehen“ hat. USt-Voranmeldung, EÜR und DATEV-Einstellungen der Kassenberichte brauchen „Buchhaltung anzeigen“, Umsatzziele im Dashboard „Berichte bearbeiten“. Die Umsatzkacheln im Dashboard bleiben für alle sichtbar.

Schlug das Versandlabel einer Teillieferung fehl, buchte „Erneut versuchen“ die Ware ein zweites Mal vom Bestand ab, und ein Nachdruck des Labels schloss den Auftrag vorzeitig ab. Jetzt bucht BIS ERP nur, was noch nicht abgegangen ist, und der Auftrag bleibt „teilweise versendet“, bis der Rest verpackt ist.

Kassenjournal (PDF und CSV je Kasse), DATEV-Kassenerlöse und optional die DSFinV-K gehen am 2. des Folgemonats um 06:00 Uhr automatisch an bis zu 5 Empfänger. Fehlt ein Tagesabschluss, wartet BIS ERP bis zum 5. Jeder Empfänger bestätigt selbst per Link und kann sich jederzeit abmelden. Der Versand ist eine Zusatzfunktion von BIS Insights.

Der digitale Bon (QR-Bildschirmbon und PDF-Download) zeigt bei Kartenzahlung jetzt den Kundenbeleg des Terminals als eigenen Abschnitt „Kartenzahlung“, die Kartennummer ist maskiert. Bei geteilter Zahlung stehen die einzelnen Teilzahlungen darauf, und die Zahlart erscheint mit dem Namen, den Sie gepflegt haben, statt kleingeschrieben. Die A4-Rechnung bleibt unverändert. Wirksam, sobald die Kasse die neue Fassung hat.

Am Handheld-Packtisch bucht der Abschluss nach einer Teillieferung nur noch die offene Restmenge vom Bestand ab. Lieferschein und Packstück-Beleg fassen Fehlmengen desselben Artikels zusammen. Und nach einem Update lädt BIS ERP wieder zuverlässig automatisch neu, statt hängen zu bleiben.

Wählt man im Kassenbuch des Kundencenters eine einzelne Kasse, zeigt es Verkäufe sowie Eröffnung, Tagesabschluss und Bargeldbewegungen dieser Kasse vollständig. Außerdem wird eine Bar-Rückgabe im laufenden Saldo nicht mehr doppelt abgezogen: Der Saldo entspricht dem Endbestand im Tagesabschluss.

EÜR, BWA, UStVA, EKS, GuV, Summen- und Saldenliste, Bilanz und Buchungsjournal sind nur noch mit dem Recht „Buchhaltung anzeigen“ abrufbar, ebenso das EÜR-PDF der Kassen-Steuerberichte und die DSFinV-K-Vorschau. Lager, Versand, Nur-Lesen und Vertrieb sehen den Reiter „Finanzen“ nicht mehr. Fehlt ein Recht oder ein Modul, sagt die Maske genau, was fehlt.

Abschluss-Detail, PDF, Z-Bon-Mail und DATEV-Kassenexport lesen Ein- und Auszahlungen nur noch aus dem eigenen Betrieb, und eine Bargeldbewegung lässt sich keinem fremden Kassenabschluss mehr zuordnen. Eine technische Diagnose-Abfrage für Kassenberichte steht nur noch dem BISpicy-Support zur Verfügung.

Aus einer Retoure entsteht wieder eine Gutschrift, zuerst als Entwurf mit den Werten der Rechnung, nach dem Finalisieren mit PDF und in UStVA, BWA, EÜR und DATEV. Rückgaben zu Kassenbons laufen über die Kasse. „Ersatzversand erstellen“ und „Punkte korrigieren“ funktionieren wieder; Treuepunkte zu korrigieren ist ein eigenes, vergebbares Recht.

Was Sie im Kundencenter unter Fernpflege → Unternehmen → Geschäftsfunktionen speichern – etwa Bargeld zählen bei Kassenöffnung, globaler Scanner, Waagen-Etiketten oder Selbstbedienungs-Kasse –, übernimmt die Kasse jetzt, ohne Kassen-Update. Selbstbedienung und unbeaufsichtigter Betrieb gelten dabei nur noch für das eine Gerät.

Wenn Sie die Artikelliste filtern und „Alle N auswählen“ wählen, aktiviert der Dialog „Für Kanäle aktivieren“ jetzt genau diese N Artikel für Marktplätze und Kasse – vorher konnte es der ganze Katalog sein. Inaktive Artikel werden bei Marktplätzen übersprungen, und Aktivieren, Preisvorgaben und Margenvorschau richten sich nach Ihren Rechten.

Das Ankaufsbuch mit den Personendaten der Verkäufer und die §25a-Auswertung sind jetzt nur noch mit dem Recht „Buchhaltung ansehen“ abrufbar, und die Kassenbewegungen zeigen bei einem Geräteankauf ohne dieses Recht nur „Geräte-Ankauf“. Liest die Kasse die Verkäuferdaten vom Ausweis aus, steht im Ankaufsbuch ein Einwilligungsvermerk mit Zeitpunkt und Mitarbeiter. Wurde dasselbe Gerät zweimal angekauft, ordnet die Auswertung jedem Verkauf den richtigen Ankauf zu.

Steht derselbe Artikel mehrfach im Auftrag, zeigt der Packtisch ihn jetzt als eine Zeile mit der Gesamtmenge. Die Lager-App stürzt bei solchen Aufträgen nicht mehr ab. Teillieferungen, Bestandsbuchung und Fehlmengen rechnen dabei richtig mit der Gesamtmenge des Artikels.

Am Kunden lassen sich jetzt Beleg-CC und Beleg-BCC hinterlegen. Rechnung, Gutschrift, Lieferschein, Bestellung und Angebot gehen mit einem Klick an diese Adressen, ohne Dialog. Neben dem Knopf steht vorher, wohin die E-Mail geht. Im Profil schalten Sie „Kopie an mich (BCC)“ ein. Auch der automatische Versand nimmt die Kopien mit.

Wenn Sie die Artikelliste filtern, etwa nach einer Kategorie, und „Alle N auswählen“ wählen, ändert die Massenbearbeitung jetzt genau diese N Artikel. Vorher konnte die Änderung alle Artikel treffen. Außerdem stehen leere Werte beim Sortieren A–Z am Ende, und Einkaufspreise erscheinen nur noch mit dem Recht „Kosten sehen“.

Rechnungen und Auftragsbestätigungen drucken die Hausnummer wieder mit, auch bei Kunden, die sie in einem eigenen Feld führen. Doppelte Hausnummern aus JTL bereinigt der Abgleich selbst. Im Rechnungsentwurf lässt sich der Kunde wechseln, gesperrte Knöpfe nennen das fehlende Recht.

Unter Einstellungen → Artikel → Gänge legen Sie je Gang fest, ob die Kasse beim Bestellen nach dem Gang fragt („Beim Bestellen nachfragen“). Der Werksgang „Getränke“ steht ab Werk auf „nicht nachfragen“, auch bei bestehenden Betrieben einmalig umgestellt. An der Kasse wirkt das erst mit dem nächsten Kassen-Update. Dann fragen Kellner-App und Hauptkasse den Gang nur noch bei Speisen.

Die Artikelliste lässt sich jetzt nach vielen Spalten sortieren, auch nach Kategorie und MwSt.-Satz, und blättert bei gleichen Werten stabil. Aufpreise der Modifikatoren lassen sich mit Nachkommastellen eintippen, und „Modifikator-Gruppe duplizieren“ funktioniert wieder.

Handyshops übernehmen ihre vorhandenen Gebrauchtgeräte jetzt per Datei: Der Artikel-Import kennt die Spalten „Differenzbesteuerung (§25a)“ und „IMEI/Seriennummer“, neue Geräte kommen mit Bestand 1 ins Lager, und im Import-Dialog gibt es die Vorlage „Gebrauchtgeräte“. Der Ankaufspreis ist Pflicht, jede IMEI wird nur einmal vergeben, und ein Gerät kommt nie über Bestand 1. Eine Spalte „Ankaufspreis“ landet jetzt im Einkaufspreis statt im Verkaufspreis.

In der Maske „Neuer Artikel“ gibt es bei aktiver Differenzbesteuerung (§25a) den Schalter „Gebrauchtgerät, differenzbesteuert (§25a) – Einzelstück“. Sie tragen IMEI/Seriennummer und Ankaufspreis ein, der Artikel wird angelegt und genau ein Stück mit dem Grund „Anfangsbestand“ eingebucht – kein Umweg mehr über die Artikeldetails und die Bestandskorrektur. Handyshops erhalten außerdem die Ansichtsvorlage „Handyshop / Gebrauchtgeräte“ ohne Felder, die für Einzelstücke keine Rolle spielen.

Im DATEV-Export von BIS ERP gibt es den neuen Exporttyp „Kassenbewegungen“ für Einlagen, Entnahmen, Bankeinzahlungen, Trinkgeld und Kassendifferenzen, getrennt vom Verkaufsstapel. In der Maske „DATEV-Kassenexport einrichten“ stellt der neue Reiter „Kassenbewegungen“ (BIS ERP und Kundencenter) die Konten ein und zeigt die Bewegungen eines Zeitraums. Einzelne Bewegungen lassen sich mit Pflicht-Grund und sichtbarem Verlauf umkontieren, der Kassendatensatz bleibt unverändert. Ob eine Kassendifferenz Fehlbetrag oder Überschuss ist, entscheidet jetzt der Z-Bon. Der Kundencenter-Export „Kassenbewegungen“ rechnet mit denselben Konten.

Die Verfahrensdokumentation Ihrer Kasse erkennt Belege, die erst später von der TSE signiert wurden. Maßgeblich ist die Signaturzeit der TSE im QR-Code des Belegs: Liegt sie mehr als 10 Minuten nach der Belegzeit, gilt der Beleg als nachträglich signiert. Der Abschnitt „Zeiträume ohne TSE-Signatur“ nennt je Tag Belegzeitraum und Signaturzeit, als Beginn der TSE-Signatur gilt der erste regulär signierte Beleg.

Die neue Maske „DATEV-Kassenexport einrichten“ finden Sie in BIS ERP unter Buchhaltung → DATEV und im Kundencenter unter Berichte → DATEV, mit Vorschau an einem echten Bon. Der Buchungstext ist mit Platzhaltern frei einstellbar, Zusatzangaben wie die Warengruppe stehen auf Wunsch in eigenen DATEV-Spalten. Auf Automatikkonten wird kein Steuerschlüssel mehr mitgegeben, Kassenstapel gehen in Windows-1252 mit echten Umlauten heraus.

Jede EAN wird beim Speichern geprüft, in der Lager-App, in BIS ERP, beim Import und von der Kasse: Prüfziffer, Steuerzeichen und GS1-Codes vom Karton. Scannerfehler wie vertauschte Zeichen werden erkannt und mit der vermutlich gemeinten Nummer abgelehnt. Eine EAN gehört zu genau einem Artikel, geprüft auch direkt gegen JTL; nur reine Zustandsvarianten dürfen dieselbe EAN tragen. In JTL entstehen keine doppelten Gebinde mehr, auch nicht bei Wiederholung oder Doppelklick.

Das Recht „Kunden ansehen“ gilt jetzt auch serverseitig. Beim Anlegen von Belegen zeigt die Kundensuche ohne dieses Recht nur Nummer, Name und Ort, der Kunden-Export braucht das Export-Recht und funktioniert wieder. Im DATEV-Export laufen alle Kunden standardmäßig auf den Sammeldebitor, ein eigenes Debitorkonto vergeben Sie je Kunde in der Kundenakte.

Die Verfahrensdokumentation Ihrer Kasse wird automatisch erzeugt und hat einen eigenen Menüpunkt, im Kundencenter und in BIS ERP unter Buchhaltung. Es gibt sie als PDF und als Markdown, frühere Fassungen bleiben mit Datum archiviert. Der neue Abschnitt „Zeiträume ohne TSE-Signatur“ entsteht aus Ihren Kassendaten, der Abschnitt „Ergänzungen des Betriebs“ nimmt eigene Angaben auf, etwa das Datum der Mitteilung an das Finanzamt. Sie ist auch ohne BIS-Archiv-Lizenz erreichbar, und die Markdown-Datei lädt mit der richtigen Endung.

In der JTL-Anbindung ordnen Sie jetzt die Zahlarten zu, die Ihre Kassen wirklich verwenden, über den Namen oder für alle gleichartigen über den Typ. Bestehende Zuordnungen wirken wie bisher. Digitaler Bon und A4-Rechnung zeigen bei nachträglich von der TSE signierten Belegen „TSE-Signatur nachträglich erstellt am …“.

Nach dem Kauf von Guthaben im Kundencenter wird es jetzt zuverlässig gutgeschrieben, meist innerhalb weniger Sekunden. Bleibt die Bestätigung von Stripe aus, holt BIS ERP sie selbsttätig nach. Guthaben kaufen Sie per Karte. Gekauftes Guthaben wird verrechnet, nicht ausgezahlt.

Beim Bezahlt-Markieren einer Eingangsrechnung wählen Sie jetzt, womit Sie bezahlt haben: Bar, Überweisung, Lastschrift oder eine andere gepflegte Zahlart. Die Rechnung zeigt danach „Bezahlt mit …“. Eine per Zahlungsabgleich der Bank zugeordnete Rechnung lässt sich nur noch über den Zahlungsabgleich wieder öffnen.

Der Reiter „Anhänge“ steht in der Artikelmaske, und Anhänge „bei Verkauf“ gehen tatsächlich an den Kunden. Der Hinweis auf Auslandslager ohne USt-Registrierung erscheint wieder, die Grundpreis-Einstellungen wirken, die Dashboard-Kacheln Kundenkennzahlen und Versandzahlen sowie CRM → Heute laden bei allen Betrieben, und eigene Rollen lassen sich löschen.

Bei Rechnungen, die Stripe ausstellt, versendet und liefert BIS ERP jetzt immer Stripes Original-PDF statt einer eigenen zweiten Rechnung. Die Stripe-Rechnungsnummer steht am Beleg, im Dateinamen und in der Suche, das Original wird dauerhaft und unveränderbar abgelegt. Storniert wird in Stripe. Außerdem stimmt der Rechnungsbetrag in der E-Mail auch ab 1.000 €, und die Nutzungsabrechnung meldet zuverlässig ohne Doppelberechnung.

Die Kommissionierung im Browser zeigt eine Zeile je Kommissionierliste, Sammellisten lassen sich aufklappen, und es gibt einen Filter nach Lager sowie den Schalter „Erledigte anzeigen“. Die Schnellwahl der Vorlagen funktioniert wieder; eine Sammelliste löscht nur noch, wer das Recht „Welle löschen“ hat, und nicht, solange ein Handgerät sie bearbeitet. Ein in BIS ERP geänderter Verkaufspreis wird nicht mehr vom nächsten JTL-Abgleich zurückgesetzt und erreicht in JTL auch die Preisgruppe „Privatkunde“, sofern der Artikel dort schon einen Gruppenpreis hat. Inventurnummern beginnen mit „IVT-“ statt „INV-“ und sind damit nicht mehr mit Rechnungsnummern zu verwechseln. Das wirkungslose Feld „Verzögerung“ bei den Gängen entfällt, und ab der nächsten Kassen-Version lässt sich der Küchenbon nach Gängen gliedern. BISPrint für Android ist in den Druckeinstellungen als „in Vorbereitung“ gekennzeichnet.

Rechte greifen jetzt auch dort, wo bisher nur die Oberfläche sie durchsetzte: bei der Verbindung zu BISConnect/JTL, API-Schlüsseln und Webhooks, dem Mail-Versand, den Zahlungsanbietern Stripe, PayPal und SumUp samt Zahlungsabgleich, Eingangsrechnungen/Rechnungspostfach und den DATEV-Einstellungen. Die Zugangsdaten der Zahlungsanbieter und das Rechnungspostfach ändert künftig nur noch ein Admin, Manager dürfen dafür Eingangsrechnungen freigeben. Im Kundencenter ändert Abo, Tarif, Zahlweise, Guthaben und Abrechnung künftig nur noch der Konto-Inhaber. Wird bei Rechnungspostfach oder Mail-Versand der Server geändert, muss das Passwort neu eingegeben werden. Bestehende Rollen bekommen die neuen Rechte automatisch nachgezogen.

Notizen, Anrufe und E-Mails aus der Kundenakte zählen unter CRM → Heute jetzt als Kontakt: Bereits angesprochene Kunden rücken in der Anrufliste nach hinten und zeigen „Letzter Kontakt: Notiz am …“. Eine fällige Wiedervorlage bleibt oben, „Kein Interesse“ blendet weiter nur über den Kontaktvermerk aus. In der Kundenliste erscheint ein Kontaktvermerk mit Notiz jetzt schreibgeschützt unter „Letzte Notiz“. Als Betreuer lassen sich nur noch aktive Benutzer des eigenen Betriebs zuordnen.

Eine Zubuchung über „Bestand korrigieren“ und Ware, die am Packtisch oder vom Kommissionierwagen zurück ins Regal ging, landeten bisher in einer Bestandszeile ohne Lager — mit angebundener JTL-Wawi stand die Menge danach doppelt im System, und an der Kasse kam eine Korrektur gar nicht an. Beides bucht jetzt ins Lager. Außerdem lassen sich die DATEV-Einstellungen wieder speichern, wenn „Kostenstellen im Export“ oder „Debitoren automatisch aus Kunden erstellen“ ausgeschaltet ist.

Beim Scannen eines Gebinde-Barcodes (z. B. Karton oder Kiste) setzt die Kasse den Gebindepreis an. Bei JTL-Anbindungen mit Staffelpreisen löschte der Abgleich diese Preise bisher bei jedem Lauf mit, und die Kasse rechnete Einzelpreis × Menge. Jetzt bleiben sie erhalten und folgen jeder Änderung von Preis, Steuersatz, Sonderpreis oder Kundengruppenpreis des Artikels — die Kasse bekommt den neuen Stand automatisch.

Zahlungsarten haben jetzt einen Zahlweg für Eingangsrechnungen: Kasse, Bank, Verrechnung oder keine. Damit wählen Sie beim Bezahlen einer Lieferantenrechnung künftig eine echte Zahlungsart statt Freitext. Zahlungsarten lassen sich jetzt auch im Kundencenter pflegen. Anlegen, Ändern und Löschen erfordert das Recht „Einstellungen bearbeiten“. Fehlt eine passende Zahlungsart, legt BIS ERP Bar, Überweisung und Lastschrift automatisch inaktiv an.

Eine fällige Wiedervorlage unter CRM → Heute zeigt jetzt das Ergebnis des letzten Gesprächs (z. B. „Rückruf vereinbart“) und Ihre Notiz dazu. Gespeichert war die Notiz immer, angezeigt wurde sie dort nicht. Auch der Durchgang (Call-Modus) und die Erinnerung über die Glocke nennen sie. Außerdem öffnen ein Klick auf den Kunden einer eigenen Wiedervorlage und „Kunde öffnen“ in der Glocke wieder die Kundenakte statt „Kunde nicht gefunden“, und eine eigene Wiedervorlage erscheint nicht mehr doppelt.

A4-Rechnungen aus der Kasse zeigen jetzt immer den Tag des Verkaufs in Ihrer Zeitzone. Bisher stand bei Verkäufen kurz nach Mitternacht der Vortag darauf, mit Folgen für Fälligkeitsdatum, Voranmeldung und Zusammenfassende Meldung. Rechnungskäufe an der Kasse merken sich jetzt, wer den Umsatz trägt (Bon, Rechnung oder JTL), als Grundlage dafür, dass er künftig genau einmal zählt. Eine Kassen-Rechnung entsteht jetzt vollständig oder gar nicht.

Konnte BIS ERP die Steuersätze Ihrer JTL-Wawi in einem Abgleich nicht lesen, setzte es bisher 19 % an und rechnete den Bruttopreis damit hoch — ermäßigt besteuerte Artikel (z. B. Lebensmittel mit 7 %) standen danach mit zu hohem Preis und falschem Steuersatz in BIS ERP und an der Kasse. Jetzt bricht der Abgleich ab und holt alles im nächsten Lauf nach; Steuersatz, Preis und Steuerklasse bleiben unverändert, solange der Satz aus JTL nicht feststeht. Staffelpreise bleiben dabei stehen.

Legt BIS ERP einen neuen Artikel automatisch in Ihrer JTL-Wawi an, übernimmt es jetzt die Steuerklasse des Artikels (z. B. „Lebensmittel“ mit 7 %), statt jeden Artikel mit dem Normalsatz anzulegen — der Normalsatz wäre beim nächsten Abgleich mit 19 % und höherem Bruttopreis nach BIS ERP zurückgekommen. Lässt sich die Steuerklasse nicht eindeutig zuordnen, wird der Artikel vorerst nicht angelegt, und das Sync-Protokoll nennt den nächsten Schritt.

Bestand aus dem Artikel-Import landet jetzt lagergenau: Haben Sie mehrere Läger, wählen Sie im Import-Dialog das Ziellager, sonst zeigte die Kasse importierte Artikel bei Mehrlager-Betrieb fälschlich als „Ausverkauft" — jede Buchung erscheint im Lagerjournal, Betriebe ohne Lagerverwaltung importieren wie bisher. Export → Reimport ist jetzt sicher: Der Export schreibt die neuen Spalten „Bestand (Export)" und „Export-Kennung", ein Reimport bucht nur noch die Änderung in der Datei, lässt seither erfolgte Verkäufe unangetastet und bucht auch beim zweiten Import derselben Datei nichts doppelt; Dateien ohne diese Spalte übernehmen den Bestand bestehender Artikel nur mit dem Häkchen „Bestand bestehender Artikel übernehmen", neue Artikel bekommen ihren Anfangsbestand immer, Lagerplätze und Ware unterwegs bleiben unberührt. Varianten (Farbe, Größe, …) werden jetzt vollständig mit Merkmalen, Reihenfolge und Vater-Kind-Verknüpfung angelegt — die Kasse fragt Größen in der fachlich richtigen Reihenfolge ab (XS < S < M < L < XL …, Kindergrößen numerisch) und mit „Farbe"/„Größe" statt „size"; eine Vaterzeile funktioniert jetzt auch nach ihren Kindern (auch in einem späteren Import), ein fehlender Vater oder ein fehlendes Merkmal erzeugt einen klaren Hinweis. Der Steuersatz wird nie mehr geraten: Ein Satz ohne passende Steuerklasse ist jetzt ein Zeilenfehler mit klarer Anweisung, Steuerklassen dürfen als Name angegeben werden, und die Sätze richten sich nach Ihrem Sitzland, jetzt auch Österreich; in Ländern ohne hinterlegte Sätze (z. B. Schweiz) wird der Satz aus der Datei übernommen. Rechte werden konsequent geprüft (Artikel/Bestand/Preis bearbeiten), „Nicht importieren" wirkt jetzt auch bei Spalten „Bestand"/„MwSt", Reservierungen und Bestellmengen werden nicht mehr überschrieben, und weitere EANs und Lieferanten aus der Datei werden auf allen Importwegen übernommen. Behoben: Der Import über die Oberfläche lief vom 21.09. bis 26.09.2026 nicht.

Kontenrahmen, Erlöskonten, Kostenstelle und Kreditoren-/Debitoren-Startnummer aus Ihren DATEV-Einstellungen gelten jetzt auch beim Erzeugen des Buchungsstapels, nicht nur in der Vorschau. Unter SKR04 werden auch Kasse, Bank und die Zahlungskanäle nach SKR04 gebucht, auch nach dem Umstellen in der DATEV-Maske. Rechnung und Zahlung stehen auf demselben Debitor. Kann BIS ERP die Einstellungen nicht lesen, bricht der Export mit einer Meldung ab, statt mit Vorgabekonten zu buchen. Nach unserer Prüfung ist bei keinem Betrieb eine Datei mit falschen Werten entstanden.

Die automatische Verbuchung in der Buchhaltung bucht Kassenbelege jetzt nach derselben Regel wie der DATEV-Kassenexport: Steuersätze, Erlöskonten, Bonrabatt, Pfand, Trinkgeld, Anzahlungen und Differenzbesteuerung stimmen je Konto mit dem DATEV-Export überein, gebucht wird auf den Tag des Bons in Ihrer Zeitzone. Bei Betrieben ohne eingerichteten Kontenrahmen steht die Automatik nicht mehr fälschlich auf „an“, und die Buchhaltung zeigt an, wenn sie ruht. Zwei Kassen mit derselben Bonnummer verdecken sich nicht mehr. An der Kasse bezahlte Rechnungen werden nur einmal als Erlös gebucht, und nach „Jetzt buchen“ sehen Sie, was gebucht wurde und was liegen bleibt.

Zwei Bereiche funktionieren erstmals: Auslandslager mit USt-Registrierungen und Meldefristen (maßgeblich ist der Lagerort, nicht das Lieferland) und Anhänge an Artikeln. Der JTL-Bildabgleich über BISConnect kommt auch bei langsamer Verbindung wieder voran, jedes angekommene Bild zählt. Pfandvorlagen richten sich nach dem Sitzland, der Bestandsverlauf in der Artikelstatistik zeigt wieder Werte, und die Relay-Anzeige nennt „zuletzt gesehen“ auch bei getrenntem BISConnect. Drucker gelten nur noch als online, wenn ihr BISPrint-Rechner läuft; Druckerliste und Küchenbon der Web-Kasse, Steuersätze an Kassen außerhalb Deutschlands, der Zahlungsabgleich im Banking sowie Kauf und Tarifwechsel im Kundencenter sind behoben. Der Menüpunkt „Koalition“ ist vorerst ausgeblendet.

Der DATEV-Export der Kassenumsätze rechnet in BIS ERP, im Kundencenter und an der Kasse jetzt nach derselben Regel: Ein Bon wird so gebucht, wie die Kasse ihn signiert hat, ältere Kassenstände bildet BIS ERP aus dem Verkauf nach und nennt den Beleg. Stornierte Bons fehlen nicht mehr, Verkauf und Storno stehen beide im Stapel. Wurde ein Zeitraum schon exportiert (in BIS ERP, im Kundencenter oder an der Kasse), fragt BIS ERP vorher nach; gesperrt wird nichts. Der Download liefert genau die Datei, die Sie damals erzeugt haben. Die Kopfzeile aller DATEV-Dateien aus BIS ERP und dem Kundencenter entspricht jetzt der DATEV-Vorgabe — bisher standen Berater- und Mandantennummer, Wirtschaftsjahr und Zeitraum um eine Stelle verschoben; die Buchungszeilen älterer Dateien sind davon nicht betroffen. Der Beginn des Wirtschaftsjahres folgt Ihrer Einstellung. Im Kundencenter zeigen Vorschau und Export dieselben Zahlen, umfassen alle Kassen des Betriebs und beachten dieselben Filter. DATEV-Vorschau, Exportliste und Download sind nur noch mit Buchhaltungsrecht erreichbar.

Wird eine offene Rechnung an der Kasse bezahlt und steht der Betrag als Umsatz auf dem Kassenbon (TSE-signiert, im Z-Bon enthalten), erfasst BIS ERP den Erlös jetzt über den Kassenbon und lässt die Rechnung in EÜR, BWA und im DATEV-Export der Ausgangsrechnungen weg — vorher stand derselbe Erlös dort zweimal. Die Rechnung bleibt gültig und aufbewahrungspflichtig; in UStVA und ZM bleibt sie enthalten, weil diese nach Rechnung rechnen. Die Rechnung trägt dazu das Kennzeichen „Erlös über Kasse" mit dem tragenden Kassenbon, Gutschriften folgen ihr automatisch. Automatisch weggelassen wird eine Rechnung nur, wenn sie erst durch die Kassenzahlung entstanden ist und alles eindeutig passt; alle anderen Fälle zeigt eine Hinweiszeile in EÜR, BWA, EKS und UStVA, sie werden mit Ihnen und Ihrer Steuerberatung geklärt und an der Rechnung protokolliert. Außerdem prüft das Kundencenter die DATEV-Konten der Zahlungsarten jetzt auf 4 bis 8 Ziffern und warnt, wenn die Zahlungsarten inzwischen an anderer Stelle geändert wurden. Vorbereitet für Kasse 1.3.3: Die gemeinsame Buchungsregel des DATEV-Kassenexports rechnet Umtausch ohne Restzahlung, Rückgeld und Cashback sowie Trinkgeld an den Betrieb jetzt richtig.

Die Spalte „Letzter Kontakt" in CRM → Kunden ist jetzt ab Werk eingeblendet. Wer bereits eine eigene Spalteneinstellung gespeichert hatte, bekommt die Spalte einmalig automatisch mit eingeblendet — wer sie danach selbst wieder ausblendet, dem bleibt sie ausgeblendet. Grund: Vermerke über das Telefon-Symbol (Kontaktvermerke, auch mit Wiedervorlage) stehen ausschließlich in dieser Spalte, nicht unter „Letzte Notiz" — ausgeblendet wirkten sie wie verschwunden.

Das Recht „Kassen-Synchronisation bearbeiten/löschen" entscheidet jetzt durchgängig darüber, wer eine Kasse aus der Ferne löschen, umstellen oder fernsteuern darf — im Kundencenter bei der Kassen-Fernsteuerung, der Kassen-Gerätepflege und bei Kassen-Kommandos. Dieselbe Regel gilt jetzt auch für Kassen-Favoriten, Kassen-Kanalgruppen und den Kassen-Nutzerkreis (Mitarbeiter, PIN, Rolle). Administrator und Manager haben dieses Recht ab Werk, Rollen wie Lager, Vertrieb oder Nur-Lesen nicht. Kassenpreise je Verkaufskanal (Festpreis/Sonderpreis) benötigen jetzt zusätzlich das Recht „Artikelpreise ändern" — die reine Zuordnung eines Artikels zu einer Kasse bleibt weiterhin mit dem Recht „Artikel bearbeiten" möglich. Kassen-PINs werden nur noch an tatsächlich gekoppelte Kassen bzw. berechtigte Konten übertragen, und fehlt das nötige Recht, erscheint jetzt eine klare Fehlermeldung statt eines fälschlich erfolgreich wirkenden Speicherns. Außerdem behoben: Die Belegzeit im gespeicherten DATEV-Kassenbeleg steht jetzt in der Ortszeit des Betriebs statt in UTC — betroffen waren vor allem Bons kurz nach Mitternacht und am Monatsersten.

Eine bereits eingerichtete Kasse oder ein Lagergerät neu zu verbinden geht jetzt nur noch mit Administrator- bzw. Manager-Anmeldung — oder wenn im Kundencenter unter Geräte „Neu koppeln erlauben (15 Min.)" freigegeben wurde. Bisher konnte jeder angemeldete Mitarbeiter ein bestehendes Gerät neu verbinden und damit unbemerkt die eigentlich im Einsatz befindliche Kasse abmelden. Neue Geräte einrichten funktioniert weiterhin mit jedem Konto. Geräte löschen, widerrufen, die Lizenz umbinden oder das Kürzel ändern dürfen jetzt nur noch Benutzer mit dem Recht „Kassen-Sync bearbeiten/löschen" (ab Werk Administrator und Manager), Kassenkonten (POS-Systembenutzer) verwalten nur noch Benutzer mit Benutzerverwaltungs-Rechten. Außerdem behoben: Ein widerrufenes Gerät ließ sich nicht wieder aktivieren.

Meldet sich der BISConnect-Rechner länger als 30 Minuten nicht mehr und bleibt dadurch etwas liegen (Kassenbons, Bestandsbuchungen) — oder ist die Verbindung als „Dauerbetrieb (Server)" markiert —, bekommt Ihr Betrieb jetzt eine Hinweis-Glocke und eine E-Mail an die Firmen-Mailadresse mit klarer Handlungsanweisung (BISConnect auf dem genannten Rechner starten; nach einem Windows-Neustart einmal anmelden) sowie später eine Entwarnung — höchstens eine solche Mail pro Tag. Unser Support bekommt automatisch ein Ticket. Neu ist außerdem der Schalter „BISConnect läuft dauerhaft (Server)" bei der JTL-Verbindung, und der Verbindungsstatus zeigt jetzt „Verbindung zu JTL unterbrochen — offline seit …" samt Anzahl wartender Bons/Buchungen. Zusätzlich kommen Bestände nach einem Verbindungsausfall jetzt zuverlässig in JTL an (Wareneingänge werden vor den Kassenbons übertragen, der Bestandsabgleich überschreibt keine noch nicht übertragenen BIS-Buchungen mehr), und Kassenverkäufe erzeugen in JTL keine doppelten Lieferscheine mehr — Rechnungs-Workflows werden nicht mehr doppelt eingereiht.

Kundennummern kommen jetzt für jeden Betrieb aus einem einzigen Nummernkreis — egal auf welchem Weg ein Kunde entsteht: Anlage direkt in BIS ERP, CSV-Import, Terminbuchung, Kundenportal/Kundencenter, Kasse, Shop- und Gambio-Bestellimport, Auftragsimport, Stripe oder die externe Schnittstelle. Bisher vergaben einzelne Wege eigene Nummern (höchste Nummer + 1, eigene Präfixe wie SHOP-, GAM-, C…, K-…) — dadurch konnten Kundennummern in unterschiedlicher Stellenzahl nebeneinander stehen (z. B. KD-00001 neben KD-000001), im DATEV-Export landeten solche Kunden fälschlich auf demselben Debitorkonto. Die Vergabe überspringt jede bereits belegte Nummer automatisch, auch in anderer Stellenzahl; der Zähler wurde dafür einmalig auf die höchste vorhandene Nummer angehoben. JTL-Kundennummern und übernommene Nummern aus Import, Migration und Odoo ändern sich nicht. Zusätzlich ziehen Rechnungsnummern aus Stripe (Abo-Rechnungen) und aus in BIS ERP erstellten Rechnungen jetzt aus demselben Rechnungsnummernkreis statt aus getrennten Kreisen — bestehende Rechnungsnummern ändern sich dabei nie. Unter Einstellungen → Nummernkreise lassen sich Kunden-, Rechnungs- und Gutschriftenkreis nicht mehr deaktivieren, der Rechnungszähler nicht mehr bei gleichem Präfix zurücksetzen (Neubeginn über ein neues Präfix), Auto-Reset steht dort fest auf „Nie" und Präfix/Suffix erlauben nur Zeichen ohne Leerzeichen und Umlaute. Außerdem lässt sich die ERP-Verfahrensdokumentation im Kundencenter-Dokumentenarchiv wieder erzeugen und archivieren.

Für Registrierkassen in Österreich (RKSV) zeigt der digitale Beleg — der QR-Code-Beleg, den Kunden nach dem Bezahlen abrufen — jetzt den maschinenlesbaren RKSV-Code als eigenen QR-Code sowie Kassen-ID, Belegnummer und Datum/Uhrzeit. Ist die Sicherheitseinrichtung ausgefallen, erscheint dazu ein passender Hinweis. Bisher stand an dieser Stelle nur eine leere Überschrift „TSE-Informationen"; digitale Belege deutscher Kassen sind unverändert. Außerdem wurden die Kassen-Konfiguration für Österreich und die TSE-Anbindung zusätzlich abgesichert — an der Kasse ändert sich dadurch nichts. Im Kundencenter unter RKSV-Einstellungen ist das FinanzOnline-Anmeldeformular entfernt — die FinanzOnline-Anmeldung wird jetzt gemeinsam mit dem Support eingerichtet (das bisherige Formular hat die Anmeldedaten nicht vollständig übertragen).

In CRM → Kunden zeigt die neue Spalte „Letzter Kontakt" (einblendbar über Spalten anpassen, sortierbar) Datum, wer und Art des Kontakts — Notiz, Kontaktvermerk, Anruf oder E-Mail, bei Kontaktvermerken zusätzlich das Ergebnis; „Letzte Notiz" zeigt zusätzlich Datum und Verfasser. Neuer Filter „Kontakt:" (noch nie · heute · letzte 7/30 Tage · nicht in den letzten 7/30/90 Tagen, schließt „noch nie" ein) wirkt auch auf die Kacheln und auf „alle Treffer zuweisen"; neue Kachel „Noch nicht kontaktiert: N". Die Liste aktualisiert sich jetzt schneller. Ausserdem behoben: In der Artikelliste waren ohne Artikel-Ändern-/Anlegen-/Löschen-Recht (z. B. Rolle Vertrieb) die Spaltenbreiten verschoben — „Artikel" extrem schmal, neben „EAN" eine große Lücke; eigene Breiten lassen sich über Spalten anpassen → „Auf Standard zurücksetzen" wieder auf Standard bringen.

Neuer Bonnummern-Lücken-Bericht unter Berichte → Kassenberichte (und im Kundencenter) zeigt fehlende Bonnummern je Kasse und Nummernkreis, abgeglichen gegen ein Protokoll der Kasse (offen/verwendet/abgebrochen/Zähler verstellt) — eine erklärte Lücke sieht nicht mehr wie ein manipulierter Beleg aus. Eine per Hand verstellte Zählernummer erklärt jetzt den ganzen dadurch entstandenen Bereich statt nur die erste Nummer. TSE-Signaturen, die verspätet bei der Kasse ankommen (z. B. nach einem kurzen Netzwerkausfall oder bei gezielter Nachlieferung), werden jetzt zuverlässiger und ausschließlich dem richtigen Gerät zugeordnet nachgetragen — ohne eindeutige Geräte-Zuordnung wird lieber gar nicht nachgetragen als geraten. Ein interner Bericht zu fehlenden TSE-Signaturen, der betroffene Belege teilweise nicht fand, ist behoben.

Auf dem Handy erschienen einige Listen doppelt — einmal als Karte, einmal zusätzlich als Tabelle, die eigentlich nur für den großen Bildschirm gedacht war. Betroffen waren unter anderem Shopify- und Etsy-Aufträge, Zahlungen, Chargen, Wareneingang, Lagerplätze, Kassenrabatte, mehrere Berichte sowie die Belege im Kundenportal. Eine CSS-Regel für die mobile Kartenansicht griff auf einigen Seiten nicht zuverlässig; jetzt wird auf dem Handy überall nur noch die Kartenansicht angezeigt.

Zubereitungsfragen (z. B. „Garstufe") liessen sich keinem Artikel und keiner Kategorie zuordnen — nach dem Speichern stand „0 Kategorie(n), 0 Einzelartikel". Jetzt wird gespeichert, bestehende Zuordnungen erscheinen wieder angehakt. Neu: Gänge sind unter Einstellungen → Artikel → Gänge pflegbar (Getränke, Vorspeise, Hauptgang, Dessert, Extras ab Werk, eigene Gänge mit Reihenfolge und Farbe), mit vererbbarem Standardgang je Warengruppe, Ausnahme je Artikel und Massenbearbeitung — die Kasse schlägt den gepflegten Gang ab Version 1.3.3 automatisch vor. Ausserdem: Artikel ohne Warengruppe kommen an Kassen ab 1.3.3 sauber als „ohne Warengruppe" an, statt in einer gelöschten Warengruppe hängen zu bleiben.

Ein Bon mit mehreren Steuersätzen (z. B. Speisen 7 % / Getränke 19 %) wird im DATEV-Export jetzt je Steuersatz auf das passende Erlöskonto gebucht. Automatikkonten führen keinen Steuerschlüssel mehr, Belegfeld 1 ist die Bonnummer, der Zeitraum richtet sich nach der Ortszeit, und Trinkgeld für Mitarbeiter wird als durchlaufender Posten statt als Erlös gebucht. SKR04 ist durchgängig korrekt (Kartenzahlung auf 1460 statt 1370, bestehende Einstellungen werden automatisch umgestellt). Auch Leergut-/Pfandrückgaben, Stornos, Forderungsausgleich, Anzahlungen und Differenzbesteuerung (§ 25a) werden jetzt richtig gebucht, der Download liefert denselben Inhalt wie das Erzeugen, und ein Hinweis warnt vor dem versehentlichen Doppelexport eines Zeitraums.

Wenn wir ein gemeldetes Problem als behoben kennzeichnen („verifiziert"), bekommen Sie jetzt eine kurze E-Mail mit der Bitte um Bestätigung. Melden Sie sich innerhalb von 7 Tagen nicht, schließen wir das Ticket automatisch — eine Antwort auf diese Mail öffnet es jederzeit wieder. Ausserdem erreichen Antworten aus der Kasse und der Lager-App auf ein Support-Ticket unser Team jetzt genauso zuverlässig wie Antworten per E-Mail oder Portal.

Die Zahlweise einer laufenden Lizenz lässt sich jetzt selbst ändern — bisher gab es dafür keinen Weg ausser kündigen und neu buchen. Ein Wechsel nach oben (höhere Stufe oder monatlich → jährlich) greift sofort und rechnet Bezahltes gegen; ein Wechsel nach unten wird zum Ende der Mindestlaufzeit vorgemerkt und lässt sich bis dahin jederzeit zurücknehmen.

Wer eine Zubereitungsfrage einer Kategorie zuordnet, erreicht damit ab sofort auch alle Unterkategorien. Bisher galt die Zuordnung nur für Artikel unmittelbar in der gewählten Kategorie — wer seine Gerichte in „Speisen › Hauptspeisen" pflegt und „Speisen" anhakte, bekam an der Kasse keine Frage nach der Garstufe. Neu ist ausserdem die Angabe, auf wie viele Artikel eine Gruppe tatsächlich wirkt.

Die Vorlagen für automatische Benachrichtigungen zeigten in der Vorschau nur den nackten Text ohne Rahmen. Wer sich daran orientierte, baute Kopfzeile und Fusszeile von Hand nach — und hatte beides anschliessend doppelt in der fertigen Mail. Die Vorschau zeigt jetzt die Mail so, wie sie beim Empfänger ankommt, und neue Vorlagen starten mit einem Muster, das nur noch Text enthält.

Auswahl- und Zubereitungsfragen der Kasse — Garstufe, Beilagen, Grössen — liessen sich bisher nur in der Browser-Kasse pflegen; aus der Warenwirtschaft führte kein Weg dorthin. Sie sind jetzt unter Einstellungen → Artikel → Modifikatoren zu finden. Ausserdem behoben: Zwei Kategorien an einem Artikel erzeugten an der Kasse eine dritte, erfundene Kategorie („Speisen, Spezialitäten"), und in der Massenänderung konnte ein Tippfehler im Kategoriefeld die Zuordnungen ganzer Artikelmengen löschen.

Wer jährlich zahlte und die Tarifstufe wechselte, landete danach still auf monatlicher Abrechnung — teurer übers Jahr und mit einer anderen Abrechnungsperiode, ohne jeden Hinweis. Im Kundencenter bot die Maske dabei einen Umschalter zwischen monatlicher und jährlicher Zahlweise an, der gar nicht ausgewertet wurde: Wer eine Jahreslizenz hatte, las dort „49,90 € pro Monat“ und bekam anschließend 499,00 € pro Jahr berechnet.

Betriebe mit zwei Kassen hatten dauerhaft Abgleiche im Minutentakt, ohne dass sich etwas geändert hatte — bei einem Gastronomiebetrieb mehrere Hundert Einstellungs-Abgleiche pro Stunde je Gerät. Ursache war ein Zeitstempel bei den Zahlungsarten, der zwischen beiden Kassen auseinanderlag und sich nie wieder anglich.

Bisher lag das Aussehen jeder E-Mail-Vorlage in der Datenbank — Gestaltungsänderungen mussten einzeln nachgezogen werden, und einmal angepasste Vorlagen behielten das Aussehen von damals. Ab sofort steht in der Vorlage nur noch der Text; wie er aussieht, entscheidet das System beim Versenden.

Die tageweise Nutzungsabrechnung (Pay-per-Use) lief seit dem 29.07.2026 systemweit nicht mehr und ist jetzt wieder aktiv. Neu im Kundencenter unter Nutzung: zwei Kacheln „Testphase-Tage" und „Gewährte Tage" — sie zeigen, was diese kostenfreien Tage gekostet hätten, fliessen aber nicht in die geschätzten Kosten ein.

Nachbesserung zur Version davor: Das Logo in unseren E-Mails stammte aus den Symboldateien der Anwendung statt aus den offiziellen Markendateien. Jetzt steht dort die dafür vorgesehene Zeilenfassung — Zeichen mit Schriftzug, in der hellen Variante für den farbigen Kopf.

Dritte und letzte Nachbesserung zur Artikel-Anlage. Die fertigen Anlage-Befehle gingen über den Lese-Kanal zur JTL-Datenbank — und der weist alles ab, was kein reines Lesen ist. Die Artikel entstanden deshalb nicht, und im Sync-Protokoll stand „SQL query must be read-only“.

Ergänzung zur Version davor: Die überarbeiteten E-Mails trugen unsere Farben, aber noch kein Logo. Das steht jetzt oben in jeder Nachricht, zusammen mit dem Schriftzug BISpicy.

Alle E-Mails von uns tragen ab sofort unser Markenbild — ruhiges Blaugrün statt Rot. Anlass war die Schaltfläche, die in vielen E-Mail-Programmen dunkelblaue Schrift auf rotem Grund zeigte: ein Kontrast von 2,6:1, während für Schaltflächen mindestens 3:1 gefordert sind.

Von einem Kunden gemeldet: Unsere Antworten auf Support-Anfragen kamen zuletzt als ein einziger durchgehender Block an, ohne Absätze und ohne Aufzählungen. Bei der Prüfung kam Gravierenderes ans Licht — seit dem 23. August konnte unsere eigentliche Antwortmail gar nicht mehr zugestellt werden, und die Ersatz-Benachrichtigung schickt keine Dateianhänge mit.

Wer einen Artikel in eine andere Warengruppe verschoben oder eine Warengruppe umgehängt hat, sah das an der Kasse bisher nicht — oder verkehrt. Zwei Ursachen, beide behoben.

Zweite Nachbesserung, gefunden beim Test am Testbetrieb. Die neue Artikel-Anlage nach JTL las Felder, die es in dieser Schreibweise gar nicht gibt — die Artikelbeschreibung unter falschem Namen, und die Zuordnung von Ausführungen zu ihrem Stammartikel auf Betrieben, die diese Verwaltung noch gar nicht haben.

Direkte Nachbesserung zur Version davor. Die neue Artikel-Anlage nach JTL brauchte einen Merker in der Artikeltabelle, um vorhandene Artikel vom automatischen Nachschieben auszunehmen. Dieser Merker liess sich bei einem Teil der Betriebe technisch nicht anlegen — die Artikeltabelle ist dort bereits so breit, dass keine weitere Spalte mehr hineinpasst.

Bisher war die Verbindung zu JTL beim Artikel eine Einbahnstrasse: Ein in BIS ERP angelegter Artikel erreichte JTL nie — der Abgleich konnte dort nur bestehende Artikel aktualisieren. Für Kunden und Aufträge legt BIS ERP längst neue Datensätze in JTL an; Artikel waren die einzige Ausnahme. Besonders spürbar war das bei Ausführungen, die seit 0.0.0.909 ausschliesslich in BIS ERP gepflegt werden.

Nachtrag zur Version davor — und der eigentliche Grund für festgefahrene Buchungen. Damit der Abgleich schnell bleibt, prüft BIS ERP vorab, ob sich in JTL überhaupt etwas am Bestand geändert hat; wenn nicht, wird der Block übersprungen. Für das Lesen ist das richtig, fürs Schreiben war es verkehrt herum: Etwas zu schieben hat BIS ERP ja dann, wenn SIE in BIS ERP gebucht haben — und das ändert auf JTL-Seite nichts.

In den JTL-Einstellungen lässt sich festlegen, wer beim Bestand das Sagen hat — JTL, BIS ERP oder beide. Für die Richtung „BIS ERP → JTL" galt das bisher nur zur Hälfte: Ihre Buchungen gingen zwar nach JTL, aber BIS ERP übernahm beim nächsten Abgleich trotzdem wieder JTLs Zahl. Betroffen war davon bislang niemand — alle bestehenden Anbindungen laufen bidirektional. Wir haben es korrigiert, bevor der erste Kunde die Umstellung vornimmt.

Bei den Paketen stand im Shop ein rechnerischer Wert („ab 41,58 €/Monat") statt des Preises, den Sie tatsächlich zahlen. Ausserdem entfällt der Testzeitraum für BIS Premium und BIS Pro, weil beide die TSE enthalten, und das erste Küchendisplay ist nicht mehr in der Kellner-Anbindung enthalten.

Für den innergemeinschaftlichen Erwerb und für Leistungen nach § 13b UStG gab es im DATEV-Export längst eigene Buchungszweige — sie konnten nie greifen, weil die steuernden Kennzeichen in der Datenbank fehlten. Der Export lief ohne Fehlermeldung durch und buchte diese Fälle schlicht nicht. Dazu zwei Hintergrundläufe, die bei einem Teil der Betriebe gar nicht durchliefen.

Wer von einem anderen Kassensystem zu BIS ERP wechselt, muss seine Artikel nicht mehr von Hand abtippen: Unter Einstellungen → Allgemein → Datenübernahme laden Sie den Artikelexport Ihres bisherigen Systems hoch (zum Start: GastroSoft Pro). BIS ERP erkennt das Vorsystem automatisch, trennt echte Artikel von Zusätzen und meldet Konflikte, statt sie stillschweigend zu übernehmen.

Ein Artikel in mehreren Farben und Größen wird ab sofort ausschliesslich in BIS ERP gepflegt — die Kasse zeigt die Ausführungen nur noch an. Neu ist ausserdem, dass Sie festlegen, wonach die Kasse beim Verkauf zuerst fragt: erst die Farbe, dann die Größe, oder umgekehrt.

Ein Kunde konnte seine Artikelliste nicht importieren — der Vorgang stoppte immer nach 50 Zeilen. Schuld war eine einzelne Zelle, die auf einem Rückwärtsschrägstrich endete; der Server zerlegte die Zeile falsch und brach daran den ganzen Import ab. Eine Mengenbegrenzung gab es nie — importiert wurden schon fast 50.000 Zeilen am Stück.

Wird Ware für einen Auftrag vom Regal auf einen Kommissionierwagen umgelagert, ist das eine reine Verschiebung — im Lager liegt danach exakt so viel wie vorher. Der Abgleich mit JTL-Wawi hat die Regalmenge anschliessend aber wieder auf JTLs Stand gesetzt, während die Menge auf dem Wagen zusätzlich stehen blieb. Bei einem betroffenen Betrieb waren das 123 Artikel mit zusammen 4.857 Stück zu viel, mit täglich wachsender Tendenz.

Ein Kunde wollte ein zweites Kellner-Tablet anbinden und kam nicht weiter: Die Lizenz gilt je Gerät, im Shop stand nach der ersten Buchung aber „Auf diese Stufe wechseln" statt „Weitere Lizenz kaufen". Betroffen war jedes Modul ohne Stufen, sobald eine Lizenz dafür lief. Abgerechnet wurde dabei nie etwas Falsches — der Server hat jeden dieser Vorgänge abgewiesen, doppelte Abos konnten nicht entstehen.

Kleine Nachbesserung: In der Prüfliste stehen zwei Arten von Einträgen nebeneinander — abweichende Positionen und in JTL zurückgenommene Stornos. Der Knopf „Storno zurücknehmen" erschien bisher bei jedem stornierten Auftrag, auch wenn er aus dem anderen Grund gelistet war.

Bisher war ein Storno eine Einbahnstrasse: Nahmen Sie es in JTL-Wawi zurück, blieb der Auftrag in BIS storniert — und zählte in keiner Auswertung mehr mit, obwohl die Ware geliefert und bezahlt war. Solche Fälle erscheinen jetzt von selbst in der Prüfliste.

Die Artikelverwaltung und das Dashboard nannten verschiedene Warenwerte — rund 42.500 € auseinander. Beide waren für sich richtig: Die eine Kachel zählt alle Artikel, die andere nur die aktiven. Ab sofort steht das auch dabei, und beide rechnen mit derselben Formel.

Wenn Sie JTL-Wawi einsetzen und dort einen Auftrag stornieren, wählen Sie einen Grund aus — „Käuferstorno", „Kein Lagerbestand", „Preisfehler". Dieser Grund kam bisher nicht in BIS ERP an. Ab sofort wird er übernommen, auch rückwirkend für bereits stornierte Aufträge. Zusätzlich können liegengelassene Warenkörbe aus dem BIS Shop zum Anlass für einen Anruf werden.

Ein Auftrag, der vor der Auslieferung storniert wurde, erscheint jetzt in der Anrufliste — mit Betrag und Zeitpunkt im Klartext. Der Kunde war bereits entschlossen zu kaufen; das ist einer der besten Gründe, ihn anzurufen.

Die letzten Kacheln ohne Klickziel sind verlinkt — und zwei Kacheln, die dieselbe Frage verschieden beantworteten, nennen jetzt dieselbe Zahl. Die im Forderungsalter ausgewiesene Summe steigt dabei sichtbar an: Das ist die Angleichung an die Kachel daneben, nicht ein Mehr an offenen Forderungen.

Ein offenes Angebot ist jetzt ein eigener Anlass in der Anrufliste — mit Betrag und Bindefrist im Klartext. Neu ausserdem: die Vertriebs-Scorecard unter Berichte → Mitarbeiter-Leistung, die jeden Mitarbeiter je Monat über sechs Bereiche bewertet.

Die Geschäftszahlen zeigen den Rohertrag jetzt auch je Gruppe — Betreuer, Erfasser, Verkaufsweg, Kundengruppe, Gebiet oder Umsatzart. Ausserdem behoben: Der Schalter „nur Händler" schränkte bisher den Umsatz ein, liess den Gewinn daneben aber unverändert.

Die Geschäftszahlen lassen sich jetzt nach dem Betreuer des Kunden und nach dem Erfasser des Auftrags auffächern — zwei verschiedene Fragen. Neu ist ausserdem die Aufteilung nach Umsatzart: passiv, aktiv erzeugt oder Reaktivierung.

Wer von der Übersicht aus zwei Kennzahlen nacheinander anklickte, bekam beim zweiten Mal die Liste der ersten zu sehen — die Anzahl in der Liste passte dann nicht zur Zahl auf der Kachel. Jeder Klick setzt die Auswahl jetzt neu, auch wenn Sie bereits in derselben Liste stehen.

Fortsetzung der klickbaren Dashboard-Kacheln: Sieben Kacheln, die beim letzten Mal noch ohne Klickziel blieben, führen jetzt ebenfalls zur passenden Liste. Kacheln mit einer Prozent- oder Verhältniszahl statt einer Trefferzahl führen zur Grundlage, aus der sich die Zahl errechnet.

Ein Klick auf eine Dashboard-Kachel öffnet jetzt die passende Liste — gefiltert auf genau die Datensätze, die die Kachel gezählt hat. Beim Verdrahten fiel auf, dass die Forderungsübersicht bereits an der Kasse bar oder per Karte bezahlte Verkäufe mitzählte: Bei einem geprüften Betrieb sank die ausgewiesene Forderungssumme dadurch von rund 156.000 € auf rund 76.000 €, die Zahl der Belege von 698 auf 358 — eine Korrektur einer zu hohen Zahl, kein Geschäftsrückgang.

Der DATEV-Export hat jede Ausgangsrechnung mit 19 % gebucht — auch Rechnungen über Waren mit 7 %. Dazu kamen doppelt geminderte Stornos in UStVA und BWA, vertauschte Steuerschlüssel und nicht erkannte innergemeinschaftliche Lieferungen aus einer JTL-Anbindung. Ein zusammenhängender Themenblock ist jetzt korrigiert — dadurch können sich UStVA-/BWA-Zahlen vergangener Zeiträume rückwirkend ändern.

Im eigenen Profil lässt sich jetzt eine Kundengruppe als Preisfokus wählen. Artikelliste und Artikel-Detail zeigen dann den Preis dieser Gruppe und rechnen Gewinn und Marge konsequent darauf — statt immer auf dem Standardpreis.

Fehlerbehebung zur Vorversion: Mit 0.0.0.886 war angekündigt, dass Angebote aus der JTL-Wawi in BIS ERP sichtbar werden. Schalter und Bedienung waren da, der ausführende Teil kam bei der Auslieferung nicht mit. Der Abgleich holt Ihre nativen JTL-Angebote jetzt tatsächlich — mit Positionen, Anschriften und Kunden.

Der neue Bereich CRM → Pipeline zeigt, wo Ihre Angebote stehen: offen, abgelaufen, angenommen, abgelehnt — mit Anzahl, Wert, Annahmequote, Verlustgründen, Liegezeit und Aufteilung nach Betreuer. Gerechnet wird direkt aus den Angeboten, ohne zusätzliche Datenhaltung.

Angebote aus der JTL-Wawi erscheinen jetzt auch in BIS ERP — mit Positionen, Anschriften und Kunden. Der Zustand kommt aus JTL, aber was Sie in BIS ERP entschieden haben, bleibt bestehen. Der Abgleich hat ein eigenes Startdatum und ist ab Werk ausgeschaltet.

Wer ein Angebot in der JTL-Wawi in einen Auftrag umwandelt, findet die Verbindung jetzt auch in BIS ERP wieder: Der Auftrag kommt herüber und hängt am Angebot, das damit als angenommen gilt. Eine bloße Kopie zählt ausdrücklich nicht als Umwandlung.

Wer mit JTL-Wawi arbeitet, kann Angebote jetzt auch dorthin abgeben: Sie stehen in JTL als echtes Angebot, tragen eine Nummer aus dem JTL-Nummernkreis und bleiben mit dem Auftrag verbunden, der später daraus wird. Der Abgleich ist ab Werk ausgeschaltet.

Die Aktion für neue Betriebe heißt jetzt „BISpicy Startaktion" und gilt für alle Branchen. Sie hat eine eigene Seite auf bispos.app, die Aktionsbedingungen stehen nur noch dort, und während des Aktionszeitraums weist jede Branchenseite darauf hin.

Die ABC-Analyse im Einkauf funktioniert wieder — „Neu berechnen" endete bisher immer in einem Serverfehler. Verkaufspreise sind jetzt eindeutig als netto oder brutto gekennzeichnet, aus der Kundenliste lässt sich eine Wiedervorlage mit Uhrzeit setzen, und die Browser-Kasse signiert in Deutschland jetzt tatsächlich über die TSE.

Die Artikelsuche in „Neue Rechnung" fand keine Artikel mehr — manuelle Rechnungen ließen sich nicht mit Positionen füllen. Das ist behoben. Außerdem funktioniert die Online-Prüfung der USt-IdNr. (VIES) jetzt; ist der Dienst eines Mitgliedstaats nicht erreichbar, zeigt BIS ERP „nicht prüfbar" statt „ungültig".

Aus einem angenommenen Angebot wird mit einem Klick ein Auftrag — mit Positionen, Preisen, Rabatten, Versand und Anschriften, auf demselben Weg wie jeder andere Auftrag. Die Maske „Neuer Auftrag" schlägt jetzt den Nettopreis für genau diesen Kunden vor, statt den Bruttopreis zu übernehmen, und speichert Versandkosten und Lieferland.

Angebote lassen sich als PDF aus der eigenen Vorlage ansehen und direkt per E-Mail an den Kunden senden. Auf dem Beleg steht das tatsächliche Gültigkeitsdatum statt „30 Tage gültig“. Ein Entwurf wird beim Senden automatisch abgeschlossen, ein Doppelklick verschickt nichts doppelt.

Im Terminplaner legen Sie je Leistung fest, ob der Gast seinen Mitarbeiter wählt oder das System die Termine gleichmäßig verteilt — wer in der Woche des Termins die wenigsten Termine hat, ist zuerst dran, und Termine landen nur noch bei Mitarbeitern, die zur gebuchten Uhrzeit Schicht haben. Die Buchungsseite zeigt statt einer Einwilligungs-Checkbox einen Datenschutz-Hinweis mit Link auf die Datenschutzerklärung Ihres Betriebs, und Betriebe bekommen bei Online-Buchungen endlich eine Benachrichtigung. Neu im Kundencenter: ein Bereich für Aktionen, den Anfang macht die „Aktion für Handyshops".

Neuer Schalter „Reverse Charge – sonstige Leistung an EU-Unternehmen" bei der Rechnungserstellung — für Dienstleistungen an Firmenkunden in einem anderen EU-Land, z. B. Provisionen, Beratung oder Software. BIS ERP setzt alle Positionen auf 0 %, druckt den Pflichtvermerk automatisch, verlangt ein Leistungsdatum und prüft die USt-IdNr. des Kunden online (VIES). Dazu: neue UStVA-Kennzahl 21, eigenes DATEV-Konto für Reverse-Charge-Erlöse, und die Zusammenfassende Meldung funktioniert wieder.

BIS ERP kann jetzt Angebote: Kunde wählen, Artikel hinzufügen, der Preis kommt automatisch aus den Konditionen des Kunden (Kundenpreis, Gruppenpreis, Staffel, Aktion). Abschließen friert das Angebot ein und vergibt die Nummer; Änderungen entstehen als neue Fassung, die alte gilt dann als ersetzt. Abgelehnte Angebote tragen einen Grund.

Kassen-Rabattvorlagen lassen sich jetzt auf einen Bereich einschränken, zum Beispiel „20 % auf alles außer Non-Food": alle Artikel, nur bestimmte oder alle außer bestimmten Kategorien/Artikeln, mit Live-Vorschau „betrifft X von Y Artikeln". Dazu ein Bugfix: Pfand (Einweg, Mehrweg, Kasten, Leergut-Rückgabe) wird konsequent nie mehr rabattiert — auch nicht, wenn ein Pfandartikel mit eigener Pfandnummer als normaler Artikel gescannt wird.

Der DSFinV-K-Export (Kassenabschluss-Export für die Fiskaly Cloud) deckt jetzt gezielt genau eine Kasse ab. Betreiben Sie mehrere Kassen, wählen Sie vor dem Export die gewünschte Kasse aus; bei nur einer Kasse geschieht das automatisch. Liegen im gewählten Zeitraum keine Kassenabschlüsse vor, zeigt der Export jetzt eine verständliche Meldung statt eines technischen Fehlercodes.

Nach der Umstellung auf das neuere KI-Modell konnte die Auswertung bei ausführlich bedruckten Etiketten abbrechen — nach über einer Minute kam eine Fehlermeldung statt der ausgelesenen Angaben. Das ist behoben, und die Auswertung ist dabei deutlich schneller geworden.

Die Automatisierung kennt jetzt auch Kunden, nicht nur Bestellungen — Regeln wie „Bestellrhythmus um das Doppelte überschritten → Aufgabe" sind damit möglich, mit denselben Größen, die auch die Anrufliste zeigt. Damit daraus keine Aufgabenflut wird, gibt es einen Stichtag: Nur Kunden, bei denen ab diesem Tag etwas passiert ist, nehmen teil. Ohne diesen Riegel wären bei einem Händler am ersten Tag 1.991 Aufgaben entstanden.

Die ABC-Analyse im Einkauf zeigte technische Platzhalter statt Texten, meldete „Fehler beim Laden" und blieb leer — sie fragte ihre Daten an einer Adresse ab, die es nicht gibt, und der Knopf „Neu berechnen" stiess die Bestellvorschläge an statt der Analyse. Alles behoben, dazu 25 fehlende Texte in drei Sprachen. Ausserdem: Die letzte Notiz zu einem Kunden steht jetzt direkt in der Kundenliste und lässt sich dort mit einem Klick ändern, ergänzen oder löschen.

Derselbe Artikel zeigte im Reiter „Preise" 52,1 % Marge und im Reiter „Statistiken" 59,7 % — die Statistik rechnete den Bruttopreis gegen den Nettoeinkauf und wies damit die Umsatzsteuer als Gewinn aus. Die Marge wird jetzt an einer Stelle gerechnet, mit dem Steuersatz des jeweiligen Artikels. Dazu: verkaufte Menge und Bestellungen je Monat am Artikel, ein Pflichtgrund beim Vermerk „Kein Interesse", eine Einschätzung samt Handlungsvorschlag je Kunde und ein Durchgangs-Modus, der einen Kunden formatfüllend mit allem für das Telefonat zeigt.

Der KI-Artikelassistent liest Ihre Verpackungsfotos ab sofort mit einem neueren Modell — genauer und schneller als bisher, bei unverändertem Preis. In der Einstellungsmaske stand es schon zur Auswahl, gearbeitet wurde aber weiterhin mit dem alten; das ist behoben.

Ein Rabatt auf die Bonsumme liess sich bisher nur aus einer vorher angelegten Vorlage wählen — wer spontan „zehn Euro runter" geben wollte, musste erst eine Vorlage anlegen oder jede Zeile einzeln herunterrechnen. Jetzt wird der Rabatt direkt an der Kasse als freier Euro-Betrag oder Prozentsatz eingetippt, und die Vorschau nennt den Betrag, der tatsächlich abgezogen wird. Dazu neu: Bereits reduzierte Artikel lassen sich vom Bon-Rabatt ausnehmen, und die Bonnummer steht als Barcode auf dem Kassenbon.

Wer einen Benutzer anlegte, dessen Postfach bei Microsoft 365 liegt, kannte die Meldung „Der Link ist ungültig" — obwohl alles in Ordnung war: Microsofts Sicherheitsprüfung öffnet jeden Link einer eingehenden E-Mail vorab und verbrauchte dabei den Einmal-Link, bevor ein Mensch ihn anklicken konnte. Ausserdem erfuhr ein neu angelegter Mitarbeiter sein automatisch erzeugtes Passwort nie und stand nach dem Bestätigen ohne Zugangsdaten da. Dazu nennen unsere Mails jetzt die Frist, die wirklich am Link hängt, statt einer fest einprogrammierten.

Drei Dinge an den grossen Listen: Die Spaltenauswahl blieb nach dem Speichern oft nicht stehen (der Browser lieferte minutenlang den Stand davor), eine neu eingeblendete Spalte verschwand nach rechts aus dem Bild, und beim Scrollen war nicht mehr erkennbar, in welcher Spalte man sich befindet.

Führt man zwei Kundenkarteien zusammen, bei denen die aufgehende gar keine Belege hat, gab es nichts zu verschieben und deshalb auch keinen Protokolleintrag. Beim späteren Auflösen meldete die Oberfläche dann, die Zusammenführung sei vor Einführung des Protokolls erfolgt — was nicht stimmte. Jede Zusammenführung hinterlässt jetzt einen Eintrag, auch ohne bewegten Beleg.

Führen zwei Artikel dieselbe EAN, kann die Kasse nur einen speichern — ein Barcode muss beim Scannen eindeutig sein. Der Rückmeldung darauf galt bisher als Änderung am Artikel, also wurde er im Minutentakt erneut geschickt und erneut abgelehnt. Gemessen bei zwei Betrieben: dieselben fünf bzw. drei Artikel, rund um die Uhr alle 70 Sekunden.

Zusammengeführte Kundenkarteien verschwanden bisher spurlos aus der Liste, und „Zusammenführung lösen" holte nur die Markierung zurück, nicht die Belege. Jetzt zeigt die Zeile des Hauptkunden alle zugeordneten Konten zum Aufklappen, und jede Zusammenführung hält fest, welche Belege sie verschoben hat — das Lösen holt genau diese zurück.

Im Wareneingang gab es vier Schaltflächen ohne Wirkung: „Export" lud nichts herunter, der Filter „Mit Abweichung" lieferte immer eine leere Liste, „Speichern" änderte nichts und „Qualitätsprüfung" öffnete nichts. Export und Filter funktionieren jetzt, die beiden anderen sind entfallen. Ausserdem zeigen die Lagerplatz-Vorschläge nur noch echte Angaben — die Auslastung in Prozent und die Entfernung in Metern waren aus der Listenposition errechnet.

Zwei Einstellungen unter Einstellungen → Inventur — Zählweise galten bisher nur in der Lager-App, obwohl die Seite ausdrücklich zusagte, sie gelten auch im BIS ERP: ob der Zählassistent mit sichtbarer oder verdeckter Sollmenge startet, und ob der Lagerplatz vor dem Artikel gescannt werden muss.

Drei neue, ausführliche Anleitungen beantworten die Fragen, die beim Einrichten am häufigsten aufkommen: der Wareneingang mit beiden Erfassungswegen, die Inventur vom Anlegen bis zur Buchung und die Pflege der Einkaufspreise. Dazu findet die Dokumentationssuche wieder zum richtigen Abschnitt — 38 Sucheinträge zeigten auf Kapitel, die es unter diesem Namen nicht mehr gab.

Die Kassen-App schreibt bei einem Absturz einen Fehlerbericht und schickt ihn beim nächsten Start an den Support. Eingebaut war das seit Langem — angekommen ist bisher kein einziger Bericht: Die Support-Ablage kannte die Herkunft „Kassen-Absturz" nicht und wies jeden Bericht beim Speichern ab, und der Meldeweg verlangte eine Anmeldung, obwohl er gerade für die nicht angemeldete Kasse gedacht ist.

Das CRM zeigt jetzt eine Liste, die ein Mitarbeiter einfach durchtelefonieren kann — umschaltbar zwischen Kunden, die lange nichts bestellt haben, und solchen, die noch nie gekauft haben. Die zweite Gruppe konnte die Liste bisher strukturell gar nicht zeigen: bei einem Betrieb 1.851 von 4.812 Kunden.

Ein Nachlass auf die Bonsumme verteilt sich ab sofort anteilig auf die einzelnen Artikel des Belegs. Bisher stand in den Auswertungen bei jeder Position der volle Preis, während in der Lade der rabattierte Betrag lag — Rohertrag, Artikelstatistik und die Erlöszeilen im DATEV-Export lagen dadurch über dem tatsächlich kassierten Betrag. Pfand bleibt unberührt.

Die Auswertung der Zahlungsarten zeigt jetzt Barzahlung, Kartenzahlung und Sonstige — die Kartenzahlung aufklappbar nach Terminal (SumUp, S-POS, EC-Terminal, Zettle, myPOS, PayOne). Vorher stand dort jede Bezeichnung einzeln, und die Zuordnung suchte nach Bruchstücken im Namen: „R-ec-hnungskauf" zählte deshalb als Kartenzahlung. Über 90 Tage lagen rund 71.000 € im falschen Topf.

Hat die Kasse Ihnen den Wareneingang überschrieben (0.0.0.851), lässt sich der Bestand jetzt nachrechnen statt zählen: eingebuchte Ware minus alles, was seither über die Kasse verkauft wurde. Das Lagerjournal taugt dafür nicht — Ihre Bons schon.

Ware, die Sie im BIS ERP einbuchten, verschwand an manchen Kassen wieder — bei einem Betrieb 84 Stück über Nacht auf 2, ohne eine einzige Buchung dazwischen. Die Kasse meldete einen Bestand zurück, den sie selbst nur geliefert bekommen hatte, und das BIS ERP übernahm ihn ungeprüft.

Der Barcode-Scanner im Wareneingang am Rechner suchte nur in den beim Öffnen geladenen Artikeln und meldete für fast jeden Scan „nicht gefunden". Er fragt jetzt den Server — wie das Handheld seit jeher.

Der Knopf „Werks-Vorlage neu erstellen" löschte eine von Ihnen bearbeitete Vorlage ohne Rückfrage — und sein Begleittext versprach das Gegenteil. Jetzt kommt eine Bestätigung, die sagt, ob Anpassungen verloren gehen.

Am Gerät gefunden: Wurde ein unterbrochener Wareneingang fortgesetzt und dort eine Menge korrigiert, landete die nachgebuchte Ware ohne Lagerplatz im Bestand — da, aber nicht auffindbar.

Jeder Verkauf an der Kasse buchte den Bestand zweimal — die Kasse meldete ihn als Beleg und zusätzlich als Bestandsbewegung, beide zogen ab. Ihr Lager wurde dadurch schneller leer, als Sie verkauft haben, und Artikel verschwanden zu früh aus dem Verkauf.

Bei einer steuerfreien Rechnung blieb die Steuertabelle leer — Spalten für 19 % und 7 % ohne Zahlen, der eigentliche Betrag fehlte. Und eine von Ihnen angepasste Belegvorlage wird nicht mehr mit Werkselementen überschrieben.

Ein Verkauf senkte bisher nur den Artikelbestand — die Lagerzeile blieb stehen. Weil „Bestand neu berechnen" den Artikelbestand aus den Lagerzeilen bildet, machte ein Klick die Verkäufe rückgängig und stellte verkaufte Ware wieder als verfügbar ein. Zugleich weist die Kachel „Geschäftszahlen" jetzt aus, warum der Kassenbon mehr zeigen kann als der Tagesumsatz.

Der Export eines ganzen Jahres brach nach einer Minute mit „Bitte erneut versuchen" ab — und jeder neue Versuch forderte einen komplett neuen Export an, während der fertige unerreichbar in der Fiskaly-Cloud lag. Anfordern und Abholen sind jetzt getrennt.

Das Lieferland entscheidet über den Steuersatz, nicht mehr der Artikel. Eine Ausfuhr ins Drittland ist steuerfrei (§ 4 Nr. 1a i.V.m. § 6 UStG) — bisher standen auf Auftrag und Rechnung trotzdem 7 % oder 19 %, und ausgewiesene Steuer schuldet man dem Finanzamt auch dann, wenn sie gar nicht anfällt.

Nachtrag zur Sofortbuchung: drei Stellen, an denen Ware in den Bestand gelangen konnte, ohne später auffindbar oder einem Gerät zuordenbar zu sein.

Der Wareneingang am Rechner sammelt nicht mehr, sondern bucht jede Position sofort — wie Plus-, Minusbuchung und Inventur. Eine Unterbrechung kostet nichts mehr: Der Beleg bleibt offen und lässt sich fortsetzen, auch von einem anderen Rechner.

Bisher liess sich nur der Terminplaner auf Nutzungsabrechnung umstellen — jetzt auch Tischreservierung, Scan-to-Order, QR-Speisekarte und die Online-Reparaturverfolgung. Die Monatspauschale bleibt bei jedem Modul bestehen.

Sie entscheiden ab sofort für jede Rolle, welche Zahlen auf der Übersicht der Kasse erscheinen. Bisher war es alles oder nichts — wer die Übersicht sehen durfte, sah sie ganz, samt Wochenumsatz und Vergleich zum Vortag.

Marktplatz-Aufträge lassen sich ab sofort pauschal abrechnen statt nach Menge — 250 für 25 €, 1.000 für 89 €, 3.000 für 199 € oder unbegrenzt für 399 €. Teurer wird es dadurch nie: Liegt die Abrechnung nach Menge darunter, berechnen wir die.

Ihre Mitarbeiter gehören ab sofort Ihrem Betrieb — nicht mehr der einzelnen Kasse. Wer an einer Kasse angelegt wird, steht sofort im Benutzerkreis und ist auf jeder weiteren Kasse bekannt. Sie geben nur noch frei, wo er arbeiten darf.

Zwei Preisänderungen: Die Zusatzmodule der Kasse können Sie künftig nach Nutzung abrechnen statt pauschal — teurer werden kann es dabei nicht, der bisherige Monatspreis ist die Obergrenze. Und die Obergrenze für importierte Marktplatz-Aufträge steigt von 159 € auf 479 €; darunter bleibt die Staffel unverändert.

Ihre Kundschaft bezahlt mit dem eigenen Handy: Die Kasse zeigt einen QR-Code, der Kunde bestätigt in seiner PayPal-App, und erst wenn das Geld bestätigt ist, bucht die Kasse und druckt den Bon. Besonders für die Selbstbedienungs-Kasse, an der niemand eine Karte entgegennehmen kann.

Der Wareneingang am Handheld sammelt nicht mehr, sondern bucht jede Position sofort — wie Plus-, Minusbuchung und Inventur. Eine Unterbrechung kostet nichts mehr: Der Beleg bleibt offen und lässt sich fortsetzen, auch nach einem Neustart des Geräts.

Die Sendungsverfolgung hat ab sofort dieselbe Freigrenze wie die Marktplatz-Auftraege: die ersten 50 im Monat sind frei. Ihr Verbrauch ist jetzt im Kundencenter einsehbar, und die Zaehlung erfasst erstmals alle Versandwege.

Begleicht ein Kunde an der Kasse eine offene Rechnung, gilt sie in JTL-Wawi ab sofort als bezahlt. Bisher wurde die Zahlung nur dem Auftrag gutgeschrieben — die Rechnung selbst blieb offen und landete im Mahnwesen.

Lagert Ihre Ware bei einem Fulfillment-Dienstleister, zeigt BIS ERP jetzt wieder Charge und Mindesthaltbarkeitsdatum je Lager — bisher stand dort ein Strich, obwohl der Dienstleister die Daten führt.

Automatisch importierte Marktplatz-Auftraege kosten keinen Grundpreis mehr. Die ersten 50 im Monat sind frei, darueber zahlen Sie je Auftrag — und nie mehr als 159 Euro im Monat, egal wie viele es werden.

Rabatte am ganzen Auftrag oder an einzelnen Positionen — mit Warnung, sobald ein Preis den Einkaufspreis unterschreitet. Dazu Unterpositionen für Veredelungen wie Textildruck, Gravur oder Zuschnitt, die sich selbst berechnen.

Herkunftsländer Ihrer Artikel erscheinen jetzt als eigener Bereich auf der Startseite — "Woher soll's kommen?" mit einer Kachel je Land. Erscheint automatisch, sobald mindestens ein Artikel ein eindeutiges Herkunftsland trägt, und wächst mit Ihrer Pflege mit.

Zwei Modelle lasen dasselbe Etikett und schrieben Zeichen für Zeichen dasselbe — und die Gegenkontrolle meldete trotzdem eine Abweichung. Der Grund saß im Vergleich, nicht in den Lesungen. Betroffen war jeder zweite Befund, und jeder davon hielt ein fehlerfrei gelesenes Produkt von der Veröffentlichung ab.

Zwei Modelle lesen jedes Verpackungsfoto unabhängig — und erst dieser Vergleich zeigt, was eine Anweisung offen lässt. Aus einem Durchlauf über hundert Fotos sind elf Präzisierungen entstanden, jede aus einem echten Fall. Außerdem gehen Bilder bei einer Ablehnung nicht mehr verloren.

Die Reparatur-Auftragsverwaltung und die Differenzbesteuerung nach § 25a UStG gehören ab sofort zur kostenlosen Grundausstattung BIS Free — ohne Buchung, in der Kasse wie in BIS ERP. Kostenpflichtig bleibt allein die Online-Statusverfolgung für Ihre Kundschaft. Dazu kommen vier klare Stufen: Free, Basic, Premium und Pro.

Jedes eingereichte Verpackungsfoto wird von einem zweiten, unabhängigen Modell blind ein zweites Mal gelesen — das war eingebaut, hat aber nie funktioniert und fiel nicht auf, weil der Fehlschlag wie eine Störung beim Anbieter aussah. Bei Zutatenlisten und Allergenen ist das die Kontrolle, auf die es ankommt. Sie greift jetzt.

Wenn der Artikel-Assistent länger braucht, sagt er das jetzt — statt still zu stehen. Die Bilder werden sofort gespeichert, Sie können das Fenster schließen, und das Ergebnis wartet beim nächsten Öffnen auf Sie: Es liegt auf dem Server, nicht in Ihrem Browser. Am Preis ändert sich nichts, abgebucht wird erst bei einem Ergebnis.

Wer am Handheld einen Karton scannt, konnte ihn zwar sehen, aber nicht einbuchen: Die Buchung meldete „Gebucht", bewegte aber nichts — beim nächsten Scan stand der Bestand wieder auf 0. Betroffen war jeder Artikel, der keine eigene Einzel-EAN führt und nur über seinen Gebinde-Barcode erreichbar ist; bei einem Getränkehändler allein 110 Artikel.

Wenn Sie Ihre Rechnungen in JTL schreiben lassen, legt BIS ERP beim Versand zusätzlich einen eigenen Beleg an — absichtlich, damit Ihre Historie vollständig bleibt. Seit die JTL-Rechnungen in den Auswertungen sichtbar sind, standen dadurch zwei Belege für denselben Auftrag in EÜR, BWA, Umsatzsteuer-Voranmeldung und DATEV-Export.

Wenn die KI aus einem Verpackungsfoto Zutaten, Allergene oder Nährwerte ausliest — im Artikel-Assistenten, im Zutaten-Reiter oder bei einer Einreichung an die Produktdatenbank —, prüft ab sofort ein zweites, unabhängiges Modell dasselbe Foto blind nach. Stimmen beide Lesungen überein, wird wie gewohnt automatisch übernommen; weichen sie ab, landet der Fall in einer neuen Prüfliste statt ungeprüft durchzulaufen.

Wer was darf, gilt jetzt auch am Lagergerät: Bis hierher konnte jeder mit einem gekoppelten Handheld alles — Bestand korrigieren, Inventuren abschliessen, Wareneingänge buchen, Retouren annehmen. Von 117 Wegen prüften genau zwei ein Recht. Zusätzlich läuft der Packtisch jetzt auf einem Tablet mit der Lager-App.

Vier Verbesserungen in einem Schritt: Die Datenschutz-, AVV- und AGB-Links in Registrierung und Kundencenter-Login funktionieren nach dem Subdomain-Umzug wieder, der Amazon-Import überspringt lückenhafte Bestellungen bei einem API-Rate-Limit statt sie fehlerhaft anzulegen, und die Einnahmen-Überschuss-Rechnung teilt Umsätze wieder korrekt auf die Steuersätze auf.

Abschluss zu 0.0.0.813: Dort war der Forderungsausgleich bereits aus EÜR und BWA herausgerechnet — der DATEV-Export und die Buchungs-Engine buchten ihn aber weiterhin als Umsatzerlös. Jetzt entsteht die richtige Buchung: Geldkonto an Forderungen aus Lieferungen und Leistungen, umsatzsteuerfrei.

Der Wortlaut auf der öffentlichen Produktseite ist jetzt rechtlich präziser. Das gepflegte Herkunftsland-Feld bildet den zollrechtlichen Ursprung ab, nicht den strengeren "Made in"-Maßstab — deshalb heißt es jetzt "Ursprungsland" statt "Hergestellt in".

Zahlt ein Betrieb Pfand für zurückgebrachtes Leergut aus, ließen EÜR, BWA und Umsatzsteuer-Voranmeldung diesen Beleg bisher vollständig aus — während der Kassenbericht ihn seit jeher einbezog. Richtig ist der Einbezug: Eine Pfandrückgabe mindert Umsatz und Umsatzsteuer (Entgeltminderung nach § 17 UStG). Bei einem Betrieb betraf das 2026 genau 76 Belege.

Bezahlt ein Kunde an der Kasse eine bereits bestehende Rechnung, floss der Betrag bisher als Kassenumsatz in die Auswertungen — obwohl der Erlös zur Rechnung gehört und dort gebucht war. Solange die JTL-Rechnungen fehlten, fiel das nicht auf; seit sie sichtbar sind, stand derselbe Betrag zweimal. Der Anteil wird jetzt positionsgenau abgezogen.

Wer seine Rechnungen in JTL schreiben lässt, sah sie in BIS ERP zwar in der Belegliste — in EÜR, BWA, Umsatzsteuer-Voranmeldung und DATEV-Export fehlten sie. Bei einem Betrieb waren das 2,72 Mio € über alle Jahre. Die Übernahme aus JTL füllte technisch nur die eine von zwei Schreibweisen, die Auswertungen lesen die andere. Ab sofort schreibt sie beide, ein einmaliger Nachtrag holt die vorhandenen Rechnungen nach.

Wer seine Rechnungen in JTL schreiben lässt und die Ware über den Packtisch versendet, bekam bei jedem Versandabschluss eine zweite Rechnung dazu — beide zählten in EÜR, BWA, DATEV und Umsatzsteuer-Voranmeldung. Der Grund war eine halbe Prüfung: Eine Rechnung hängt über drei Felder am Auftrag, nachgesehen wurde nur in einem. Dazu: Betreuer und Gebiet lassen sich jetzt für viele Kunden auf einmal zuordnen, Listen merken sich wieder, wo man war, und das Handheld sagt beim Scannen, ob eine Nummer ein Einzelstück oder einen Karton meint.

Beim Verpacken merkt sich das System, was im Karton liegt. Diese Notiz wurde bisher nur aufgeräumt, wenn der Auftrag am Packtisch abgeschlossen wurde — ging er über die Sendungsanlage, die JTL-Anbindung oder einen Marktplatz raus oder wurde storniert, blieb sie für immer stehen. Ein regelmäßiger Aufräumlauf entfernt sie jetzt von selbst.

Am Packtisch entscheidet jetzt der gewählte Grund, was mit dem Bestand geschieht. Bruch, abgelaufene Ware und eine echte Bestandsdifferenz werden ausgebucht; alle übrigen Gründe lassen die Ware verkäuflich im Regal stehen. Bisher passierte in beiden Fällen dasselbe — nämlich nichts, und die Bruchware stand weiter zum Verkauf.

Der unbeaufsichtigte Betrieb der Kasse und das Lesen preiscodierter Waagen-Etiketten waren vollständig gebaut — nur ließen sie sich nirgends einschalten. Beides steht jetzt in der Kasse unter Einstellungen → Unternehmen → Betriebsmodus und lässt sich zusätzlich je Gerät aus dem Kundencenter fernsteuern.

In der Marge-Zeile des Artikels stand beim Verkaufspreis der Bruttobetrag, während Gewinn und Marge daneben netto gerechnet wurden — die Zeile war in sich widersprüchlich. Gerechnet wurde immer richtig, falsch war nur die Anzeige. Dazu übernimmt BIS ERP jetzt auch den zuletzt gezahlten Einkaufspreis aus JTL, wenn das Stammdaten-Feld leer ist.

Wird die Versandart eines Auftrags nachträglich in JTL geändert, übernimmt BIS ERP das jetzt automatisch — in jedem Bearbeitungsstand. Die Zahlungsart zieht ebenso nach, aber nur solange noch kein Beleg existiert.

Scheitert der JTL-Workflow, der die Rechnung schreibt und verschickt, an einer Sperre — weil ein Mitarbeiter den Auftrag gerade offen hat —, holt BIS ERP das jetzt von selbst nach. Bisher wurde der Fehlschlag zwar binnen Minuten erkannt, aber niemand tat etwas: In einem Fall wartete der Kunde vier Stunden auf eine Rechnung über gut 2.000 €.

Anschrift, Versand, Zahlung und Abschluss auf einer Seite — und der Bestellknopf heisst endlich richtig.

Vorschaubilder zeigen den ganzen Artikel; „In den Korb" lässt den Kunden auf der Seite.

Retourenbelege der JTL-Kasse fehlten ganz oder unvollständig — bei einem Mandanten 58 Belege über 14.466,36 €. Und in JTL gelöschte Artikel blieben in BIS ERP aktiv stehen.

Die Startseite trägt jetzt immer zwei Knöpfe — vorher erschien einer nur bei vollständiger Pflege.

Ihre Kunden legen sich Artikel für später zurück — Herz, Zähler in der Kopfzeile, eigene Seite.

Ihr Kunde musste bisher jeden Artikel erst öffnen, um ihn zu kaufen.

Suchen ging bisher nur, wenn der Kunde erst auf eine Sortimentsseite fand — im Kopfbereich gab es kein Feld.

Der Abgleich schob immer nur die 500 zuletzt geänderten Artikel — wer aus dem Fenster fiel, wurde nie wieder angefasst.

Ein einziger Artikel ohne Variante warf die ganze Kategorieseite ab — der Kunde sah eine Fehlerseite statt Ihres Sortiments.

Markenzeile, Verfügbarkeit und Grundpreis waren seit Wochen fertig — und unerreichbar, weil die Pflegestelle im ausgeblendeten Shop-Backend lag.

Bisher durfte ein eigenes Layout nur kleiden — die Reihenfolge auf der Startseite lag fest und sah bei jedem Shop gleich aus.

„Vor 8 Stunden" waren in Wahrheit 6: Zeitpunkte vom Server wurden zwei Stunden zu alt gelesen — im Winter eine.

Die Produktkacheln waren nie gestaltet, und ganz oben stand Werbung für BISpicy statt für Ihren Laden.

Die Aktualisierung lief durch und änderte nichts — der Zwischenspeicher des Shops hielt die alte Gestaltung fest.

Die Fehlerliste nach einem Gebinde-Import endete bei 50 Zeilen, ohne das zu sagen — ein Import mit 300 Fehlern sah aus wie einer mit 50.

Ein Gebiet mit Tourtag Mittwoch war samstags gar nicht zu sehen, und die Kundenliste endete nach 30 Einträgen ohne Weg zum Rest.

Die Übernahmeregel verlangte eine positive Menge — eine Gutschrift besteht aber nur aus negativen und fiel deshalb vollständig heraus.

Derselbe Fehler lag ein zweites Mal in der Maske hinter „Duplikate verwalten" — und die Reparatur dort räumte nur eines der beiden Barcode-Felder.

Die Freigabe „darf vor Zahlungseingang versendet werden" kam bisher nur aus JTL und war nicht änderbar — jetzt steht sie an Ihrer eigenen Zahlungsart.

Die Kachel meldete „152 Artikel betroffen" und listete zwanzig, und die Prüfung auf doppelte Gebinde-EANs verglich jedes Gebinde mit sich selbst.

Bisher galt der Kurzname als vergeben, solange das Layout in Gebrauch war — ein Update war ein Vierschritt mit sichtbarer Zwischenstufe.

Ohne Steuerdaten blieb jeder Artikel ohne Preis liegen. Und die Steuerklasse entscheidet jetzt über den Satz, nicht ein oft veraltetes Feld.

Bei jedem Abgleich fragte BIS ERP Ihre JTL-Wawi mehrfach nach Version und Tabellen-Ablage — Angaben, die sich praktisch nie ändern.

Der Buchhalter sieht wieder Einkaufspreise und Marge, der Vertrieb den Einkauf nicht mehr, und Newsletter darf er versenden, aber nicht löschen. Aufträge werden ohnehin nur storniert und nie gelöscht — das ist jetzt abgesichert.

Der Abgleich mit JTL-Wawi schrieb Ihre Warengruppen bei jedem Durchlauf komplett neu — auch ohne Änderung.

Artikel kamen im Webshop bisher gar nicht an, und die Fußzeile zeigte fremde Rechtstexte. Beides ist behoben.

Aussendienst und Innendienst bekommen jetzt verschiedene Übersichten. Die eine ist eine Arbeitsliste („wen rufe ich heute an"), die andere zeigt Durchsatz und Ausnahmen. Wer sein Dashboard schon selbst eingerichtet hat, behält es unverändert.

Neu ist ein Schalter „Sichtbarkeit in Suchmaschinen" je Verkaufskanal. Bisher lag diese Entscheidung in der Serverkonfiguration — an einer Stelle, die kein Händler sieht. Praktisch war damit jeder Shop für Suchmaschinen gesperrt, auch ein fertiger.

Der Rohertrag war zu hoch, weil Rabattzeilen aus der Rechnung fielen. Ausserdem sagt die Kachel jetzt, worauf sie rechnet: Pfand und Positionen ohne Einkaufspreis bleiben aussen vor und werden ausgewiesen. Und die Auftragskette folgt endlich dem gewählten Zeitraum.

Ein einzelner Auftrag ohne zugeordneten Kunden konnte den gesamten JTL-Abgleich bei jedem Durchlauf als fehlgeschlagen markieren.

Die Aufstellung „Gewinn & Kosten" in der Auftragsansicht war für jeden sichtbar — Nettoumsatz, Wareneinsatz, Gebühren, Gewinn und Marge. Ohne das Recht „Kosten sehen" verschwindet sie jetzt vollständig, statt Nullwerte zu zeigen.

In der Auftrags- und Rechnungsmaske sowie im Kassen-Dashboard standen Beträge als „10.99 EUR" statt „10,99 €" — direkt neben Kacheln, die es richtig machten. 18 Stellen korrigiert, dazu ein Wächter, damit das Muster nicht zurückkommt.

Die Kachel „Gesamtwert" rechnet Bestand mal Einkaufspreis und stand bisher jedem offen — auch Mitarbeitern, die bewusst keine Einkaufspreise sehen sollen. Ohne das Recht „Kosten sehen" verschwindet sie jetzt, statt „0,00 €" zu zeigen.

Nachtrag zur letzten Version: Wer keine Artikel ändern, anlegen oder löschen darf, sah zwar keine Knöpfe mehr — die Spalte „Aktionen" stand aber weiter da und nahm Breite weg. Sie wird jetzt mit ausgeblendet.

Knöpfe, die Ihre Rolle nicht bedienen darf, erscheinen nicht mehr — in der Artikelliste ebenso wie in der Seitenleiste. Ein Knopf, der zuverlässig in eine Fehlermeldung führt, ist schlimmer als gar keiner. Ausserdem kann der Vertrieb keine Preise mehr über den Repricer ändern.

Aufträge, Kunden, Rechnungen, Lager und Kommissionierung prüfen ab sofort die Rollenrechte. Bisher konnte jeder angemeldete Mitarbeiter dort anlegen, ändern, löschen und importieren — die Rechtevergabe wirkte nur auf die Oberfläche, über die Adresszeile kam man trotzdem hin. Betroffen sind 81 Vorgänge. Ein Wächter hält offen, dass jeder neue Vorgang sein Recht nennt.

Unsere Systemüberwachung meldete, Artikelbestand und Lagerbestand gingen auseinander. Die Warnung war falsch — sie zählte Lagerzeilen mit, die nicht zum verfügbaren Bestand gehören.

Der Artikelstamm prüft jetzt Ihre Rollenrechte: Anlegen, Ändern, Löschen, Import und Bestandskorrektur verlangen das Recht, das ihr Name sagt. Neu ist „Artikelpreise ändern“ als eigenes Recht — wer Texte, Bilder und Masse pflegt, muss nicht zugleich Preise setzen dürfen. Ausserdem behoben: Preisänderungen am Artikel wurden bei Nicht-Administratoren stillschweigend verworfen.

Ihr Webshop kann jetzt die Marke über dem Produktnamen zeigen, die Verfügbarkeit an der Kachel und den Fortschritt zum versandkostenfreien Warenkorb. Jedes einzeln schaltbar, ab Werk alles aus. Dazu bekommt der Spurenhinweis bei Lebensmitteln einen eigenen, deutlich abgesetzten Platz — er gehört nicht ins Zutatenverzeichnis.

Die ABC-Einstufung Ihrer Kunden liess sich bisher nirgends im ERP ablesen. Neu zeigt eine Kreuztabelle, wie sich A, B, C und D auf Ihre Kundengruppen verteilen — bei einem Grosshandel mit 4.730 Kunden sind 131 der 134 A-Kunden Händler, und 1.612 der 2.133 inaktiven ebenfalls. Ausserdem bekommt jeder Mitarbeiter beim ersten Anmelden das Dashboard, das zu seiner Rolle passt.

Unsere Systemüberwachung schlug mehrfach Alarm, weil einzelne Seiten während der nächtlichen Datensicherung langsam waren. Sie unterscheidet das jetzt von echten Auffälligkeiten.

Ein hochgeladenes Shop-Layout, das eine Pflichtangabe verschluckt, wird ab sofort abgelehnt statt ausgeliefert — drei Bauweisen kamen bisher durch, und die Seite baute dabei fehlerfrei. Außerdem meldet sich ein neu bereitgestellter Webshop von selbst, sobald er erreichbar ist.

Zwei Steuer-Auswertungen gingen bisher davon aus, dass Ihr Betrieb in Deutschland sitzt. Sie richten sich jetzt nach dem Land in Ihren Firmeneinstellungen.

Aufträge mit abweichendem Preis warten auf eine Freigabe — die erteilen Sie ab sofort im neuen Reiter „Preisfreigaben“ der Auftragsliste, mit Artikel, Katalogpreis, zugesagtem Preis und Abweichung in Prozent. Freigeben, eigenen Preis setzen oder ablehnen; bei den letzten beiden ist ein Vermerk Pflicht.

Beim nächsten Anmelden werden Sie einmalig gebeten, Firmenname, Anschrift, Land und Rechtsform zu vervollständigen — danach ist Ruhe. Davon hängen Rechnungen, Lieferscheine und die vorgeschriebene Signatur Ihrer Kassenbons ab.

Auf dem Lieferschein stand bisher nur der „Bearbeiter“ — und das ist, wer den Beleg erstellt oder gepackt hat, nicht wer den Vorgang kennt. Neu steht dort der Mitarbeiter, der den Auftrag erfasst hat; ersatzweise der Betreuer des Kunden. Ist beides nicht gepflegt, bleibt die Zeile bewusst leer.

Ein Auftrag hielt bisher nirgends fest, welcher Mitarbeiter ihn angelegt hat — damit war weder auswertbar, was jemand selbst erfasst hat, noch konnte ein Ansprechpartner auf einem Beleg stehen. Neu merkt sich jeder in BIS ERP erfasste Auftrag seinen Urheber, und die Kachel „Meine Aufträge“ zeigt erfasste, bezahlte, versandte und offene Aufträge samt Auftragswert und überfälligen Rechnungen.

Neben den fünf mitgelieferten Layouts können Sie jetzt Ihr eigenes mitbringen: als ZIP-Archiv hochladen, BIS ERP prüft es, baut die Stile und stellt es in Ihrem Shop zur Auswahl. Ihr Layout gehört Ihnen allein — kein anderer Händler sieht es oder kann es einsetzen, auch nicht, wer den Namen errät.

Einkaufspreise, Marge und Gewinn sind jetzt überall rechtepflichtig — nicht mehr nur auf dem Dashboard. Abweichende Preise werden nicht mehr stillschweigend zurückgesetzt, sondern laufen über eine Freigabe: Der Auftrag entsteht mit dem zugesagten Preis und wartet, statt dass der Kunde erst auf der Rechnung sieht, dass etwas anderes gilt. Und Kontaktversuche stehen mit Namen in der Kundenakte.

Die Überwachung meldete „83 % Bestandsabweichung“, tatsächlich waren es 0,15 %. Gemessen wurde genau während der Abgleich mit JTL die Lagerzeilen neu aufbaute. Die Sicherung dagegen existierte, hatte aber eine eigene Zeitgrenze (10 Minuten) — der Abgleich selbst wartet 15.

Sie bekommen nur noch die Steuerberichte angeboten, die zu Ihrem Betrieb passen: Kapitalgesellschaften sehen keine Einnahmen-Überschuss-Rechnung mehr, Betriebe ausserhalb Deutschlands keine deutschen Formulare. Neu erfassbar sind Rechtsform, Gewinnermittlung, Registergericht und Geschäftsführung.

Der Abgleich mit JTL las bei jedem Durchlauf den kompletten Lagerbestand — bei einem Betrieb 93.615 Zeilen, von denen sich zuletzt neun geändert hatten. Er fragt jetzt zuerst nach, ob sich überhaupt etwas bewegt hat, und überspringt den Block sonst.

Drei Quellen für Fehlmeldungen sind versiegt: Rechnungsentwürfe galten als „Rechnung ohne Auftrag“ (71 von 89 Fällen bei einem Betrieb), 28 Stück Bestandsabweichung auf 25 Artikeln lösten Alarm aus, und ein Vorfall, der mehrere Betriebe gleichzeitig traf, erzeugte je Betrieb eine eigene Meldung.

Ein Barcode, den kein Artikel führt, landete am Handheld mit Erfolgston in der Liste und wurde beim Buchen stillschweigend verworfen. Jetzt fragt das Gerät nach: Artikel suchen und den Barcode zuordnen, neu anlegen, oder bewusst ohne Zuordnung übernehmen.

Der Gesamtumsatz in der Kundenakte war schon immer netto — darunter stand aber „brutto“, und der Hinweistext behauptete, die Umsatzentwicklung zeige „deshalb kleinere Beträge“. Beides war falsch. In der Tourliste stand die Sortierung zu Unrecht unter Verdacht: Sortiert wurde nach Gesamtumsatz, angezeigt der 90-Tage-Umsatz.

Der Artikelabgleich holt aus JTL nur, was dort als geändert gemeldet wird — wurde ein Artikel dabei einmal übersprungen, kam er nie wieder an die Reihe. Bei einem Mandanten mit knapp 5.000 Artikeln fehlten dadurch 293 gepflegte Mindestbestände, 670 Herkunftsländer und 52 Barcodes, ohne dass irgendwo eine Meldung erschien. Neu prüft BIS ERP den kompletten Artikelstamm laufend selbst nach.

Zwei wiederkehrende Warnungen waren Fehlalarme, und eine ganze Klasse von Meldungen kam nach dem ersten Mal nie wieder — alle drei Ursachen lagen in der Überwachung selbst, nicht in den Daten. Gemeldet wurden unter anderem „80 von 80 Rechnungen ohne Auftragsbezug“ (alle waren Abo-Rechnungen) und „96,9 % Bestandsabweichung“, wo nachgemessen 0,1 % standen.

Wer seine Warenwirtschaft aus JTL übernimmt, bekam bisher Aufträge, Rechnungen, Artikel und Kunden — drei Bereiche fehlten ganz. Gutschriften hatten schlicht keinen Weg: Steuerlich sind sie Rechnungen mit umgekehrtem Vorzeichen, und solange sie fehlen, weisen EÜR, BWA und der DATEV-Export Erlös aus, den Sie längst gutgeschrieben haben — bei einem Kunden 183 Gutschriften über 30.014,91 €, zurück bis Februar 2024. Bei Zahlungen stand am Beleg nur „bezahlt“; jetzt kommen 5.924 Zahlungen über 2,59 Mio. € mit, darunter 117 Rechnungen mit Teilzahlungen, womit offene Posten und Mahnwesen belastbar werden. Und Retouren zeigen jetzt, welcher Artikel aus welchem Grund zurückkam. Kassenzahlungen bleiben außen vor — die stehen über die Kasse bereits im System.

Alle zehn Dashboard-Kacheln haben einen Export — nicht die Kennzahl, sondern jede Zeile, die in sie eingeht, mit Herkunftsangabe im Kopf und einer Summenzeile, die mit der Kachel übereinstimmt. Bei allen zehn an echten Daten gegengerechnet.

Unter Einstellungen → Webshop entsteht Ihr Shop mit einem Klick — samt Adresse, Verwalter-Zugang und Grundeinstellungen. Dort sehen Sie auch, was bei einer offenen Rechnung passiert: 14 Tage läuft alles unverändert weiter, danach wird der Verkauf geschlossen, während Impressum, Datenschutz, Widerruf und Bestellverfolgung erreichbar bleiben.

Der Zeitraum-Umschalter im Dashboard funktionierte nicht — jede Auswahl ersetzte die Seite durch eine Fehlermeldung. Das ist behoben, ebenso die Beschriftungen, die bei „Letzter Monat“ weiterhin „heute“ sagten. Zusätzlich führen Exporte keine Formeln mehr aus.

Wer etwas mit Pfand in den Warenkorb legte, konnte die Bestellung nicht abschliessen — statt einer Bestätigung erschien „Das Produkt Pfand ist nicht mehr verfügbar“. Behoben und nachgeprüft. Aufgefallen war es nie, weil bis dahin niemand Pfandware bestellt hatte.

Im Webshop endete der Bestellabschluss mit einer Fehlerseite, obwohl die Bestellung sauber angekommen war. Ursache war der Einwilligungs-Banner: Er vergewisserte sich bei jedem Seitenaufbau, dass sein Ablagefach existiert — und unterbrach damit mitten im Bestellvorgang den laufenden Vorgang der Datenbank.

Sie bestimmen jetzt den Auswertungszeitraum — heute bis letztes Jahr oder frei gewählt. Und Sie können jede Zahl belegen: Geschäftszahlen und Mindesthaltbarkeit lassen sich als CSV oder Excel herunterladen, mit jeder Zeile, die in die Kennzahl eingeht, und einer Summenzeile, die mit der Kachel übereinstimmt.

Unter welcher Adresse Ihr Webshop erreichbar ist, war bisher nichts, was Sie selbst einstellen konnten — sie wurde bei der Einrichtung vergeben. Unter Einstellungen → Webshop → Adresse & Domain ändern Sie den Namen jetzt selbst, und Sie können eine eigene Domain anbinden.

Funktionieren die hinterlegten DHL-Zugangsdaten? Das liess sich bisher nur herausfinden, indem man einen echten Auftrag verpackte und hoffte. Unter Einstellungen → Versanddienstleister → DHL steht jetzt „Verbindung testen“ — und ab Werk entsteht dabei nichts: keine Sendungsnummer, kein Etikett, keine Kosten.

Auf dem Dashboard stand unter „Niedrigbestand“ statt der beiden Schaltflächen ein interner Platzhalter, im Artikelbereich fehlte die Beschriftung „Versandklasse“. Alle drei sind in Deutsch, Englisch und Thailändisch ergänzt.

Ein Zahlendreher im Mindesthaltbarkeitsdatum machte Ware unsichtbar: Wer statt 2026 versehentlich 2069 eingab, bekam keinen Hinweis — die Charge lief für das System „in 43 Jahren“ ab, tauchte in keiner Ablaufwarnung auf und wurde vom Ausverkauf nicht erfasst. Solche Daten werden bei der Erfassung jetzt abgelehnt, bereits erfasste Fälle erscheinen unter Datenqualität.

Bisher konnten Sie einen an der Kasse ausgestellten Gutschein im Onlineshop einlösen. Jetzt geht auch der Weg dorthin: Sie verkaufen Gutscheine im Shop, eingelöst werden sie an der Kasse. Ein Haken im Artikel genügt.

Am Packtisch funktionierte das Minus nur für denjenigen, der die Ware auch eingescannt hat. Packte Kollege A und korrigierte Kollege B, zählte der Bildschirm herunter — im Bestand passierte nichts, die Ware blieb auf dem fremden Wagen reserviert. Jetzt merkt sich der Karton, wohin gebucht wurde.

Die Forderungen nach Alter standen innerhalb der Auftragskette. Fachlich passte das, in der Bedienung war es ein Rückschritt: Was in einer Kachel steckt, lässt sich nicht mehr einzeln verschieben, verkleinern oder ausblenden. Beide sind jetzt wieder eigene Kacheln und stehen im Werkslayout nebeneinander.

Der Webshop bekommt ein fünftes Aussehen. „Kollektion“ ist für Mode, Schmuck und Wohnen gemacht und unterscheidet sich von den bisherigen nicht in der Farbe, sondern im Aufbau: wenige Stücke groß statt vieler klein. Wählbar je Verkaufskanal unter Einstellungen, Schnittstellen, Aussehen (Webshop).

Auftragskette, Lagerbestand und Mindesthaltbarkeit waren bisher nur sichtbar, wer die Vorlage „Geschäftsführung“ ausdrücklich geladen hat. Sie werden Ihrem Dashboard jetzt automatisch hinzugefügt — unten angehängt, ohne dass Ihre eigene Anordnung durcheinandergerät.

Das Eingabefeld für Guthaben-Gutscheine war im Warenkorb zwar zu sehen, tat aber nichts — der Klick landete bei der Kasse statt bei der Einlösung. Behoben und im Browser durchgeprüft: Code eingeben, Betrag wird angerechnet, der noch zu zahlende Rest steht darunter.

Wird beim Verpacken jede offene Position als Fehlbestand ausgebucht, ist der Karton leer. Bisher ließ sich der Vorgang trotzdem abschließen — daraus entstand eine Sendung über nichts, mit Beleg, Bestandsabzug und Rechnung über Ware, die niemand bekommen hat.

Das Dashboard zeigt jetzt zusammen, was zusammengehört — und es zeigt, welche Ware Ihnen davonläuft. Neu ist eine Kachel für das Mindesthaltbarkeitsdatum, die Ihre Ware nach Restlaufzeit staffelt, damit sich abverkaufen lässt, solange sie noch verkäuflich ist. Die Auftragskette steht oben und führt von den Zahlen des Tages bis zur bezahlten Rechnung.

Ein Gutschein aus Ihrer Kasse lässt sich jetzt auch im Webshop einlösen. Der Kunde gibt den Code im Warenkorb ein und sieht sofort, wie viel angerechnet wird und was noch zu zahlen bleibt. Der Gutschein wird als Zahlung verbucht, nicht als Rabatt — dadurch bleiben Umsatz und Umsatzsteuer korrekt.

Ware, die einem Kunden zugesagt ist, muss vom verfügbaren Bestand abgehen — sonst verkaufen Sie sie ein zweites Mal. Bisher zählten dafür nur die Zustände Neu, Bestätigt und In Bearbeitung; zurückgehaltene Aufträge und Teillieferungen fielen durch und hielten überhaupt keinen Bestand fest. Bei einem Mandanten waren das 124 Artikel mit 4.042 Stück, die den Marktplätzen weiterhin als verfügbar gemeldet wurden.

Riss die Verbindung zum JTL-Fulfillment-Network ab, konnte Ware wieder auftauchen, die beim Dienstleister längst nicht mehr liegt — BIS ERP griff dann auf den Bestand zurück, den JTL-Wawi für dasselbe Lager führt, und der steht seit dem Umzug aufs Fulfillment still. Ab sofort führt das Fulfillment-Network Ihren Bestand auch dann weiter, wenn die Verbindung gerade gestört ist.

Beim Verpacken entstand bisher ein Beweisfoto je Packstück. Ab sofort legen Sie fest, wie viele Aufnahmen gemacht werden und was darauf zu sehen sein soll — „Karton offen von oben“, „Karton verschlossen mit Etikett“. Der Text steht am Lagergerät über dem Auslöser, der Packer muss also nicht raten.

Auf Belegen stand bisher auch dann ein Strichcode, wenn der Artikel keine EAN hat — codiert wurde dann die interne Artikelnummer. Diese Codes sind deutlich schmaler als die echten, und scannen lässt sich damit beim Empfänger nichts. Ab sofort gilt: keine EAN, kein Barcode. Die Zeile bleibt sonst unverändert.

Wenn Sie Artikel, Kunden und Aufträge aus JTL übernehmen, stellt sich eine Frage, die bisher niemand beantworten konnte: Ist wirklich alles angekommen? Der Abgleich holt laufend Änderungen — aber ob dabei etwas durchs Raster gefallen ist, hat schlicht nichts geprüft. Ab sofort zählt BIS ERP alle sechs Stunden beide Seiten gegeneinander: Aufträge, Rechnungen, Artikel, Kunden und Gebinde. Weicht eine Zahl ab, steht das im Protokoll und in der JTL-Übersicht. Das kostet nichts an Geschwindigkeit, denn die Prüfung überträgt keine Daten, sondern holt nur Zahlen — ob hinter Ihrem Mandanten fünfzig Artikel stehen oder vierhunderttausend Kunden, macht für sie keinen Unterschied. Gerechnet wird mit denselben Regeln, nach denen auch importiert wird: Was bewusst draußen bleibt, zählt nicht als fehlend, und was Sie in BIS ERP zusätzlich pflegen, gilt nicht als Fehler.

Wer keinen eigenen Webshop hat, sah unter Einstellungen → Webshop bisher eine rote Fehlermeldung. Dabei ist daran nichts kaputt — die weitaus meisten Betriebe führen keinen eigenen Shop. Statt der Fehlermeldung steht dort jetzt eine Erklärung.

Der Knopf beim Lieferschein sagt jetzt, was er tut: Solange es keinen gibt, heißt er „Lieferschein erstellen“ — danach „Lieferschein herunterladen“, mit der Belegnummer daneben. Bisher ließ sich jederzeit ein PDF ziehen, auch wenn die Erstellung unter Versandaktionen ausgeschaltet war; das Papier entstand erst im Moment des Klicks, trug die Sendungsnummer statt einer Lieferscheinnummer und stand in keiner Liste. Ab sofort entsteht ein echter Beleg mit fortlaufender Nummer, den verpackten Mengen und den Leergutkisten.

Ein Auftrag, der in JTL längere Zeit offen bleibt, wurde ab einem bestimmten Punkt nicht mehr übernommen — und danach nie wieder. Der laufende Abgleich sieht offene Aufträge nur, solange sie jung genug sind; wer länger auf eine Lieferung wartet, fiel heraus, und der einmalige Nachlauf für Altbestände war da längst abgehakt. Bei einem Kunden waren das 42 Aufträge aus November und Dezember 2025: in BIS ERP überhaupt nicht vorhanden, also auf keiner Pickliste, in keiner Auswertung, in keinem Umsatz. Alle späteren offenen Aufträge waren da — es traf genau den Rand des Fensters. Inzwischen sind alle 42 vollständig übernommen, in der Summe auf den Cent genau wie in JTL. Solche Nachzügler holt der Abgleich jetzt gezielt nach. Und die Rechnungen prüfen sich ab sofort genauso nach: Bisher sah niemand nach, ob wirklich alle aus JTL angekommen sind — auf Rechnungen stützt sich aber die Belegsperre, und aus ihnen rechnen EÜR, BWA und der DATEV-Export.

Nachtrag zu 0.0.0.707: Die Summen standen richtig, aber wer eine Zahl aufklappte, sah eine andere Welt — für August 2026 wies die Zelle 370,00 € aus, die Belegliste darunter listete acht Rechnungen über 625,00 €. Die Zelle rechnete nach Zahlung, die Belegliste suchte nach Rechnungsdatum. Jetzt folgt die Liste derselben Regel wie die Zelle, aus der Sie sie geöffnet haben.

Wird ein Auftrag in JTL-Wawi nachträglich auf einen anderen Kunden umgehängt, übernimmt BIS ERP diese Änderung ab sofort: Empfänger, Liefer- und Rechnungsanschrift sowie die Kundenzuordnung wandern mit. Das betrifft alle, die Aufträge zunächst über ein Sammelkonto erfassen — etwa im Außendienst — und sie später im Büro dem richtigen Kunden zuordnen. Bisher blieb die zuerst erfasste Anschrift stehen, und am Packtisch bekam das Paket den falschen Empfänger.

Neben den Warenkorb-Rabatten können Sie ab sofort auch Preisaktionen am Artikel in BIS ERP anlegen: Der Artikel erscheint im Shop mit dem gesenkten Preis, ohne dass der Kunde einen Code eingeben muss. Sie legen fest, für welche Artikel die Aktion gilt — eine ganze Kategorie, einzelne Artikel oder bestimmte Varianten — und um wie viel der Preis sinkt.

Vorbereitung dafür, dass ein Gutschein aus Ihrer Kasse auch im Webshop gilt. Dabei sind drei Fehler ans Licht gekommen, die Geld gekostet hätten, sobald zwei Verkaufswege denselben Gutschein annehmen — alle drei sind behoben. Neu ist außerdem eine Einlösungs-Historie: Sie sehen, welcher Beleg welchen Anteil verbraucht hat, und ein Storno bucht zurück.

Die Anlage EKS zeigte oben eine Gewinnzahl und darunter eine Tabelle, deren Monatsspalten sich zu einer anderen Summe addierten. Grund: Für die Anlage EKS zählt das Zuflussprinzip — maßgeblich ist, wann das Geld geflossen ist, nicht wann die Rechnung geschrieben wurde. Die Gesamtsummen folgten dieser Regel bereits, die Monatsspalten noch dem Rechnungsdatum. Jetzt gilt für die ganze Ansicht dieselbe Regel.

Rabatte für Ihren Webshop stellen Sie ab sofort in BIS ERP ein — unter Einstellungen → Webshop → Rabattaktionen. Eine Aktion besteht aus Bedingungen (ab welchem Bestellwert, bei welchem Artikel, für welche Kundengruppe) und Wirkungen (Prozent oder Festbetrag auf die Bestellung, je Artikel oder auf die Versandkosten). Wahlweise gilt sie für alle Kunden oder nur mit Gutscheincode.

Bei 84 aus JTL übernommenen Aufträgen passte die Summe der Einzelpositionen nicht zur Auftragssumme im Kopf. Der Gesamtbetrag war dabei immer richtig — falsch war nur die Aufschlüsselung, also das, was in der Auftragsmaske Zeile für Zeile steht. Betroffen war damit alles, was auf Positionen rechnet: Rohertrag, Deckungsbeitrag und die Kommissionierung. Alle 84 sind bereinigt.

Kein sichtbarer Unterschied in der Anwendung — festgehalten wurde ein Konzept. Geplant ist ein Bereich, in dem Sie Erweiterungen Ihres Webshops selbst ein- und ausschalten: Pfand, Grundpreis-Anzeige, Mindesthaltbarkeitsdatum, Chargen. Jede Erweiterung wird von uns geprüft und mitgepflegt — deshalb können wir zusichern, dass Ihr Shop nach einem Update weiterläuft. Gebaut wird es, sobald der Shop selbst rund läuft.

Die Zahlungsanbieter stehen wieder unter Buchhaltung — sie waren versehentlich in den neuen Webshop-Bereich gewandert. Ausserdem ist der Kanal „Euro Web Store“ verschwunden: eine Altlast der Sylius-Erstinstallation, abgeschaltet und ohne eine einzige Bestellung, die in der Aussehen-Maske trotzdem neben dem echten Shop stand. Ein neu eingerichteter Shop bekommt diesen Kanal nicht.

Die Einstellungen zum Webshop lagen verstreut — das Aussehen unter Schnittstellen, die Zahlungsanbieter unter Buchhaltung. Beides steht jetzt zusammen unter dem neuen Punkt „Webshop“. Die Aussehen-Maske erklärt sich ausserdem selbst: Ein Satz erläutert, was ein Verkaufskanal ist, und unter jedem Kanal steht seine Adresse — damit ist klar, welcher der Shop ist, den Kunden sehen.

Wer den eigenen Webshop verwaltet, brauchte bisher zwei Zugänge. Ab sofort öffnet ein Knopf unter Einstellungen → Schnittstellen → Aussehen (Webshop) die Shop-Verwaltung in einem neuen Tab — bereits angemeldet, mit dem BIS-ERP-Zugang. Ein eigenes Shop-Passwort entfällt. Auch nach dem Trennen der Verbindung bleibt der Zugang bestehen: Die Anmeldung am Shop funktioniert weiter mit denselben Daten.

Bisher hat niemand nachgesehen, ob ein einmal übernommener Beleg vollständig ist — wurde beim Import etwas nicht mitgeholt, blieb die Lücke für immer bestehen. Das war kein theoretisches Risiko: Von den aus JTL übernommenen Rechnungen eines Kunden trugen 490 von 6.421 überhaupt Einzelpositionen; bei den übrigen stand nur der Gesamtbetrag, zusammen über 2,6 Millionen Euro. In EÜR, BWA und DATEV-Export erscheinen solche Belege nur als Summe: nicht nachvollziehbar, nicht nach Steuersätzen aufteilbar. Ab sofort prüft der Abgleich das laufend mit und holt fehlende Zeilen nach — Rechnungen wie Aufträge. Beim genannten Kunden wurden 66.325 Rechnungszeilen und 28.870 Auftragszeilen ergänzt. Wer neu aus JTL übernimmt, bekommt die Belege von Anfang an vollständig. Ergänzt wird dabei nur, nie geändert oder gelöscht; selbst geschriebene Belege bleiben unangetastet.

Die drei Vorlagen des BIS Shop unterschieden sich bisher in Farben, Schriften und Rundungen — der Seitenaufbau war überall derselbe. Ab sofort ist jede Vorlage eine eigene Seite: Feinkost stellt das Foto gross in den Vordergrund und zeigt Beschreibung, Merkmale und Bewertungen offen untereinander; Technik legt sie auf Reiter und stellt die wichtigsten Merkmale direkt unter den Kaufknopf; BISpicy bleibt die klare Referenz. Auch die Startseiten und die Dichte der Produktraster unterscheiden sich.

Der Nachlauf, der beim Einrichten einer JTL-Verbindung die zurückliegenden Aufträge holt, lief seit dem 26.08.2026 wirkungslos: Er startete, brach nach knapp drei Sekunden ab und legte keinen einzigen Auftrag an. Unbemerkt blieb das, weil die Prüfung, ob überhaupt etwas fehlt, in Ordnung war — die Lücke wurde also korrekt erkannt und gemeldet, nur holen konnte der Nachlauf nichts. Behoben; bei einem betroffenen Mandanten wurden anschliessend 2.766 Aufträge nachgeholt.

Beim Kommissionieren im Browser wurde bei jedem Griff die bisherige Gesamtmenge erneut auf den Wagen gebucht statt nur des neu gegriffenen Stücks — bei fünf einzeln gegriffenen Stücken landeten fünfzehn auf dem Wagen. Ausserdem entstand für Griffe aus dem Browser keine Zeile im Bewegungsjournal. Beides ist behoben; das Handgerät war nicht betroffen.

Der Wagen, auf den beim Kommissionieren die Ware wandert, lässt sich jetzt auch im Browser erfassen — scannen oder eintippen, so wie am Handgerät. Wer keinen erfasst, bekommt eine feste Wagen-Nummer. Vorher stand dort der Name des Angemeldeten, mit Leerzeichen und Umlauten — und daraus wurde ein Lagerplatz-Code, den kein Scanner lesen kann.

Die Selbstprüfung des Abgleichs zählte bisher nur ganze Aufträge. Ein Auftrag kann aber vollständig angekommen sein und trotzdem falsche Positionen tragen — die Kopfsumme stimmt, weil sie aus der Warenwirtschaft kommt, nur die Aufschlüsselung nicht. Betroffen ist alles, was auf Positionen rechnet: Rohertrag, Deckungsbeitrag und vor allem die Kommissionierung.

Der Historien-Nachlauf holt Ihre zurückliegenden Aufträge einmalig; danach hält der laufende Abgleich den Bestand aktuell. Wurde eine Importregel nachgebessert, blieben zuvor übersprungene Aufträge dauerhaft weg — der Nachlauf stand auf „fertig“, und der laufende Abgleich sieht sie nie wieder. Jetzt zählt das System selbst nach.

Stand am Auftrag keine E-Mail-Adresse, unterblieb der Versand stillschweigend — die Einstellung stand auf „an“, der Beleg ging nie raus. Jetzt wird die Adresse aus dem Kundenstamm verwendet. Betroffen waren Rechnung, Lieferschein und Versandbestätigung.

Zwei Kleinigkeiten, die im Alltag nicht klein sind. Der Adresszusatz — „c/o“, „Hinterhaus“, „2. OG“, „Tor 4“ — stand längst am Auftrag und auf dem Lieferschein, war am Packtisch aber weder sichtbar noch änderbar, und auf dem DHL-Etikett fehlte er ganz. Und beim Land stand ein Kürzel: „TH“. Jetzt steht dort „Thailand“, in der Sprache, die gerade eingestellt ist.

Die letzte Kachel aus dem Entwurf für die Geschäftsführung: eine kurze Liste dessen, was heute nicht in Ordnung ist — verdichtet aus dem, was die übrigen Kacheln einzeln zeigen.

Der angebundene Webshop sah aus wie ein Baukasten von der Stange, und das Aussehen war der letzte Bereich, für den man trotz Anbindung noch ins Shop-Backend musste. Jetzt bringt der Shop drei Themes mit — BISpicy, Feinkost und Technik — und die Wahl gehört nach BIS ERP, je Verkaufskanal. Die drei unterscheiden sich nicht nur in der Farbe, sondern in Typografie, Abständen und Formensprache.

Neue Kachel „Ziele & Hochrechnung“: Tagesziel, Monatsziel und Zielmarge tragen Sie direkt in der Kachel ein. Danach zeigt sie die Zielerreichung, die Hochrechnung aufs Monatsende und den Betrag, der je verbleibendem Verkaufstag nötig wäre.

Drei weitere eigenständige Kacheln für Ihr Dashboard: Auftragskette, Versandzahlen und Lagerzustand.

Rohertrag & Marge, Forderungen nach Alter und Kundenkennzahlen — alle drei als eigenständige Kacheln, damit Sie sich Ihr Dashboard so zusammenstellen, wie Sie es brauchen.

Das bisherige Logo war gar kein Logo, sondern ein Bild davon: eine SVG-Hülle um eine Rastergrafik von 157 × 36 Punkten, mit dem dunklen Hintergrund fest eingebrannt. Auf hellen Flächen wirkte es wie ein aufgeklebter Kasten, auf hochauflösenden Bildschirmen franste es aus. In BIS ERP selbst gab es gar keines — Seitenleiste und Anmeldeseiten zeigten nur Text. Jetzt gibt es fünf echte Vektordateien, die in jeder Größe scharf sind.

Auf einem Dashboard konnten zwei Kacheln nebeneinander stehen, beide beschriftet „Umsatz heute“, und verschiedene Beträge zeigen. Beide waren für sich richtig — die eine rechnete brutto, die andere netto. Nur stand es nirgends. Die Auftragsübersicht rechnet jetzt wie das Dashboard, und ein Abgleich prüft laufend, ob die Zahlen zusammenpassen.

In der Kachel „Geschäftszahlen“ schalten Sie oben rechts zwischen Netto und Brutto um. Ab Werk steht sie auf Netto.

Die Kachel „Geschäftszahlen“ bekommt den Schalter „nur Händler“, und an den Zahlen steht jetzt, worauf sie sich beziehen.

Die Kacheln „Geschäftszahlen“ und „Lagerbestand in Zahlen“ lagen im Layout, wurden gespeichert und standen im Layout-Editor — auf dem Dashboard erschienen sie trotzdem nie. Von außen sah es aus, als hätte ein Wechsel der Vorlage keine Wirkung.

Die Kachel „Geschäftszahlen“ zeigte den Umsatz bisher fest nach Vor Ort, Online und eigenen Aufträgen. Jetzt wählen Sie oben rechts selbst, wonach aufgeteilt wird. Dazu kommt ein neuer Block „Lagerbestand in Zahlen“.

Wählen Sie im Layout-Editor eine Vorlage aus, ändert sich das Dashboard jetzt sofort. Bisher passierte sichtbar nichts — die Vorlage war übernommen und gespeichert, aber das Dashboard hinter dem Editor-Fenster zeigte weiter das alte Layout.

Der Abgleich mit der Warenwirtschaft schreibt Kundendaten jetzt nur noch, wenn sich tatsächlich etwas geändert hat. Das war so gedacht, funktionierte aber nicht: Ein Feld wurde beim Vergleich gar nicht mitgelesen — die Hausnummer. Dadurch galt praktisch jeder Kunde bei jedem Abgleich als geändert.

Seit das Shop-Backend bei bestehender Anbindung ausgeblendet ist, ließen sich Zahlarten an keiner Stelle mehr pflegen. Jetzt kommen sie aus BIS ERP: Schalter „Im Webshop anbieten“ an jeder Zahlart, getrennt vom Online-Checkout des Ladenscans. Dazu ein neuer Abschnitt „Zahlungsanbieter (Webshop)“, der zeigt, welche Anbieter der Shop kann und welche Zugangsdaten hinterlegt sind.

Braucht ein Kassenabgleich ungewöhnlich lange, wird das jetzt in jedem Fall protokolliert — auch dann, wenn dabei gar keine Verkäufe übertragen wurden. Für Sie ändert sich nichts Sichtbares; es hilft uns, Verzögerungen beim Kassenabgleich schneller einzugrenzen.

Die Vor-Tour-Liste zeigt jetzt auch Händler, bei denen kein Firmenname eingetragen ist — sofern sie einer Geschäftskundengruppe angehören. Bisher entschied allein der Firmenname darüber, wer auf die Tour kommt.

Unter Einstellungen, JTL-Integration gibt es jetzt den Abschnitt „Verkaufshistorie nachholen“. Er zeigt, wie viele Aufträge aus der Warenwirtschaft bereits in BIS ERP stehen — und daneben, wie viele dort überhaupt vorhanden sind. Erst dieser Vergleich beantwortet die Frage, ob noch etwas fehlt.

Aufträge, deren Positionen alle auf Menge 0 stehen, werden bewusst nicht übernommen — sie wären leere Hüllen in jeder Liste. Diese Prüfung war jedoch zu eng: Sie erkannte Ware nur, wenn sie mit einer Artikelnummer aus Ihrem Stamm verknüpft ist. Marktplätze und Shops liefern Positionen aber häufig als freien Text.

Die interne Datenprüfung meldete Rechnungen ohne zugehörigen Auftrag als möglichen Fehler. Zwei Fälle traf sie dabei zu Unrecht.

Ein abgebrochener Datenabruf durfte die Artikelnummern löschen: Blieb die Frage, welche Felder die JTL-Datenbank führt, einmal unbeantwortet, galt das als „Feld gibt es nicht“ — und der leere Barcode wanderte in alle Artikel und zurück nach JTL.

Kann eine Bestandsbuchung nicht an die Warenwirtschaft übergeben werden, bleibt sie als offener Vorgang liegen und wird nach einer Woche gemeldet. Häufig gleicht sich der Bestand aber zwischenzeitlich von selbst aus — dann gibt es nichts mehr nachzubuchen, die Meldung kam trotzdem täglich wieder.

Versandarten haben einen neuen Abschnitt „Webshop“: Im Shop anbieten (ab Werk aus), Steuersatz der Versandkosten und Zielgebiet mit Schnellwahl für Deutschland und die EU. Auch die Lieferzeit erreicht jetzt den Shop — sie war schon immer pflegbar und kam dort nie an.

Die Kachel „Geschäftszahlen“ stand bisher nur zur Auswahl — wer nichts tat, sah sie nie. Ab sofort erscheint sie automatisch auf Ihrem Dashboard.

Neu im Dashboard: die Kachel Geschäftszahlen — Umsatz getrennt nach Verkaufsweg (vor Ort, online, selbst erfasst) jeweils mit dem Vortag daneben, Gewinn für heute, gestern und den laufenden Monat, offene Rechnungen mit Überfälligkeit und die Pakete des Tages. Der Gewinn erscheint nur mit dem Recht „Einkaufspreise & Gewinn“; Umsatz, Forderungen und Pakete bleiben für alle sichtbar.

Als Kostenstelle liess sich alles waehlen — nur nicht der Wareneingang, ausgerechnet der groesste Ausgabenposten eines Handelsbetriebs. Er ist jetzt da, auch bei bestehenden Betrieben. Die Kostenstelle wird ausserdem endlich ausgewertet: in der BWA und im DATEV-Buchungsstapel. Und was an der Kasse als Lieferantenrechnung erfasst wird, kommt in der Warenwirtschaft an, statt auf dem Geraet liegen zu bleiben.

Mit der letzten Version übernimmt der Abgleich den Verkaufsweg, allerdings nur bei neuen Aufträgen. Für eine Auswertung „Umsatz gestern, Umsatz diesen Monat, getrennt nach vor Ort und online“ hilft das wenig — sie hätte erst ab dem Umstellungstag Zahlen. Der Verkaufsweg wird deshalb auch für vorhandene Aufträge nachgetragen.

Wer BIS ERP nutzt, pflegte den Shop bisher an zwei Stellen — und der Abgleich überschrieb alle zehn Minuten wortlos, was im Shop geändert wurde. Solange die Anbindung besteht, zeigt das Shop-Backend jetzt nur noch einen Verweis in die Warenwirtschaft. Wird die Anbindung entfernt, ist es sofort wieder da; fällt sie aus, öffnet es sich nach zwei Tagen von selbst.

Bisher trugen alle Aufträge aus der Warenwirtschaft denselben Vermerk — unabhängig davon, ob sie im Laden, im Onlineshop oder von Hand im Innendienst entstanden sind. Die Frage „wie viel Umsatz machen wir vor Ort, wie viel online?“ ließ sich damit nicht beantworten.

Meldet jemand beim Kommissionieren „nicht genug da“, bucht die Warenwirtschaft die Fehlmenge ab. Diese Buchung stand bisher als einzige ohne jede Angabe im Bewegungsjournal — ausgerechnet die, die Bestand vernichtet.

In der Rollenverwaltung lässt sich jetzt festlegen, welche Dashboard-Kacheln eine Rolle nicht sehen soll — unabhängig davon, welche Rechte sie hat.

Wer ein Recht nicht hat, sieht den zugehörigen Bereich jetzt auch nicht mehr — die Oberfläche richtet sich nach den vergebenen Rechten, statt Knöpfe zu zeigen, die beim Klick abgewiesen werden.

Für Lager, Vertrieb, Buchhaltung und Geschäftsführung liegen fertige Dashboard-Vorlagen bereit — ein Klick, und die passenden Kacheln stehen an ihrem Platz.

Ihr Dashboard-Layout hängt jetzt an Ihrem Konto statt am Browser: Sie finden es am Rechner, am Tablet und im Lager unverändert wieder.

Der BIS Shop konnte verkaufen, ohne dass die Warenwirtschaft davon erfuhr — kein Auftrag, kein Bestandsabzug, keine Rechnung. Eine abgeschlossene Bestellung wird jetzt binnen zehn Minuten zum Auftrag mit Kunde, Positionen und Anschriften und läuft durch Pickliste, Packtisch und Rechnung. Bestehende Bestellungen bleiben unangetastet: Beim ersten Abgleich wird nur festgehalten, was schon da war.

Wurde eine Position am Packtisch als Fehlbestand ausgebucht, stand sie auf „0 von 18“ und galt als erledigt — ein späterer Scan der doch gefundenen Ware wurde mit „bereits vollständig“ abgewiesen. Eine Fehlmenge ist aber eine Vermutung, kein Urteil: Der Scan wird jetzt angenommen und die Fehlmenge sinkt um genau das Gefundene. Sichtbar ist es auch: amber mit Warnzeichen statt grünem Häkchen.

Bisher konnte jeder angemeldete Mitarbeiter den Lagerwert zu Einkaufspreisen abrufen — die Kachel war für alle sichtbar. Wer den Einkauf kennt, kennt die Marge. Dafür gibt es jetzt ein eigenes Recht: „Einkaufspreise & Gewinn“, zu finden in der Rechteverwaltung bei jeder Rolle.

Ob ein Auftrag unvollständig rausgehen darf, war bisher ein Haken pro Auftrag — bei über 16.000 Aufträgen trugen ihn fünf. Jetzt lässt sich das einmal unter Pick & Pack festlegen; einzelne Aufträge können weiterhin abweichen, in beide Richtungen. Fehlt beim Packen etwas, fragt der Packtisch nach und zeigt genau, was fehlt, statt die Sendung stillschweigend rauszuschicken. Und eine Fehlmenge veraltet nicht mehr: Kommt die Ware zurück, öffnet sich die Position von selbst wieder.

Ein Teil der Aufträge kam nie in BIS ERP an, und derselbe Kunde zeigte je nach Ansicht zwei verschiedene Umsätze. Beides ist behoben.

Ein Artikel, von dem der Packtisch keinen Bestand kannte, wurde nicht mehr zum Sammeln angeboten — er stand grün mit „0 von 8“ da, als wäre er abgehakt, und ein Vermerk entstand nirgends. Bei einem Auftrag mit 45 Positionen blieben so acht Flaschen liegen, obwohl 80 Stück im Regal standen: Der Bestand war nur noch nicht in den Lagerzeilen angekommen. Jetzt zählt ohne Lagerzeile der Artikelstamm, und fehlender Bestand ist kein „erledigt“ mehr.

Rabatte, Gutscheine und Pfand stehen im Auftrag, ohne dass es dazu einen Artikel im Lager gäbe. Bisher galten sie als „unbekannter Artikel“ und setzten den ganzen Auftrag auf „teilweise lieferbar“, obwohl jedes Stück Ware im Regal lag. Umgekehrt konnte eine Position ohne Artikelbezug am Packtisch komplett unsichtbar sein — auf einem Auftrag lagen so 11.520 Stück im Wert von rund 9.900 €, von denen der Packer nie erfuhr. Beides ist behoben.

Der Abgleich mit der Warenwirtschaft brauchte zuletzt bis zu 277 Sekunden je Durchlauf, bei einem Fünf-Minuten-Takt. Jeder Lauf war beim Start also praktisch schon überfällig. Die Ursache lag im Rechnungsabgleich: Er suchte jede Rechnung einzeln und schrieb sie anschließend immer neu.

Bei einem Kunden mit sauber hinterlegter Straße, Postleitzahl und Ort stand in der Kundenakte „Keine Adresse hinterlegt“. Die Anschrift wird an zwei Stellen geführt, und gelesen wurde nur eine davon. Dazu mehrere Verbesserungen an der Vor-Tour-Liste.

Warengruppen und Marken lassen sich jetzt richtig pflegen: Bild hochladen statt Adresse abtippen, Beschreibung und Angaben für die Trefferliste — und alles davon kommt im Shop an. Marken bekommen eine eigene Seite mit Logo. Behoben: Warengruppen wurden im Shop angelegt, tauchten in der Navigation aber nicht auf, und Umlaute wurden in Adressen verstümmelt.

Wer in der Kundenakte nach älteren Rechnungen suchte, fand nichts — die Akte stand leer, obwohl in der Warenwirtschaft Rechnungen über Monate vorliegen. Zwei Ursachen lagen dahinter, beide sind behoben.

Nachtrag zu 0.0.0.633. Rief man einen zusammengeführten Kunden über einen alten Link auf, fehlte der Hinweis „Dieser Kunde wurde zusammengeführt — die Belege liegen jetzt bei …“. Man sah eine Akte ohne Aufträge und ohne Erklärung. Der Hinweis wurde zwar ermittelt, aber auf dem Weg zur Anzeige wieder verworfen; jetzt kommt er an.

Im CRM gibt es einen neuen Bereich „Dubletten“: Kunden, die derselbe sein könnten, stehen nebeneinander — mit Anschrift, Anzahl der Aufträge, Umsatz und letzter Bestellung. Sie wählen den Hauptkunden und führen zusammen; Aufträge, Rechnungen, Adressen, Kundenpreise und Belege wandern mit. Nichts geschieht automatisch, und das hat einen konkreten Grund: In einem geprüften Kundenstamm heißen acht verschiedene Betriebe „City Kiosk“ — in Köln, Mannheim, Bielefeld, Spenge und weiteren Städten. Wer nach Firmennamen zusammenführt, wirft acht Kunden in einen Topf. Deshalb schlägt das System nur vor, wenn ein Merkmal wirklich einen Betrieb bezeichnet: dieselbe E-Mail, dieselbe Telefonnummer oder dieselbe Firma an derselben Anschrift. Abgelehnte Vorschläge kommen nicht wieder. Der zusammengeführte Kunde bleibt erhalten, verschwindet aus allen Listen und zeigt über alte Links, in wem er aufgegangen ist.

Wurde ein Auftrag nur teilweise gepackt, konnte er wenige Minuten später als komplett ausgeliefert dastehen — samt aller Positionen, die nie im Karton lagen; die Restmenge verschwand aus der Packwarteschlange und wurde nie nachgeliefert. Ursache war der Abgleich mit JTL, der den dortigen Lieferstatus zu großzügig las. Vier betroffene Aufträge wurden geprüft und zurückgesetzt. Ausserdem kann ein Scan nicht mehr über die Bestellmenge hinaus buchen: Zu viel gepackte Ware wäre mitgegangen, ohne irgendwo als geliefert zu stehen. Ein Storno an der Kasse bucht die Ware bei neuen Anbindungen ab Werk auch in JTL zurück. Beim Wareneingang bleiben MHD und Charge am Beleg, nicht nur in der Bestandsbuchung — für Rückruf und Lieferantenreklamation ist der Beleg die Grundlage. Und neu einstellbar: abgelaufene Ware zuerst herausgeben, wenn sie noch abverkauft statt abgeschrieben wird.

Sobald zu einem Auftrag eine Rechnung, ein Lieferschein oder eine Sendung existiert, ist der Vorgang belegt: Positionen, Mengen, Preise, Summen, Empfänger und Adressen lassen sich dann nicht mehr ändern. Bis jetzt war genau das möglich — der Auftrag ließ sich umbauen, während die Rechnung unverändert daneben lag, und beim nächsten Blick stimmten beide nicht mehr überein. Notizen, Priorität und der Statusfortschritt bleiben möglich; ein Vermerk zum Vorgang ändert nichts an der ausgelieferten Ware. In der Auftragsmaske steht der Grund im Klartext, mit der Nummer des Belegs. Auch der JTL-Abgleich hält sich daran: Bislang stoppte er nur bei einer Rechnung, jetzt zählen Lieferschein und Sendung genauso.

„Vor der Tour“ zeigt nur noch Händler. Im Gebiet standen bisher alle Kunden mit passender Postleitzahl — bei einem Gebiet mit 36 Kunden waren davon 25 Privatkunden, für eine Tourplanung im Großhandel reines Rauschen. Gezählt und gelistet werden jetzt ausschließlich Kunden mit hinterlegter Firma; Füllstand, Umsatz und Tonnage der Tour ziehen mit. Ausserdem haben Vertriebsgebiete einen eigenen Punkt im CRM: Bisher waren sie nur über einen Knopf in der Kundenliste erreichbar — für die Grundlage der ganzen Tourplanung zu tief versteckt. Der Weg über die Kundenliste bleibt bestehen.

„Offene Rechnungen“ stand bei vielen Kunden auf 0,00 €, obwohl es welche gab. Zwei Gründe: Die Kundenverknüpfung einer Rechnung steht je nach Herkunft in einem von zwei Feldern, gesucht wurde nur in einem — wer seine Rechnungen aus der Warenwirtschaft bekommt, sah deshalb immer null. Und teilbezahlte Rechnungen zählten nicht mit, obwohl eine Rechnung mit Anzahlung offen ist. Ausserdem sagt die Marge jetzt, worauf sie sich bezieht: Neben dem Gewinn steht der Nettoumsatz, aus dem der Prozentwert gerechnet wird (etwa „9,1 % Marge von 5.505,12 € netto“) — bisher stand daneben nur der Bruttoumsatz, und wer nachrechnete kam auf einen anderen Wert. In „Vor der Tour“ führt aus dem Hinweis „Noch kein Vertriebsgebiet mit Tourtag angelegt“ jetzt ein Knopf direkt in die Gebietsverwaltung.

Wird ein Auftrag in JTL nachträglich umgebaut — eine Position gestrichen, eine Menge korrigiert, ein anderer Artikel eingesetzt —, hat BIS ERP das bisher nie mitbekommen: Die Positionen wurden genau einmal geholt, beim ersten Import. Ab jetzt gleicht BIS die Aufträge laufend ab. Solange JTL die Rechnungen schrieb, war das folgenlos; sobald BIS ERP selbst fakturiert, stünde sonst ein anderer Warenkorb auf der Rechnung als der ausgelieferte. Bei einem Kunden führten 22 von 145 geprüften Aufträgen in beiden Systemen unterschiedliche Positionen — in einem Fall Ware für 251,83 € gegen 118,62 €. Aufträge, an denen bereits gearbeitet wird, bleiben ausdrücklich unangetastet: Ab der Kommissionierung liegt die Ware womöglich schon im Karton. Solche Fälle landen unter „Aufträge → Abgleich prüfen“, wo je Auftrag steht, was auseinanderläuft — Sie entscheiden mit einem Klick.

Wer ein Ticket gemeldet hat und von uns eine Rückmeldung bekommt, konnte bisher nur eine Nachricht tippen. Im Kundencenter stehen jetzt zwei Knöpfe, sobald wir auf Rückmeldung warten: „Problem ist behoben“ schließt das Ticket ab — vorher fragen wir noch einmal nach und sagen ausdrücklich dazu, dass danach keine Antwort mehr möglich ist. „Problem besteht weiter“ meldet, dass die Änderung nicht wirkt, mit kurzer Angabe wozu; das Ticket bleibt offen. Beides erscheint im Verlauf, damit nachvollziehbar bleibt, wer was bestätigt hat. Der wichtigere Teil steckt dahinter: Antworten aus dem Kundencenter haben bisher gar keine Benachrichtigung ausgelöst — nur ein neu angelegtes Ticket tat das. Ab sofort geht bei jeder Antwort und jeder Rückmeldung eine Nachricht an unser Team.

Das Postfach bispicyservice@gmail.com ist jetzt direkt zugänglich — suchen, lesen, antworten, als gelesen markieren — statt über den Umweg des Ticketsystems. Der Umweg wurde beendet, weil er sich als untauglich erwiesen hat: In vier Monaten kam über dieses Postfach keine einzige Kundenanfrage herein, nur Zustellfehler eigener Testläufe. Von 36 erzeugten Tickets waren 33 solcher Bounces. Der automatische Ticket-Import ist deshalb abgeschaltet und alle Tickets sind geschlossen. Neu sind Endpunkte, die das Postfach direkt bedienen, inklusive Antworten im richtigen Verlauf und Ablegen von Entwürfen.

Wer die BIS AI Bridge gekauft hatte und im Kundencenter auf „Herunterladen“ klickte, bekam eine Fehlerseite. Der Link zeigte auf bispicy.com/downloads/… — dort liegt der Installer aber nicht: Die Installationsdateien werden über unser Content-Netzwerk ausgeliefert, auf dem Webserver stehen nur die Signatur und die Update-Datei daneben. Der Link zeigt jetzt auf die Adresse, unter der die Datei tatsächlich liegt — dieselbe, die auch die Download-Seite verwendet. Der Prüfschritt aus 0.0.0.623 achtet jetzt zusätzlich darauf, dass Installationsdateien nie auf den Webserver verlinkt werden, während Signaturen und Update-Dateien dort erlaubt bleiben.

Wer seinen Shop an BIS ERP angeschlossen hat, musste zwei Pflichtangaben bisher doppelt pflegen: den Grundpreis („je Liter“, „je Kilogramm“) und das Pfand. Beides steht längst am Artikel — im Shop stand es trotzdem nicht. Ab sofort wandert beides mit: Sie tragen Inhalt und Einheit am Artikel ein, setzen den Haken „Grundpreis ausweisen“, und der Shop rechnet. Das Pfand erscheint als eigene Zeile statt im Artikelpreis versteckt — einschließlich Kistenpfand: 20 Flaschen à 0,15 € plus 1,50 € für die Kiste ergeben 4,50 €, getrennt geführt. Auch das Ausland stimmt: Österreich führt das Einwegpfand seit 2025 außerhalb der Bemessungsgrundlage, dort erscheint es mit 0 %. Das Pfandland steht am Artikel, Sie können also deutsche und österreichische Ware im selben Shop führen. Kategorien legt der Shop bei Bedarf selbst an. Außerdem behoben: Stücklisten ließen sich bei neu angelegten Mandanten nicht befüllen — die leere Stückliste sah dabei aus wie eine fertige.

Beim Umzug auf die eigenen Adressen (erp.bispicy.com für die Anwendung, my.bispicy.com für das Kundencenter) sind einige Links in E-Mails auf der alten Adresse stehengeblieben, wo inzwischen die Website liegt — die Empfänger landeten auf einer Fehlerseite. Am schwersten wog der Bestätigungslink der Gelangensbestätigung: Kunden konnten den Erhalt einer Lieferung gar nicht bestätigen, und das ist der steuerliche Nachweis für eine steuerfreie Lieferung ins EU-Ausland. Ebenfalls betroffen: der Knopf „Ticket ansehen“ in der Support-Benachrichtigung, der Registrierungs-Hinweis im Shopify-Onboarding und der Verweis auf die Einrichtungsanleitung der BIS AI Bridge. Weitere Links funktionierten zwar, liefen aber über zwei Weiterleitungen — digitaler Kassenbon, Gutschein-Link, Kundencenter und Fehler-Tracker zeigen jetzt direkt auf ihr Ziel. Ein neuer Prüfschritt schlägt künftig Alarm, wenn ein Link auf die alte Adresse fest im Code steht.

Die Ticketliste kannte keinen Filter nach Herkunft — dabei stammen 657 von 778 Tickets aus einem einzigen Kanal. Wer sehen wollte, was über ein bestimmtes Postfach hereinkam, musste scrollen. Ein entsprechender Filter war halb angelegt: Er löste beim Umstellen brav ein Neuladen aus, wurde aber nie an den Server geschickt und hatte nicht einmal ein Bedienelement. Jetzt steht er neben Status, Priorität und Kategorie und wirkt auch. Ausserdem sortiert die Liste erledigte Tickets nach unten: In der Ansicht „Alle anzeigen“ standen sechs abgeschlossene Vorgänge aus März und April über einem Ticket von heute, weil nur nach Priorität und Änderungsdatum sortiert wurde — der Status spielte keine Rolle.

Der Knopf „Bestand neu berechnen“ auf der Kommissionierungs-Seite rechnet Bestand und Reservierung aus den Bestandszeilen zurück — und übersah dabei die Ware, die auf einer Kommissionierliste steht. Eine angelegte Liste merkt sich die zugesagte Menge am Artikel, nicht an der Lagerplatz-Zeile; zwischen Anlegen und Versand war die Reservierung damit ungeschützt. Ein Klick gab diese Ware wieder zum Verkauf frei, obwohl sie fest eingeplant war — über alle Kanäle und ohne Hinweis. Jetzt bleibt reserviert, was einer noch nicht versandten Liste zugeteilt ist. Dieselbe Absicherung greift auch beim Löschen einer einzelnen Bestandszeile, wo sie bisher ganz fehlte.

Der Gewinn (DB1) in der Kundenakte war bei Aufträgen aus JTL zu niedrig — teils um ein Vielfaches. Grund: Die Positionsbeträge sind je nach Herkunft unterschiedlich abgelegt; Kassenverkäufe führen sie brutto, JTL-Aufträge netto. Die Berechnung zog pauschal die Umsatzsteuer ab und traf JTL-Positionen damit doppelt. Bei einem Kunden standen so 52,20 € Deckungsbeitrag, tatsächlich waren es 420,28 €, die Marge 2,6 % statt 17,6 %. Ausserdem zählte bisher nur der fest hinterlegte Einkaufspreis — Artikel mit Durchschnitts- oder letztem Einkaufspreis galten als „ohne Kosten“ und fielen samt ihrem Umsatz aus der Rechnung. Und die Kennzahlen sagen jetzt, worauf sie sich beziehen: Auf einem Bildschirm standen drei Umsatzgrößen nebeneinander (netto, brutto, Marge-Basis), wer nachrechnete kam auf drei verschiedene Prozentwerte.

Drei Dinge in der Kundenliste, die auseinanderliefen. Der Zurück-Pfeil bringt Sie dorthin zurück, wo Sie waren: Die Kundenliste gibt es an zwei Stellen — im CRM und als eigener Bereich; wer im CRM einen Kunden öffnete, verlor beim Klick die CRM-Reiter, und der Pfeil führte danach auf die andere Liste ohne die gesetzten Filter. Geschäfts- und Privatkunden werden jetzt vollständig gefiltert: Bisher wirkte diese Auswahl nur auf den geladenen 50 Zeilen, was bei 4.667 Kunden ein unvollständiges Ergebnis zeigte, das wie ein vollständiges aussah. Und die drei Kennzahlen oben ziehen mit — „Gesamt · Aktiv · Inaktiv“ zeigten immer den kompletten Kundenstamm, egal welcher Filter gesetzt war.

Nachtrag zu 0.0.0.617. Beim Nachmessen mit einer echten Testmail zeigte sich ein zweiter Riegel hinter dem ersten: Der Abruf fand die E-Mails einwandfrei, aber das Anlegen des Tickets scheiterte still an der Datenbank. Die Spalte `source` der Nachrichten-Tabelle kannte den Wert „gmail“ nicht — bei der Ticket-Tabelle war er ergänzt worden, bei der Nachrichten-Tabelle nicht, obwohl beide beim selben Vorgang beschrieben werden. Nach aussen sah das aus wie ein leeres Postfach: „0 E-Mails abgerufen“. Die betroffenen Mails blieben ungelesen liegen und wurden alle fünf Minuten erneut vergeblich versucht. Wer ein solches Wertefeld erweitert, muss alle Tabellen erweitern, in die derselbe Wert geschrieben wird.

Das Gmail-Support-Postfach war seit Mai nur in eine Richtung angeschlossen: Antworten gingen hinaus, eingehende E-Mails kamen nie an. Der Abruf lief alle fünf Minuten und tat dabei nichts — ohne Fehlermeldung, ohne Protokolleintrag; der Schalter in den Einstellungen sprang bei jedem Neuladen auf „aus“ zurück, weil in der Datenbank die zugehörigen Felder fehlten und die Abfrage still auf „ist halt aus“ zurückfiel. Die Felder legt das System jetzt beim ersten Zugriff selbst an, und beide Stellen, die den Fehler verschluckt haben, hinterlassen eine Spur. Neu ist ein Startdatum, ab dem E-Mails zu Tickets werden: Ältere Post bleibt unangetastet im Postfach liegen — ohne diese Grenze hätte der erste scharfe Lauf den gesamten ungelesenen Posteingang eingesaugt und für jede Mail ein Ticket samt Benachrichtigung erzeugt. Eine Vorschau zeigt vorher, wie viele E-Mails tatsächlich zu Tickets würden, ohne etwas zu importieren.

Nachtrag zu 0.0.0.614/.615. Wer in der Kundenliste mehrere Filter durchprobierte und dann die Zurück-Taste drückte, landete nicht beim vorherigen Filter, sondern aus der Liste heraus — jeder Wechsel überschrieb denselben Eintrag im Browserverlauf. Jetzt bekommt jeder Filterwechsel einen eigenen Eintrag: Zurück führt einen Schritt zurück, nicht weg. Suchtext und Seitenzahl bleiben bewusst außen vor, damit nicht jeder Tastenanschlag einen Verlaufseintrag erzeugt.

Nachtrag zur Übersicht aus 0.0.0.614. Beim Nachmessen fiel auf: Die Kundenliste zeigt aktive und inaktive Kunden, solange man den Aktiv-Filter nicht ausdrücklich setzt — die Kacheln der Übersicht zählen dagegen nur aktive. Bei Mandanten mit inaktiven Kunden hätte „316 B-Kunden“ also auf eine Liste mit einer anderen Zahl geführt. Die Kacheln geben den Filter jetzt mit, und der Aktiv-Umschalter steht wie die übrigen Filter in der Adresszeile. Ausserdem leuchtet die Kachel „Ohne Betreuer“ nur noch, wenn es etwas zu melden gibt: Wer Betreuer gar nicht pflegt, hätte sonst dauerhaft eine Warnung gesehen, die keine ist.

Das CRM begann bisher mitten in der Arbeit: Wer es öffnete, landete in der Kundenliste. Wie viele Kunden aktiv sind, wer nie bestellt hat, wie sich die Kundschaft auf die ABC-Klassen verteilt — das stand nirgends zusammen. Der neue erste Reiter „Übersicht“ zeigt es auf einen Blick, und jede Zahl dort ist ein Link: Ein Klick auf „316 B-Kunden“ öffnet die Kundenliste, gefiltert auf genau diese 316. Eine Kennzahl, die man nicht aufklappen kann, beantwortet die zweite Frage nicht — nämlich welche das sind. Die Filter stehen jetzt außerdem in der Adresszeile, damit sich eine gefilterte Liste als Lesezeichen ablegen und weitergeben lässt und die Zurück-Taste den vorherigen Filter wiederherstellt. Neu sind auch die beiden Filter „nie bestellt“ und „seit N Tagen nicht bestellt“ — bewusst getrennt, weil ein Kunde, der noch nie gekauft hat, ein anderes Gespräch braucht als einer, der weggeblieben ist. Verschoben wurde nichts: Die Artikel-ABC bleibt im Einkauf, weil sie eine Frage der Beschaffung ist und keine des Vertriebs; die Übersicht verlinkt dorthin, statt eine zweite Fassung derselben Auswertung anzulegen.

Sammeln und Verpacken laufen über zwei Türen — das Handgerät im Lager und den Browser am Schreibtisch. In vier Punkten taten sie nicht dasselbe. Der Kommissionierwagen trägt jetzt Ihren Klarnamen statt der Anmelde-Adresse, die bisher sogar als Lagerplatz-Name im System landete. Der Lagerplatz steht wieder in der Kommissionierliste: Wer im Browser sammelte, las „Lagerplatz –“ und „Gehen Sie zu Lagerplatz“ ohne Ziel, während der Packtisch für denselben Artikel das Fach nannte. Gesammelte Ware auf dem Wagen überlebt jetzt den nächtlichen JTL-Abgleich — bisher konnte er die Zwischenstation wegräumen, und die Ware galt wieder als verkäuflich, obwohl sie im Wagen lag. Und ohne Lagerplatzführung wird beim Sammeln nichts mehr ausgebucht: Der Abgang geschieht beim Versand, so wie am Handgerät, damit beide Wege denselben verfügbaren Bestand zeigen.

Eine Sendung kommt zurück — falsche Hausnummer, Empfänger unbekannt, nicht abgeholt. Bisher blieb nur der Umweg über einen kopierten Auftrag, bei dem die Ware ein zweites Mal aus dem Bestand gebucht wurde, obwohl sie das Lager nie wieder gesehen hat. Jetzt gibt es einen eigenen Weg, erreichbar aus der Sendungsliste und aus dem Auftrag: Grund aus einer festen Liste wählen, bei Bedarf die Anschrift korrigieren, neues Label. Der Bestand wird nicht angefasst, es entsteht kein zweiter Auftrag und keine zweite Rechnung. Die zurückgekommene Sendung bleibt dokumentiert, die neue verweist auf sie. Nicht zu verwechseln mit dem Ersatzversand: Dort geht neue Ware raus, und die wird richtigerweise ausgebucht.

BIS ERP erledigt vieles im Hintergrund — Wareneinsatz, Reservierungen, Rechnungen, Auftragsbestätigungen — in einem gemeinsamen Durchgang alle zwei Minuten. Antwortete ein Mailserver nicht, wartete BIS ERP bisher eine volle Minute auf Antwort, und zwar bei jedem Versuch; der ganze Durchgang stand so lange still. Am 23.08.2026 waren das auf dem Produktivsystem 24 Wartezeiten in einer halben Stunde, der Hintergrunddurchgang lief 19 Minuten lang gar nicht — betroffen waren damit auch Bestandsbuchungen und Rechnungen. Ab sofort bricht ein Verbindungsversuch nach 15 Sekunden ab. An der Zustellung ändert sich nichts: Ein erreichbarer Mailserver antwortet in Bruchteilen einer Sekunde.

Die ausgewiesene Umsatzsteuer wird jetzt je Steuersatz auf die Summe der Netto-Beträge berechnet statt als Summe der einzelnen Positionssteuern. Ein Beleg mit 16 Positionen zu 19 % und 195,09 € netto weist damit 37,07 € aus — einzeln gerechnet und addiert waren es 37,05 €, zwei Cent zu wenig. § 14 Abs. 4 Nr. 8 UStG verlangt den auf das Entgelt entfallenden Steuerbetrag; so rechnen auch JTL und DATEV. Mehrere Steuersätze auf einem Beleg werden getrennt gerechnet. Wer die optionale Spalte „Steuerbetrag“ je Position eingeblendet hat: Diese Zeilenwerte addieren sich nicht mehr centgenau zum Summenblock — das entspricht dem üblichen Belegaufbau.

Wer die Positionen einer Rechnung zusammenzählte, kam gelegentlich auf einen anderen Betrag als im Summenblock stand — meist einen Cent daneben, bei der Umsatzsteuer etwas häufiger. Der Grund lag in der Reihenfolge: Die Zeilenbeträge wurden in voller Genauigkeit addiert und erst die Summe auf Cent gerundet, während auf dem Beleg je Position ein gerundeter Betrag steht. Jetzt wird zuerst jede Position gerundet und dann summiert, genau wie auf dem Papier. Nach § 14 UStG muss das Entgelt aufgeschlüsselt sein — eine Aufschlüsselung, die sich nicht zur Endsumme addiert, erfüllt das nicht. Bereits erstellte Rechnungen bleiben unverändert (GoBD).

Zwei Fehler, die den Rechnungsbetrag verfälscht haben — beide beim Probelauf der Rechnungsumstellung aufgefallen. Belegrabatte, Zahlungsartaufschläge und Freitextpositionen aus JTL kamen nicht als eigene Zeilen in BIS ERP an; die Auftragssumme stimmte, die Aufschlüsselung nicht. Sobald BIS ERP selbst fakturiert, rechnet es aus den Positionen — ein gemessener Auftrag über 369,59 € wäre mit 385,38 € berechnet worden, der Kunde hätte seine 15,78 € Rabatt nicht bekommen. Solche Zeilen kommen jetzt mit und gelten als nicht lieferbar: Sie machen einen vollständig versandten Auftrag nicht mehr zur Teillieferung und werden immer voll berechnet. Zweitens wurde eine zu 100 Prozent rabattierte Versandpauschale mit ihrem Listenpreis berechnet statt mit den tatsächlichen 0,00 € — jetzt zählt der berechnete Betrag. Im Probelauf steht bei Abweichungen unter 5 Cent „Rundung“ statt „Abweichung“.

Drei Bausteine schließen das Vertriebs-CRM ab. Gebiete lassen sich jetzt aus den Postleitzahlen Ihrer Kunden vorschlagen — mit Kundenzahl, Jahresumsatz und Namensvorschlag aus dem häufigsten Ort; angelegt wird nichts von allein, und ein zu großer Bereich wird feiner aufgeteilt. Die Liefer- und Kommissionierzulage folgt einer frei einstellbaren Staffel nach Auftragswert und erscheint als eigene Position auf Auftrag, Rechnung und Lieferschein — nicht versteckt in den Versandkosten; wächst der Auftrag über die Grenze, verschwindet sie wieder. Und in der Kundenakte stehen die Sortimentslücken: welche Warengruppen vergleichbare Kunden kaufen und dieser nicht, wahlweise verglichen mit ähnlichen Kunden oder mit den anderen Läden derselben Tour.

Nacharbeit am gedruckten Beleg: Beschriftungen ohne Wert („Lieferdatum“, „Bearbeiter“, „IBAN:“) verschwinden, der Steuerbetrag im Summenblock stimmt, und wo Positionen nicht zur Kopfsumme passen, gelten die Auftragssummen — statt einer Aufstellung, die sich selbst widerspricht.

Wer BIS ERP über die Schnittstelle mit einem anderen System verbindet, bekam bisher ein unvollständiges Bild. `GET /v1/orders` lieferte ausschließlich Kassenbons — wer Aufträge schreibt, sah davon nichts; jetzt kommen beide Quellen, jede mit Herkunftsangabe. Die JTL-Kundennummer, über die ein anderes System denselben Kunden wiedererkennt, wird mitgeliefert, dazu ABC-Klasse, Potenzial, Betreuer, Gebiet und beim einzelnen Kunden Umsatz und letzter Auftrag. Und neue Aufträge melden sich von selbst: Bisher meldeten Webhooks nur, was über die Schnittstelle selbst geändert wurde — ein Auftrag aus JTL oder vom Marktplatz blieb stumm. Nebenbei behoben: Beim Deckungsbeitrag zählten retournierte Aufträge als Umsatz, und ein Webhook-Abonnement auf ein Ereignis mit Tippfehler wurde gespeichert, statt abgelehnt zu werden.

Bisher musste ein freigeschalteter Kunde für jeden Artikel die Kamera-App neu öffnen — nach drei Artikeln hört damit jeder auf. Auf der Startseite steht jetzt „Artikel scannen“: Die Kamera bleibt offen, der Artikel mit dem eigenen Preis erscheint darunter, und eine Liste zeigt, was schon gescannt wurde.

Die Auftragsbestaetigung war kein gestalteter Beleg, sondern ein interner Ausdruck — und ging trotzdem per E-Mail an den Kunden, samt internem Bearbeitungsstand („In Bearbeitung“, „Kommissionierung“) und „N/A“ bei fehlenden Angaben. Jetzt rendert sie im selben Layout wie Rechnung und Lieferschein, mit Lieferanschrift, Zahlungsbedingungen und nach Steuersatz getrennten Betraegen.

Ein heruntergeladener Beleg hiess je nach Stelle unterschiedlich und oft nichtssagend — `lieferschein-4f3a91c2-….pdf`, `packstueck-3.pdf`, `label-<interne Nummer>.pdf`. Ab sofort gilt ueberall Art_Datum_Belegnummer, und der Server gibt den Namen vor.

Damit der QR-Code am Preisschild ohne Anmeldung funktioniert, ist auf der Adresse der Produktinfo-Seite ein Teil der Zugangsprüfung bewusst gelockert. Diese Lockerung war weiter gefasst als nötig — sie beruhte auf einem Adressmuster, und ein Muster kann bestimmte interne Adressen nicht sicher von denen der Produktinfo-Seite unterscheiden. Jetzt gilt dort eine feste Liste: Was nicht zur Produktinfo-Seite gehört, existiert auf dieser Adresse nicht.

Wer sich an der Kasse für seine Preise freischalten lässt, konnte bisher nur Preisschilder scannen — jede Seite war eine Sackgasse. Jetzt führt der QR-Code auf eine Startseite mit Ihren Aktionen, einer Nachfrage nach den Kontaktdaten (höchstens alle 30 Tage) und einem Feld für Rückmeldungen. Gemeldete Kontaktdaten ändern nichts von selbst: Sie kommen als Vorschlag an und werden erst durch Ihren Klick übernommen.

Wer seine Belegvorlage im Design Studio angepasst hatte, bekam kuenftige Layout-Verbesserungen nicht mehr — der einzige Weg dorthin war das Zuruecksetzen auf Werkseinstellungen, bei dem alle eigenen Anpassungen verloren gingen. Jetzt meldet das Design Studio eine neue Werksfassung und uebernimmt sie auf Wunsch, ohne die eigenen Einstellungen anzuruehren.

An jeder Versandart lässt sich hinterlegen, womit gepackt wird: Spedition → Palette, DHL → Karton, Hausspedition → Colli — optional auch das konkrete Packmittel wie „Europalette 120 × 80“. Am Packtisch steht es dann fertig da, mit Maßen und Leergewicht, und darunter steht, woher die Vorauswahl kommt. Der Packer wählt nur noch, wenn er abweicht; seine eigene Wahl bleibt auch dann erhalten, wenn danach die Versandart gewechselt wird. Ohne Eintrag ändert sich nichts — es wird nichts aus dem Versandweg erraten.

Eine Rechnung mit einer einzigen Position wurde zweiseitig gedruckt: Positionen auf Seite 1, Summen und Zahlungsangaben auf Seite 2, mit vollständig wiederholtem Briefkopf. Ursache waren die Falt- und Lochmarken am linken Rand: Ihnen fehlte in älteren Vorlagen die Kennzeichnung als ortsfest, sodass sie mit dem Text nach unten wanderten und dabei einen Seitenumbruch erzwangen.

Am Lieferschein ließ sich aus der Übersicht heraus nichts öffnen: PDF anzeigen, drucken, per E-Mail senden, bearbeiten, bestätigen und löschen liefen alle in einen Serverfehler. Ursache war eine andere Schreibweise der Belegkennung zwischen Übersicht und Aufruf — der Abbruch geschah, bevor eine Fehlerbehandlung greifen konnte. Die Belege selbst waren nie betroffen, nur der Zugriff darauf.

Der Packtisch im Browser fragt jetzt, womit gepackt wird: Palette, Colli oder Karton — jeweils mit den hinterlegten Maßen, also etwa Europalette 120 × 80 oder Düsseldorfer Palette 80 × 60. Was gewählt wurde, steht anschließend am Packstück der Sendung: nicht mehr nur „Packstück 1 / 3“, sondern „Palette 1 / 3“ mit Maßen und Gewicht. Maße und Leergewicht kommen aus dem Packmittel-Katalog; wer selbst misst oder wiegt, überschreibt sie. Nebenbei behoben: Die Auswahlliste zeigte bislang immer die vier fest eingebauten Ersatzgrößen S/M/L/XL statt der Kartons des eigenen Betriebs.

Unter „E-Mail-Protokoll“ fehlten die meisten Nachrichten: Rechnungen, Lieferscheine und Versandbestätigungen wurden zwar verschickt, tauchten im Protokoll aber nicht auf. Ursache war ein Formatunterschied bei der Auftragskennung, an dem der Protokolleintrag abbrach — vermerkt auf einer Stufe, die im Betrieb nicht ausgeliefert wird. Ab sofort wird jede Mail erfasst, auch fehlgeschlagene Versuche mit Fehlermeldung.

Der neue CRM-Reiter „Vor der Tour“ zeigt für jede anstehende Tour, wer im Gebiet noch nicht bestellt hat. Im Kopf steht, wann die Tour fährt, wie viele Kunden schon bestellt haben und wie voll der LKW ist (Umsatz und Kilogramm); darunter die offenen Kunden, die wichtigsten zuerst. Damit die Gebiete überhaupt füllbar sind, lassen sich am Gebiet PLZ-Bereiche hinterlegen — ein Klick ordnet alle passenden Kunden zu, und vorher zeigt eine Vorschau genau, wie viele es sind. Beim Verpacken lässt sich jetzt zudem unterscheiden, ob ein Packstück eine Palette, ein Colli oder ein Karton ist; die gängigen Paletten sind mit Maßen, Leergewicht und Traglast ab Werk hinterlegt.

Der Mail-Testmodus hielt bisher jede Kundenmail an. Ab sofort lässt sich die Reichweite wählen: nur die Probelauf-Rechnungen umleiten (Vorgabe, das Tagesgeschäft läuft normal weiter) oder wie bisher jede Kundenmail anhalten. Dabei fiel auf, dass die Ausnahmeliste für Anmelde- und Passwortmails das Kundenportal nicht erfasste — dessen Registrierungs- und Passwort-Mails wären mit umgeleitet worden.

Beim Erstellen einer Rechnung aus einem Auftrag nahm BIS ERP den Steuersatz bisher aus den Artikelstammdaten. Ab sofort gilt der Satz aus dem Auftrag — also der, mit dem der Verkauf zustande kam. Der Artikelstamm kennt nur den deutschen Regelsatz und weiß nichts von innergemeinschaftlicher Lieferung (0 %), Ausfuhr, OSS-Fernverkauf mit dem Satz des Bestimmungslandes oder einem Lagerort im Ausland. Rechnung und Auftrag stimmen damit wieder überein, auch beim Versand.

Im CRM gibt es einen neuen Reiter „Heute“. Er beantwortet die Frage, mit der ein Verkäufer den Tag beginnt: Wen rufe ich an, und warum? Die Liste zeigt die 25 dringendsten Kunden und nennt zu jedem den Grund im Klartext — „−89 % Umsatz gegenüber der Vorperiode“, „seit 38 Tagen still, bestellt sonst etwa alle 9 Tage“, „Tour Paderborn in 2 Tagen“. Die Reihenfolge entsteht aus ABC-Klasse, Umsatzrückgang, Überfälligkeit gegenüber dem eigenen Bestellrhythmus des Kunden, Inaktivität, Tournähe und Potenzial. Sie wird bei jedem Aufruf neu berechnet und kann deshalb nicht veralten.

Wer eine Rechnung per E-Mail bekam, fand im Anhang eine Datei namens inv_pdf_HCBDgi — ohne Endung, ohne erkennbaren Dateityp. Ab sofort heißt sie Rechnung_RE-000123.pdf und wird korrekt als PDF ausgewiesen. Mailprogramme zeigen damit wieder Symbol und Vorschau; ein Anhang ohne Typkennung wird von manchen Programmen gar nicht geöffnet und von Spamfiltern strenger bewertet.

Die Gegenüberstellung im Rechnungs-Probelauf frischte sich nur auf, solange BIS ERP neue Vergleichsrechnungen erzeugte. Sobald alle Aufträge einmal berechnet waren, blieb sie stehen — also genau dann, wenn es darauf ankommt, denn die JTL-Rechnung entsteht in aller Regel später als die Probe-Rechnung. Ab sofort wird nachgemessen, solange der Probelauf läuft.

Die Kundenverwaltung wusste bisher nicht, wer für einen Kunden zuständig ist und wie wichtig er ist. Beides lässt sich ab sofort hinterlegen — und danach filtern. Neu an jedem Kunden: Betreuer, ABC-Klasse (automatisch aus dem Umsatz der letzten zwölf Monate), Potenzialklasse als Einschätzung des Außendienstes, Anteil am Einkauf sowie Gebiet und Tourtag über einen neuen Gebiets-Katalog. Eine von Hand gesetzte ABC-Klasse wird von der nächtlichen Berechnung nie überschrieben und ist in der Liste an einem Schloss erkennbar. Die neuen Filter laufen auf dem Server und durchsuchen damit wirklich alle Kunden — die bisherige Filterung nach Aktiv/Inaktiv sah nur die gerade geladene Seite an.

Die Einstellung „Rechnungen aus JTL abholen“ wirkte bisher nur auf Knopfdruck — im automatischen Abgleich alle fünf Minuten wurde sie übersehen. Der Schalter stand auf an, und trotzdem kam keine Rechnung an. Ab sofort holt der automatische Abgleich sie mit. Ein Startdatum ist dabei Pflicht: Fehlt es, wird der Schritt übersprungen und vermerkt, statt die komplette Rechnungshistorie zu ziehen.

Wer seine Rechnungen heute in der JTL-Wawi schreibt, kann die Umstellung auf BIS ERP jetzt vorher ausprobieren: Im Probelauf berechnet BIS ERP dieselben Aufträge ein zweites Mal und stellt seinen Beleg dem der JTL-Wawi gegenüber — Netto, Steuer, Brutto und Positionszahl nebeneinander, mit der Abweichung auf den Cent. Die Probe-Rechnung erreicht niemanden, verbraucht keine Rechnungsnummer und taucht in keiner Auswertung auf. Dazu ein Mail-Testmodus, der ausgehende Kundenmails an eine interne Sammeladresse umleitet, solange geprüft wird.

Zwei Einstellungen, die pro Kasse verschieden sein müssen, gehören ab sofort zur einzelnen Kasse statt zu den Firmendaten: die Kundengruppe der Laufkundschaft (sie entscheidet über brutto oder netto mit Pfand-Aufschlag) und die Kundenabfrage vor dem Verkauf. Damit sind eine Endkunden-Kasse und eine Händlerkasse im selben Betrieb kein Sonderfall mehr — jede behält ihre Einstellung, unabhängig davon, was an den Firmendaten geändert wird.

Die Kundenakte nannte bisher nur eine Summe: was der Kunde insgesamt jemals gekauft hat. Ob er gerade weniger kauft als vorher — die wichtigste Frage im Vertrieb — war daran nicht zu erkennen. Ab sofort steht über der Kundenakte die Umsatzentwicklung in drei Zeitfenstern (30 Tage, 90 Tage, 12 Monate), jeweils gegen den gleich langen Zeitraum davor verglichen und farblich bewertet. Dazu kommt der Bestellrhythmus: In welchem Abstand bestellt der Kunde üblicherweise, wann ist die nächste Bestellung zu erwarten, ist er überfällig. Damit diese Zahlen stimmen können, holt ein neuer Historien-Abgleich die abgeschlossenen JTL-Aufträge samt Positionen nach — bisher kannte BIS ERP nur die offenen.

Wer unter Einstellungen → Unternehmen den Firmennamen, die Anschrift oder die Steuernummer speicherte, hat damit unbemerkt Einstellungen aller Kassen gleichgeschaltet — auch solche, die pro Kasse unterschiedlich sein müssen. Bei einem Betrieb mit zwei Händlerkassen und einer Endkunden-Kasse übernahm die Endkunden-Kasse dadurch die Händler-Einstellungen: Nettopreise, Kundenabfrage vor jedem Verkauf und Mehrwertsteuer auf den gesetzlichen Einwegpfand. Diese Einstellungen bleiben ab sofort bei der einzelnen Kasse.

Welche Kundengruppe eine Kasse bei Laufkundschaft ohne erfassten Kunden verwendet, entscheidet über die Preisbasis und darüber, ob brutto (Privatkunde) oder netto mit Pfand-Aufschlag (Händler) gerechnet wird. Diese Einstellung liess sich bisher nur direkt am Gerät ändern — stand sie an einer Kasse falsch, half nur der Gang zum Tablet. Ab sofort stellen Sie sie im Kundencenter unter Fernwartung → Preiskalkulation ein, und zwar als Auswahlliste Ihrer echten Kundengruppen statt als Zahlenfeld.

Ein zusätzlicher Benutzer für BIS ERP, Kundencenter oder die Lager-App kostet ab sofort 3,50 € je genutztem Tag, höchstens 20 € im Monat — bisher waren es 9 € am Tag mit einer Obergrenze von 59 €. Damit zahlen Sie für einen Lagermitarbeiter oder WaWi-Zugang dasselbe wie für ein Kellner-Tablet. Hintergrund: Zwei getrennte Preismodelle für dieselbe Sache laufen erfahrungsgemäss irgendwann auseinander — wir haben uns für einen einzigen Tarif entschieden, und zwar für den günstigeren.

Seit 0.0.0.571 kann am Preisschild ein QR-Code stehen, der Kunden eine Produktseite zeigt. Ihre Mitarbeitergeräte konnten ihn bisher nicht lesen und meldeten „Kein Artikel gefunden“. Das ist behoben — damit ist die Idee vollständig: EIN Code am Artikel, den Kunde und Mitarbeiter gleichermaßen scannen. Ein zweiter Aufkleber ist nicht nötig.

Wurden zu einem Lieferschein mehrere Pakete verschickt, hängte BIS ERP alle Sendungsnummern hintereinander in ein Feld. Ab dem fünften Paket war die Zeichenkette zu lang und der gesamte Vorgang schlug fehl — der Auftrag stand danach ohne Sendungsnummer, ohne Versanddatum und ohne Zusteller da, obwohl die Ware längst unterwegs war. Jetzt führt der Auftrag die Nummer der Leitsendung, die vollständige Liste aller Pakete steht daneben. Auch bei 50 Paketen.

Wer einen Artikel deaktiviert, kann dessen EAN ab sofort woanders weiterverwenden — zum Beispiel als Gebinde-Barcode am Einzelartikel. Bisher meldete das System dort „EAN wird bereits von Artikel … verwendet“, obwohl der genannte Artikel längst abgeschaltet war. Der häufigste Fall: Ein Karton lief als eigener Artikel und soll künftig als Gebinde am Einzelartikel geführt werden — Karton-Artikel deaktivieren, seinen Barcode beim Gebinde eintragen, in einem Zug.

Wird ein Teil einer Position als Fehlbestand ausgebucht, zeigt die Zeile ab sofort nur noch die Menge, die tatsächlich in den Karton soll: Aus „23/72“ wird „23/24“. Nimmt jemand danach ein Stück wieder aus dem Karton, steht die Position auch wieder als offen da, statt weiterhin als erledigt zu gelten — ein versehentlicher Druck auf das Minus lässt sich damit einfach durch einen weiteren Scan ausgleichen. Bisher war die Zeile danach gesperrt, und der einzige Ausweg war, die ganze Fehlmengen-Entscheidung zu widerrufen und neu auszubuchen.

Wer die Kellner-Anbindung oder einen zusätzlichen Benutzer tageweise nutzt, bekommt die genutzten Tage ab sofort korrekt in Rechnung gestellt. Das klingt selbstverständlich, war es bisher aber nicht: Die Tage wurden zuverlässig erfasst und im Kundencenter richtig ausgewiesen — auf dem Weg zur Rechnung ging jedoch eine Übergabe ins Leere, sodass nie ein Betrag entstand. Betroffen waren ausschliesslich unsere eigenen Test- und Demo-Zugänge; kein Kunde hat dadurch zu viel oder zu wenig gezahlt.

Wer Bestellungen mit dem Tablet am Tisch aufnimmt, zahlt dafür ab sofort 3,50 € pro genutztem Tag und Gerät — höchstens 20 € im Monat, ab dem sechsten Tag ist jeder weitere frei. Bisher lief ein Kellner-Tablet über denselben Posten wie ein Lagermitarbeiter und kostete bis zu 59 €. Der Grund ist technischer Natur: Ein Kellner-Tablet ist ein Client an Ihrer Hauptkasse, signiert nichts selbst und braucht keine eigene technische Sicherheitseinrichtung — anders als eine vollwertige zweite Kasse. Der alte Preis stammte aus dem Benutzermodell der Warenwirtschaft und machte ein Bestelltablet teurer als eine zweite Kasse, obwohl es weniger kann.

Wird ein Auftrag an der Kasse bezahlt und die Ware mitgenommen, bucht BIS ERP den Warenausgang und schreibt den Lieferschein dazu. Neu ist, dass beides zuverlässig zusammen passiert oder eben gar nicht: Bisher galt der Kassenbeleg schon als erledigt, bevor Zahlung, Bestandsabgang und Lieferschein geschrieben waren. Brach ein Schritt ab, blieb ein Auftrag zurück, dessen Bestand gebucht war, dem aber der Lieferschein fehlte — und der sieht in JTL aus wie einer, der noch zu liefern ist. Wurde er dort von Hand ausgeliefert, verließ dieselbe Ware das Lager ein zweites Mal.

Unter der Steueraufteilung steht jetzt ein eigener Pfandblock: Warenwert, Pfandwert und — separat ausgewiesen — der Kastenpfand. Erkannt wird das Pfand über die am Artikel gepflegten Angaben, Kästen also auch dann, wenn sie nicht als eigene Zeile auf der Rechnung stehen. Die Rechnung bekommt außerdem dasselbe Gesicht wie der Lieferschein: Artikelnummer als Barcode und Klartext, Bestelldatum und Besteller im Kopf, Ansprechpartner mit Durchwahl.

Am Preisschild kann jetzt ein QR-Code stehen, der Ihren Kunden eine Produktseite zeigt — Bild, Bezeichnung, Beschreibung, Herkunft und bei Lebensmitteln Zutaten, Allergene und Nährwerte. Gescannt wird mit der Handykamera, ohne App und ohne Anmeldung. Dabei bleibt es bei einem einzigen Code am Artikel: Derselbe QR-Code enthält die EAN weiterhin im Klartext, sodass Mitarbeitergeräte sie daraus lesen können.

Die Sync-Überwachung erkennt jetzt einen Fall, der bisher lautlos durchrutschte: Der Auftrag zur Rechnungserstellung ist an die Warenwirtschaft übergeben — und bleibt dort liegen, ohne dass eine Rechnung entsteht. Bei einem Mandanten lagen so zehn Rechnungsaufträge über zwei Wochen unbearbeitet, weil sich über 12.000 fremde Einträge davorgeschoben hatten.

Unter der Steueraufteilung stehen jetzt Warenwert und Pfandwert getrennt, dazu die Zwischensumme. Fällt Kastenpfand an, erscheint er mit Anzahl in einer eigenen Zeile. Der Block zeigt sich nur auf Belegen, die Pfand tragen. Die Pfandzeilen selbst bleiben bei ihrer Ware in der Positionsliste — der Block fasst zusammen und rechnet nichts neu.

Verkaufen Sie ein Set — etwa Gerät, Koffer und Zubehör als einen Artikel —, können Sie die Bestandteile jetzt sichtbar machen: im Warenkorb, auf dem Kassenbon, auf dem digitalen Bon und auf der A4-Rechnung. Rein informativ: Das Set bleibt eine Position mit seinem Gesamtpreis, an Steuerausweis und TSE-Signatur ändert sich nichts. Der Schalter ist ab Werk aus.

Rechnungen, die automatisch entstehen — nach dem Verpacken einer Sendung oder wenn ein offener Auftrag an der Kasse bezahlt wird —, enthalten jetzt zuverlässig auch die Pfandbeträge. Bei einem Getränkehändler ist das kein Nebenbetrag: Auf drei Rechnungen eines Mandanten fehlten zusammen 276,00 € netto, und auffallen konnte das nur dem Kunden.

Verkaufen Sie ein Gerät mit Seriennummer, steht diese Nummer jetzt auf der A4-Rechnung und auf dem digitalen Bon — pro Position, unter dem Artikelnamen. Bisher blieb sie unsichtbar, obwohl die Kasse sie beim Kassieren erfasst hat. Bei Geräten, Werkzeugen oder Waffen ist der Beleg der Nachweis, welches Einzelstück ein bestimmter Kunde bekommen hat.

Wer in einem Lager ohne Lagerplatzverwaltung kommissionierte, wurde trotzdem mit Lagerplätzen geführt — ganz oben stand groß „Kein Lagerplatz“ mit Ortsmarke. Jetzt schaut das Gerät nach, ob das Lager, in dem Sie stehen, Plätze führt: Ohne Plätze führt der Artikel, mit Plätzen bleibt alles wie gewohnt. Dazu bekommt das Kommissionieren denselben Ablauf wie der Packtisch: Check-in-Scan, Mengeneingabe, Aktionsmenü und die Frage nach dem Grund, wenn Ware fehlt.

Ein in JTL hinterlegter Sonderpreis gilt jetzt ununterbrochen. Bisher verschwand er bei jedem Abgleich für rund 40 Sekunden, weil die Preistabelle komplett neu aufgebaut wurde — fiel ein Verkauf in dieses Fenster, wurde der reguläre Preis berechnet.

Rabatt, Zahlungsziel und Zahlungsart eines Kunden landen jetzt auch in der JTL-Wawi — bisher blieben sie in BIS ERP stehen, ohne Fehlermeldung. Zusammen mit der Adressübertragung sind alle Kundendaten wieder durchgängig. Rückstände arbeitet der Abgleich zudem zehnmal schneller ab.

Der Abgleich überträgt nur noch, was sich wirklich geändert hat. Bisher löste schon eine reine Bestandsbuchung eine Übertragung des ganzen Artikels aus — obwohl dabei kein Wert übergeht, den JTL nicht schon hätte. Ein Abgleich dauert jetzt gut eine Minute statt bis zu neun.

Eine Picklisten-Vorlage („alles per Spedition“, „höchstens fünf Aufträge je Rundgang“) erschien bisher nur im Browser als Schnellstart — am Handgerät musste man trotzdem jeden Auftrag einzeln antippen. Jetzt stehen die Vorlagen oben im Anlege-Bildschirm der Lager-App: Ein Tipp sucht die passenden Aufträge und legt die Kommissionierliste an. Angelegt werden die Vorlagen weiterhin nur in BIS ERP.

Die Gewinnübersicht eines Auftrags zeigt die Versandkosten jetzt sofort — aus den Konditionen Ihrer Versandart, statt erst nach dem Einlesen einer Frachtrechnung. Die Zahl wächst mit dem, was bekannt ist: erst aus dem Versandgewicht vorkalkuliert (110 kg sind bei einer 31-kg-Staffel vier Pakete), nach dem Verpacken mit den tatsächlich gepackten Packstücken, zuletzt mit dem abgerechneten Betrag. Zusätzlich werden Ware und Pfand in Umsatz und Wareneinsatz getrennt ausgewiesen — samt Marge ohne Pfand.

Antwortet der Server beim Abschluss einer Sendung nicht, zeigt das Handheld jetzt ein Wartesymbol statt einer Fehlermeldung — und holt den Abschluss automatisch nach, auch wenn die App zwischendurch geschlossen wird. Das Versandetikett kommt in jedem Fall aus dem Drucker. Vorher blieb ein fertig gepackter Karton in so einem Fall liegen: ohne Bestandsabzug, ohne Sendung, ohne Lieferschein und ohne dass es jemandem auffiel.

Berechnen Sie an Ihren Artikeln einen Pfandbetrag, für den unter Pfandarten kein Eintrag existiert, meldet das System das jetzt von selbst. Ohne passende Pfandart greift eine automatisch gebildete Artikelnummer, zu der es in Ihrer JTL-Wawi keinen Artikel gibt — die Pfandzeile wird dort als freie Position ohne Artikelbezug gebucht.

Im Artikel unter Allgemein lässt sich ein weiterer Barcode wieder per Mausklick auf Hinzufügen speichern. Bisher passierte beim Anklicken nichts — nur über Tabulator und Eingabetaste kam man weiter. Der Knopf war nicht defekt, sondern verdeckt: Die Eingabezeile lief aus ihrer schmalen Spalte heraus und schob sich unter das Feld UPC, das den Mausklick abfing.

Wer in seiner JTL-Wawi einen eigenen Pfandartikel führt und ihn unter Pfandarten zugeordnet hat, bekommt ihn jetzt zuverlässig auf Auftrag und Lieferschein — als richtige Artikelposition statt als freie Position ohne Artikelbezug. Ursache war eine Uneinigkeit zwischen Kasse und Warenwirtschaft darüber, ob der Pfandbetrag netto oder brutto gemeint ist.

Zwei Dinge, die stillschweigend nicht funktioniert haben, funktionieren wieder: Adressänderungen an einem Kunden landen jetzt auch in der JTL-Wawi, und geänderte Artikelpreise oder -bezeichnungen gehen wieder hinüber. Beide Fehler waren unsichtbar — es gab keine Meldung, und der Abgleich meldete Erfolg.

Ein in JTL angelegter Auftrag steht künftig binnen weniger Minuten am Packtisch. Bisher konnte das bis zu 45 Minuten dauern — nicht weil der Abgleich lange brauchte, sondern weil er ganz hinten anstand: erst Kategorien, Artikelstamm und Bestand, dann die Aufträge. Der Lieferschein zurück nach JTL geht denselben kurzen Weg.

Jede Pfandart trägt ab Werk eine feste Artikelnummer — PFAND25 für den Einwegpfand von 25 Cent, PFAND08 für den Mehrwegpfand von 8 Cent, PFAND150 für den Bierkasten. Bisher blieb das Feld leer und die Nummer entstand unsichtbar im Hintergrund. Wer in seiner JTL-Wawi einen eigenen Pfandartikel führt, trägt dessen Nummer ein und bucht damit auf genau diesen Artikel.

Am Handgerät standen zwei Kacheln nebeneinander — „Kommissionierung“ und „Sammeln“ — für dieselbe Arbeit. Jetzt gibt es einen Punkt: Alle Kommissionierlisten stehen beieinander, und daneben steht, für wie viele Aufträge die jeweilige gilt. Beim Anlegen wählen Sie die Aufträge mit einem Haken; einer oder fünf, es entsteht immer eine Liste.

Der Lieferschein zeigt in jeder Zeile drei Mengen statt einer: bestellt, geliefert, offen. Die Artikelnummer steht als Barcode und als Klartext untereinander — der Wareneingang Ihres Kunden kann scannen, wer die Nummer vorlesen will, kann das weiterhin. Was nicht mitging, steht in einer eigenen Tabelle mit Grund und voraussichtlichem Termin statt als Fließtext im Hinweisfeld. Dazu kommen Packstückliste mit Sendungsnummern, Empfangsbestätigung zum Unterschreiben und ein QR-Code zur Sendungsverfolgung.

Wer am Handheld sammelt oder packt, sieht jede Entnahme jetzt sofort im Artikeljournal — und die Ware im Karton ist ab dem Scan nicht mehr verkäuflich. Bisher galt das nur für Betriebe mit Lagerplatzverwaltung; ohne sie passierte beim Packen gar nichts, und dieselbe Ware konnte online weiterverkauft werden. Beim Sammeln wurde sie umgekehrt sofort ausgebucht, obwohl sie noch auf dem Wagen im Haus stand. Jetzt gilt einheitlich: Sammeln und Packen bewegen die Ware, verkauft wird sie erst beim Versand.

Der Firmenname eines Kunden lieferte in der Auftragsliste keinen Treffer — gesucht wurde nur in Auftragsnummer, Kundenname, E-Mail und Artikeln. Jetzt zählen Firma, Straße, PLZ, Ort, Telefon und USt-IdNr. mit, in Liefer- wie Rechnungsanschrift, dazu die Angaben aus der Kundenakte. Rechnungs- und Kundenliste haben dieselbe Erweiterung bekommen.

Stellten Sie „Tag: 18.08.“ ein, standen dort auch Vorgänge vom frühen Morgen des 19.08. — und der Tagesumsatz zählte sie mit; umgekehrt fehlten Vorgänge aus der Zeit zwischen Mitternacht und 2 Uhr. Die Datenbank führt alle Zeitstempel in Weltzeit, der Filter verglich sie ungerechnet mit dem Kalendertag. Jetzt gilt überall die Zeitzone Ihres Betriebs: für Filter, Kacheln, Berichte und angezeigte Uhrzeiten — für alle Mitarbeiter gleich.

Wer am Packtisch im Browser einen Auftrag zusammengestellt hatte, verlor alles beim Neuladen der Seite. Der Fortschritt liegt jetzt beim Server statt im Browserfenster — damit lässt sich mitten im Vorgang wechseln: Handgerät zu Bildschirm, ein Mitarbeiter zum nächsten. Und angefangene Packstücke werden nie mehr automatisch weggeräumt: Sie sind der Nachweis, dass Ware im Karton liegt statt im Regal.

Pfandpositionen trugen bisher eine interne Nummer — auf jedem Kassengerät eine andere, bei der Leergut-Rücknahme sogar bei jedem Bon eine neue; in der Warenwirtschaft kam die Zeile ganz ohne Artikelnummer an. Jetzt hat jede Pfandart eine feste Nummer: dieselbe im Warenkorb, auf dem Beleg und als Position im JTL-Auftrag. Wer in JTL einen eigenen Pfandartikel führt, ordnet ihn im Kundencenter unter „Pfandarten“ zu.

Pfand ist keine Entscheidung: Wer 23 statt 24 Flaschen bekommt, zahlt Pfand für 23. Am Artikel steht ohnehin, ob er Pfand trägt und wie hoch — dieselbe Angabe, mit der die Kasse arbeitet. Daraus ergibt sich die Pfandmenge jetzt automatisch aus der gelieferten Ware, auch bei einer Teillieferung. Am Packtisch muss dafür nichts mehr bestätigt werden.

Beim Forderungsausgleich stand derselbe offene Posten bei JTL-Anbindung doppelt in der Trefferliste — einmal als Rechnung aus JTL, einmal als Auftrag aus BIS ERP. Wurde der falsche gewählt, war das Geld in der Kasse, die Forderung in JTL blieb aber offen. Jetzt erscheint jeder Beleg genau einmal.

Der Hinweistext über der Reparaturübersicht behauptete noch, Positionen und Preise lägen nur auf dem Kassen-Tablet — für Vorgänge aus dem ERP stimmt das längst nicht mehr. Ausserdem sind Positionen eines abgerechneten Vorgangs jetzt sichtbar gesperrt statt nur wirkungslos.

Beim Rückversand einer Reparatur erschien am Packtisch jede Auftragsposition — auch Arbeitszeit. Der Packer suchte im Regal nach „Ladebuchse tauschen“. Jetzt steht dort nur noch, was wirklich in den Karton gehört: das Gerät des Kunden.

Auf Aufträgen aus der Kasse stand bei einzelnen Pfandzeilen ein Rabatt von rund 0,1 Prozent — für Ware, die niemand rabattiert hat. Dahinter steckte ein halber Cent: 30 Flaschen Pfand à 0,2975 € ergeben 8,925 €, und den halben Cent haben Kasse und Warenwirtschaft gegenläufig gerundet. Diesen einen Cent hat die Übertragung als Preisnachlass gedeutet. Jetzt rechnen beide Seiten gleich.

Wer Reparaturen per Versand annimmt, erzeugt jetzt direkt aus dem Vorgang ein Einsende-Label: Der Kunde druckt es aus und schickt sein Gerät ein. Die Schaltfläche erscheint nur, wenn der Versanddienstleister Retouren auch wirklich freigeschaltet hat.

Aus einem Reparaturvorgang wird auf Knopfdruck ein ganz normaler Auftrag — mit Rechnung, Zahlungseingang, Versandlabel und Packtisch. Wer sein Geschäft über den Versand betreibt, kann Reparaturen jetzt vollständig in BIS ERP abwickeln, auch ganz ohne Kasse.

Reparaturaufträge entstehen an der Kasse, verwalten liess sich der Fortschritt aber auch nur dort. Jetzt steht die Werkstatt in BIS ERP unter Aufträge → Reparaturaufträge: Stand setzen, Termin eintragen, Hinweis für den Kunden hinterlassen, benachrichtigen — die Kasse übernimmt die Änderung beim nächsten Abgleich von selbst.

Enthält ein Auftrag ein Set, erscheinen beim Kommissionieren jetzt die Komponenten auf der Liste — nicht mehr das Set selbst. Ein Set liegt nicht als fertiger Karton im Regal; sein Bestand wird aus den Einzelteilen errechnet. Vorher fand der Kommissionierer nichts, und der Auftrag galt zusätzlich als nicht lieferbar.

Mehrere Aufträge in einem Rundgang sammeln: Die Liste zeigt jeden Artikel einmal mit der Summe über alle Aufträge. Bisher wurden dabei zwar Wellen angelegt und ein Fortschritt angezeigt, aber kein Bestand gebucht — jetzt bucht jeder Griff sofort und über denselben Weg wie die Einzel-Kommissionierung.

Unten in der Seitenleiste stand dauerhaft 0.0.0.376 — eine Nummer aus dem Juli, während die Anwendung längst 155 Versionen weiter war. Die Anzeige stimmt jetzt wieder.

Ein Fehler aus den letzten beiden Versionen: Sobald eine Sendung „Abholbereit“ oder „Zustellproblem“ wurde, fragte die Sendungsverfolgung sie nicht mehr ab — sie wäre nie auf „Zugestellt“ gewechselt, auch wenn der Kunde sein Paket längst geholt hat.

Meldet DHL „Zustellung nicht möglich. Weiterleitung an Filiale“ oder hinterlässt eine Benachrichtigungskarte, ist das eine Verzögerung — das Paket ist weiter unterwegs. Solche Sendungen erschienen als „Zustellproblem“ und lösten Alarm für einen Alltagsfall aus.

Wird ein Paket nicht angetroffen und in die Filiale weitergeleitet, meldet der Versanddienstleister das in zwei Schritten. Seit der letzten Version blieb der erste stehen — die Sendung galt als Zustellproblem, obwohl sie normal zur Abholung bereitlag. Solche Sendungen haben jetzt den eigenen Status „Abholbereit“.

Meldet der Versanddienstleister eine beschädigte, neu verpackte oder entsorgte Sendung, stand sie bisher weiter unter „Unterwegs“ — der Schaden war nur in den Verfolgungsdetails zu finden. Solche Sendungen haben jetzt den Status „Zustellproblem“ mit eigener Kachel und eigenem Filter.

Beim Verkauf eines seriennummerngeführten Artikels wird das konkrete Einzelstück in JTL jetzt zuverlässig ausgebucht. Bisher geschah das nur, wenn der Verkauf über den grossen Abgleich lief — der schnelle Abgleich, über den die meisten Kassenverkäufe gehen, übersprang den Schritt stillschweigend.

In der Versandübersicht stand unter „Unterwegs“ eine Zahl, die nicht stimmen konnte — in einem Fall 4.451 Sendungen, von denen 19 tatsächlich unterwegs waren. Sendungen, zu denen der Versanddienstleister nach 90 Tagen nichts mehr meldet, gelten jetzt als „Abgeschlossen“ statt endlos als unterwegs.

Reine Wartung: Zehn Programmstellen im Retourenbereich, die durch gleichnamige an anderer Stelle ersetzt sind und nie ausgeführt werden, sind jetzt eindeutig gekennzeichnet.

Wer die Geräteeinstellungen im Kundencenter speichern wollte, ohne BIS Remote gebucht zu haben, bekam eine technische Meldung zu sehen, aus der sich nichts ableiten ließ. Jetzt steht dort im Klartext, welches Modul fehlt und wo es zu finden ist — und zwar bevor Sie ein Formular ausfüllen.

Gutscheine aus dem Gutscheinsystem von JTL lassen sich jetzt an der BISpicy-Kasse einlösen und dort verkaufte Karten aufladen — inklusive Teileinlösung mit Restwert. Und seriennummerngeführte Artikel bringen ihre Einzelstücke aus JTL-Wawi mit: Beim Verkauf wird die konkrete Seriennummer gewählt oder gescannt und genau dieses Stück in JTL ausgebucht.

Beim Löschen einer Retoure blieben ein zugehöriger Werkstattauftrag und eine vereinbarte Lieferanten-Lösung als verwaiste Einträge zurück. Sie werden jetzt mitentfernt.

Der Abruf der Rückgabegründe endete in einem Serverfehler — und zwar immer, denn der Gründe-Katalog ist ab Werk gefüllt. Sichtbar wurde das erst, seit der Aufruf überhaupt ankommt.

Vier Aufrufe kamen überhaupt nicht an: Sie wurden intern mit dem Aufruf einer einzelnen Retoure verwechselt. Ob ein Aufruf ankam, hing allein von seiner Position im Programm ab.

Mehrere Listen im Retourenbereich endeten in einem Serverfehler, sobald auch nur ein Eintrag vorhanden war. Solange nichts da war, sahen sie gesund aus — deshalb fiel es nie auf.

Zwei Bereiche des Retourenmoduls konnten nie funktionieren: Die zugehörigen Tabellen wurden unter einem anderen Namen und mit völlig anderen Feldern angelegt, als das Programm sie anspricht.

Die Retourenansicht zeigte bei Lieferantenretouren vier Versandfelder an, in denen immer „-“ stand — es gab sie in der Datenbank nicht und nirgends eine Eingabemöglichkeit. Beides ist jetzt da.

Der Aufruf für die Kennzahlen-Kacheln der Retourenübersicht wurde intern mit dem Aufruf einer einzelnen Retoure verwechselt und abgewiesen. Die Kacheln füllen sich jetzt.

Beim Durchtesten des kompletten Ablaufs kamen drei weitere Fehler ans Licht, die das Wellen-Modul unbenutzbar machten — darunter die Detailansicht, die sich grundsätzlich nicht öffnen ließ.

Nachtrag: Praktisch jede Funktion der Wellen-Kommissionierung las die Antwort des Servers an derselben Stelle falsch aus. Am Handheld blieb die Positionsliste dadurch leer — Kommissionieren war dort nicht möglich.

Ein Befehl zum nachträglichen Anlegen von Datenbankspalten stammt aus einem anderen Datenbanksystem und funktioniert bei uns grundsätzlich nicht — abgesichert ausgeführt, blieb sein Scheitern unsichtbar. 25 Stellen waren betroffen, darunter die Systemüberwachung und das Retourenmodul.

Dritte Runde der Frontend-Prüfung: Aufrufe mit falscher Parameterzahl. Fünf davon waren funktionsverhindernd — darunter zwei Datei-Importe, bei denen die Datei den Server nie erreichte.

Fortsetzung der Frontend-Prüfung: Stellen, an denen die Oberfläche ein Feld unter einem anderen Namen erwartete, als der Server es liefert. Sichtbar wurde das als leere Spalte, als 0,00 € oder als Aktion, die abbrach.

Bei Einkaufslisten ließ sich ein Fälligkeitsdatum eintragen — gespeichert wurde es nie, und die Spalte „Fällig“ blieb dauerhaft leer. Beides ist behoben.

Eine systematische Prüfung des Frontends hat 92 Stellen gefunden, an denen Code auf etwas zugriff, das es dort nicht gibt. Solche Fehler zeigen sich nicht als Meldung, sondern als leere Fläche oder als Aktion, die scheinbar nichts tut.

Wird an der Kasse eine Zahlungsart ohne hinterlegte Zuordnung verwendet, hat BIS ERP die passende JTL-Zahlungsart geraten — und lag falsch: Eine Kartenzahlung landete auf „Scheck“, weil die Namenssuche ausgerechnet dort ein „EC“ fand.

Sendungsliste und Versanddienstleister-Einstellungen folgen jetzt der eingestellten Sprache. Bislang war dort alles auf Deutsch beschriftet, unabhängig davon, welche Sprache im Konto hinterlegt war.

Die Versandkosten eines JTL-Auftrags stehen dort als eigene Position und wurden beim Import übergangen. Der Gesamtbetrag stimmte, die Aufschlüsselung nicht — „Versandkosten“ stand bei jedem JTL-Auftrag auf 0,00 €.

Die Suche über der Auftragsliste blieb ohne Wirkung — ab dem zweiten eingetippten Zeichen brach im Hintergrund ein Fehler ab. Der Suchbegriff wird jetzt wie vorgesehen serverseitig gesucht.

Die Oberfläche für das Briefporto — Portokasse einrichten, Produkt wählen, Marke kaufen — war bislang nur auf Deutsch beschriftet. Sie folgt jetzt der eingestellten Sprache, wie der Rest des BIS ERP.

Wird ein Auftrag in JTL-Wawi zuerst angelegt und erst danach mit Positionen befüllt, holte BIS ERP bisher nur den Auftragskopf. Am Packtisch stand der Auftrag dann mit „0 Positionen“ und ließ sich nicht abarbeiten.

Ein unverändert übernommener Positionspreis gilt nicht mehr als Preisänderung. Damit setzt das Speichern eines Auftrags durch jemanden ohne Preisberechtigung keine vereinbarten Preise mehr auf den aktuellen Artikelpreis zurück.

In der Auftragsliste ist jetzt verlässlich zu sehen, woran im Lager gerade gearbeitet wird — und ebenso, wenn niemand mehr daran arbeitet. Bisher blieb ein einmal geöffneter Auftrag dauerhaft auf „Packtisch“ stehen.

Wer einen Auftrag bearbeitet hat, ohne das Recht zum Ändern von Preisen zu besitzen, bekam beim Speichern eine Fehlermeldung — betroffen war jede Änderung am Auftrag, etwa das Aktivieren von „Teillieferung erlauben“. Das Speichern funktioniert nun wieder.

Ergänzung zu 0.0.0.460: Die an der Kasse vergebenen PINs erscheinen künftig auch in der Mitarbeiterverwaltung Ihres Kundenkontos — bisher blieb das Feld dort leer, wenn die PIN nur am Gerät gepflegt wurde. Sie können eine PIN damit von beiden Seiten aus ändern, die jeweils letzte Änderung gewinnt.

Seit heute Vormittag konnte es passieren, dass sich Mitarbeiterinnen und Mitarbeiter mit ihrer gewohnten PIN nicht mehr an der Kasse anmelden konnten. Ursache war ein Abgleich, der eine fehlende PIN eigenständig ergänzte — und diese Ersatz-PIN anschließend auf das Kassengerät zurückschrieb, wo sie die dort hinterlegte PIN ersetzte. Das ist behoben: Die Kasse behält immer die PIN, die auf dem Gerät gepflegt ist.

Wer Ware im Brief verschickt, frankiert jetzt direkt aus der Sendungsliste. Sie hinterlegen einmal Ihre Portokasse der Deutschen Post, wählen beim Versand das Produkt — Standardbrief, Großbrief, Maxibrief oder Einschreiben — und die Marke wird gekauft, gedruckt und der Sendung zugeordnet. Ein DHL-Geschäftskundenvertrag ist dafür nicht nötig.

Die Reihenfolge, in der das Handheld die Positionen zum Verpacken auflistet, lässt sich jetzt einstellen — „Schwerste zuerst“ oder „Leichteste zuerst“, als Stufe in der Rangfolge unter Bestandsstrategie. Ohne gewählte Stufe bleibt alles wie bisher.

Hinweise am Fragezeichen-Symbol waren in Tabellen nur zur Hälfte lesbar — die Tabelle schnitt ab, was über ihren Rand ragte. Sie werden jetzt über der Seite gezeichnet statt in der Zeile und rücken am Fensterrand nach innen.

Wer die Zahlarten an einer Kasse ändert, verteilt sie damit an alle Kassen des Betriebs. Dieser Abgleich brach im Hintergrund ab, ohne sich zu melden — die übrigen Geräte wurden nicht benachrichtigt und zogen die Änderung erst beim nächsten regulären Abgleich nach.

Der Hinweis auf fehlenden Bestand erschien auch an abgeschlossenen Aufträgen — an jedem Kassenbon stand „teilweise lieferbar“. Er gehört nur an Aufträge, die noch rausgehen. Außerdem ist die Marke dezenter: ein farbiges Warnzeichen statt eines Textfelds, das in der schmalen Spalte umbrach.

Ein an der Kasse angelegter Mitarbeiter ohne PIN kam im BIS ERP nie an: Die Kasse lässt ihn zu, das BIS ERP verlangte die PIN zwingend — und wies deshalb bei jedem Abgleich den kompletten Mitarbeiter-Block ab. Auf dem Tablet stand der Mensch, in der Mitarbeiterverwaltung blieb die Liste leer.

Für Artikel gab es im BIS ERP zwei Nummernkreise nebeneinander — einen, den nie jemand gelesen hat, und einen zweiten, der starr bei 10000 begann. Wer seine Artikel aus einem Import oder aus der Kasse übernommen hatte, bekam damit Nummern vorgeschlagen, die zum eigenen Bestand nicht passten.

Ein Auftrag, der am Packtisch nicht auftaucht, sah in der Übersicht aus wie jeder andere. Jetzt zeigt eine Marke „nicht lieferbar“ oder „teilweise“, und in der Detailansicht steht je Position „0 von 24 verfügbar“ — samt der beiden Sonderfälle, die sonst niemand versteht.

Die Artikelnummer der Kasse wird auf dem Gerät vergeben und nur dort auf Dopplung geprüft. Nach einem Werksreset zählt die Kasse wieder bei 1000 los und trifft auf Nummern, die im BIS ERP längst vergeben sind — der Abgleich hielt das für denselben Artikel und aktualisierte ihn.

Bei neu angelegten Mandanten konnte die Artikelliste zeitweise gar nicht laden. Und wer eine CSV mit der Spalte „Preis“ importierte, bekam den Wert als Einkaufspreis eingetragen — die Artikel standen anschließend ohne Verkaufspreis da.

Das Erstelldatum kommt jetzt aus JTL statt vom Importzeitpunkt. Aufträge, bei denen in JTL alle Mengen auf 0 stehen, werden nicht mehr importiert — sie landeten als leere Hülle in jeder Liste. Und die Packwarteschlange zeigt nur noch, was wirklich gepackt werden kann.

Ein in JTL versendeter Auftrag blieb im BIS ERP auf „bestätigt“ — und damit in der Packwarteschlange. Ein Mitarbeiter hätte ihn ein zweites Mal gepackt, mit zweitem Bestandsabzug. Der Abgleich zieht den Lieferstatus jetzt nach.

Die Versandbestätigung an Kunden wurde noch nie verschickt: Die Einstellung stand auf „an“, die Adresse lag vor — nur suchte das System sie in einem Feld, das es an dieser Stelle nicht gibt. Behoben. Ob sie rausgeht, entscheidet jetzt die Versandart, ab Werk ausgeschaltet.

Der Auftrag stand in der Warteschlange, beim Antippen kam „Positionen konnten nicht geladen werden“: Eine zweite Bestandsprüfung beim Öffnen zählte noch alle Positionen mit — auch die Pfandzeile mit Bestand 0. Beide Prüfungen stellen jetzt dieselbe Frage.

Arbeitet ein Lager ohne Lagerplätze, gibt es keinen Laufweg — bisher stand die Positionsliste dort nach Artikelnummer. Jetzt führt sie das schwerste Stück zuerst, damit die schwere Ware nach unten in den Karton oder auf die Palette wandert. Bei gleichem Gewicht entscheidet das kürzeste MHD.

Steht am Auftrag „Spedition“, schlägt das Handheld den Speditionsweg vor; steht dort „DHL Paket“, ist DHL vorgewählt — ohne dass dafür Versandarten angelegt und zugeordnet werden müssen. Bisher brauchte es beides, und bei Aufträgen aus JTL oder einem Shop steht ohnehin nur ein Text am Auftrag.

Positionen ohne Bestandsführung — Pfand, Zuschläge, Gebühren — erscheinen nicht mehr auf Pickliste und Packtisch und blockieren den Abschluss nicht länger. Auf Lieferschein, Rechnung und in JTL stehen sie unverändert. Versand- und Zahlungsart kommen beim JTL-Abgleich endlich mit.

Wer die Einstellungen für Pick & Pack öffnete, wurde abgemeldet — mit der Meldung „Sitzung abgelaufen“, obwohl die Anmeldung gültig war. Die Seite fragte dort Daten über einen Zugang ab, der ausschließlich den Lager-Geräten offensteht; die Abweisung wurde fälschlich als Ende der Anmeldung gedeutet.

Auftragsdetails öffnen sich wieder — bei jedem Betrieb ohne Fulfillment-Network endete „Details“ seit dem 16.07. im internen Fehler. Außerdem: Die JTL-Auftragsnummer ist wieder sichtbar und suchbar, der Sendungs-Rückweg nach JTL ist einschaltbar, und Bestellungen lassen sich einzeln abgleichen.

Über der Position steht jetzt groß, wohin der Mitarbeiter gehen muss, wie viel er dort holt und mit welchem MHD — statt der gesamten Positionsmenge. Der Zielplatz ist verbindlich, mit drei Auswegen. Und die Reihenfolge beim Kommissionieren lässt sich als Rangfolge festlegen statt als Entweder-oder.

Statt nur „Paketdienst“ oder „Spedition“ werden jetzt die Versandarten einzeln ausgewählt — mehrere gleichzeitig. Die konkrete Auswahl schlägt die grobe Einteilung; Geräte, die noch auf Paketdienst oder Spedition stehen, arbeiten unverändert weiter.

Das Startdatum begrenzte bisher nur die Richtung von JTL herein. Jetzt steuert dasselbe Feld beide Richtungen — was älter ist, geht auch nicht nach JTL hoch.

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.

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

Ein Gebinde oder Set hat keinen eigenen Bestand — er wird aus dem Basisartikel abgeleitet. Diese Ableitung lief bisher nur im Abgleich mit der Warenwirtschaft und rechnete zudem mit der falschen Bestandsquelle: Nach einer Inventur des Basisartikels blieben die Gebinde-Bestände auf dem alten Stand stehen.

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.

Die freie Zählung am Lager-Scanner war rudimentär: Man tippte den Lagernamen ein und scannte Barcodes, ohne den aktuellen Bestand zu sehen. Sie ist jetzt eine vollwertige Direktzählung.

Bisher galt: Sobald für ein Lager Lagerplätze angelegt waren, wurde beim Buchen und Zählen auch einer verlangt. Wer seine Platzstruktur erst aufbaut — Regale beschriftet, Codes vergibt, aber noch nicht eingeräumt hat — stand damit vor einer Pflicht, die er noch gar nicht erfüllen konnte.

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.

Beim Anlegen einer Inventur wählen Sie jetzt das Lager, für das sie gilt. Bisher fehlte diese Angabe vollständig — mit der Folge, dass die Lagerplatz-Auswahl die Plätze aller Läger anbot und beim Zählen niemand wusste, ob überhaupt mit Lagerplätzen gearbeitet wird.

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.

Im eigenständigen BIS Archiv fehlte bisher der schwebende Support-Knopf. Nutzer konnten dort zwar Dokumente und E-Mail-Archive öffnen, aber Fehler, Verbesserungsvorschläge oder Support-Anfragen nicht direkt aus der Oberfläche heraus melden.

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.

Zwei Stolpersteine im Belegdesigner sind beseitigt. „Neue Vorlage“ legte bisher eine völlig leere Vorlage an — es sah aus, als sei etwas kaputt. Und die Werksvorlage ließ sich nicht löschen, sondern quittierte den Versuch mit einer Fehlermeldung.

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 mailservice@bispos.app — 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.

Wer in der Warenwirtschaft eine Kundengruppe gelöscht hat, sah sie in BIS ERP weiterhin — der Abgleich legte neue Gruppen an und aktualisierte vorhandene, räumte aber nie auf. Das ist behoben.

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.

Der BISprint-Druck konnte Preisschilder bisher nur an eine gekoppelte Kasse schicken. Lager-Handhelds ließen sich zwar koppeln, waren im Auswahlfeld für das Druckziel aber nicht von einer Kasse zu unterscheiden.

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.

In neueren Ausgaben der Warenwirtschaft stehen Name, Anschrift und Kontaktdaten nicht mehr dort, wo BIS ERP sie suchte. Die Kundensuche lief deshalb ins Leere, und neu angelegte Kunden kamen unvollständig an. Beides ist behoben.

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

Der Rechnungskauf an der Kasse ist jetzt durchgängig: Verkäufe mit der Zahlart Rechnung gelten als offen statt als bezahlt, erzeugen auf Wunsch automatisch eine Rechnung und tragen ein korrektes Zahlungsziel — mit und ohne angebundene Warenwirtschaft.

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.