Lager-/Lagerort
Ihr Leitfaden zur V5-Integration!
Die Integration von Inventar/Lagerort zwischen V5 Traceability und dem ERP-System eines Kunden ermöglicht dies Ware Bestandsdetails wie Chargennummern, verfügbare Mengen und Standorte, die an V5 Traceability gesendet werden sollen. Diese Angaben ermöglichen dann die Verwendung dieser Waren für die Produktion/Bestellung usw.
Abhängig von unserem ERP-Setup gibt es verschiedene Möglichkeiten, wie wir mit Lagerbeständen umgehen können:
- ERP als Lagerstamm: Hier würde das ERP Bestandsdaten in V5 einspeisen und dann würde V5 Anpassungen/Verbrauch/Produktion usw. zurückgeben. (am häufigsten) (Einlagerung, Abmeldung). Dies kann auf zwei Arten erfolgen; Der aktualisierte Bestandswert aus dem Protokoll (Los 2 beträgt jetzt 123 LB); Oder Sie schauen sich den Anpassungswert im Protokoll an (Lot50 -123LBS). Die erste Option hält die Dinge synchroner, birgt jedoch ein höheres Risiko, dass eine Transaktion verpasst wird.
- V5 als Lagerstamm: V5 leitet Bestandsdaten an das ERP weiter. Das ERP gibt dann in regelmäßigen Abständen aktualisierte Lagerbestände zurück. (Vorrat aus, Vorrat ein)
- ERP als Lagerstamm: Das ERP füttert den V5-Bestand, dann gibt V5 regelmäßig die Lagerbestände zurück und das ERP aktualisiert seinen Bestand. Dies ist von Vorteil, da ERP und V5 immer synchronisiert werden. Dies kann jedoch aufgrund des Zeitpunkts und der Häufigkeit der Synchronisierung problematisch sein, insbesondere wenn Bestände im ERP selbst abgezogen werden können, können diese angepassten Bestände bei der nächsten V5-Synchronisierung überschrieben werden. Diese Methode kann nützlich sein, wenn das ERP/MRP den Lagerbestand nicht direkt anpasst, sondern ihn lediglich für Finanzdaten bereithält. (Lagerbestand, Lagerbestand)
Wenn Sie sich nicht sicher sind, welchen Weg Sie für Ihr spezielles ERP-Setup am besten einschlagen sollen, kann SG Systems eine Beratungssitzung vereinbaren, um die optimale Methodik für Ihr System bestmöglich zu beurteilen.
Inhaltsverzeichnis
1. Layout des Kontrollzentrums
Im Hinblick darauf, wie wir Lagerbestands-/Lagerstandortdetails mit dem verknüpfen können, was wir im Control Center sehen, werden wir diesen Endpunkt hauptsächlich dazu verwenden, das untere linke Feld zu füllen, um unsere Lagerbestände/Lagerstandorte für vorhandene Waren zu importieren und zu exportieren.
Mit dem V5-Gateway können wir die Daten hier einfach über zwei Endpunkte füllen: ‘Stock’ , ‘StockLocation’.
2. API-Links
Weitere Informationen zu den Definitionen dieser Datenbankklassen finden Sie unter den folgenden Links:
3. Integrationsvorlage
Die Integrationsvorlage für Stock Location kann heruntergeladen werden hier.
4. StockLocation-Feldführer
4.1. Primärschlüssel
Primärschlüssel sind die eindeutige Kennung für jede Tabelle innerhalb der V5-API. Für StockLocation, diese sind:
location.code – Der eindeutige Identifikationscode für die Lagerort.
stock.commodity.code – Der eindeutige Identifikationscode für die Ware
stock.lotNo – Die Chargennummer des Bestands.
Für Stock, die Primärschlüssel sind:
lotNo – Die Chargennummer des Bestands.
commodity.code – Der eindeutige Identifikationscode für die Ware.
Beachten Sie, dass Chargennummern automatisch vom System generiert oder manuell eingegeben werden können. Lieferantenchargennummern können über das unten beschriebene Feld eingegeben werden. Chargennummern können global (keine zwei Chargennummern dürfen gleich sein) oder pro Ware generiert werden.
4.2. Benötigte Felder
Weitere Felder, die von SG zum Ausfüllen einer gültigen Warenzeile im V5 Control Center benötigt werden, sind:
stock.expiry – Das Ablaufdatum der jeweiligen Charge.
qty – Die Menge der Ware in dieser Charge.
4.3. Bevorzugte Felder
Bevorzugte Felder dienen dazu, weitere Informationen zu der betreffenden Ware hinzuzufügen. Sie sind zwar nicht erforderlich, aber nützlich, wenn es um zusätzliche Funktionen in V5 Traceability geht.
stock.supplier.code - Der Code des Lieferanten, der die Warencharge bereitgestellt hat.
stock.cost - Die Kosten (pro UoM) der Ware.
stock.dateReceived - Das Datum, an dem die Charge in den Bestand gebucht wurde.
stock.supplierLotNo - Die vom Lieferanten zugewiesene Chargennummer.
4.4. Weitere Felder
Es können auch zusätzliche Felder eingebunden werden, wie zum Beispiel:
stock.commodity.description - Die Beschreibung der Ware.
stock.commodity.units.code - Die Standard-ME der Ware.
stock.commodity.recordStock – Ob die Verwendung dieser Ware mit V5 Traceability verfolgt wird.
Beachten Sie, dass diese zusätzlichen Felder zum Erstellen von Wareneinträgen in V5 Traceability sowie zum Zuweisen von Lagerorten und -mengen verwendet werden können. Bei Verwendung des CSV-Methode Für den Datenaustausch müssen wir sicherstellen, dass im „Gateway“ des Control Centers „Untergeordnete Entitäten erstellen“ ausgewählt ist. Vorhandene Waren können jedoch nicht im aktualisiert werden V5-API Wenn wir diesen Endpunkt verwenden, müssen wir diese stattdessen direkt mit dem ' ansprechen.Ware' Endpunkt stattdessen.
5. Methodik
Abhängig vom Zweck unserer API-Integration können wir davon Gebrauch machen ‘StockLocation’ or ‘Stock’ Endpunkt für JSON- und CSV-Importe und -Exporte. Das können wir uns nun unten ansehen.
5.1. JSON – Importieren
StockLocation:
Wir können das nutzen ‘StockLocation’ Endpunkt zum Einfügen von Bestandsaufzeichnungen für Waren (vorhanden oder nicht) in V5 Traceability, die Informationen zu Empfangs-/Ablaufdaten, Los-/Lieferanten-Losnummern und natürlich zum Lagerort enthalten.
‘StockLocation’ Endpunkt/URI importieren –
http://host:port/V5-API/api/integrate/import/stock_location
Für diesen Beispielimport mit der ‘StockLocation’ Endpunkt können wir eine grundlegende Importdatei für ein einzelnes Los wie folgt strukturieren:
Diese JSON-Beispieldatei kann heruntergeladen werden werden auf dieser Seite erläutert.
Anhand des API-Handbuchs können wir hier sehen, dass wir nur das verwenden ‘qty’ Wert von der ‘StockLocation’ Klasse, wobei alle anderen Werte unter einer der beiden verschachtelt sind ‘stock’ or ‘location’ Klasse. Wir können auch sehen, dass die ‘code’ , ‘units’ Datenpunkte werden weiter unter verschachtelt ‘commodity’ Klasse.
Nachfolgend finden Sie eine Zusammenfassung dieses Datenflussprozesses:
Wenn wir die JSON-Datei oben ausführen, sehen wir, dass es sich um eine Ware handelt ‘I015’ (Jalepenos) Jetzt wurde dieses Los in das Control Center importiert.
Allerdings können wir damit nichts anfangen ‘StockLocation’ Endpunkt sind Änderungswerte wie die Chargennummer des Lieferanten und das Ablaufdatum des vorhandenen Lagerbestands. Dazu müssten wir die verwenden ‘Stock’ Endpunkt.
Lager:
Wie oben erwähnt, die ‘StockLocation’ Der Endpunkt kann zum Einfügen von Bestandsdatensätzen und den zugehörigen Standorten verwendet werden. Wenn wir jedoch die Details zu diesen Losen aktualisieren möchten, die unter die fallen ‘Stock’ Header müssen wir verwenden ‘Stock’ Endpunkt. Dazu gehören Details wie die Chargennummer des Lieferanten, das Verfallsdatum und das erhaltene Gewicht.
‘Stock’ Endpunkt/URI importieren –
http://host:port/V5-API/api/integrate/import/stock
Für ein sehr einfaches ‘Stock’ Importdatei, die das Verfallsdatum und die Chargennummer des Lieferanten der oben erstellten Charge aktualisiert, können wir Folgendes verwenden:
Dies führt dazu, dass die Chargeninformationen in V5 aktualisiert werden:
5.2. JSON – Exportieren
Im Hinblick auf den Empfang von Dateien, die sich auf Lagerbestandsstandorte beziehen, von der V5-API, wenn wir die Methodenzusammenfassungen unter überprüfen IntegrationExport Klasse, das denken wir vielleicht ‘StockLocations’ (export/locations/stock) wäre das, wonach wir suchen. Dies ist jedoch nicht der Fall, da dieser Endpunkt eine Liste der im System vorhandenen Lagerstandorte (im Vergleich zu Produktionsstandorten) exportiert.
Um Standort- und Lagerbestandsinformationen für unsere Waren zu erhalten, können wir Folgendes verwenden:
Einzelne Ware + Chargenbestand:
Endpunkt/URI exportieren –
http://host:port/V5-API/api/integrate/export/stock/{commodityCode}/{lotNumber}
Dieser Endpunkt exportiert eine JSON-Datei mit allen zugehörigen Informationen für die angegebene Charge einer einzelnen Ware. Wenn wir diese Anfrage mit den gerade importierten Chargeninformationen ausführen, erhalten wir eine Datei, die etwa so aussieht:
Beispiel-JSON-Dateien dieses Typs können heruntergeladen werden werden auf dieser Seite erläutert.
Alle Lagerbestände:
Endpunkt/URI exportieren –
http://host:port/V5-API/api/integrate/export/stock/{all}
Dieser Endpunkt exportiert eine JSON-Datei, die eine Liste aller zugehörigen Informationen für alle Chargen aller Waren im System enthält, abhängig vom Wert des Felds {all}. Wenn das ist ‘true’ dann ziehen wir alle Lagerbestände ab, während wenn ‘false’ dann erhalten wir lediglich eine Rückgabe für neue Lagerartikel (also viele Waren, die nicht als bereits exportiert gekennzeichnet sind).
Wenn wir diese Anfrage ausführen als ‘true’ (damit http://host:port/V5-API/api/integrate/export/stock/true) , erhalten wir eine Datei, die etwa so aussieht:
Beispiel-JSON-Dateien dieses Typs können heruntergeladen werden werden auf dieser Seite erläutert.
Die oben genannten Endpunkte liefern nur die aktuellen Lagerbestände. Was aber, wenn wir unsere Lagerbestände während der Produktion verfolgen möchten? Hier haben wir verschiedene Möglichkeiten, je nachdem, wie wir die API verwenden und in ein ERP-System integrieren.
Wir können auch eine Vielzahl von verwenden Transaktions- und Protokollendpunkte um relevantere Informationen über Bestandsänderungen abzurufen.
Für Systemprotokoll Endpunkte sind dies:
Verbrauchte/produzierte Systemprotokolle
Für Transaktional/Generisch Endpunkte sind dies:
5.3. CSV – Importieren
Dateiname der Kopf-/Spaltendefinition: “stockLocation.csvh”
Fertige Header-Dateien sollten abgelegt werden in: “<installdir>\SG Control Center\gateway\import\column_defs”
CSV-Dateiname importieren: “stockLocation-datetime.csv”
CSVs für den Import sollten abgelegt werden in: “<installdir>\SG Control Center\gateway\import”
Header-Datei:
Header-Dateien werden im Allgemeinen von SG Systems kompiliert, bevor CSV-Integrationen stattfinden. Wir sehen jedoch ein einfaches Beispiel für eine Datei, die wir für Inventar/Lager verwenden können, indem wir die zuvor definierten Dateien verwenden Klassendefinitionenunten:
Weitere Informationen zur Strukturierung dieser Dateien finden Sie im Hauptintegrationsseite. Diese Beispiel-Header-Datei kann heruntergeladen werden werden auf dieser Seite erläutert.
CSV-Importdatei:
Anschließend können wir die definierte Reihenfolge der Datenpunkte im Header verwenden, um unsere Importdatei zu strukturieren. SG Systems kann hierfür eine Vorlagendatei bereitstellen, die den Datenpunkt für jede Spalte auflistet, um die Dinge beim Ausfüllen der Liste klarer zu gestalten. Beachten Sie, dass diese erste Zeile vom Control Center ignoriert werden kann und daher bei der Übermittlung zum Import in der Datei beibehalten werden kann.
Eine Beispiel-CSV-Importdatei könnte etwa so aussehen:
Hier sehen wir, dass wir 3 neue Chargen von 2 verschiedenen Lieferanten importieren. Diese Beispielimportdatei kann heruntergeladen werden werden auf dieser Seite erläutert.
Nachdem der Import abgeschlossen ist, können wir sehen, dass diese zusätzlichen Jalapeno-Lots zum Control Center hinzugefügt wurden. Beachten Sie hier den Unterschied zwischen ‘Qty’ (zur Hand) und ‘Stock_WeightReceived’ in unserer Import-CSV.
5.4. CSV – Exportieren
Wie bei JSON-Exporten haben wir hier verschiedene Möglichkeiten:
StockLocation:
Wenn wir Waren mit dieser Methode exportieren, können wir denselben Endpunkt verwenden Klassendefinitionen wie wir es für Importe getan haben.
Dateiname der Kopf-/Spaltendefinition: “stockLocation.csvh”
Fertige Header-Dateien sollten abgelegt werden in: “<installdir>\SG Control Center\gateway\export\order”
CSV-Dateiname exportieren: “StockLocation-datetime.csv”
CSVs für Exporte werden generiert in: “<installdir>\SG Control Center\gateway\export”
Dieser Export müsste auch im Gateway-Bereich des Control Centers aktiviert werden. Wir können hier den Export auswählen ‘Stock’ .
Header-Datei:
Von hier aus wäre es ein einfacher Fall, unsere Export-Header-Datei so zu strukturieren, dass sie den Informationen entspricht, die wir vom System zurückerhalten möchten.
Wir könnten es auf eine sehr ähnliche Weise strukturieren, wie wir den Import-Header strukturiert haben:
Diese Beispiel-Header-Datei kann heruntergeladen werden werden auf dieser Seite erläutert.
CSV-Exportdatei:
Dies würde eine CSV-Rückgabe für unsere letzten Importe ergeben, die etwa wie im folgenden Beispiel aussehen würde. Hier können wir sehen, dass wir alle zuvor nicht exportierten Lagerbestände abgerufen haben, einschließlich der Hinzufügung einiger Produkte, die früher am Tag hergestellt wurden.
Diese Beispielexportdatei kann heruntergeladen werden werden auf dieser Seite erläutert.
Wie bei den oben genannten JSON-Exporten würde dies jedoch keine Transaktionsdaten zurückgeben, sodass wir auch hier auf die zurückgreifen können ‘SystemLog’ Stattdessen können Sie den Endpunkt nutzen, um relevantere Daten im Hinblick auf Transaktionen und Bestandsanpassungen abzurufen.
SystemLog:
Dieser Endpunkt kann zum Extrahieren einer Vielzahl von Daten verwendet werden, indem die verfügbaren, von hier aus verlinkten Datenpunkte durchlaufen werden. Wir können die Definitionen sehen, die wir verwenden können werden auf dieser Seite erläutert.
Dateiname der Kopf-/Spaltendefinition: “SystemLog.csvh”
Fertige Header-Dateien sollten abgelegt werden in: “<installdir>\SG Control Center\gateway\export\order”
CSV-Dateiname exportieren: “SystemLog-datetime.csv”
CSVs für Exporte werden generiert in: “<installdir>\SG Control Center\gateway\export”
Wie oben müsste dies im Gateway-Bereich des Control Centers aktiviert werden:
Header-Datei:
Von hier aus können wir unseren Header danach strukturieren, welche Transaktionsdaten wir zurück an das ERP erhalten möchten. Für unsere Zwecke hier könnte das so aussehen:
Diese Beispiel-Header-Datei kann heruntergeladen werden werden auf dieser Seite erläutert.
CSV-Exportdatei:
Wir können hier also sehen, dass wir speziell auf unsere Bedürfnisse zugeschnittene Daten zurückerhalten, darunter Daten wie die Ware, ihre Chargennummer, die ursprüngliche Menge, etwaige Anpassungen und den Benutzer, der die Aktion durchgeführt hat, zusammen mit etwaigen Gründen und relevanter Tätigkeit /Batch-Info.
Wenn wir das Systemprotokoll mit dem obigen Header ausführen, erhalten wir einen Export, der etwa so aussieht:
Diese Beispielexportdatei kann heruntergeladen werden werden auf dieser Seite erläutert.
