Erweiterte Servereinstellungen dienen dazu, den Bedarfsplanungsserver auf verschiedene Weise einzurichten. Einige dieser Einstellungen können in Setup-Dialogfeldern oder in der Konfigurationsdatei im Installationsordner des Bedarfsservers festgelegt werden, während andere nur direkt in den erweiterten Servereinstellungen geändert werden können, die auf der Seite „Bedarfsplanungsserver“ zu finden sind. Die Standardwerte werden in die Liste geschrieben, wenn der Bedarfsplanungsserver zum ersten Mal gestartet wird. Hinweis: Sie sollten beim Ändern dieser Einträge SEHR VORSICHTIG vorgehen und Änderungen nur vornehmen, wenn Sie sich dessen absolut sicher sind. Die Standardeintragswerte werden in Servereinstellungen geschrieben, wenn der Bedarfsplanungsserver zum ersten Mal gestartet wird.
Hinweis: Die Standardwerte basieren auf dem Server, der mit einer MONATSPERIODE arbeitet. Wenn der Server mit anderen Periodenversionen ausgeführt werden soll, müssen dazu einige der Werte in den Servereinstellungen geändert werden. Die Parameter sollten dann so geändert werden, dass sie sowohl zur Funktionsweise der Modelle passen als auch zusammen mit der neuen Periodenversion funktionieren:
Es kann sein, dass Sie unabhängig von der ausgeführten Periodenversion die Art und Weise ändern möchten, wie die Prognosemodelle das System optimieren, um es besser an die Umgebung anzupassen, in der es ausgeführt werden soll. Die wichtigsten zu ändernden Abschnitte sind:
NumberOfPartsLimmit: Dies ist die maximale Anzahl von Artikeln, für die das TSPT-Modell während des Zyklus eines Prognoseerstellungsjobs ausgeführt werden kann. Wird diese Grenze erreicht, erhalten Sie eine Fehlermeldung und der DP-Server führt stattdessen das am besten geeignete Prognosemodell aus. Diese Einstellung hat keine Auswirkung auf die Anzahl der Artikel, wenn Sie das TSPT-Niveau-/Trend-/Saisonmodell manuell über den Bedarfsprognose-Client verwenden. Siehe Prognosemodelle für weitere Informationen.
Die Grenzen der Beste-Treffer-Suche für die verschiedenen Prognosemodelle müssen entsprechend der neu ausgewählten Periodenversion geändert werden. Siehe Prognosemodelle für weitere Informationen.
Durch Festlegen der Parameter in den Prognosemodellen, aus denen das Bayes’sche Prognosemodell besteht, können Sie genauere Vorhersagen als mit der Beste-Treffer-Optimierung der Parameter erzielen und das Modell wird auch schneller ausgeführt. Siehe Prognosemodelle für weitere Informationen.
Das regelbasierte Prognosemodell muss normalerweise so konfiguriert werden, dass es für jeden Kundenbedarf geeignet ist, wenn es verwendet werden soll.
Es gibt mehr Parameter als die, die in diesem Dokument beschrieben sind. Diese Parameter dürfen nur nach Rücksprache mit einem IFS Berater geändert werden. Siehe Prognosemodelle für weitere Informationen.
Dient zur Speicherung des Freigabedatums.
ApproveAfterCreateForecast: Wenn auf 1 gesetzt, müssen die Artikel freigegeben werden, bevor sie zu IPR-Berechnungen nach Ausführen der Jobs zum Erstellen einer Prognose verwendet werden. Standardeinstellung ist 0.
Zur internen Verwendung durch den Bedarfsplanungsserver. Dient zur Verwaltung von Sicherungskopien und verfolgt den Speicherort der aktuellen Sicherungsdatei. Bitte prüfen Sie dies vor der Änderung mit einem IFS-Berater.
Dient zur Speicherung von Grenzen für einige der Bedarfsklassen, in die die verschiedenen Artikel eingeteilt werden. Siehe Artikelklassifizierung zu Informationen über die Grenzwerte.
RunForecastAlso: Wenn der Wert auf „True“ (1) gesetzt ist, führt der Bedarfsplanungsserver beim Durchführen einer Klassifizierung das Prognosemodell für die Artikel aus. Die Standardeinstellung ist „False“ (0).
Dient zur Speicherung der Einstellungen für die Kommunikation zwischen Bedarfsplanungsserver und Bedarfsplanungs-Client.
Listener: Portnummer aus dem Setup-Dialogfeld, die für die Kommunikation verwendet wird. Standardeinstellung ist 5010. Verwendet in alter direkter Kommunikation DP-Server <-> DP-Client.
Port: Wird für das Debugging verwendet. Bitte vor der Änderung an einen IFS-Berater wenden.
Server: Der Name/die IP-Adresse des Web-Servers sollte mit dem der Maschine übereinstimmen, auf der der Bedarfsplanungsserver läuft. Verwendet in alter direkter Kommunikation DP-Server <-> DP-Client.
ServerID: Die Server-ID, die aus der Datenbank gelesen werden soll.
OverwriteServer: Wird in Cloud-Umgebungen verwendet, wenn die Installations-Maschine für Bedarfsplanungsserver bei Zugriff von außen einen anderen öffentlichen Namen oder eine andere IP-Adresse hat. Ein Hinweis ist, dass die Host-Zeichenfolge im DP-Server-Dashboard nicht den vollständigen Namen der Maschine anzeigt, auf der der DP-Server ausgeführt wird. Um die Bedarfs-Funktionalität zum Laufen zu bringen, sollte die vollständige Adresse der Maschine eingegeben werden, auf der der DP-Server läuft, z. B. 145.168.0.1 oder dpserver.cloud.net.com.
Speichert alle Einstellungen zur Kommunikation zwischen dem Bedarfsplanungsserver und der Oracle-Datenbank. Die meisten Parameter werden während der Installation oder über die Konfigurationsdatei festgelegt. Die Parameter, die in diesen Fällen nicht festgelegt werden, sind:
DescriptionValue: Die Funktion, die verwendet werden soll, um die Artikelbezeichnung abzurufen. Bitte prüfen Sie dies vor der Änderung mit einem IFS-Berater.
Interface: Gibt an, welche OCI-Verknüpfung des DP-Servers verwendet werden soll, was vom Oracle-Client, der auf dem DP-Server-Computer installiert ist, bestimmt wird. <empty> oder OCCI bedeutet „OCCI“, was Oracle 12g oder höher ist. OCI bedeutet frühere Oracle-Clients, normalerweise 11G. Standardeinstellung ist OCCI/Oracle-Client 12.
InventoryTable: Die Tabelle/Ansicht, mit der Bestandsartikelwerte gelesen werden sollen. Bitte prüfen Sie dies vor der Änderung mit einem IFS-Berater.
InventoryValue: Wird verwendet, um die Kompatibilität mit älteren Versionen von IFS Cloud, z. B. IFS App 9, zu gewährleisten. Wird dieser Parameter nicht ausgefüllt, verwendet der Bedarfsplanungsserver zum Lesen von Bestandswerten die Funktion INVENTORY_PART_API.Get_Inventory_Value_By_Method(CONTRACT, PART_NO). Wenn eine andere Funktion eingesetzt werden soll, muss die gewünschte Funktion/das gewünschte Feld in diesem Eintrag eingegeben werden. Beispiel: INVENTORY_PART_COST_API.Get_Total_Standard(CONTRACT, PART_NO, 1). Standardwert ist leer. Hierbei handelt es sich um eine flexible Lösung, die ein einfacheres Laden verschiedener Werte in die Bedarfsplanung ermöglicht.
IPRRouteIDTable: Dient zum flexiblen Laden von Toureninformationen zum IPR-Server. Der Standardwert ist FORWARD_DELIVERY_SCHEDULE_TAB.
LeadTimeValue: Wird verwendet für das flexible Laden der Vorlaufzeit. Wenn leer, verwendet der Bedarfsplanungsserver die Vorlaufzeit für die Fertigung für Fertigungsartikel und die Vorlaufzeit des Einkaufs für Einkaufsartikel. Wenn die erwartete Vorlaufzeit verwendet werden soll, können Sie in diesem Feld die Funktion INVENTORY_PART_API.Get_Expected_LeadTime (Contract, Part_no) angeben. Standardwert ist leer.
NumberOfRecordsReadInAgg-Qual: Größe des Lesepuffers beim Zusammenfassen und Auswählen von Artikeln. Standardwert ist 1000.
Predecessor_SuperSedes: Der Standardwert ist 0. Auf 1 gesetzt, wird das Feld für den Bestandsartikel als Vorgänger in der Bedarfsplanung gelesen.
Verkaufspreis/Kostentabelle: Dient zur Festlegung einer Kostentabelle, die in der Bedarfsplanung als Verkaufspreis verwendet wird. Es muss einfach die zu verwendende Kostentabelle angegeben werden, z. B. „7“. Standardwert ist leer. Nur aktiv, wenn Wert/Verkaufspreis leer ist.
Wert/Verkaufspreis: Wird verwendet für das flexible Laden des Gewichtswerts. Wird dieser Parameter nicht ausgefüllt, verwendet der Bedarfsplanungsserver dieses und liest dann die Kostentabelle ab, die durch die Verkaufspreis-Kostentabelle definiert ist. Wenn eine andere Funktion eingesetzt werden soll, muss die gewünschte Funktion/das gewünschte Feld in diesem Eintrag eingegeben werden. Beispiel: INVENTORY_PART_COST_API.Some_Function(CONTRACT, PART_NO, 1). Standardwert ist leer.
Wert/Gewicht: Wird verwendet für das flexible Laden der Gewichtswerte. Wird dieser Parameter nicht ausgefüllt, verwendet der Bedarfsplanungsserver die Funktion INVENTORY_PART_API.Get_Weight_Net(CONTRACT, PART_NO), um die Gewichtswerte zu lesen. Wenn eine andere Funktion eingesetzt werden soll, muss die gewünschte Funktion/das gewünschte Feld in diesem Schlüssel eingegeben werden. Beispiel: INVENTORY_PART_COST_API.Some_Function(CONTRACT, PART_NO, 1). Standardwert ist leer.
Hinweis: Keine der 4 vorstehend genannten Funktionen (InventoryValue, WeightValue, SalesPriceValue, LeadTimeValue und IPRRouteIDTable) muss mit dem Präfix für den Anwender „appowner“ versehen werden. Der DP-Server führt dies automatisch durch.
Dient zur Speicherung der Sprachdatei des Bedarfsplanungs-Servers, die am Anfang während der Installation des Bedarfsplanungs-Servers festgelegt werden.
Definiert die 3 verschiedenen Messungen des Öko-Fußabdruck-Moduls, die verwendet werden sollen:
Messung1: Die erste Messung. Der Standardwert ist GWP100.
Messung2: Die zweite Messung. Der Standardwert ist ODP100.
Messung3: Die dritte Messung. Der Standardwert ist HTP.
Verfügbare Messungen sind:
NumberOfPartsLimmit: Die Anzahl der Artikel, für die das TSPT-Prognosemodell während der Erstellung des Prognoseauftrags berechnet wird, wenn das Limit erreicht ist, erhalten die anderen Modelle mit TSPT-Modellsatz den Best-Fit-Prognosemodellsatz. Der Grund für diese Einstellung sind Leistungsprobleme, da das TSPT-Prognosemodell sehr rechenintensiv ist. Der Standardwert ist 1000.
BayesInitPerioden: Gibt an, wie viele Historienperioden der Artikel benötigt, bevor das Prognosemodell „Bayes“ gestartet wird. Der gleitende Durchschnitt (über alle Perioden) wird als Prognosemodell verwendet, bevor dieser Grenzwert erreicht ist. Der Standardwert ist 6.
Es ist möglich, das Bayes-Modell mit festen Parametern für den gleitenden Durchschnitt, AEWMA und die Brown-Stufen sowie Trendmodelle auszuführen. Die festen Parameter für dieses Modell werden in den erweiterten Servereinstellungen gesetzt. Wenn für „BayesianMovingAveragePeriods“ ein negativer Wert eingegeben wird, wird das beste Optimierungskonzept zur Bestimmung der Parameter für die Modelle (alle Modelle) verwendet.
BayesianMovingAveragePeriods: Gibt an, welche gleitenden Durchschnittsperioden in einem einfachen gleitenden Durchschnittsmodell beim Ausführen des Bayes-Modells verwendet werden sollen. Wenn negativ, wird der Parameter mit dem besten Trefferalgorithmus optimiert, wenn negativ festgelegt, werden alle Parameter/Modelle des Bayes-Prognosemodells optimiert. Der Standardwert ist -1.
BayesianAEWMABeta: Gibt an, welcher Beta-Wert im Modell AEWMA verwendet werden soll. Der Standardwert ist 0,2.
BayesianBrownAlpha: Der Alpha-Parameter, der auf Brown-Ebene und im Trendmodell verwendet werden soll. Der Standardwert ist 0,2.
OptimizingMethod: Definiert, welche Prognosemessung zur Bestimmung des besten Prognosemodells/Parameterkombination verwendet werden soll, wenn beste Treffer/Bayes ausgeführt wird. 0-MAE, 1-MSE. Der Standardwert ist 0-MAE.
BayesianMovingAveragePeriods: Gibt an, welche gleitenden Durchschnittsperioden in einem einfachen gleitenden Durchschnittsmodell beim Ausführen des Bayes-Modells verwendet werden sollen. Wenn negativ, wird der Parameter mit dem besten Trefferalgorithmus optimiert, wenn negativ festgelegt, werden alle Parameter/Modelle des Bayes-Prognosemodells optimiert. Der Standardwert ist 12.
BayesianAEWMABeta: Der Alpha- und Beta-Wert, der im AEWMA-Modell verwendet werden soll. Der Standardwert ist 0,2. (Sowohl der Alpha- als auch der Beta-Wert im AEWMA-Modell wird auf diesen Wert gesetzt).
BayesianBrownAlpha: Der Alpha-Parameter, der auf Brown-Ebene und im Trendmodell verwendet werden soll. Der Standardwert ist 0,2.
MovingAveragePeriods: Gibt an, welche Anzahl gleitender Durchschnittsperioden in einem einfachen gleitenden Durchschnittsmodell beim regelbasierten Ausführen verwendet werden soll. Wenn negativ, wird der Parameter mithilfe des gleitenden Durchschnittsalgorithmus optimiert. Wenn negativ festgelegt ist, werden alle Parameter/Modelle des gleitenden Durchschnittsprognosemodells optimiert. Der Standardwert ist 6.
Period_Start_Bayesian: Dadurch kann definiert werden, wie viele historische Datenperioden der Artikel haben muss, bevor das Bayes-Modell unter dem regelbasierten Modell ausgeführt wird. Der Standardwert ist 6.
Period_Start_Moving_Average: Dadurch können Sie definieren, wie viele historische Datenperioden der Artikel haben muss, bevor das gleitende Durchschnittsmodell unter dem regelbasierten Modell ausgeführt wird. Der Standardwert ist 3.
Vor dem Erreichen der Anzahl von Perioden für Period_Start_Moving_Average wird das manuelle Prognosemodell ausgeführt.
CleansingMethod: 0 = Keine Daten reinigen, 1 = Daten gemäß der Standard-Ableitungsmethode reinigen. Siehe Daten bereinigen. Standardeinstellung ist 1.
MSECleansingMethod: 0 = Keine Daten bereinigen, 1 = Daten gemäß der Standard-Ableitungsmethode bei MSE-Berechnung bereinigen. Siehe Daten bereinigen/Prognosegenauigkeit. Standardeinstellung ist 1.
SystemProfileAlpa: Standardwert 0,2. Der Alphawert, der für die Erstellung des Systemperiodenprofils und der wöchentlichen Systemprofilerstellung verwendet wird. Dies ist die Glättungskonstante, die beim Hinzufügen/Glätten des neuen periodischen/wöchentlichen Verkaufsprofils zum alten Profil verwendet wird, nachdem der Prognosejob ausgeführt wurde. Das Hinzufügen ist ein EWMA-Prozess mit diesem Alpha.
PeriodProfileDivideRange: Standardwert 3, gibt an, wie viele Perioden in der zukünftigen Prognose in Tage aufgeteilt werden, wenn eine Woche oder ein Periodenprofil verwendet wird. Wenn auf 0 oder kleiner eingestellt, wird der gesamte Prognosebereich in Tage aufgeteilt. Beachten Sie, dass bei einer vollständigen Aufteilung des Gesamtbereichs in Tage der Speicherbedarf steigt und die Auslastung des Bedarfsplanservers um etwa 3000 % steigt, wenn wir eine monatliche Periode und ein Jahr Prognosehorizont voraussetzen.
AlphaDayQty: Standardwert 0,01. Der Alpha-Wert, der für die Erstellung des normalen täglichen Verkaufs als Verkaufsmenge für den Umsatz verwendet wird, wenn das wiederkehrende Ereignis nicht stattgefunden hätte. Diese tägliche Menge wird verwendet, um die Indizes des wiederkehrendes Ereignisses für jeden Tag innerhalb des wiederkehrenden Ereignisses zu berechnen.
AlphaHolidayIndex: Standardwert 0,45. Der Alpha-Wert, der beim Glätten der Indizes des wiederkehrenden Ereignisses verwendet wird.
siehe Wiederkehrende Ereignisse für Details.
CalculateFutureOrders: Legt fest, ob zukünftige IPR-Aufträge berechnet werden oder nicht. Bei Festlegung auf 1 berechnet IPR prognostizierte zukünftige Aufträge aus der IPR, IPR berechnet zukünftige Aufträge für die in FutureSimulationRange festgelegte Anzahl von Tagen. Bei Festlegung auf 0 werden keine zukünftigen IPR-Aufträge berechnet. Der Standardwert ist 1.
FutureSimulationRange: Definiert die Anzahl der Tage zur Berechnung zukünftiger IPR-Aufträge. IPR berechnet alle Aufträge, die laut Prognose in der hier angegebenen Anzahl von Tagen für alle Artikel mit Planungsmethode B generiert werden sollen, wenn der Parameter „CalculateFutureOrders“ auf 1 gesetzt ist. Der Standardwert ist 365.
OnlyMethodBParts: Legt fest, ob nur Artikel der Planungsmethode B in IPR geladen werden sollen. Wenn auf 1 gesetzt, lädt IPR nur Artikel der Planungsmethode B. Wenn auf 0 gesetzt, lädt IPR auch Artikel mit Planungsmethoden A, D, E, F, G und M. Standardeinstellung ist 0.
LogFile: Bitte prüfen Sie dies vor der Änderung mit einem IFS-Berater.
SkipApprove: Wenn der Wert auf 1 gesetzt ist, werden die IPR-Ergebnisse unabhängig davon berechnet, ob die Prognose während des IPR-Jobaktualisierungslaufs genehmigt wurde oder nicht. Bei der Festlegung des Werts auf 0 muss die Prognose des Artikels genehmigt worden sein, bevor IPR neue Ergebnisse berechnet. Standardeinstellung ist 0.
FilterQtyOnHandByLasModifiedDate: Bitte prüfen Sie dies vor der Änderung mit einem IFS-Berater.
Hinweis: Die im IFS Cloud-Client verwendeten Werte werden für den IPR-Aktualisierungsjob im Bedarfsplanungs-Server verwendet.
BackOrderInterestRate: Standardeinstellung ist 0,1 (10 %). Wird als Rückstandskosten (die Kosten, die bei Nichterfüllung eines Auftrags direkt aus dem Lager entstehen) verwendet, ausgedrückt als Prozentsatz der Kosten des Bestandsartikels. Wird in der Excel-Simulation in IPR verwendet.
NurStandortLaden: Wenn dies angegebenen ist, lädt das IPR-Modul nur Daten für diesen Standort. Standardmäßig ist hier kein Wert angegeben, was bedeutet, dass alle Standorte geladen werden.
SimulationBackOrders: Wenn dieser Wert (in der IPR-Excel-Tabellenkalkulation) auf 1 gesetzt ist, wird während der Simulation ein negativer Bedarf kumuliert, wenn der simulierte Bestand unter 0 fällt. Wenn dieser Wert auf 0 gesetzt ist, stoppt der simulierte Bestand bei 0 und wird nicht negativ. Die Standardeinstellung ist 1 = Auftragsrückstände aktiviert.
SimulationLengthYears: Legt fest, wie viele Jahre die Simulation in der IPR-Excel-Tabellenkalkulation dauern soll. Der Standardwert ist 5 = 5 Jahre.
In: Wird verwendet, um den Wert im Dialogfeld „Artikel auswählen“ zu speichern. Bitte prüfen Sie dies vor der Änderung mit einem IFS-Berater.
Out: Wird verwendet, um den Wert im Dialogfeld „Artikel auswählen“ zu speichern. Bitte prüfen Sie dies vor der Änderung mit einem IFS-Berater.
Periods: Wird verwendet, um den Wert im Dialogfeld „Artikel auswählen“ zu speichern. Bitte prüfen Sie dies vor der Änderung mit einem IFS-Berater.
Dient zur Speicherung der verschiedenen Grenzen für das automatische Saisonprofil und den Algorithmus zur automatischen Saisonprofilgenerierung. Für nähere Informationen dazu siehe Saisonindizes.
MinHistLimitSystemSeasonProfile: Bei Artikeln mit einer geringeren historischen Länge als der hier festgelegten wird das Saisonmuster nicht aus der Historie entfernt. Die Standardeinstellung ist 0: Bei allen Artikeln wird die Saisonabhängigkeit beispielsweise immer aus der Historie entfernt.
AssertLimit: Die maximale Anzahl der Anlagen, die in den Fehlerprotokollen und im Statusbildschirm des Bedarfsplanungsservers angezeigt werden. Standardeinstellung ist 5.
CalculationThreads: Anzahl der verwendeten Threads beim Anwenden von Vererbungsregeln. Die Standardeinstellung ist 8.
DatabaseThreadsDemand: Anzahl der Datenbanksitzungen (Threads), die vom Bedarfsplanungsserver während des Ladens von Bedarfsplanungsdaten verwendet werden darf. Im Allgemeinen gilt: Je mehr Sitzungen der DP-Server verwenden darf, desto schneller wird der gesamte Jobprozess ausgeführt. HINWEIS: Die Ausführung von mehreren Threads führt zu Beeinträchtigung aller anderen Datenbankjobs, die auf dem Datenbankserver ausgeführt werden. Der Standardwert ist 1. Es ist nicht sinnvoll, eine höhere Anzahl Threads als Basis-Flows im Setup des Bedarfsplans zu haben.
DatabaseThreadsLoadIPR: Anzahl der Datenbanksitzungen (Threads), die vom Bedarfsplanungsserver während einer Sitzung zum Laden von IPR-Daten verwendet werden darf. Im Allgemeinen gilt: Je mehr Sitzungen der DP-Server verwenden darf, desto schneller wird der gesamte Jobprozess ausgeführt. HINWEIS: Die Ausführung von mehreren Threads führt zu Beeinträchtigung aller anderen Datenbankjobs, die auf dem Datenbankserver ausgeführt werden. Der Standardwert ist 1. Es ist nicht sinnvoll, eine höhere Anzahl Threads zur Berechnung durch das IPR-Programm als Standorte zu haben.
DatabaseThreadsUpLoad: Anzahl der Datenbanksitzungen (Threads), die vom Bedarfsplanungsserver während des Zurückschreibens von Daten vom Bedarfsplanungsserver verwendet werden darf. Im Allgemeinen gilt: Je mehr Sitzungen der DP-Server verwenden darf, desto schneller wird der gesamte Jobprozess ausgeführt. HINWEIS: Die Ausführung von mehreren Threads führt zu Beeinträchtigung aller anderen Datenbankjobs, die auf dem Datenbankserver ausgeführt werden. Der Standardwert ist 1.
DbBufferSize: Die Puffergröße jedes Blocks, der in der Oracle-Datenbank geschrieben/aktualisiert wird. Die Standardeinstellung ist leer, d. h. 1.000.
SalesPlanVisibility: Legt fest, wie der Server Verkaufsangebote lesen soll, um die zukünftige Auftragspipeline / den Absatzplan zu bestimmen.
Hinweis: Wenn diese Einstellung 0 oder 1 ist, sind die Messungen „Zukünftiger Auftragsverkaufsfaktor“ und „Zukünftiger Auftragsverkaufsfaktor Bereich“ nicht verfügbar Siehe Detailansicht
Einsatzplaner aktivieren: Dient zum Ein- und Ausschalten der Job-Ausführung. Bei Einstellung 0 werden keine geplanten Jobs ausgeführt. Bei Einstellung 1 werden alle geplanten Jobs normal ausgeführt. Dies ist nützlich, wenn Backup-Dateien der Kunden eingesehen werden und geplante Jobs nicht gestartet werden sollen, um zu verhindern, dass die Kundendatenbank aktualisiert wird oder Fehlermeldungen aufgrund von fehlenden Zugriffsrechten auf die Kundendatenbank angezeigt werden. Der vorgegebene Wert ist 1. HINWEIS: Während der Bearbeitung von Positionen müssen diese Felder IMMER LEER sein!
Festes Datum: Der Bedarfsplanungsserver verwendet dieses Datum, unabhängig von Datum/Uhrzeit des Datenbankservers und der Systemzeit des Computers, auf dem der Server ausgeführt wird. Kann bei der Nutzung von Demodatensätzen zum Fixieren der Zeit verwendet werden. Standardwert ist leer, Datum/Uhrzeit werden von der Variablen „UseTime“ definiert. HINWEIS: Während der (Live-)Bearbeitung von Positionen müssen diese Felder IMMER LEER sein!
FlowToRead: Standardmäßig leer. In der Regel nur für Debuggen/Entwicklungszwecke verwendet. Sind schreibgeschützt in den definierten Flows, definieren Sie die Liste durch Kommas getrennt. Basis-Flows, nur mit Vorsicht in kombinierten Flows verwenden. HINWEIS: Während der Bearbeitung von Positionen müssen diese Felder IMMER LEER sein!
Datensatzzählung IPR-Auslastung: Interne DP-Server-Layoutvariable; sollte nicht geändert werden.
WBZ-Methode: Gibt an, wie der Server die WBZ des Artikels behandeln sollte. Die Wiederbeschaffungszeit (WBZ) kann bestimmen, wann mit der Speicherung der historischen Prognose der Artikel begonnen werden soll, sodass die Prognosefehlermessungen (MAE, MAPE...) messen, wie korrekt die Prognose des Artikelbedarfs eine WBZ in der Zukunft ist, anstatt nur den nächsten Prognosezeitraum zu messen.
Der Standardwert ist Wert 0. Diese Einstellung gibt an, wie die periodische Vorlaufzeit berechnet wird und wie wiederum die erklärende Prognose berechnet wird, und damit, wie der beste Treffer/Parameteroptimierer funktioniert.
LoadInventoryHistory: WAHR oder 1, wenn Sie möchten, dass der Server historische Transaktionen lädt, während IPR ausgeführt wird. Dadurch werden historische Daten in der IPR-Excel-Tabelle erscheinen. Der Standardwert ist 0 (FALSE).
Datensatzzählung Auslastung: Interne DP-Server-Layoutvariable; sollte nicht geändert werden.
Protokollebene: Definiert, wie die detailliert die Server-Protokolldatei sein soll. 0-Alle Nachrichten sind protokolliert; 1-Nachrichten über mittlere und schwerwiegende Ereignisse werden protokolliert; 2-Nur Nachrichten über schwerwiegende Ereignisse werden protokolliert. Der Standardwert ist 1.
MaxInheritanceGenerations: Anzahl der Generierungen, der der Bedarfsplanungsserver zurückgeht, wenn Vererbung der Historie für einen Artikel mit definierter Vererbung durchgeführt wird. Standardeinstellung ist 5.
MaxWritebackBuffer: Sagt dem Bedarfsplanungsserver, wie viele Datensätze der max. Grenzwert für den Rückschreibe-Puffer umfasst. Das Festlegen eines Grenzwertes für diesen Puffer verringert den Speicherplatz, den der Bedarfsplanungsserver benötigt. Aber es wird die Laufzeiten der Jobs des Bedarfsplanungsservers verlängern. Die Standardeinstellung ist 0, was bedeutet, dass kein Grenzwert für diesen Puffer festgelegt ist.
Modus: Die Konfiguration für die aktivierten Rechenwerke in der Bedarfsplanung, die normalerweise nur während der Installation/Implementierung eingestellt wird, sollte in der Produktionsumgebung nach dem Start normalerweise nicht mehr geändert werden. 0 - Nur Prognosemodul aktiviert, 1 - Nur IPR-Berechnungsmodul aktiviert, 2 - Sowohl Prognose- als auch IPR-Berechnungsmodul aktiviert.
OutlinerSmoother: Dient zum Glätten (EWMA ist der Alphawert im Modell) von Ausreißerwerten, um eine sortierte Ausreißerliste zu erstellen. Siehe Prognoseartikel auswählen. Der Standardwert ist 0,25. Es muss ein Wert zwischen (0 - 1,0) sein.
Trace: Nur für interne Verwendung durch IFS. Dient dazu, verschiedene Messgrößen für die Leistung auszugeben. Bitte prüfen Sie dies vor der Änderung mit einem IFS-Berater.
TraceLevel: Nur für interne Verwendung durch IFS. Dient dazu, verschiedene Messgrößen für die Leistung auszugeben. Bitte prüfen Sie dies vor der Änderung mit einem IFS-Berater.
TimeshiftCreateForecast: Anzahl der Stunden, die dem SYSDATE hinzugefügt werden, wenn der Job „Prognose erstellen“ ausgeführt wird. Dies ermöglicht, den Prognose-Job wöchentlich am Sonntagabend zu planen, der dann aber weiterhin für Montagmorgen angezeigt wird. Beispiel: TimeShiftCreateForecast ist auf 12 gesetzt. Und der Job „Prognose erstellen“ ist für Sonntag, den 5. Januar, um 19:00 Uhr geplant. Der Job „Prognose erstellen“ wird dann ausgeführt, wenn es für ihn so aussieht, dass das Datum der 6. Januar und die Uhrzeit 07:00 Uhr ist (Sonntag, 05.01., 19:00 Uhr + 12 Stunden). Die Standardeinstellung ist 0/leer. Dies sollte mit Bedacht verwendet werden. Stellen Sie sicher, dass der Gesamtumsatz in der aktuellen Periode (die zu aggregierende Periode) in der Basis-Flow-Tabelle/den Ansichten vorhanden ist, die zum Zeitpunkt der Ausführung des Jobs „Prognose erstellen“ verwendet werden. Dies ist wichtig, da die für diese Periode verwendeten historischen Daten die Daten sind, die zur Ausführungszeit des Jobs „Prognose erstellen“ gelesen werden.
TimeshiftIPR: Die Anzahl von Stunden, die SYSDATE hinzugefügt werden, wenn der Job „IPR-Daten aktualisieren“ ausgeführt wird. Ermöglicht, den Job „IPR-Daten aktualisieren“ sonntags auszuführen, aber den Job „IPR-Daten aktualisieren“ dies weiterhin als Montagmorgen wahrnehmen zu lassen, sodass der richtige Liefertourplan erstellt wird. Beispiel: TimeShiftCreateForecast ist auf 12 gesetzt. Und der Job „IPR-Daten aktualisieren“ ist für Sonntag, den 5. Januar, um 19:00 Uhr geplant. Der Job „IPR-Daten aktualisieren“ wird dann ausgeführt, wenn es für ihn so aussieht, dass das Datum der 6. Januar und die Uhrzeit 07:00 Uhr ist (Sonntag, 05.01., 19:00 Uhr + 12 Stunden). Die Standardeinstellung ist 0/leer. Sollte mit Bedacht verwendet werden. Das dynamische Abdeckungsmodell wird nicht korrekt berechnet, wenn Daten zwischen der Zeit der Ausführung des Jobs „IPR-Daten aktualisieren“ und der Anzahl von Stunden für TimeshiftIPR in der Zukunft eingehen.
Zeit verwenden: TRUE oder 1, wenn der Server Uhrzeit und Datum des Server-PCs verwenden soll, FALSE oder 0, wenn als Zeitvariable die Oracle-Zeit verwendet werden soll. Der Standardwert ist 0 (FALSE).
QtyLostCalculationSource: Wenn der Wert auf 0 gesetzt ist, wird die Systemprognose für die Berechnung von „Menge verloren“ verwendet, wobei für die anderen Werte „Angepasste Prognose“ verwendet wird. Der Standardwert ist 0.
BackupDailyAdjusted: Wenn auf 1 (Ein) gesetzt, wird ein tägliches Backup der täglichen Anpassungen für die Machine Learning-Prognose erstellt, die in Artikeln mit ML-Wetter als Prognosemodell empfangen wurden. Standardmäßig ist dies 1 (Ein). Dieses Backup wird durchgeführt, um Daten für Genauigkeitsmessungen zu sammeln.
SendAllForecastParts: Bei Einstellung auf 1 (Ein) werden unabhängig vom gewählten Prognosemodell alle Artikel im Flow (angegebener Standort) für wetterbasierte Prognosen durch maschinelles Lernen gesendet.
Der Bedarfsplanungsserver sollte ausgeführt werden oder mindestens einmal ausgeführt worden sein.
Abhängig von den Änderungen reagiert der Bedarfsplanungsserver entsprechend.