Versionsverlauf von BISpicy ERP

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

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

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

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

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

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

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

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

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

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

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

Version 0.0.0.54 — Bestellliste: Sortierung bleibt nach Reload erhalten

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Version 0.0.0.46 — TSE-Mehrfachkauf im Shop

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

Version 0.0.0.45 — KI-Artikelanlage mit Credit-System

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

Version 0.0.0.44 — Performance-Optimierung

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

Version 0.0.0.43 — KI-Artikelanlage

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

Version 0.0.0.42 — POS-Kundensync vollständig

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

Version 0.0.0.41 — JTL Zahlungsarten in POS & Kunden-Zahlungsziele

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

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

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

Version 0.0.0.39 — Pfand B2B/B2C MwSt & konfigurierbare Pfandarten

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

Version 0.0.0.38 — JTL-Kundensuche & Kunden-Push repariert

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