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.

wpe4.jpg (6284 bytes)

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 informatoin 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.

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:

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'

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

System Effects

There are no system effects until the server is started.