Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Konfigurationsdaten für die Planung In diesem Abschnitt werden alle erforderlichen Felder aufgeführt, die von Supply Planning verwendet werden, und es wird beschrieben, wie jedes Feld verwendet wird. Informationen zu Datenfeldern, die für Supply Planning erforderlich sind, finden Sie unter[Planung der Versorgung](entities-supply-planning.md). **Topics** + [Produkt](#product) + [Site](#site) + [Handelspartner](#trading-partners) + [Produkt des Anbieters](#vendor-product) + [Vorlaufzeit des Anbieters](#vendor-leadtime) + [Beschaffungsregel](#sourcing-rule) + [Inventarpolitik](#inventory-policy) + [Zeitplan für die Beschaffung](#sourcing-schedule) + [Stückliste (BOM)](#product-bom) + [Produktionsprozess](#production-process) + [Parameter für die Angebotsplanung](#production-process2) + [Transaktionsdaten](transactional.md) ## Produkt Die Produktentität definiert die Liste der Artikel oder Produkte, die in die Planung aufgenommen werden müssen. Die Bestellanfragen verwenden das *Feld unit\$1cost* der Entität *Product*, um den Bestellwert oder die Menge zu ermitteln. Die Entität *Product* enthält auch die Produktgruppe, die einem bestimmten Produkt entspricht. Dabei handelt es sich um einen Fremdschlüssel für eine *Product\$1Hierarchy-Entität*. Produktgruppen können zur Konfiguration von Inventarrichtlinien, Beschaffungsplänen, Lieferzeiten usw. auf aggregierter Ebene verwendet werden. ## Site Die *Site-Entität* definiert die Liste der Standorte oder Standorte, die in die Planung einbezogen werden müssen. Die Entität *Site* enthält auch Regionen, die einer bestimmten Site entsprechen, was ein Fremdschlüssel für eine Geography-Entität ist. Regionen können zur Konfiguration von Inventarrichtlinien, Beschaffungsplänen, Lieferzeiten usw. auf aggregierter Ebene verwendet werden. ## Handelspartner Die Entität *Trading\$1Partner* definiert die Liste der Lieferanten. *tpartner\$1type sollte beim Hochladen von Lieferanteninformationen* *auf Vendor gesetzt werden.* ## Produkt des Anbieters Die von den einzelnen Lieferanten gelieferten Produkte sind in der Entität *vendor\$1product* definiert. Diese Entität enthält auch herstellerspezifische Kosteninformationen. ## Vorlaufzeit des Anbieters Die Vorlaufzeit eines Lieferanten ist der Zeitraum zwischen der Bestellung bei einem Lieferanten und dem Eingang der Bestellung. Diese Daten sind in der *VendorMgmt*Kategorie unter der Datenentität *vendor\$1lead\$1time* definiert. Die Vorlaufzeit des Anbieters folgt der folgenden Überschreibungslogik: + Die Vorlaufzeit des Anbieters auf Produktebene hat Vorrang vor der Lieferantenvorlaufzeit auf Produktgruppenebene. + Die Vorlaufzeit der Lieferanten auf Standortebene hat Vorrang vor der Vorlaufzeit der Lieferanten auf regionaler Ebene. + Die Vorlaufzeit der Lieferanten auf regionaler Ebene hat Vorrang vor der Vorlaufzeit der Lieferanten auf Unternehmensebene. Um nach einem Datensatz zu suchen, verwendet Supply Planning die folgenden Felder: + company\$1id + region\$1id + Seiten-ID + Produktgruppen-ID + product\$1id Im Folgenden finden Sie ein Beispiel für die Override-Logik: ![\[Beispiel für eine Override-Logik\]](http://docs.aws.amazon.com/de_de/aws-supply-chain/latest/userguide/images/override_logic.png) Im Folgenden finden Sie ein Beispiel dafür, wie Supply Planning die Vorlaufzeit eines Lieferanten berechnet: ![\[Berechnung der Lieferzeiten\]](http://docs.aws.amazon.com/de_de/aws-supply-chain/latest/userguide/images/vendor_lead_time.png) **Die Reihenfolge der Priorisierung lautet *Produkt* > *Produktgruppe > *Standort* > Dest\$1Geo* *(Region) > Produktsegment > Unternehmen*.** ## Beschaffungsregel Supply Planning generiert einen Plan auf der Grundlage der Supply-Chain-Netzwerktopologie, die in der Entität *sourcing\$1rules* definiert ist. Die unterstützten Bezugsregeltypen sind Transfer, Kauf und Fertigung. *Die Bezugsregeln folgen der *Überschreibungslogik product\$1id* > *product\$1group\$1id* > company\$1id.* ***Supply Planning ruft die Transportvorlaufzeit ab, indem es auf transportation\$1lane\$1id verweist und in transportation\$1lane auf transit\$1time zugreift.*** Es gibt zwei Schritte, um die Transfer-Vorlaufzeit abzurufen. 1. *Suchen Sie in sourcing\$1rules nach *transportation\$1lane\$1id*.* **Nur die Bezugsregeln, die sowohl „*to\$1site\$1id*“ als auch „from\$1site\$1id“ enthalten, können „transfer\$1lead\$1time“ abgerufen werden.** 1. *Verwenden *Sie transportation\$1lane\$1id*, um transportation\$1lane nachzuschlagen.* Wenn es in der *Sourcing\$1Rule-Entität* mehrere Datensätze mit derselben *to\$1site\$1id und product\$1id* *(*product\$1group\$1id**) gibt, werden nur die Datensätze mit der höchsten Priorität (der kleinsten Zahl) verwendet. Beispiel für Beschaffungsregeln: Basierend auf der vorherigen Definition wählt Supply Planning die folgende Beschaffungsregel aus SR1: Laptop am Standort `TX0` wird vom Standort `IL0` über bezogen`transportation_lane_9`. | sourcing\$1rule\$1id | product\$1id | Produktgruppen-ID | Typ der Quellregel | von\$1site\$1id | zu\$1site\$1id | Priorität bei der Beschaffung | Beförderungsweg-ID | | --- | --- | --- | --- | --- | --- | --- | --- | | SR1 | Laptop | Elektronik | Übertragung | IL0 | TX0 | 1 | transportation\$1lane\$19 | | SR2 | Laptop | Elektronik | Übertragung | NJ1 | TX0 | 2 | transportation\$1lane\$121 | | SR3 | Laptop | Elektronik | Übertragung | IL0 | TX0 | 1 | transportation\$1lane\$111 | *Wenn mehrere Datensätze mit derselben Priorität für dieselbe Kombination aus *to\$1site\$1id, product\$1id (oder product\$1group\$1id**) existieren, wird die Nachbestellmenge* *auf Grundlage des Felds sourcing\$1ratio* auf die verfügbaren Bezugsoptionen verteilt.* Beachten Sie, dass die Mehrfachbeschaffung derzeit nur für den Bezugsregeltyp unterstützt wird. `buy` Beispiel für Multisourcing: | sourcing\$1rule\$1id | product\$1id | Produktgruppen-ID | Typ der Quellregel | Partner-ID | to\$1site\$1id | Priorität bei der Beschaffung | Beschaffungsverhältnis | | --- | --- | --- | --- | --- | --- | --- | --- | | SR1 | Laptop | Elektronik | kaufen | Lieferant 1 | TX0 | 1 | 4 | | SR2 | Laptop | Elektronik | kaufen | Lieferant 2 | TX0 | 1 | 6 | Beide Bezugsregeln SR1 und SR2, sind ausgewählt, und die Bestellmenge wird zwischen Lieferant 1 und Lieferant 2 im Verhältnis 4:6 aufgeteilt. ## Inventarpolitik Supply Planning sucht mithilfe der folgenden Felder nach einem Datensatz im Datensatz: + *site\$1id* + *geodätisch* + *Unternehmens-ID* + *produkt-ID* + *Produktgruppen-ID* + *Segment\$1ID* Supply Planning verwendet *ss\$1policy, um die Inventarrichtlinie* zu bestimmen. ***Die Override-Logik verwendet die folgende Priorität: *product\$1id > product\$1group\$1id > *site\$1id** *> und dest\$1geo\$1id > segment\$1id > company\$1id*. ***** Die *unterstützten* **ss\$1policy-Werte** *sind* abs\$1level*, doc\$1dem*, doc\$1fcst und sl. Das folgende Beispiel zeigt die Prioritätslogik zum Überschreiben. ![\[Logik überschreiben\]](http://docs.aws.amazon.com/de_de/aws-supply-chain/latest/userguide/images/override1.png) Im Folgenden finden Sie ein Beispiel für den Wert *ss\$1policy*, der auf der Override-Logik basiert. ![\[Beispiel für die Override-Fahrlogik für den Wert ss_policy\]](http://docs.aws.amazon.com/de_de/aws-supply-chain/latest/userguide/images/override2.png) ## Zeitplan für die Beschaffung **Anmerkung** Der Beschaffungsplan ist eine optionale Einheit. Wenn diese Entität nicht angegeben wird, verwendet Supply Planning einen kontinuierlichen Überprüfungsprozess, um das *erforderliche Datum* auf der Grundlage des Bedarfs der Produkte zu generieren. Supply Planning verwendet den Beschaffungsplan, um Einkaufspläne mithilfe der folgenden Schritte zu erstellen: + *Suchen Sie *sourcing\$1schedule\$1id in sourcing\$1schedule*.* + **Suchen Sie den Zeitplan mithilfe von sourcing\$1schedule\$1id in sourcing\$1schedule\$1details.** **Supply Planning sucht in sourcing\$1schedule\$1id unter sourcing\$1schedule nach den folgenden Feldern.** + *to\$1site\$1id* + **tpartner\$1id oder from\$1site\$1id** **Basierend auf dem Beschaffungspfad in den Beschaffungsregeln bestimmt Supply Planning, ob from\$1site\$1id oder tpartner\$1id verwendet werden soll.** Supply Planning liest den Wert im Feld *sourcing\$1schedule\$1id, um den nächsten Schritt zu bestimmen*. *Supply Planning liest die Termindetails unter sourcing\$1schedule\$1details mit den folgenden Feldern:* + *sourcing\$1schedule\$1id* + *firmen\$1id* + *Produktgruppen-ID* + *Produkt\$1ID* *sourcing\$1schedule\$1details folgt der Override-Logik product\$1id > product\$1group\$1id* ***> company\$1id.*** Im Folgenden finden Sie ein Beispiel für die Override-Logik in *sourcing\$1schedule\$1details.* ![\[Logik zum Überschreiben des Beschaffungszeitplans\]](http://docs.aws.amazon.com/de_de/aws-supply-chain/latest/userguide/images/sourcing_schedule2.png) Im Folgenden sind die ausgewählten Zeitpläne aufgeführt, nachdem die Überschreibungslogik angewendet wurde. ![\[Logik zum Überschreiben des Beschaffungsplans\]](http://docs.aws.amazon.com/de_de/aws-supply-chain/latest/userguide/images/sourcing_schedule3.png) Der tatsächliche Zeitplan kann je nach Komplexität des Zeitplans aus einer Zeile oder mehreren Zeilen bestehen. Für das Feld *week\$1of\$1month* ist in jeder Zeile nur eine Zahl zulässig. Für mehrere Wochen des Monats sind mehrere Datensätze erforderlich (siehe das folgende Beispiel). Für das Feld *day\$1of\$1week* sind sowohl Ganzzahl als auch Tagesname zulässig (So: 0, Mo: 1, Di: 2, Mi: 3, Do: 4, Fr: 5, Sa: 6). *In den Details des Beschaffungsplans ist für die wöchentliche Planung week\$1of\$1month erforderlich.* In der Tagesplanung kann *week\$1of\$1month leer* sein, d. h. jede Woche. Sehen Sie sich die folgenden Beispiele an. ![\[Logik zum Überschreiben des Beschaffungszeitplans\]](http://docs.aws.amazon.com/de_de/aws-supply-chain/latest/userguide/images/sourcing_schedule4.png) *Beachten Sie, dass für die wöchentliche Planung *week\$1of\$1month erforderlich ist, wenn day\$1of\$1week* angegeben wird.* Das folgende Beispiel zeigt die Daten, die für die Tagesplanung verwendet werden können. | Date | Tag der Woche | Woche des Monats | | --- | --- | --- | | 1.8.2023 | N/A | N/A | | 12.8.2023 | N/A | N/A | | N/A | 2 | N/A | | N/A | 5 | N/A | Das folgende Beispiel kann sowohl für die Tages- als auch für die Wochenplanung verwendet werden. | Date | Tag der Woche | Woche des Monats | | --- | --- | --- | | 1.8.2023 | N/A | N/A | | 12.8.2023 | N/A | N/A | | N/A | 2 | 1 | | N/A | 2 | 2 | | N/A | 2 | 3 | | N/A | 2 | 4 | | N/A | 2 | 5 | | N/A | 5 | 1 | | N/A | 5 | 2 | | N/A | 5 | 3 | | N/A | 5 | 4 | | N/A | 5 | 5 | ## Stückliste (BOM) Die Produktstückliste wird in Fertigungsplänen verwendet, wenn *sourcing\$1rule* auf Manufacture gesetzt ist. Informationen zur Erfassung der Produktstückliste finden Sie im API-Referenzdokument. AWS Supply Chain ## Produktionsprozess *production\$1process\$1id wird in den Entitäten sourcing\$1rule* **und product\$1bom referenziert.** Diese Felder werden verwendet, um Informationen zur Durchlaufzeit für die Erstellung oder Zusammenstellung einer Stückliste zu verwenden. ## Parameter für die Angebotsplanung *In der Entität *supply\$1planning\$1parameters* kann der *Planner\$1Name des Versorgungsplaners* auf Product\$1ID-Ebene zugewiesen werden.* Der Name des Planers wird auf den von der Supply Planning Engine generierten Planbestellungen angezeigt. # Transaktionsdaten **Topics** + [Forecast](#forecast) + [Verkaufshistorie oder Nachfrage](#demand) + [Höhe des Inventars](#inventory-level) + [Eingehende Bestellungen](#in-flight-orders) ## Forecast Bei der Angebotsplanung werden zwei verschiedene Prognosequellen und -typen verwendet. Sie können die folgenden Quellsysteme verwenden, um die Prognosequelle abzurufen: + *Extern* — Supply Planning verwendet die Daten, die in die Data Lake-Prognoseeinheit aufgenommen werden. + *Bedarfsplanung* — Die Angebotsplanung verwendet die Prognosen aus der Bedarfsplanung. + *Keine* — Supply Planning verwendet die Daten zur Umsatz- oder Nachfragehistorie aus der ausgehenden Auftragsposition. Die Angebotsplanung unterstützt zwei Arten von Prognosen: deterministische und stochastische Prognosen. Deterministische Prognosen enthalten nur den Mittelwert der Prognose. Stochastische Prognosen enthalten P10/P50/P90, manchmal zusammen mit dem Mittelwert. Wenn bei stochastischen Prognosen kein Mittelwert angegeben wird, verwendet die Angebotsplanung P50 (Median) als Mittelwert. Jeder Prognosedatensatz hat vier Felder, die die Nachfrageprognose darstellen: + Mittelwert (doppelt) + p10 (doppelt) + p50 (auch bekannt als Median, Doppel) + p90 (doppelt) Basierend auf der konfigurierten Inventarrichtlinie sind unterschiedliche Felder in dieser Entität erforderlich. Für *sl* ist p10/p50/90 erforderlich; für *doc\$1fcst* ist die Richtlinie p50 oder mean erforderlich. *Supply Planning verwendet p50 als Näherung für den Mittelwert, und für *doc\$1dem* und abs\$1level ist keines der Prognosefelder erforderlich.* **Tägliche Planung** Prognosen können für die tägliche Planung anders sein als für die wöchentliche Planung. Hier ist ein Beispiel für die Anforderungen an die tägliche und wöchentliche Planung von Prognosen. ![\[Tägliche Planung\]](http://docs.aws.amazon.com/de_de/aws-supply-chain/latest/userguide/images/daily-planning.png) **Wöchentliche Planung** Sie können das Beispiel für die tägliche Planungsprognose für die wöchentliche Planung verwenden, oder Sie können auch das folgende Beispiel für die wöchentliche Planung verwenden. ![\[Wöchentliche Planung\]](http://docs.aws.amazon.com/de_de/aws-supply-chain/latest/userguide/images/weekly-planning.png) ## Verkaufshistorie oder Nachfrage Die Inventarrichtlinie *doc\$1dem benötigt die* Bedarfshistorie, um den historischen Durchschnittsbedarf zu berechnen. *Supply Planning ruft den Nachfrageverlauf von der Entität *outbound\$1order\$1line* in der Kategorie Outbound ab.* Supply Planning verwendet die folgenden Felder: + *ship\$1from\$1site\$1id* (Zeichenfolge) + *product\$1id* (Zeichenfolge) + *actual\$1delivery\$1date (timestamp); falls nicht, verwende promised\$1delivery\$1date* *(timestamp)* Als Teil der Berechnung verwendet Supply Planning historische ausgehende Auftragspositionen mit Lieferdaten in den letzten 30 Tagen. *Das für die Menge verwendete Zielfeld ist *quantity\$1delivered. Wenn es fehlt, verwenden Sie quantity\$1promised*.* *Wenn *quantity\$1promised fehlt, wird final\$1quantity\$1requested verwendet*.* *Wenn alle fehlen, wird 0 verwendet.* *Wenn Sie beispielsweise am 1. Juli 2023 am Standort „“ die Beschaffungsplanung für das Produkt „LaptopTX0“ verwenden, liegt der Datensatz in *outbound\$1order\$1line mit product\$1id=laptop, TX0 *ship\$1from\$1site\$1id=** *und actual\$1delivery\$1date* zwischen dem 1. Juni 2023 und dem 30. Juni 2023.* Die Angebotsplanung addiert alle Datensätze und dividiert sie durch 30 Tage, um den täglichen Bedarf zu ermitteln. ## Höhe des Inventars Für die Angebotsplanung ist ein erster Lagerbestand erforderlich, um den Planungsprozess starten zu können. Supply Planning sucht nach der Inventarebene unter der *Datenentität inv\$1level*. Supply Planning sucht nach einem Datensatz mit den folgenden Feldern: + *product\$1id* + *Seiten-ID* Supply Planning verwendet *on\$1hand\$1inventory*, um den Lagerbestand zu ermitteln. ## Eingehende Bestellungen Supply Planning verwendet *inbound\$1order\$1line, um die Menge der Bestellungen während* des Fluges abzurufen. Wenn eine Bestellung während des Planungshorizonts geliefert wird, wird die Menge als Teil des bestehenden Angebots betrachtet. Supply Planning sucht unter *inbound\$1order\$1line* nach einem Datensatz mit den folgenden Feldern: + **order\$1receive\$1date; falls nicht, verwenden Sie expected\$1delivery\$1date** + *product\$1id* + *to\$1site\$1id* Die folgenden Auftragsarten werden unterstützt: PO (Einkauf), TO (Transfer) und MO (Produktion oder Fertigung). Supply Planning verwendet den Wert *quantity\$1received*. Wenn dieser Wert fehlt, verwenden Sie *quantity\$1confirmed und anschließend *quantity\$1submitted*, um die bestellte* Menge zu ermitteln.