Flows definieren
Erläuterung
An dieser Stelle werden die Bedarfe definiert, für die Prognosen erstellt werden sollen. Die Beschaffungskette enthält verschiedene Flows von Artikeln zwischen unterschiedlichen Standorten und Kunden. Bei einem Flow handelt es sich um eine Untergruppe von Transaktionen in einem der Flows, die in der Regel auf den in den Kundenauftragspositionen enthaltenen Transaktionen basiert. Verschiedene Flows ermöglichen die Aufteilung des Bedarfs in Gruppen sowie die Erstellung einer gesonderten Prognose für die einzelnen Gruppen.
Die obige Abbildung stellt den Flow der Artikel aus dem Lager, einem regulären Standort in IFS, an zwei Kundengruppen dar. Flow 1 repräsentiert den Bedarf von Kundengruppe 1 (C1), Flow 2 dementsprechend den Bedarf von Kundengruppe 2 (C2). Diese Flows werden als Basisflows bezeichnet, da eine weitere Aufgliederung nicht möglich ist. Die Möglichkeit, den Bedarf eines bestimmten Kunden innerhalb der Gruppe anzuzeigen, besteht nicht.
Ein Basis-Flow stellt den Bedarf eines spezifischen Distributionskanals dar. Für jeden Basis-Flow werden die zugehörigen Transaktionen festgelegt. Die Transaktion wird dann in Perioden (definiert durch Version/Periode) zusammengefasst, und für jeden Flow wird eine Prognose erstellt. Jeder Basis-Flow verfügt über eine Gruppe von Prognoseartikeln. Jeder Artikel umfasst den historischen Bedarf und eine Prognose.
Zur Erstellung einer Prognose für den gesamten Bedarf des Lagers kann ein neuer Flow (Flow 3) angelegt werden, der den Bedarf aus Flow 1 und Flow 2 enthält. Dieser Flow wird als kombinierter Flow bezeichnet, d. h., er enthält mindestens zwei Basis-Flows. Der Bedarf eines kombinierten Flows wird durch Addieren der Bedarfe der Basis-Flows berechnet. Dasselbe gilt für angepasste Prognosen. Diese Zusammenfassung erfolgt ohne Unterbrechung des Prozesses auf dem Bedarfsplanungs-Server. Änderungen der angepassten Prognosen in Flow 1 wirken sich daher unmittelbar auf die angepassten Prognosen in Flow 3 aus. Ähnlich führt eine 10-prozentige Erhöhung der angepassten Prognosen für Flow 3 zu einer 10-prozentigen Erhöhung der Prognosen für Flow 1 und 2.
Neben den Basis-Flows und den kombinierten Flows existiert der importierte Flow. Im Wesentlichen entsprechen importierte Flows den Basis-Flows, sie erhalten jedoch per E-Mail Flows, die von anderen Bedarfsplanungs-Servern erstellt wurden. Es besteht ebenfalls die Möglichkeit festzulegen, welche Flows von einem Bedarfsplanungs-Server an andere Bedarfsplanungs-Server exportiert werden sollen. Derselbe Flow kann an zahlreiche Bedarfsplanungs-Server weitergeleitet werden. Zur Speicherung der exportierten Flows der Ausgangsserver müssen die Empfängerserver über importierte Flows verfügen.
Feldinformationen, die im Basis-Flow der Einrichtung der Bedarfsplanungs-Servers verfügbar sind, werden unten beschrieben.
Flow-ID: Die Flow-ID wird automatisch erzeugt und ist schreibgeschützt.
Beschr./Flow: Eine Beschreibung des Flows.
Standort-ID: Der Ursprungs-Standort des Basis-Flows. Dieses Feld muss ausgefüllt werden.
Beschr./Standort: Eine schreibgeschützte Beschreibung des Standorts.
Master-Flow: Gibt an, ob der Basis-Flow ein Master-Flow ist. Die Prognosen in einem Master-Flow werden in eine Registerkarte für die Tagesprognose exportiert, wodurch sie für andere IFS-Module verfügbar sind. Diese Prognosen werden zu dem Standort exportiert, der im Feld Standort-ID angegeben ist, was bedeutet, dass nur ein einziger mit einem bestimmten Standort verknüpfter Flow der Master-Flow sein kann. Wenn keine der Flows, die mit einem Standort verknüpft sind, ein Master-Flow ist, wird die Prognose nicht in die Registerkarte „Prognosetag“ exportiert.
Flow zurück schreiben: Wird diese Option auf "Ja" gesetzt, wird der Flow in FORECAST_FLOW_DAY_PUB zurück geschrieben, unabhängig davon, ob es sich um einen Master-Flow handelt oder nicht. Der Flow wird auf die gleiche Weise zurück geschrieben wie Master-Flows in FORECAST_DAY_PUB zurück geschrieben werden. Der einzige Unterschied besteht darin, dass auch die Flow-ID in FORECAST_FLOW_DAY_PUB geschrieben wird, damit zwischen den verschiedenen Flows unterschieden werden kann.
Prognose nach: Die verfügbaren Einstellungen in diesem Feld werden durch die Einstellung im Feld „vor Ort/Fertigung/DP-Import/Prognose nach“ bestimmt. Wenn auf „Artikel“ eingestellt, ist die Basis-Flow-Prognose nur dann für andere IFS-Komponenten verfügbar, wenn sie als Master-Flow für den Standort eingestellt ist. Andere mögliche Einstellungen für dieses Feld sind Kunde, Statistikgruppe/Kunde, Markt, Region, Bezirk oder Land. Beachten Sie, dass nur 2 Einstellungen verfügbar sind: der Artikel und die Einstellung für „vor Ort/Fertigung/DP-Import/Prognose nach“. Wenn einer dieser Werte (das heißt, nicht „Artikel") gewählt wird, sollte der SQL-Basis-Flow die relevante Historie für die ausgewählte „Prognose nach ID“-Dimension abrufen (siehe unten). Wenn eine dieser anderen Einstellungen für „Prognose nach“ definiert ist, steht der Flow für die Primärplanung zum Importieren nach Kundendimension zur Verfügung. Sie können die resultierende Prognose auf dem Bildschirm „Exportierte Prognose nach Dimension“ sehen.
Prognose nach ID: Die verfügbaren Einstellungen werden durch die Einstellung für „Prognose nach“ (Standort/Fertigung/DP-Import/Prognose nach) bestimmt. Wenn für „Prognose nach“ die Option „Artikel“ ausgewählt ist, wird die Einstellung in diesem Feld nicht verwendet. Wenn "Prognose nach ID" auf einen der anderen Werte (Kunde, Kundenstatistikgruppe, Markt, Region, Bezirk oder Land) eingestellt ist. Der hier angegebene Wert bestimmt den Schlüssel in der Ansicht/Bildschirmseite „Exportierte Prognose nach DIMENSION“, wodurch dieser Flow zu einem Master-Flow für die ausgewählte „Prognose nach“-Dimension wird. Die Basisflow-SQL sollte dann die historischen Daten sammeln, die der Einstellung in diesem Feld entsprechen. Ein Beispiel: Die Einstellung „Prognose nach“ ist „Kunde“ (definiert in der Einstellung „Standort/Fertigung“) und die Einstellung „Prognose nach ID" ist „Kunde1“. Ein Beispiel für einen Basis-SQL-Flow könnte dann lauten: SELECT contract, part_no, issue_date, issue_qty FROM comb_ext_inv_part_issue_pub WHERE customer_no='Cust1'
SQL-Befehl: Definiert die zur Zusammenfassung des historischen Bedarfs zu verwendenden Transaktionen. Dieser SQL-Befehl muss entsprechend dem folgenden allgemeinen Format geschrieben werden:
SELECT standort(vertrag), art_nt, datum, menge
FROM eine_tabelle
WHERE ein_feld = ein_element AND ein_feld = ein_weiteres_element
Die Reihenfolge der Felder "standort", "art_nr", "datum" und "menge" muss eingehalten werden. Die FROM-Anweisung darf nur eine Tabelle enthalten und keine Joins besitzen. Dies ist eine notwendige Einschränkung, da der SQL-Befehl vor seiner Ausführung vom Bedarfsplanungs-Server modifiziert wird. Der Server fügt eine WHERE-Bedingung hinzu, Site = Connected Site (Standort = Verknüpfter Standort), um sicherzustellen, dass der Flow nur Transaktionen mit dem Standort des Flows umfasst. Der Server fügt zudem eine WHERE-Bedingung hinzu, um den zeitlichen Umfang der Transaktionen einzuschränken.
Dies bietet maximale Flexibilität bei der Einrichtung von Flows, aber es können leicht Fehler auftreten. Aus diesem Grund wurden die vordefinierten Ansichten Internal_Invent_Part_Issue_Pub und External_Invent_Part_Issue_Pub eingerichtet. Es wird empfohlen, diese Ansichten zu verwenden, wann immer dies möglich ist. Wenn Sie entscheiden, Ihre Auswahl direkt aus einer Ansicht zu treffen, beachten Sie bitte die folgenden Fallstricke:
- Transaktionen vermeiden, die nicht eingeschlossen werden dürfen.
- Vergewissern Sie sich, dass Sie alle Transaktionen mit aufnehmen, die enthalten sein sollten.
- Rücksendungen sollten (falls möglich) das gleiche Datum wie die ursprüngliche Transaktion besitzen.
- Rücksendungen müssen eine negative Menge besitzen, sonst werden sie zum zweiten Mal als Bedarf gezählt.
- Anstatt Gelieferte Menge und Liefertermin, sollten Sie (falls möglich) die Gewünschte Menge und den Gewünschte Liefertermin einstellen.
Internal_Invent_Part_Issue_Pub verwenden
Die Ansicht Internal_Invent_Part_Issue_Pub enthält den gesamten internen Verbrauch von Artikeln. Sie kann wie folgt definiert werden:
SELECT vertrag, art_nr, entnahme_datum, entnahme_mg FROM Internal_Invent_Part_Issue_Pub
External_Invent_Part_Issue_Pub verwenden
Der externe Verbrauch (Kundenaufträge) lässt sich folgendermaßen definieren:
SELECT vertrag, art_nr, entnahme_datum, entnahme_mg FROM External_Invent_Part_Issue_Pub
Hier kann die zu erstellende Prognose wie im Beispiel anhand der Entnahmemenge und des Entnahmedatums definiert werden, oder es können die gewünschte, zugesagte oder geplante Menge und die entsprechenden Termine verwendet werden. Auf diese Weise können anstatt der Menge und des Termins, die vom Lieferanten realisiert werden können, die Menge und der Termin eingegeben werden, die vom Kunden gewünscht werden.
Ein Flow für den gesamten externen Verbrauch an einem Standort durch einen Kunden (kd1) wird folgendermaßen definiert:
SELECT vertrag, art_nr, entnahme_datum, entnahme_mg FROM External_Invent_Part_Issue_Pub WHERE kunde_nr = 'kd1'
Nutzung von Comb_Ext_Inv_Part_Issue_Pub
Diese Ansicht ist eine Verknüpfung zwischen „Extern_Invent_part_Issue_Pub“ und den Transaktionen, die auf der Bildschirmseite Manuelle historische Bedarfsplanungsdaten hinzugefügt wurden. Diese Ansicht ist ideal, wenn Sie Transaktionen aus anderen Systemen in die IFS-Bedarfsplanung importieren möchten, um historische Daten zu erhalten, die vor der Zeitspanne mit „echten“ IFS-Kundenaufträgen im System liegen.
Ein Flow für den gesamten externen Verbrauch an einem Standort durch einen Kunden (kd1) wird folgendermaßen definiert:
SELECT contract, part_no, issue_date, issue_qty FROM comb_ext_inv_part_issue_pub WHERE customer_no='Cust1'
Daten aus IFS Anforderungsmanagement
Es wurden 2 neue Ansichten erstellt, die Verbrauchsdaten aus IFS Anforderungsmanagement abgerufen haben
Geplanter_Materialbedarf – Material, das für wiederkehrende Services geplant ist (zukünftiger Bedarf) und für Anforderungsarbeitsaufgaben verbraucht wird (historischer geplanter Bedarf). Hierbei handelt es sich um Bedarf/Transaktionen, die aus einer geplanten präventiven Dienstleistung stammen.
Diese Ansicht besteht aus den folgenden Feldern
| Name | Typ | Beschreibung |
| CONTRACT | VARCHAR2(5) | Vertrag/Standort, aus dem der Verbrauch stammt |
| PART_NO | VARCHAR2(25) | Die verwendete Artikelnummer |
| GEPLANTES_DATUM | DATUM | Das geplante Datum für die Verwendung |
| GEPLANTE_MGE | NUMBER | Die geplante Menge für die Verwendung |
| ENTNAHMEDATUM | DATUM | Das aktuelle Datum für die Verwendung |
| AUSGABE_MGE | NUMBER | Die tatsächliche Menge für die Verwendung |
| CUSTOMER_NO | VARCHAR2(20) | Der Kunde, für den die Dienstleistung erbracht wurde |
| DIENSTLEISTUNG_ORGANISATION | VARCHAR2(20) | Die Serviceabteilung, die die Dienstleistung erbracht hat |
| DIENSTLEISTUNG_LIEFERUNG_EINHEIT | VARCHAR2(20) | Die Dienstleistungsliefereinheit, die die Dienstleistung erbracht hat |
Ungeplanter_Materialbedarf – Für Anforderungsarbeitsaufgaben verbrauchtes Material (historischer ungeplanter Bedarf). Hierbei handelt es sich um Bedarf/Transaktionen, die aus Dienstleistung/Reparaturen stammen, die nicht Teil einer geplanten vorbeugenden Instandhaltung sind, auch korrektiver Servicebedarf genannt
Diese Ansicht besteht aus den folgenden Feldern
| Name | Typ | Beschreibung |
| CONTRACT | VARCHAR2(5) | Vertrag/Standort, aus dem der Verbrauch stammt |
| PART_NO | VARCHAR2(25) | Die verwendete Artikelnummer |
| ENTNAHMEDATUM | DATUM | Das tatsächliche Datum für die Verwendung |
| AUSGABE_MGE | NUMBER | Die tatsächliche Menge für die Verwendung |
| CUSTOMER_NO | VARCHAR2(20) | Der Kunde, für den die Dienstleistung erbracht wurde |
| DIENSTLEISTUNG_ORGANISATION | VARCHAR2(20) | Die Serviceabteilung, die die Dienstleistung erbracht hat |
| DIENSTLEISTUNG_LIEFERUNG_EINHEIT | VARCHAR2(20) | Die Dienstleistungsliefereinheit, die die Dienstleistung erbracht hat |
Diese Ansichten sollen als Teil eines umfassenderen Logistik-Support-Frameworks für die Verwaltung von Artikeln genutzt werden, die in Dienstleistung und Instandhaltung innerhalb von IFS Cloud verwendet werden. Ziel ist es, die Bedarfsplanung zu nutzen, um eine Prognose für den künftigen Bedarf im Zusammenhang mit dem Servicebetrieb (Anforderungsmanagement) zu erstellen. Diese umfassende Prognose kann dann als Eingabe für die Bestandsplanung und -auffüllung (IPR) dienen, um Bestellpunkte, Ebenen von Sicherheitsbeständen und Losgrößen für Artikel zu bestimmen, die im Anforderungsmanagement/Serviceprozess benötigt werden.
Dieser Ansatz gewährleistet ein optimales Bestandsniveau, um die Serviceanforderungen effektiv zu erfüllen. Es ist wichtig zu beachten, dass IPR unter Verwendung einer speziellen Kombination der verfügbaren Modelle innerhalb des Systems konfiguriert werden sollte. Die Empfehlungen lauten wie folgt:
Bedarfsmodell: Prognose
Sicherheitsbestand-Modell: Zeitliche Abdeckung oder mittlerer absoluter Fehler
Losgrößenmodell: Es kann jedes beliebige Modell verwendet werden, wobei das Modell mit der größten Bedeutung (zeitliche Abdeckung, wirtschaftliche Losgröße oder dynamische Abdeckung) verwendet wird
Bestellpunktmodell: Vorlaufzeitgesteuert
Beachten Sie, dass es Gründe geben kann, von diesen Vorgaben abzuweichen, aber diese Kombinationen sollten die Grundlage bilden.
Ein typischer Aufbau in der Bedarfsplanung werden dann diese Basis-Flows sein:
Servicestandort S1 – Geplanter Bedarf Basis-Flow sql "SELECT contract, part_no, issue_date, issue_qty FROM planned_material_demand"
Servicestandort S1 – Ungeplanter Bedarf Basis-Flow sql "SELECT contract, part_no, issue_date, issue_qty FROM unplanned_material_demand"
Dann erstellen Sie einen kombinierten Flow, der aus den beiden Basis-Flows von Servicestandort S1 besteht. Dieser kombinierte Flow ist der Master für den Servicestandort S1 und wird für die weitere Planung in IPR verwendet.
"Einfluss"
Hinweis: Der Bedarfsplan-Server wurde nicht für erweiterte SQL-Anweisungen entworfen, verwenden Sie keine verschachtelten SQL-Anweisungen. Halten Sie es einfach!
SELECT vertrag, art_nr, entnahme_datum, entnahme_mg FROM External_Invent_Part_Issue_Pub WHERE <Beliebige Anweisung>
Das Präfix APPOWNER voranstellen, wenn der DP-Server von einem anderen Anwender als dem Appowner ausgeführt werden soll.
Voraussetzungen
- Diese Aktivität erfordert, dass die in der Registerkarte spezifizierten allgemeinen Parameter des Bedarfsplanungsservers definiert sind.
Auswirkungen
Bevor der Server gestartet wird, bestehen keine Auswirkungen auf das System.