Lagerorte verwalten
Lager anlegen, umbenennen, löschen; Systemlager sind geschützt
Funktionen · Stammdaten & Ware
Lager & HACCP
Hier wird verwaltet, was tatsächlich im Haus liegt — und dass es sauber und richtig gekühlt liegt. Der Lagerteil führt Bestände je Lagerort, bucht jeden Verkauf automatisch vom Bestand ab (auch über Rezepturen: ein Cocktail zieht Flasche und Saft anteilig), nimmt Ware vom Lieferanten an, schlägt Nachbestellungen aus Mindest- und Sollmengen vor und rechnet einmal im Jahr oder häufiger die Inventur ab. Der HACCP-Teil ist das digitale Hygiene-Handbuch: Checklisten für Kühltemperaturen, Reinigung, Wareneingang und Personalhygiene, die das Personal an der Kasse abhakt und die als unterschriebenes Protokoll archiviert werden — auf Wunsch als PDF für das Gesundheitsamt. Beide Teile sind kostenpflichtige Zusatzmodule und sind ohne Freischaltung im Programm nicht sichtbar.
112 geprüfte Funktionen
Funktionsstand 07.09.2026
Allergene direkt an den Artikeln dokumentieren.
Echte Oberfläche
Lager & HACCP in DiKAS
Keine Stockmotive: Die Aufnahmen stammen aus den reproduzierbaren DiKAS-Demos und zeigen die jeweilige Funktion im Produkt.
Vollständiger Überblick
Was DiKAS in diesem Bereich kann
Alle folgenden Punkte stammen aus dem gegen den Programmcode geprüften Funktionskatalog.
Mindest-/Sollmengen je Lager
Pro Artikel und Lagerort Min/Max hinterlegen — Grundlage des Bestellvorschlags
Bestandsübersicht
Aktueller Bestand je Artikel und Lager, mit Ø-Einkaufspreis und Periodenzählern
Buchungen (Wareneingang, Umlagerung, Verlust)
Einzelne Bestandsbewegungen anlegen, ausführen, offene löschen
Buchungsjournal
Alle gebuchten Bewegungen, filterbar nach Lager, Artikel und Zeitraum, mit Seitenblättern
Verlustgründe
Bruch, MHD, Eigenverbrauch, Personal, Inventur, Sonstiges je Buchungsposition
Anforderung Theke → Hauptlager
Ausgabestelle fordert Nachschub an; Ablauf Neu → In Lieferung → Gebucht
Automatische Anforderung
Job füllt Theken-Lager alle 5 Minuten aus dem Hauptlager auf (Schalter StockAutoRequestEnabled)
Verkaufsabbuchung inkl. Rezeptur
Jeder Bon zieht Hauptartikel, Rezepturkomponenten (bis 3 Ebenen) und Optionen vom Lager des Arbeitsplatzes ab
Rezeptkosten aus Lager- und Lieferanten-EK
Grundrezepte werden über dieselbe zyklensichere Drei-Ebenen-Auflösung wie die Verkaufsabbuchung bewertet. Preisfolge je Lagerposition: Hauptlager-Ø-EK, erster positiver Ø-EK eines anderen Lagers, Standard-/erster positiver Lieferanten-EK geteilt durch Gebindefaktor. Bestandgeführte Zwischenartikel und Unterzutaten zählen beide
Storno-Rückbuchung
Storno eines Belegs oder Bons bucht die Mengen zurück
Pfand-/Leergut-Automatik
Verkauf eines Artikels mit hinterlegtem Pfand bucht die Pfand-Einheiten automatisch auf das Systemlager sysempties; Rücknahme (Pfand-Artikel mit negativer Menge) bucht gegenläufig, Storno dreht zurück
Pfandartikel je Gebinde
Ein Artikel verweist optional auf SEINEN Pfandartikel (Article.DepositArticleId); die automatische Pfandposition trägt dann dessen Namen, Steuersatz und — wenn am Gebinde kein Betrag steht — dessen Preis. Ohne Verweis gilt wie bisher art_pfand. Ein Getränkemarkt führt damit Kasten, Flasche und Fass getrennt
Pfand-Massenzuweisung je Warengruppe
Pfandartikel und Betrag für alle Artikel einer Warengruppe in einem Zug setzen, auf Wunsch samt Untergruppen; Pfand- und Systemartikel bleiben unberührt, gepflegte Ausnahmen lassen sich schützen
Pfandposition folgt dem Storno des Hauptartikels
Der Storno einer Tischposition nimmt ihre automatisch beigelegte Pfandposition mit (OpenBon.DepositForBonId); die Pfandzeile allein ist NICHT stornierbar (DEPOSIT_VOID_WITH_MAIN)
Lieferantenstamm
Lieferanten anlegen, pflegen, löschen (soft delete); Anschrift, Bestell-Mail, Kundennummer, Mindestbestellwert, Lieferzeit, Notizen, Bankverbindung (IBAN/BIC), Buchhaltung (Vorkontierung, USt-IdNr., Kreditorenkonto) und die zugeordneten Artikel — seit 07.09.2026 in einer Maske unter Admin → Lieferanten (Etappe W1)
Handelsumfang am Lieferanten
Reiter „Konditionen": Lieferantennummer, Zahlungsziel, Skonto (%/Tage), Freihaus-Grenze, Währung, Bewertung 1–5, Merkmale. Der Server blendet die sieben Felder ohne Modul aus und weist einen Request mit ihnen ab (MODULE_NOT_LICENSED)
Lieferantennummer LFR-0001
Fortlaufend, vom Server beim Speichern vergeben (nie aus dem Request). Bestandslieferanten bekommen ihre Nummer beim ersten Speichern; zwei gleichzeitige Anlagen ziehen zwei Nummern, und ein Zähler hinter dem Bestand wird einmalig nachgezogen
Gebinde je Lieferant am Artikel
Lieferanten-Artikelnummer, Gebindegrösse und Einkaufspreis pro Gebinde
Bestellungen beim Lieferanten
Bestellung anlegen, ändern, Status führen (Entwurf → Bestellt → Teilgeliefert → Geliefert → Abgeschlossen, jederzeit stornierbar). Der Zustandsautomat sitzt auf dem Server (StockOrderStatusAutomat): ein unzulässiger Wechsel antwortet 409 ORDER_STATUS_INVALID — und benennt, was möglich wäre. Geändert werden darf nur, solange die Bestellung den Lieferanten nicht erreicht hat | stock | Controllers/V1/ERP/StockOrdersController.cs, Domain/Services/StockOrderStatusAutomat.cs | Lagerverwaltung
Handelsumfang an der Bestellung
Bestellnummer, Steuersatz je Position, Versandkosten, interne Notiz und der Summenblock Netto/Steuer/Brutto. Der Server blendet die Felder ohne Modul aus und weist einen Request mit ihnen ab (MODULE_NOT_LICENSED) — gegated wird feldweise, nicht am Controller: Bestellwesen und Bestellvorschlag gehören zu Stufe 1
Bestellnummer BES-0001
Fortlaufend, vom Server beim Aufgeben vergeben — ein Entwurf hat keine (Regel C2). Beide Wege dorthin („Als bestellt markieren" und „An Lieferanten senden") rufen dieselbe Stelle, ein zweites Aufgeben zieht keine zweite Nummer; zwei gleichzeitige Aufgaben ziehen zwei, und ein Zähler hinter dem Bestand wird einmalig nachgezogen
Bestellsummen rechnet der Server
Positionswert, Netto (inkl. Versand), Steuer und Brutto entstehen an EINER Stelle und kaufmännisch (Geld.Runden, Regel C1) — 50 % von 2,01 € ergibt 1,01 €. Gerundet wird je Position, dann summiert. Kein Request trägt eine Summe, keinen Steuersatz und keine Bestellnummer (Regel B3); den Steuersatz zieht der Server aus dem Artikel
Bestellvorschlag
Bedarf aus Min/Soll, gruppiert je Lieferant, aufgerundet auf volle Gebinde
Bestellung per Mail senden
HTML-Bestellmail an den Lieferanten, Status springt auf „Bestellt". Mit wawi nennt sie die Bestellnummer in Betreff und Kopf und zeigt den Summenblock (Zwischensumme, Versand, Steuer, Brutto); ohne Steuer und ohne Versand bleibt es bei der einen Gesamtzeile wie bisher . Seit 07.09.2026 hängt zusätzlich das Bestell-PDF an (Zeile darunter)
Bestell-PDF für den Lieferanten
Vierte Belegart neben Rechnung, Angebot und Lieferschein: eigener Titel („Bestellung"/„Pedido"), Bestellnummer, gewünschter Liefertermin, unsere Kundennummer beim Lieferanten, Positionen mit Fremd-Artikelnummer, Gebinde, Menge und EK, Summenblock — ohne Bankverbindung und ohne Zahlungsziel (eine Bestellung ist keine Zahlungsaufforderung). Hängt an der Bestell-Mail und ist über GET /api/v1/stock-orders/{id}/pdf bzw. den Knopf „Bestell-PDF" im Bestellreiter abrufbar (Recht stock.view). Ohne Bestellnummer ein Entwurfs-Ausdruck. Wird jedes Mal neu gerendert und NICHT abgelegt — anders als Rechnung und Lieferschein: eine Bestellung ist ein Schreiben an einen Lieferanten, kein aufbewahrungspflichtiger Beleg
Wareneingang / Teillieferung
Gelieferte Gebinde erfassen, Restmengen bleiben offen, Ø-EK wird fortgeschrieben
Seriennummern erfassen
Für Positionen mit TrackSerials verlangt der Wareneingang genau eine Nummer je Bestandseinheit (Gebindefaktor zählt mit); es entsteht EINE Bestandsbuchung für die Menge und je Stück ein Gerätedokument mit Zustand „Auf Lager", Lieferant, EK und Garantieende. Eine falsche Anzahl wird abgewiesen (SERIAL_COUNT_MISMATCH), eine doppelte Nummer ebenfalls (SERIAL_DUPLICATE)
Interne Seriennummer DK-000001
Eigene fortlaufende Nummer des Hauses je Stück, vom Server beim Wareneingang vergeben; Präfix aus Betrieb → Lager (QrPrefix). Zwei gleichzeitige Erfassungen ziehen zwei Nummern, ein Zähler hinter dem Bestand wird einmalig nachgezogen
Garantieende je Stück
Wareneingang + DefaultWarrantyMonths (Vorgabe 24), danach am Stück überschreibbar. 0 Monate heißt „keine Garantie geführt" und ergibt kein Datum. Ob sie abgelaufen ist, rechnet der Server
Zustand eines Geräts
Auf Lager → reserviert → beim Kunden → Reklamation → beim Hersteller → zurück ins Lager → ausgebucht. Der Zustandsautomat sitzt an einer Stelle (SerializedItemZustand); ein unzulässiger Wechsel antwortet 409 SERIAL_STATUS_INVALID und nennt die möglichen Folgen. Jeder Wechsel, der die Lagerfrage ändert, bucht den Bestand mit — abgeleitet, nicht je Handler ausgeschrieben
Bestand und Stücke decken sich
Die Zahl der Stücke, die im Lager liegen (Auf Lager, reserviert, zurück), entspricht je (Artikel, Lagerort) der Bestandsmenge. Bewacht von SeriennummernBestandDeckungTests — der Test, der den Unterschied zum alten Warenwirtschafts-Pack ausmacht
Der Verkauf nimmt die Stücke mit
Wird ein seriennummerngeführter Artikel an der Kasse verkauft, wechseln so viele Stücke nach „Beim Kunden", wie Einheiten abgebucht wurden (FIFO, ältestes zuerst); der Storno holt sie zurück. Es wird dabei kein zweites Mal gebucht. Fehlen Stücke, läuft der Verkauf trotzdem und die Lücke steht als Warnung im Protokoll
Gerätereiter
Reiter „Geräte" im Lagerbereich: Liste mit Seriennummer, interner Nummer, Artikel, Lagerort, Kunde, Garantie und Zustand; Detail mit Verlauf, Zustandswechsel und Umlagern. Ohne Filter zeigt er, was im Lager liegt; eine eingegebene Seriennummer wird in jedem Zustand gesucht. Der Lagername kommt seit 07.09.2026 aus stock-labels.ts (übersetzte Systemlager-Namen an EINER Stelle) statt aus der um die Systemlager gekürzten Umlager-Liste
Seriennummer suchen
Genau eine Nummer über den Index byfield — kein Vollscan (der alte Pack lud bei jedem Barcode-Scan alle Nummern des Mandanten). Der Vergleich ist seit 07.09.2026 Groß-/kleinschreibungsUNABHAENGIG: die View-Map normalisiert ihren Schlüssel (n(doc.SerialNumber), ASCII-Großschreibung), SQL vergleicht über upper(). Gilt für SerializedItem und Claim. Umgebende Leerzeichen fallen weg
Geräte eines Kunden
„Welche Geräte hat dieser Kunde?" über den vorhandenen bycustomer-Index (das Gerät trägt IHasCustomerId) — ohne eigenen Index und ohne Reindex
Gerät umlagern / ausbuchen
Ein Stück in einen anderen Lagerort legen (mit Umbuchung) oder ausbuchen (Abgang nach syslost). Was nicht im Lager liegt, lässt sich nicht umlagern (SERIAL_NOT_IN_STOCK)
Seriennummer korrigieren
Tippfehler an der Herstellernummer, Regal/Fach, Garantie, Charge und Notiz nachträglich ändern — mit Dublettenprüfung und Verlaufseintrag. Zustand und Lagerort stehen bewusst nicht in diesem Weg
Lieferschein als Beleg
Eigener Belegtyp mit Nummer LS-0001, Zustandsautomat, PDF-Ablage am Dokument und Storno. Der Entwurf trägt keine Nummer — sie entsteht beim Ausstellen (Regel C2). Bis W4 gab es nur zwei ephemere Ausdrucke (zur Rechnung, zum Warenanteil einer Lizenzbestellung): nicht gespeichert, ohne Nummer, ohne Spur
Lieferschein ausstellen
Zieht die Nummer, setzt die Geräte auf „Beim Kunden", bucht den Bestand ab und legt das PDF am Beleg ab. Schlägt die Ablage fehl, wird nicht ausgestellt — sonst gäbe es lautlos einen Beleg mit Nummer, den niemand drucken kann. Es gibt bewusst keinen eigenen Ausstellen-Endpunkt: Ausstellen ist ein Zustandswechsel und läuft durch denselben Automaten
Lieferschein vormerken
Beim Anlegen wechseln die genannten Stücke auf „Reserviert". Der Bestand ändert sich dabei nicht — eine Vormerkung ist keine Abbuchung, das Gerät liegt weiter im Regal. Ein aus dem Entwurf entferntes Stück wird wieder frei
Lieferschein stornieren
Bucht die Zustände exakt zurück: die Stücke, die auf dem Beleg stehen, nicht ein Verhältnis. War der Beleg noch Entwurf, fällt nur die Vormerkung; war er ausgestellt, kommen die Geräte zurück ins Haus. Die Nummer bleibt am Beleg — sonst entstünde eine Lücke in der Serie
Lieferschein-PDF
Über den vorhandenen Druckweg (GenerateDeliveryNotePdfAsync + DeliveryNoteTemplate.xls), ohne Preise. Ein ausgestellter Beleg kommt byte-identisch aus der Ablage am Dokument, ein Entwurf als Vorschau ohne Nummer. Die Seriennummern stehen als Unterzeile in der Bezeichnung — die Vorlage hat nur zwei Spalten
Lieferschein per Mail
Beim Ausstellen optional an den Kunden, über die Outbox wie die Rechnung (nicht synchron per SMTP). Das Versanddatum setzt der Worker, wenn die Mail wirklich draussen ist — nicht der Handler beim Einreihen
Reiter „Lieferscheine"
Liste (ohne Filter die offenen), Detail mit Positionen und Seriennummern, Anlage mit Artikelauswahl und Scanfeld, Ausstellen, PDF, Storno mit Grund. Sichtbar mit dem Modul, Aktionen an stock.ship
Scanfeld für Seriennummern
Ein Bauteil für Wareneingang und Lieferschein: Eingabe oder Scan (Enter übernimmt), Dublettenprüfung, Anzahl gegen die erwartete Stückzahl mit Fehlzahl, und ein Bereich SN-001..SN-050 klappt aus. Es prüft nur — der Server weist weiterhin ab
Seriennummern im Wareneingang erfassen
Der Bestellreiter schickt die gescannten Nummern jetzt mit. Bis W4 tat er das nicht — ein Wareneingang für einen geführten Artikel war über die Oberfläche schlicht nicht buchbar, der Server antwortete SERIAL_COUNT_MISMATCH. Erwartet werden Bestandseinheiten, nicht Gebinde
Packtisch
Ein Packvorgang je Lieferschein: Sollliste, Großes Scanfeld, Fehlliste. Jeder Scan wird sofort gegen den Beleg geprüft — steht die Nummer nicht darauf, wird sie abgewiesen und benannt (PACKING_SERIAL_NOT_ON_NOTE). Der alte Pack lud bei jedem Scan alle Seriennummern des Mandanten und prüfte das gar nicht. Der Vorgang bucht nichts: der Bestand fällt beim Ausstellen (W4)
Packvorgang beginnen
Idempotent: läuft zu diesem Beleg schon einer, kommt genau der zurück (Regel C3). Zwei Vorgänge zum selben Beleg gäbe es nicht — sie wären zwei Wahrheiten darüber, was im Karton liegt. Nur ein noch änderbarer Beleg (Entwurf, gepackt) lässt sich packen
Mengenware abzählen
Für Positionen ohne Seriennummernführung gibt es nichts zu scannen — die Menge wird abgezählt und bestätigt, und zwar in einer eigenen Liste: ein Scan ist eine Maschinenlesung, eine Bestätigung eine Menschenaussage. Für geführte Artikel wird die Bestätigung abgewiesen (PACKING_SERIAL_REQUIRED)
Packvorgang abschließen
Setzt den Lieferschein auf „Gepackt" und übernimmt Packstücke, Gewicht und Stückzahl an den Beleg. Ein unvollständiger Karton wird abgewiesen (PACKING_INCOMPLETE) — mit Fehlliste im Klartext, damit der Packer weiß, wonach er sucht
Teillieferung mit Restlieferschein
Auf ausdrückliche Entscheidung: was fehlt, wandert auf einen neuen Entwurf ohne Nummer, der Beleg behält genau das, was im Karton liegt. Die Vormerkungen der fehlenden Stücke zeigen ab dann auf den Restbeleg; gebucht wird dabei nichts. Ein Teilversand ohne Ware wird abgewiesen — der Restbeleg wäre eine Kopie des Originals
Packvorgang abbrechen
Braucht einen Grund. Gibt keine Vormerkungen frei: die hält der Lieferschein, nicht der Packvorgang — der Beleg ist danach weiterhin ein gültiger Entwurf. Wer die Ware freigeben will, storniert den Beleg
Aufräumer liegengebliebener Packvorgänge
Ein offener Vorgang hält den Packtisch für seinen Beleg — bleibt er liegen, ist der Beleg dauerhaft blockiert, ohne dass etwas fehlschlägt. Nach 12 h ohne Bewegung wird er beendet, mit Marker AbortedByCleanup und Protokolleintrag. Er gibt keine Vormerkungen frei
Versand ohne Carrier
Der Wechsel auf „Versendet" läuft über IVersanddienst mit genau einer Umsetzung: ManuellerVersand. Sie erfindet keine Sendungsnummer, behauptet kein Label und meldet keinen Zustellstatus — der alte Pack erzeugte die Nummer mit new Random() im DHL-Format und meldete Erfolg. Der Beleg trägt danach ShippingProvider = "manuell"
Versand ohne Sendungsnummer
Geht nur mit Grund (DELIVERY_TRACKING_REQUIRED). Es gibt echte Fälle — Selbstabholung, eigener Fahrer, Kurier ohne Verfolgung —, und sie stumm zu erlauben hiesse, „hat keine" von „vergessen" nicht mehr unterscheiden zu können. Der Grund steht am Beleg und in der Kunden-Mail
Versandmeldung an den Kunden
Eine eigene Mail mit Dienstleister und Sendungsnummer, nicht die Belegmail: beim Ausstellen gibt es die Nummer noch nicht, beim Versand ist das PDF schon beim Kunden. Ohne Nummer nennt sie den Grund statt zu schweigen. Über die Outbox, Vorlage delivery_shipped
Reiter „Packtisch"
Liste der packbaren Belege, Großes Scanfeld mit Fokus (Enter übernimmt, der Fokus kehrt zurück), Sollliste mit Fehlliste je Zeile, Packstücke mit Gewicht und Massen, Abschluss und Teillieferung, Abbruch mit Grund. Touch-tauglich, Sichtbarkeit am Modul, Aktionen an stock.ship
Hardware-Lieferschein am Support-Ticket
Auf dem Lizenzserver: aus dem Warenanteil der Lizenzbestellung entsteht ein gespeicherter Beleg mit Nummer, verknüpft über SupportTicket.DeliveryNoteId. Ein zweiter Druck liefert denselben Beleg und dasselbe PDF (Regel C3) statt eine neue Nummer zu ziehen. Seit Etappe W8 baut dieser Weg den Beleg nicht mehr selbst — er stellt den Entwurf aus, der schon mit der bezahlten Bestellung entstanden ist
Ausstellen an EINER Stelle
Nummer, Lizenzkopplung, Stücke auf „Beim Kunden", PDF, Ablage — eine Routine, zwei berechtigte Aufrufer (Lager und Lizenzserver). Der Zustandsautomat wird in der Routine geprüft, damit kein Aufrufer daran vorbei ausstellen kann
Gerät trägt seine Lizenz
Beim Ausstellen bekommen die Stücke LicenseId, LicenseOrderId und OnlineName, sofern der Beleg zu einer Lizenzbestellung gehört. Nur auf dem Lizenzserver belegt; auf einer Kundeninstanz ist der Kopplungsdienst nicht registriert und die Felder bleiben leer — das ist dort die richtige Antwort, kein Fehler
Geräte einer Lizenz finden
GET /api/v1/serialized-items?licenseId=… über den byfield-Index. Auf dem Lizenzserver liegen die Geräte ALLER Kunden in EINER Datenbank — ohne Index wäre jede dieser Fragen ein Vollscan über den Gerätebestand des ganzen Hauses (Regel A3)
Reklamation / RMA-Vorgang
Eigener Typ mit Nummer RMA-0001, Zustandsautomat (gemeldet → eingegangen → geprüft → entschieden → abgeschlossen), Kommunikationsverlauf und Storno. Die Nummer entsteht beim Anlegen — der Vorgang IST die Ausstellung, es gibt keinen Entwurf, der eine Lücke hinterlassen könnte. Bis W6 gab es die Gerätezustände „In Reklamation"/„Beim Hersteller"/„Zurück", aber keinen Vorgang, der sie zusammenhält: keine Nummer, keinen Grund, keine Garantieaussage, keinen Entscheid
Reklamation anlegen aus der Seriennummer
Der Client nennt die Seriennummer und den Mangel — mehr weiß er auch nicht. Kunde, Artikel, Lieferant, Rechnung, Lieferschein, EK und die Garantieaussage zieht der Server aus dem Gerät (Regel B3). Ein Gerät hat höchstens EINEN offenen Vorgang (CLAIM_ALREADY_OPEN), sonst wäre einer von zweien unsichtbar — SerializedItem.ActiveClaimId zeigte auf einen davon
Garantieprüfung am Vorgang
Ob der Fall zum Meldezeitpunkt in Garantie war, rechnet der Server: Garantieende am Gerät, sonst Lieferdatum aus dem Lieferschein + WarehouseSettings.DefaultWarrantyMonths. Ohne beides ist die Antwort null = nicht feststellbar und NICHT false — ein false wäre eine Aussage, die niemand geprüft hat (Regel A2). Die Aussage ist ein Schnappschuss und ändert sich nicht, wenn jemand die Hausfrist später herunterdreht
Rückläufer annehmen
Der Übergang auf „eingegangen" setzt das Gerät auf „Zurück im Lager" und bucht damit zu — der Bestand steigt um 1. Optional in einen anderen Lagerort (Retourenlager). Die Buchung fällt aus dem W3-Zustandsautomaten an, sie wird nicht danebengeschrieben
Weg über den Hersteller
„Zum Hersteller schicken" bucht das Gerät wieder ab (es verlässt das Haus), die Rückkehr bucht es zu. RMA-Nummer des Lieferanten und Trackingnummer werden von Hand erfasst — es wird keine erfunden (Regel A2, Architektur-Entscheid E3)
Entscheid: Reparatur, Austausch, Gutschrift, Ablehnung
Eigener Endpunkt, weil ein Entscheid Betrag, Ersatzgerät und Bestandsfolge mitbringt. Der Zustand fällt aus dem Entscheid (ClaimZustand.ZustandZu) und wird nicht daneben mitgeschickt; der Zustandsweg weist Entscheide ab (CLAIM_RESOLUTION_ENDPOINT). Eine Ablehnung ohne Begründung wird abgewiesen, und aus einem Entscheid führt kein Weg in einen anderen
Austausch koppelt das neue Gerät an den Kunden
Das Ersatzgerät (über seine Seriennummer, es muss im Lager liegen) geht an den Kunden; das alte kommt je nach Entscheid in den freien Bestand oder wird ausgebucht — und wird dabei vom Kunden gelöst. Wächter: nach einem Austausch steht genau eine gekoppelte Seriennummer beim Kunden. Bliebe die alte hängen, antwortete „welche Geräte hat dieser Kunde?" mit zweien
Erstattung rechnet der Server
Bei einer Gutschrift kommt der Betrag aus der Rechnungsposition des Geräts — je Stück, einschließlich des rechnungsweiten Rabatts (der steckt NICHT in GroßAmount), kaufmännisch über Geld.Runden. Übergeben wird an den vorhandenen Gutschrift-Weg, es entsteht kein zweiter Mechanismus. Ohne Beleg wird der Entscheid ABGEWIESEN (CLAIM_REFUND_NO_POSITION) statt 0,00 EUR zu buchen
Kommunikationsverlauf
Eingehend, ausgehend oder interne Notiz — nur angehängt. Der Benutzer kommt vom Server, nicht aus dem Request; der Zustand des Vorgangs wandert mit in den Eintrag, damit hinterher sichtbar ist, wann welche Zusage fiel
Reiter „Reklamationen"
Liste (ohne Filter die laufenden Vorgänge), Suche nach Seriennummer, Detail mit Garantie und Verlauf, Zustandsknöpfe aus allowedNextStatuses, Entscheid aus allowedResolutions, Storno mit Grund. Sichtbar mit dem Modul, Aktionen an stock.claim. Die Maske trägt kein Betragsfeld
Set-Artikel („Kasse = Terminal + Drucker + TSE")
Haken „Set" am Artikel: die vorhandene Rezeptur wird damit zur Stückliste eines Bündels. Keine zweite Stücklisten-Entität — dieselbe rekursive, zyklensichere Auflösung über drei Ebenen wie die Gastro-Rezeptur. Ein Set ohne Komponenten wird abgewiesen (SET_WITHOUT_COMPONENTS)
Set führt keinen eigenen Bestand
Der Server schaltet TrackStock/TrackSerials am Set ab und liest überall Article.FührtEigenenBestand. Sonst stünden zwei Bestände für dieselbe Ware nebeneinander („3 Kassen" und „3 Terminals + 3 Drucker + 3 TSE"), und der Verkauf buchte beide ab
Set verkaufen bucht die Komponenten
Verkauf und Direktverkauf eines Sets senken den Bestand jeder Komponente um ihre Menge je Set; der Storno spiegelt das exakt. Es ist derselbe Weg, den die Rezeptur seit jeher geht
Set-Preis ist ein eigener Preis
Der VK des Sets ändert sich nie dadurch, dass eine Komponente teurer wird (Owner-Entscheid 07.09.2026). Die Komponentensumme steht in der Maske als Vorschlag mit Übernahme-Knopf — ein automatisch summierter Preis wäre eine Preisänderung ohne Entscheidung
Montierbare Sets
min(Bestand / Menge je Set), abgerundet — die Engstelle steht je Komponente daneben. Ist der Bestand auch nur einer Komponente unbekannt, lautet die Antwort „unbekannt", nicht 0 und nicht „beliebig viele". Gezählt werden nur Lager, die verfügbaren Bestand führen (StockService.FührtVerfügbarenBestand): sysmain, sysempties und jedes selbst angelegte Lager. Die Gegenkonten sysin/sysout/sysblackhole/syscook und der Schwund syslost bleiben draussen — eine Summe über ALLE Lager wäre wegen der doppelten Buchung strukturell 0 (07.09.2026 am laufenden System gemessen, Fix-Bericht 114)
Set auf dem Lieferschein
Die Set-Position trägt ihre Komponenten als Unterzeilen, jede mit ihrer eigenen Seriennummer — der Kunde kauft eine Kasse und bekommt drei gekoppelte Geräte. Ausstellen liefert alle drei, der Storno holt alle drei zurück. Artikel, Name und Menge der Unterzeilen kommen aus der Stückliste, nie aus dem Request
Lagerstatistik
GET /api/v1/stock-statistics?from=&to=: Bestandswert je Lager, Geräte je Zustand, offene Bestellungen/Lieferscheine/Reklamationen, Lieferungen und Reklamationen im Zeitraum, Einkaufsvolumen je Lieferant, Durchlaufzeit Bestellung → Wareneingang. Modulgate am Controller, stock.view im Handler
Kennzahlen kommen aus dem Index, nicht aus den Dokumenten
Die Zustandszahlen laufen über das _count-Reduce des bystatus-Views (CouchDB) bzw. ein COUNT() (SQL) — kein Gerät, kein Beleg, keine Reklamation wird dafür geladen (Regel A3). Neue Vertragsmethode CountByStatusAsync mit Default-Rückfall auf die gezählte Liste. Wächter: StatistikLädtNichtAllesTests verbietet GetAllAsync auf einem Bewegungstyp in der Auswertungsdatei — Quelltext-Wächter, weil ein Laufzeittest gegen InMemory immer grün wäre
Zwei Arten von Kennzahl in einer Antwort
Bestände (Bestandswert, Geräte, die drei offenen Zähler) sind Stichtagszahlen und bewegen sich nicht mit dem Zeitraum; Bewegungen (Lieferscheine, Reklamationen, Einkauf, Durchlaufzeit) liegen im Zeitraum. Die Maske trennt sie in zwei Blöcke — gemischt suchte der erste Anwender, warum „offene Bestellungen" im Januar dieselbe Zahl zeigt wie im Juni
Durchlaufzeit Bestellung → Wareneingang
Vom Aufgeben (StockOrder.OrderedAt) bis zum ERSTEN Wareneingang (ReceivedAt, Teillieferung zählt); beide Zeitstempel idempotent und bewusst NICHT modulgegatet (ein Zeitpunkt ist eine Tatsache). Ausgewiesen werden Mittelwert und Median und die Grundmenge. Ohne messbare Bestellung ist die Antwort null, nicht 0 — die fehlende Grundmenge machte den Lagerumschlag des alten Packs überall zu 0, und 0 sah aus wie eine Zahl
Offene Bestellungen indiziert
StockOrder2/StockOrder stehen seit Etappe W9 in bystatus (v6). Damit laufen die Bestellliste UND die Kennzahl über den Index; der LadeAlles-Deckel fiel von 1 auf 0. Welche Zustände offen sind, sagt StockOrderStatusAutomat.Offene — abgeleitet aus IstEndzustand, keine zweite Aufzählung
Reiter „Statistik"
Zeitraumleiste mit drei Schnellwahlen, Kachelblock „Aktueller Stand", Kachelblock „Im gewählten Zeitraum", Tabellen für Bestandswert je Lager, Geräte je Zustand, Einkauf je Lieferant. Sichtbar am Modul, Zahlen und Zustandsklartexte vom Server
Inventur (Zählliste)
Inventur starten, zählen, abschließen oder abbrechen; Differenzen als Korrektur
Barcode-Suche in der Zählliste
Artikel per EAN-Scan oder Artikelnummer in der Inventur finden
Lagerbericht
Bestandswert, Verkauf, Zugang, Verlust je Grund, Korrektur und Wareneinsatz je Lager
Lager an der Kasse
Kachel „Lager": Theken-Bestand, Anforderung, Bruch/Verlust, Wareneingang bestätigen
Restmengen-/Ausverkauft-Badge auf Kassen-Kacheln
Bestand <= 0 markiert die Kachel als „Ausverkauft" (Direktverkauf + Tischansicht); der Verkauf wird nie blockiert, nach Buchung wird optimistisch dekrementiert — nur mit stock.view sichtbar. Davon getrennt: der manuelle „86-Knopf" am Küchenmonitor (02) sperrt die Kachel wirklich und sticht dieses Badge in der Anzeige
Lager-Berechtigungen
stock.view/book/inventory/order/admin/serial/ship/claim, Sammelrecht stock.manage. stock.serial (Etappe W3) trägt Ändern, Umlagern, Ausbuchen und Zuordnen eines Geräts — das Erfassen beim Wareneingang fällt unter stock.book. stock.ship (Etappe W4/W5) trägt Lieferschein anlegen, ausstellen, stornieren und packen und versenden: bewusst NICHT stock.order (wer beim Lieferanten bestellt, entscheidet nicht über das, was das Haus verlässt) und bewusst nicht stock.serial (ein Versandmitarbeiter soll deshalb nicht auch einzelne Geräte ausbuchen). stock.claim (Etappe W6) trägt Reklamation anlegen, führen und entscheiden — eigenes Recht, weil der Entscheid eine Gutschrift auslösen und damit eine offene Forderung tilgen kann; das ist die folgenreichste Aktion des Lagerbereichs. Einkaufspreis und Lieferant sieht nur stock.admin/stock.manage, am Gerät wie am Vorgang. Zufallsfund W9 (07.09.2026): stock.claim hatte KEIN Häkchen in der Personalmaske. W6 führte das Recht im Handler ein, staff.component.ts bekam es nie — es war damit nur über stock.manage oder eine Admin-Rolle zu bekommen, also gar nicht einzeln vergebbar. Ein Recht ohne Schalter ist ein totes Recht (Regel B2), und niemand sieht es der Maske an. Nachgetragen samt Beschriftung in allen sechs Sprachen
HACCP-Vorlagen
Checklisten definieren: Kategorie, Frequenz, Prüfpunkte, Sortierung
Fünf Prüfpunkt-Typen
Temperatur, Ja/Nein, Text, Zahl, Foto — je mit Einheit und Grenzwerten
Grenzwerte und Warnbereiche
MinValue/MaxValue als harte Grenze, WarnMinValue/WarnMaxValue als Vorwarnung
Prüfung durchführen (Kasse)
Checkliste auswählen, Werte erfassen, abschließen — mit digitaler Signatur
Fälligkeits-Badge im Kassenmenü
Zähler auf der HACCP-Kachel zeigt fällige Prüfungen; nur bei aktivem Modul sichtbar
Foto-Nachweis
Foto zu einem Prüfpunkt hochladen und wieder abrufen. Das Dateifeld trägt bewusst kein capture: mit capture erzwingt ein Telefon die Kamera und ein Rechner bekäme gar keine Auswahl — ohne bietet das Telefon Kamera UND Galerie, der Rechner den Dateidialog (Owner 25.08.2026)
HACCP-Protokoll als PDF
Gezeichnet mit QuestPDF (seit 25.08.2026, vorher ein gedrucktes FlexCel-Tabellenblatt): verhältnismässige Spaltenbreiten, eingebettete Fotos, Unterschriftsblock immer am Ende, Seitenzahl im Fuss. Das Excel bleibt FlexCel
NFC-Tag per Kartenleser erfassen
Im Vorlagen-Editor „Tag scannen": Tag an den Leser halten, die Kennung wird eingetragen. Zielgerichtet je Prüfpunkt (eine Vorlage hat viele) — ein dauerhaft mitlaufender Leser wüsste nicht, in welche Zeile die Kennung gehört
Freigabe durch Verantwortliche
Abgeschlossenes Protokoll wird vom Schichtleiter gegengezeichnet
Protokoll-Archiv
Alle Protokolle einsehen, filtern, Abweichungen erkennen
Protokoll als PDF / Excel
Revisionssichere Ausgabe eines Protokolls für die Kontrolle
HACCP-Kennzahlen
Übersichtskacheln: erledigt, offen, überfällig, Abweichungen
Frequenz „Alle 2 Stunden"
Vierte Frequenz neben täglich/wöchentlich/monatlich — der Rundgang einer Gästetoilette. Periode = volles Zwei-Stunden-Fenster
Vorlagenpaket „Reinigung"
Knopf legt Gästetoilette (alle 2 h), Reinigungsplan Küche (Tagesplan) und Wochenrunde an; vorhandene Namen werden übersprungen statt überschrieben
Bereichsfilter der Checklisten
Vorlagenliste (Admin) und Kachelliste (Kasse) nach Kategorie filtern, damit Reinigungs-Checks nicht zwischen den Temperatur-Checks hängen
NFC-Tag am Prüfpunkt
Optionale Tag-Kennung je Prüfpunkt, normalisiert über CardIdNormalizer
Quittierung per aufgelegtem Tag
Karte an Kasse/Handheld auflegen → öffnet den fälligen Check und springt auf dessen Prüfpunkt; ein offenes Protokoll wird fortgesetzt
Aushang-QR „zuletzt gereinigt"
Öffentliche Mini-Ansicht /clean/{token} mit Bezeichnung und Uhrzeit — ohne Namen und ohne interne Ids
Aushang-Schild ausstellen und drucken
Token je Prüfpunkt ausstellen (beliebig oft nachdruckbar) oder neu vergeben; druckfertiges Blatt mit QR in neuem Tab
Stabile Prüfpunkt-Kennung
Jeder Prüfpunkt trägt eine eigene Kennung (hi_…), unabhängig von Titel und Position; Protokolleinträge verweisen darauf. Trägt der Aushang-Token und die Historie über Umbenennungen hinweg
Zwei-Stunden-Takt folgt den Öffnungszeiten
Sind Öffnungszeiten gepflegt, laufen die Zwei-Stunden-Fenster nur während der Öffnung; nachts und an Ruhetagen steht die Periode still. Ohne gepflegte Zeiten Takt rund um die Uhr wie bisher — kein eigener Konfigurationsdialog
Mengenbegrenzung des Aushangs
Eigene Politik aushang (60 Anfragen/min/IP) für die anonyme Gäste-Seite, deren Adresse gedruckt an der Wand hängt
Kein Treffer in diesem Bereich. Gesamte Website durchsuchen
Oft gesucht
Begriffe rund um Lager & HACCP
LagerLagerverwaltungWarenwirtschaftBestandLagerbestandLagerortHauptlagerThekeInventurZähllisteWareneingangLieferungTeillieferungBestellungBestellvorschlagNachbestellungLieferantDistributor
Weiterstöbern