Stock-Anpassungen
Stock-Anpassungen erfassen Bestandsveränderungen außerhalb des normalen Verkaufs und Wareneingangs – etwa bei abgelaufener oder beschädigter Ware.
Wofür gibt es Stock-Anpassungen?
Nicht jede Bestandsänderung entsteht durch einen Verkauf oder einen Wareneingang. Ware kann zum Beispiel ablaufen, zerbrechen oder aus einem anderen Grund nicht mehr verfügbar sein. Solche Fälle werden als Stock-Anpassung erfasst: Die betroffene Menge wird vom Bestand abgezogen. Wenn eine frühere Änderung rückgängig gemacht werden muss, kann die Menge wieder zugebucht werden.
Beispiel: Abgelaufene oder zerbrochene Ware verringert den verfügbaren Bestand.
Eine entsprechende Menge wird wieder zum Bestand hinzugefügt.
Technischer Eingang
Datei im Unterordner bereitstellen
Die Stock-Anpassungen werden über den Unterordner Stockanpassungen bereitgestellt. Wie beim Bestandsabgleich kommt die Datei von DACHSER.
Regelmäßig einlesen
Ein Cronjob prüft den Unterordner alle zehn Minuten auf neue Dateien und liest neue Meldungen zur Verarbeitung ein.
XML-Positionen auswerten
Die XML-Datei enthält pro Position unter anderem Artikelnummer, Batchnummer und Menge. Die Bewegungsrichtung wird über VoucherType bestimmt: 171 bedeutet Zugang, 431 bedeutet Abgang. Das gezeigte Beispiel enthält 431 und ist damit eine Abbuchung. Quantity Code="OUT" steht ebenfalls in diesem Beispiel.
Intern speichern
Die Stock-Anpassungen werden zunächst in der Datenbank von tbs.erp gespeichert. Eine direkte Übergabe an weclapp erfolgt beim Einlesen der XML-Datei nicht.
Gesammelt an weclapp übertragen
Die intern gespeicherten Anpassungen werden anschließend gesammelt an weclapp übergeben. Die Datenbank hält dazu unter anderem Status und Buchungszeitpunkt fest; die genaue Übertragungslogik wird noch dokumentiert.
Beispiel einer DACHSER-XML
Das folgende Beispiel zeigt einen Abgang, weil VoucherType den Wert 431 hat. Die Detailposition enthält die Artikelnummer 1031243, die Batchnummer XYN08AG und Quantity Code="OUT" mit der Menge 12.000.
<?xml version="1.0" encoding="UTF-8"?>
<OutboundMovement>
<DocumentHeader>
<EDISender>
<PartnerInformation>
<PartnerGLN>4023083000008</PartnerGLN>
</PartnerInformation>
</EDISender>
<EDIReceiver>
<PartnerInformation>
<PartnerID>47195745</PartnerID>
</PartnerInformation>
</EDIReceiver>
<DocumentID>79070-00007063806</DocumentID>
<DocumentDate>
<Date>2026-01-12T13:46:13</Date>
</DocumentDate>
</DocumentHeader>
<GoodsMvtOutboundHeader DachserOutboundNumber="00007063806">
<GoodsMvtOutboundHeaderContent>
<Branch>
<PartnerInformation>
<PartnerID>00000183</PartnerID>
</PartnerInformation>
</Branch>
<Customer>
<PartnerInformation>
<PartnerID>47195745</PartnerID>
</PartnerInformation>
</Customer>
<Consignee>
<PartnerInformation/>
</Consignee>
<VoucherType>431</VoucherType>
<AdditionalReference Qualifier="CT">
<ReferenceValue>00007063806</ReferenceValue>
</AdditionalReference>
<AdditionalReference Qualifier="DQ">
<ReferenceValue>L</ReferenceValue>
</AdditionalReference>
<AdditionalReference Qualifier="ON">
<ReferenceValue>L</ReferenceValue>
</AdditionalReference>
</GoodsMvtOutboundHeaderContent>
<GoodsMvtOutboundDetail ArticleNumber="1031243">
<GoodsMvtOutboundDetailDate Code="BOOK">2026-01-12T00:00:00</GoodsMvtOutboundDetailDate>
<GoodsMvtOutboundDetailDate Code="BBD">2028-10-31T00:00:00</GoodsMvtOutboundDetailDate>
<SSCC>00940221279057313870</SSCC>
<Quantity Code="OUT">12.000</Quantity>
<BatchNumber>XYN08AG</BatchNumber>
</GoodsMvtOutboundDetail>
</GoodsMvtOutboundHeader>
</OutboundMovement>DocumentID identifiziert die Meldung; DocumentDate enthält deren Datum. DachserOutboundNumber bezeichnet die ausgehende Bewegung.
ArticleNumber ist die Artikelnummer/SKU, BatchNumber die Charge und Quantity die gemeldete Menge samt Richtungscode.
BOOK ist das Buchungsdatum, BBD das Mindesthaltbarkeitsdatum und SSCC die Kennung der logistischen Einheit.
VoucherType 171 = Zugang (Bestand erhöhen); VoucherType 431 = Abgang (Bestand verringern). Im XML-Beispiel steht 431.
Interne Datenbankstruktur
Vor der gesammelten Übergabe an weclapp wird jede Stock-Anpassung als Datensatz in der tbs.erp-Datenbank abgelegt. Der Grund wird über fk_stock_anpassung_grund_id referenziert; im gezeigten XML-Beispiel ist kein eindeutiges Grund-Feld zu erkennen. Wie dieser Fremdschlüssel aus der Meldung bestimmt wird, ist noch zu klären.
| Feld | Typ laut Screenshot | Bedeutung |
|---|---|---|
| id | int(11) | Interne ID |
| fk_stock_anpassung_grund_id | int(11) | Verweis auf den Anpassungsgrund |
| erstellt_am | datetime | Erstellungszeitpunkt |
| importiert_am | datetime | Importzeitpunkt |
| filename | varchar(100) | Dateiname |
| dokument_id | varchar(100) | Dokumentkennung |
| artikel_id | varchar(255) | Artikelkennung |
| sku | varchar(255) | SKU |
| anzahl | int(11) | Menge |
| art | enum | Zugang oder Abgang |
| batch_nummer | varchar(255) | Batchnummer |
| verfallsdatum | date | Verfallsdatum |
| gebucht_am | datetime | Buchungszeitpunkt |
| status | enum | Verarbeitungsstatus |
Im Screenshot sind bei art die Werte zugang und abgang erkennbar. Bei status ist offen lesbar; die übrigen ENUM-Werte sind abgeschnitten.