Use this window to enter the basic setup parameters for the demand planning server.
For the description of each tab in the window, follow the appropriate link: General, Base Flows, Combined Flows, Period Version, Scheduling, DB Idle.
N/A
N/A
This window contains:
Forecast Server ID: The Demand Plan Server ID for this setup.
Description: The Demand Plan server's description.
Use this window to set up how the forecast server will operate when it is started and data is loaded.
This window contains:
Max Historic Length: The maximum number of historical periods for the server to read into memory. The length of each period is determined by the period version. If the period version is monthly, then each period is a month's duration. This is a mandatory field.
Number Of Forecast Periods: How far ahead the forecasts should extend, in periods. The length of each period is determined by the period version. This is a mandatory field.
Forecast Error Periods: The number of periods to go backward from the last historical demand if you are calculating MAE, MAPE, ME, and Value of MAE.
Measurement Periods: The number of periods to go backward from the last historical demand if you are calculating Their.
Copy Rule: When moving from one period to the next, the system creates a new system forecast. The following alternatives exist as initial settings for the adjusted forecast:
From System means that the adjusted forecast is set to the system forecast for each new forecast made.
To Zero means that the adjusted forecast is always set to 0 for each new forecast made.
From Previous Adjusted means that all periods that were adjusted in the previous forecast are copied to the new forecast, while periods not adjusted are copied from the system forecast. Note that events are not set as fixed adjustments, so for periods with event adjustments will follow the system forecast with the event added.
From Previous means that all adjusted values from the previous forecast are copied to the new forecast adjusted values.
Default Forecast Model: The global default forecast model, used when there are no standard models set on a forecast part. See Forecast Models.
Default Alpha: The default alpha is used when no alpha value is specified on a part. This is a mandatory field. See Forecast Models.
Default Beta: The default beta is used when no beta is specified on a part. This is a mandatory field. See Forecast Models.
Default Rho: The default rho is used when no rho is specified on a part. This is a mandatory field. See Forecast Models.
Default Moving Average Periods: The default number of periods used in the moving average model when no value is specified on a part. This is a mandatory field. See Forecast Models.
Default Delta: The default delta is used when no delta is specified on a part. This is a mandatory field. See Forecast measurements.
Default Season Profile: Whether a season profile is used for the part. The default season profile (Yes) is used when no season profile is specified on a part. If No is selected, no season profile is used for the part. This is a mandatory field. The default season profile, also called automatic, is the system profile for the part's historical pattern. Note that the part must pass the season profile test to have a profile assigned. See Season Profiles. (Automatic Generation of Season Indexes is the has season profile test).
Group 1...6: Connects group 1 to an IFS application group field. Using the Demand Plan Server, it is possible to view and modify forecasts on groups of parts. For example, you can modify the total forecasts made for all the parts belonging to a specific product family. It is also possible to combine two or more groups, i.e., to see the total forecast for all parts within a specific product family and a specific ABC Class. Max six different group fields can be selected.
The following fields can be used to group parts: Part Product Code, ABC Class, Type Code, Lead Time Code, Planner Buyer, Asset Class, Prime Commodity, and Second Commodity. It is possible to add other fields from other IFS tables; see Release Notes.
Use this window to define base flows. To better understand the concept of base flow, see Define flows.
You can define flows indefinitely on a site, but only one of them can be a master flow. If you are going to use the standard views (INTERNAL_INVENT_PART_ISSUE_PUB or EXTERNAL_INVENT_PART_ISSUE_PUB) as the origin of your base flows, use the Base Flow Wizard to create them.
Note that when you do not run the Demand Server with the appowner user you might have to prefix the tables/views used in the base flow SQL's with the appowner user to avoid access problems.
| Menu Choice | Activity |
| Delete Flow | Deletes the entire flow. |
| Change Flow Definition | Allows you to change the flow definition from the dialog Change SQL Statement. |
| Define Flows |
This window contains:
Flow ID: The flow's identity, auto-generated and read-only.
Flow Description: A characterization of the flow.
Site ID: The origination site for the base flow. This field is mandatory.
Site Description: A read-only specification of the site.
Master Flow: Specifies whether the base flow is a master flow. The forecasts in a master flow are exported to a forecast day tab, allowing other IFS modules to use it. These forecasts are exported to the site found in the Site ID field, meaning that only one flow connected to a specific site can be the master. If none of the flows connected to a site is a master flow, the forecast will not be exported to the forecast day tab.
Write back flow: Yes here will cause the flow to be written back to FORECAST_FLOW_DAY_PUB regardless if it is a master flow or not. The flow will be written back in the same way master flows are written back to FORECAST_DAY_PUB, the only different is that the flow id is included in the FORECAST_FLOW_DAY_PUB view to differentiate between the different flows.
SQL Statement: This defines the transactions to be used to aggregate historical demand. This SQL statement must be written according to the following general format:
SELECT site(contract), part_no, date, quantity
FROM some_table
WHERE some_field = some_thing AND some_field = some_thing_else
The fields site, part_no, date, and quantity must appear in that order. The FROM statement must list only one table and have no joins. This is a necessary limitation because the SQL statement is modified by the Demand Planner Server before it is executed. The server puts on a 'where' clause, Site = Connected Site, to ensure that only transactions connecting the flow's site are included in the flow. The server also adds a 'where' clause to limit the range in time of the transactions.
This way of setting up flows provides maximal flexibility, but it is easy to make errors. To counter this, we have made the predefined views Internal_Invent_Part_Issue_Pub and External_Invent_Part_Issue_Pub. These views must be used whenever possible. If you decide to select directly from a view, then beware of the following pitfalls:
Internal_Invent_Part_Issue_Pub contains all the internal consumption of parts; it can be defined as follows:
SELECT contract, part_no, date_issued, qty_issued FROM Internal_Invent_Part_Issue_Pub
All external consumption (Customer Orders) can be defined as follows:
SELECT contract, part_no, issue_date, issue_qty FROM External_Invent_Part_Issue_Pub
Here, you can define the forecast to be made on the issue quantity and date as shown in the example, or you can use the desired, promised, or planned quantity and date. In this manner, you can set the quantity and date the customer wants, instead of the quantity and date you are able to deliver.
A flow over all external consumption on a site by customer (cust1) is defined as follows:
SELECT contract, part_no, issue_date, issue_qty FROM External_Invent_Part_Issue_Pub WHERE Customer_no = 'cust1'
'Note the demand plan server does not like advanced sql, do not use nested SQL statements. Keep it simple!
SELECT contract, part_no, issue_date, issue_qty FROM External_Invent_Part_Issue_Pub WHERE <Some clause>
Remember to prefix with APPOWNER if you are planning to run the DP server from another user than the appowner.
Use this window to set up combined flows, i.e., flows consisting of two or more base flows.
| Menu Choice | Activity |
| Delete Flow | Deletes the flow. |
| Edit Combined Flow | Allows you to change the flow definition from the dialog Combined Flow. |
| Define Flows |
This window contains:
Flow ID: The system-generated ID of the combined flow.
Flow Description: The name of the flow.
Site ID: The site associated with the flow, if any.
Site Description: The description of the site.
Master Flow: States whether the flow is a master for the site. The forecasts in a master flow are exported to the forecast day tab, allowing other IFS modules to use it. The forecasts are exported to the site found in the Site ID field. This means that only one flow connected to a specific site can be the master. If none of the flows connected to a site is a master flow, the forecast will not be exported to the forecast day tab.
Use this window to generate and define the period intervals the demand planning server will use for forecasting. Note if you are setting another period version than monthly, you should also consider to change some of the best fit forecast model limits. See Registry Settings for details. When setting up period versions you need to consider the allotted time intervals. You are not allowed to have any holes or overlapping entries. To validate that you have entered dates correctly you may run the Validate Dates method. If everything is ok the Date valid flag will be checked, otherwise an error message describing the problem will appear. Note that after an upgrade the flag will be switched off for all period versions and you need to run the method to validate your setup.
This window contains:
Start Year: The starting year for generating the periods. You cannot specify a start year prior to the current year.
End Year: The ending year for generating the periods. You cannot specify an end year prior to the current year.
Validate Dates: Indicates whether or not the dates in the child table conform with the validation rules. To test a modified period version run the Validate Dates RMB method.
Dates Valid: Indicates that the period version is valid.
The Change Period Group consists of:
Weekly: Activate this radio button to create weekly periods. (The year is divided into 52 periods.)
Monthly: Activate this radio button to create monthly periods. (The year is divided into 12 periods.)
Quarterly: Activate this radio button to create quarterly periods. (The year is divided into 4 periods.)
User Defined: Activate this radio button to specify the number of periods into which the year should be divided. If you choose this option, you must type each start date/end date for each period in the table below.
Periods Per Year: The number of periods into which the year is divided. This field is editable only when user-defined periods are chosen.
Create New Period Version: This button generates a new period, based on the parameters set. This option replaces the existing periods with the set you generate.
Add Periods: This button is used to add periods to an existing set of periods.
Description: The year and period number. This description is displayed on the legend of the x-axis in the forecasting client graph.
Start Date: The start date of the period.
End Date: The end date of the period.
Length (Days): The length in days of the period, read-only.
Use this window to set up and schedule jobs. The window always contains eight jobs; it is not possible to add or delete any.
This window contains:
Job: The name of the job.
A normal schedule with Demand Planning includes a Create forecast job at the beginning of the forecast period. together with a Forecast Write back File job that is ran every 30 minutes. The minimum schedule is to have a Create Forecast jog scheduled.
If you only are running IPR then the only job you should schedule is the Refresh IRP Data.
Scheduled Type: Indicates how often the job is scheduled to run. Possibilities are:
Scheduled Date: The schedule's start date. The date works a little different when periodically is selected it is best illustrated with an example imagine using monthly period version if you set at date lets say the 5th then the periodically schedule type will give a scheduled date that is always 5 days into each new period when the period changes. E.g. Scheduled date 5.10.2008 then the next scheduled date will be 12.10.2008 if weekly periods where selected. Assuming that you have weeks starting on a Monday and ending on a Sunday. Since the 5.10.2008 is a Friday and this is 5 days into the period (week), then the next scheduled date will be the 5 days into the next period (week) 12.10.2008. This will be a good schedule type if you want the job to be executed in the beginning of a period and have strange period versions (weeks, 26 periods etc).
Scheduled Time: The time of day the job is scheduled to start.
Scheduled Minute: The interval between each job, in minutes. This field is active only when Scheduled Type is set to Minute.
Job Started: Clocks the time when the scheduled job is started. See Scheduled Job Alarms.
Writeback Done: Clocks the time when the write back of data to database is completed after the job has computed new results. See Scheduled Job Alarms.
Job Status: The status of the job it it's finished or something has gone wrong. The purpose of this field (together with the Job Started and Writeback Done) is to be able to write a event/trigger and send e-mail / SMS to certain individuals when a Demand Plan Server or IPR server job has not gone OK or when it has gone OK. See Scheduled Job Alarms.
Number of Qualification Periods: This is a parameter for Job Qualify only. This number specifies how many periods to go back from the current period when qualifying for forecast parts. The qualifying job checks the number of transactions for each part and adds or deletes forecast parts, depending on whether they fall within different numbers of transactions. For example, If 0 is set in this field only the current period is used. If the setting is 1, then the current period and the immediately previous period are used.
Minimum Number of Transactions to Qualify As: This is a parameter for Job Qualify only. It specifies the lower limit of transactions for an inventory part if it is to be added as a forecast part. All parts that have equal or more than this number of transactions is added to the forecast part table.
Maximum Number of Transactions to Delete: This is a parameter for Job Qualify only. The inventory part must have a number of transactions less than this one in order to be deleted from the forecast part register.
Backup Path: This is a parameter for the Job Forecast write back file only. It specifies the path where the backup HD files are stored.
Number of Backups: This is a parameter for the Job Forecast write back file only, specifying the number of backup files stored on the HD. For example, if zero (0) is selected, only the last backup file remains in the backup path directory. If 1 is selected, the second oldest backup file is present, along with the new one. The files are named with the date and time of the backup; the extension is .BAK.
Refresh Data: This is a parameter for the Create Forecast, check box indicates if we should run a data refresh of the database or not at the end of the create forecast job, this is the same job as the Refresh DP Data job that can be scheduled separately. Not including the refresh job will speed up the time the create forecast job takes to perform. Only enabled when in the Create Forecast job.
External Command: This is a parameter for the External Export and the External Import jobs. External PL/SQL function name doing the Import/Export job, this can be created by IFS Data migration.
This version of Demand Planning has no scheduled write back job, instead we have implemented the write back to the database to run in parallel with the normal operation. During certain times of a day or week it might be that you do not want the Demand Server to update the data base at all (backup times) or to update the database with reduced speed. That's the purpose with this tab.
Use this window to set up and when you want the Demand Plan Server write back job to have full, only partial or no access to the Data Base. With no records defined here the DP Server write back job will run at full speed constant. So you only need to specify when you NOT want the DP server to run with full speed.
This window contains:
ID: The ID of the idle record.
Description: Description.
Start Time: When should the new idle time start.
End Time: When should the new idle time start.
Percent: What percentage of the DB capacity do you want DP to use. 100 the DP server runs with full speed no delays, 50 the DP server waits as long as it takes to run each command before running the next, 25 the DP server waits 25 % longer that it takes to run the previous command before running the next command.
Monday: Tick of if you want the idle settings to be valid for Mondays.
Tuesday: Tick of if you want the idle settings to be valid for Tuesdays.
Wednesday: Tick of if you want the idle settings to be valid for Wednesdays.
Thursday: Tick of if you want the idle settings to be valid for Thursdays.
Friday: Tick of if you want the idle settings to be valid for Fridays.
Saturday: Tick of if you want the idle settings to be valid for Saturdays.
Sunday: Tick of if you want the idle settings to be valid for Sundays.
Tells you about the status of the Demand Plan Server, the IPR Server and the Write back engine. You see what the servers are doing right now, and if there are any records on queue to be written back to the database. You can also see and filter on the log and error messages produced by the Demand Plan / IPR Server. There is also possible to start the different Demand Plan & IPR Server jobs from there.
This window contains:
Server: Shows the status of the Demand Plan Server.
Host: The address of the machine the Demand Plan / IPR server is running
Port: The port number of the communication with the server
Job: Shows the job the server currently is running, you can also start jobs from here.
The following jobs/tasks can be started
| Stopping server | Stops the the Demand Plan / IPR Server |
| Complete Writeback to database | Writes back the total contents of the Server back to the data base no matter if the records is changed (dirty) or not. So every thing in the server is written to the data base. |
| Qualify Parts | Opens the Qualify Input dialog, which is used to qualify and disqualify parts as forecast parts. |
| Refresh DP Data | Looks for changes in the DP data done in IFS Applications, deleted parts, added parts or changes done to forecast parts. NOTE that you still need to take down (File-Exit) the server BEFORE any changes in the Demand Plan Server Setup dialog is to be done. |
| Create Forecast | First, aggregates historical demand from the newest historical demand period to the current period - 1. Then it generates the forecast for the current period and the specified number of forecast periods into the future. See Demand Plan Server Setup/General. |
| Send auto trolleys | This will send out all trolleys that are defined with the auto send parameter. See Send Trolley. Note Trolley function has a replacement function in this release (Demand Forecast & Publish Parts in IEE), and the function will be removed in future releases. |
| Define Budget base | Sets the budget equal to the system forecast for all parts on the base flows. This will give a good budget on each individual part when entering the budget on an aggregated level. Note that the only level where a 1005 accurate budget revision can occur is the level where you enter it. But the budget on each part will be the best approximation for a part by part budget. |
| Define Target Sales Plan base | Sets the target sales plan equal to the system forecast for all parts on the base flows. This will give a good target sales plan on each individual part when entering the target sales plan on an aggregated level. Note that the only level where follow up on target sales plan can occur 100% accurate is the level where you enter it. But the target sales plan on each part will be the best approximation for a part by part target sales plan. |
| Delete Unused season profiles | This job deletes all unused season profiles form the library. |
| Aggregate daily | Aggregates historical demand from the start of the current period to the current day. |
| Complete Refresh DP Data | Will refresh ALL data in demand planning with the database. This also reads changes done to Budget or Target Sales Plan lines, in short reads all DP data from the database. Only Possible when DP is enabled. |
| Retry | Retries to start the online write back process, typically after an critical error has occurred. |
| Lock/Unlock Server | Turns server locking on and off. If the lock is on, clients cannot change forecasts. |
| Turn On IPR Simulation mode | Sets the Demand Plan Server in IPR Simulation Mode. In this mode the DP server will not write back any data when running IPR. Allows the user to do simulation changes in IPR hierarchy and take out Excel reports of the result without IPR Changes being written back to the Database. |
| Refresh IPR Data | Will update all IPR changes made to Inventory parts in IFS Supply Chain, and recalculate the new IPR result. |
Execute: Starts the selected job.
Status: The status of the Demand Plan Server (what jobs etc its currently doing) idle means that its ready to serve Demand Plan Clients.
IPR: Shows the status of the IPR Server
Status: The status of the IPR server. What jobs etc the IPR server is currently doing.
Writeback: The status of the write back engine
Status: Tells if everything is OK with the Oracle connection and how the write back of data is going
Prioritized Records: Number of IPR results on queue (Lot Size, Safety Stock, Order Qty / Inventory part updates)
Standard Records: Number Demand Planning result records on queue.