Versionsverlauf von BISpicy ERP

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.

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.