Define Flows
Explanation
Here you define the demands for which you want to create forecasts. In the supply chain there are different flows of parts from different sites to different customers. A flow is a subset of transactions in one of these flows, typically based on transactions found in the customer order lines. Different flows make it possible to split demand into groups and to make a separate forecast for each group.
The figure above represents the flow of parts from the warehouse (a typical site in IFS) to two customer groups. Flow 1 represents the demand from customer group 1 (C1), and flow 2 represents the demand from customer group 2 (C2). These flows are called base flows because they cannot be broken down into smaller pieces. It is impossible to see the demand from a specific customer within the group.
A base flow represents the demand from a specific distribution channel. For each base flow, you define which transactions the flows contain. The transaction is then aggregated into periods (defined by the period version), and a forecast is made for each flow. Each base flow has its own set of forecast parts. Each part includes historical demand and a forecast.
If you want to make a forecast of all demand originating from the warehouse, you can make a new flow called flow 3 that contains the demand from flow 1 and flow 2. This is called a combined flow, i.e., it contains two or more base flows. The demand on a combined flow is calculated by aggregating the demand found in the base flows. The same is true for adjusted forecasts. This aggregation is done on the fly in the Demand Plan Server. Therefore, when you modify the adjusted forecasts in flow 1, this directly affects the adjusted forecasts in flow 3. Similarly, an increase in adjusted forecasts for flow 3 by 10% results in the forecasts for both flow 1 and flow 2 to be increased by 10%.
In addition to base and combined flows, there is imported flow. Imported flows are the same as base flows, except that they receive, via e-mail, flows created by other demand plan servers. You can also set up which flows are to be exported form this demand plan server to other demand plan servers. The same flow can be distributed to many demand plan servers. The receiving servers must have some imported flows to store the exported flows from the sending servers.
Field information available in Demand Plan Server Setup, Base Flow list are described in below,
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.
Forecast By: The available settings in this field is determined by the setting on Site/Manufacturing DP Import Forecast By field. When set to Part the base flow forecast will only be available other IFS components if it set to be a Master Flow for the site. Other Possible settings for this field are Customer, Customer Stat Group, Market, Region, District or Country, note that only 2 settings are available the Part and the one set on Site/Manufacturing/DP Import Forecast By. When set to one of these (different from Part) the base flow SQL should fetch the relevant history for the selected Forecast by ID defined dimension (see below). When one of these other settings are defined the forecast for the flow will be available for Master Scheduling to import by customer dimensions, you can see the resulting forecast in Exported Forecast By Dimension screen.
Forecast By ID: The available settings are determined by the setting in Forecast By (Site/Manufacturing/DP Import Forecast By), if Forecast By is set to Part then the setting is this field is not used. When Forecast By Id is set to any of the other values (Customer, Customer Stat Group, Market, Region, District or Country). The value here will determine the key in the Exported Forecast By Dimension view/screen, thus making this flow a master flow for the selected Forecast By dimension. The Base Flow SQL should then collect the historical data that corresponds to the setting in this field. Example lets say the Forecast By setting is Customer (defined in the site/manufacturing setting) and the Forecast By ID setting is Cust1. Then an example on a base flow SQL could be SELECT contract, part_no, issue_date, issue_qty FROM comb_ext_inv_part_issue_pub WHERE customer_no='Cust1'
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:
- Avoid transaction types that should not be included.
- Be sure to include all transaction types that should be included.
- Returns should (if possible) have the same date as the original transaction.
- Returns must have a negative quantity; otherwise, they are counted as demand for the second time.
- Instead of Delivered Quantity and Delivered Date, you should set (if possible) the Desired Quantity and the Desired Delivery Date.
Using Internal_Invent_Part_Issue_Pub
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
Using External_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'
Using Comb_Ext_Inv_Part_Issue_Pub
This view is a join between External_Invent_part_Issue_Pub and the transactions added in Manual Historical Demand Planning Data screen. Making this view ideal when you want to import transactions from other systems into IFS Demand Planning to get a longer historical data then the time span with 'real' IFS customer orders in the system.
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 comb_ext_inv_part_issue_pub WHERE customer_no='Cust1'
Data From IFS Request Management
There are created 2 new views that fetched consummation data from IFS Request Management
Planned_Material_Demand - Material planned on Recurring Services (Future Demand) and consumed on Request Work Tasks (Historical Planned Demand). This is demand/transactions that origins from a planned preventive service.
This view consist of the following fields
| Name | Type | Description |
| CONTRACT | VARCHAR2(5) | Contract / site where the consumption origins |
| PART_NO | VARCHAR2(25) | The part number used |
| PLANNED_DATE | DATE | The planned date for the usage |
| PLANNED_QTY | NUMBER | The planned quantity for the usage |
| ISSUE_DATE | DATE | The actual date for the usage |
| ISSUE_QTY | NUMBER | The actual quantity for the usage |
| CUSTOMER_NO | VARCHAR2(20) | The customer the service was delivered for |
| SERVICE_ORGANIZATION | VARCHAR2(20) | The service organization that delivered the service |
| SERVICE_DELIVERY_UNIT | VARCHAR2(20) | The service delivery unit that delivered the service |
UnPlanned_Material_Demand - Material consumed on Request Work Tasks (Historical Un Planned Demand). This is demand/transactions that origins from service/repairs that is not part of any planned preventive maintenance, also called corrective service demands
This view consist of the following fields
| Name | Type | Description |
| CONTRACT | VARCHAR2(5) | Contract / site where the consumption origins |
| PART_NO | VARCHAR2(25) | The part number used |
| ISSUE_DATE | DATE | The actually date for the usage |
| ISSUE_QTY | NUMBER | The actually quantity for the usage |
| CUSTOMER_NO | VARCHAR2(20) | The customer the service was delivered for |
| SERVICE_ORGANIZATION | VARCHAR2(20) | The service organization that delivered the service |
| SERVICE_DELIVERY_UNIT | VARCHAR2(20) | The service delivery unit that delivered the service |
These views are intended to be utilized as part of a broader logistics support framework for managing parts used in service and maintenance within IFS Cloud. The objective is to leverage Demand Planning to generate a forecast for future demand associated with service operations (Request Management). This comprehensive forecast can then serve as input for Inventory Planning and Replenishment (IPR) to determine reorder points, safety stock levels, and lot sizes for parts required in the Request Management/service process.
This approach ensures optimal inventory levels to effectively meet service demands. It is important to note that IPR should be configured using a specialized combination of the available models within the system. The recommendations are as follows:
Demand Model : Forecast
Safety Strock Model : Time Coverage or Mean Absolute Error
Lot Size Model : Any one of the models can be used really most relevant will be (Time Coverage, Economic Lot Size or Dynamic Coverage)
Order Point Model : Lead Time Driven
Note there might be reasons to deviate from these but combo's of these should be the base line.
A typical set up in Demand Planning will then be these base flows :
Service site S1 - Planned Demand base flow sql "SELECT contract, part_no, issue_date, issue_qty FROM planned_material_demand"
Service site S1 - Un Planned Demand base flow sql "SELECT contract, part_no, issue_date, issue_qty FROM unplanned_material_demand"
Then you create a combined flow that consist of the to Service Site S1's 2 base flows this combiend flow will be master for the Service site S1 to be used for further planning in IPR.
Important
'Note the demand plan server has not been designed for 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.
Prerequisites
- This activity requires that the parameters specified on the Demand Plan Server/General tab are defined.
System Effects
There are no system effects until the server is started.