Erfasse Shopify-Bestellungen trotz Fehlbestand

docs/modules/erp/bestellungen/processes/sub_processes/erp.bestellungen.shopify_order_projection.md

@@ -24,8 +24,8 @@ Keine vorbereiteten Kunden-, Adress-, Positions- oder Shopify-Rohdaten werden ü
 3. Vorhandene `sales_order.shopify_order_gid` idempotent prüfen.
 4. Shopify-Customer-GID über `party_external_identity` auflösen oder einen Kontakt über die definierte Kontaktschnittstelle anlegen und die externe Identität speichern.
 5. Jede Position ausschliesslich über den Shopify-Varianten-/SKU-Alias des Artikel-Mappings auf ein `sellable_item` auflösen.
-6. Bei `dry_run` nur Mapping, Mengen und verfügbaren Chargenbestand prüfen.
-7. Bei Echtlauf Bestellkopf und -positionen schreiben und jede Position genau einmal über die Lagerschnittstelle allokieren.
+6. Bei `dry_run` nur Mapping und Mengen prüfen; fehlender Bestand ist kein Grund, die Bestellung zu verwerfen.
+7. Bei Echtlauf Bestellkopf und -positionen schreiben und jede Position genau einmal über die Lagerschnittstelle allokieren. Reale Bestände werden als `allocated` mit Lagerbewegung zugewiesen; Fehlmengen als `reserved` auf einer virtuellen Fehlbestandscharge ohne Lagerbewegung.
 8. Shopify-Varianten- und Produkt-GIDs beim bereits bestätigten Shopify-Alias speichern.
 9. Keine Shopify-Mutation und keine externe Kommunikation ausführen. Die anschliessende n8n-Auslösung gehört zum owning Delta-Prozess.
 
@@ -42,7 +42,7 @@ Write targets:
 - `party`, `address`, `party_external_identity`
 - `sales_order`, `sales_order_line`
 - `external_item_alias` nur für fehlende Shopify-GIDs eines bereits bestätigten SKU-Alias
-- `sales_order_line_lot_allocation`, `stock_move` ausschliesslich über die Lagerschnittstelle
+- `sales_order_line_lot_allocation`, `stock_lot`, `stock_move` ausschliesslich über die Lagerschnittstelle
 
 ## 5. Batch, Betriebsmodell und Einbettung
 
@@ -57,12 +57,13 @@ Kompaktes Projektionsergebnis mit Status, ERP-Bestell-ID, Positionen und Allokat
 - eine Shopify Order-GID führt zu höchstens einer ERP-Bestellung
 - jede Position ist eindeutig gemappt
 - die Chargenallokation entspricht den `sellable_item_component`-Mengen
+- jede Fehlmenge ist einer virtuellen, nicht bestandswirksamen Charge zugewiesen
 - `dry_run` schreibt keine fachlichen Daten
 - bestehende ERP-Bestellungen und ihre Chargenrelationen bleiben unverändert
 
 ## 8. Fehlerschranke
 
-Ein fehlender Alias, unzureichender Lagerbestand oder ungültige Shopify-Daten ist ein fachlicher Klärfall und erzeugt keine Teilbestellung. Technische DB- oder Shopify-Fehler schlagen hart fehl.
+Ein fehlender Alias oder ungültige Shopify-Daten ist ein fachlicher Klärfall und erzeugt keine Teilbestellung. Fehlender Bestand erzeugt eine virtuelle `reserved`-Allokation und keinen Lagerabbruch. Technische DB- oder Shopify-Fehler schlagen hart fehl.
 
 ## 9. Fachliche Betriebsregel
 
@@ -102,6 +103,7 @@ Nicht anwendbar.
   "sales_order_id": 0,
   "line_count": 0,
   "allocation_count": 0,
+  "virtual_allocation_count": 0,
   "clarification_reasons": []
 }
 ```