GENTEX ASCP PLAN

Consumption in ASCP, Saphran Forecast

Netting in customization and Saphran
Forecast Interface
Prepared by: Deepak Khosla and Shailender Pushkarna
Ramananda Nayak, Fujitsu Dec 22, 2008
2
Contents
Gentex EBS Forecasting Flow
Forecasts for ASCP
Forecast Consumption within ASCP: Options and Option Evaluation
Saphran Forecast Interface, Saphran Netting against Radley, Derive
Truncated Saphran Forecast Prior to ASCP
Saphran data mapping- Requirements
Forecasting- EBS Setups
Action Items
Conclusions
Questions

3
Gentex EBS Forecasting Flow
Collect
Radley FC,
Truncated
Saphran FC,
Manual FC
and Sales
orders
ASCP
System
Planner/
Schedule
r
Receive
Corporate
forecast from
Saphran into
EBS
Saphran Interface
Run & Monitor
ASCP Plan
(Constrained)
with the
collected
Forecast sets
ASCP
Receive
Radley EDI
Forecast into
EBS
Radley Interface
Consume
Forecast
against Sales
orders at Item-
Customer
level
ASCP
Net Saphran
Forecast
against Radley
at item-
Customer level:
Custom logic
Custom-Interface
Derive
Truncated
Saphran Net
forecast as
input to ASCP-
Toggle weeks
Custom-Interface
Run MRP
Detail Report
Custom Report
Analyze
consumption
details,
Compare
Forecasts
MRP Report
Analyze ASCP
Forecast
Consumption
on the ASCP
Workbench
ASCP
Manual
Forecast-
Automotive,
Fire
Protection
Forecast
Note: Please refer to the MD50 for details on netting logic.
4
Forecasts for ASCP
Receive Radley Forecast from Customers.
Receive Saphran Forecast.
Net Original Saphran Forecast with the Radley Forecast at ship from
org-item-customer level.
Derive a final Saphran-Truncated Forecast which will be used as
one of the inputs to ASCP.
The idea is to use Radley until a time limit and a combination of Radley
and Saphran after that time limit.
Input Radley and Saphran-Truncated forecasts as demands to
ASCP along with Sales Orders.
Thus the final independent demand inputs to ASCP will be:
Radley EDI Forecast
Sales Orders
Saphran-Truncated Forecast
Manual Forecast
Safety Stock Targets (Bucket days and Percent)
Forecast Consumption within ASCP:
Options and Option Evaluation
Ramananda Nayak, Fujitsu Dec 22, 2008
6
Option1: Item-Customer ship to/Bill To level
Example: Item 905-1016-006: Time bucket: 01-Jan-2008.
Initial Forecast input to ASCP:
FC1: Customer: GM-CAMI, ship_to:Kigstone, qty: 1000
FC2: Customer: GM-CAMI, ship_to:Ingersol, qty: 900
Sales orders input to ASCP:
SO1: Customer: GM-CAMI, ship_to:Kigstone, qty: 1200
SO2: Customer: GM-CAMI, ship_to:Ingersol, qty: 150

After consumption at ship-to level in ASCP:
Consumed Forecast in ASCP:
FC1: Customer: GM-CAMI, ship_to:Kigstone, qty: 1000-1200==>0----
Overconsumption exception.
FC2: Customer: GM-CAMI, ship_to:Ingersol, qty: 900-150=750.
Total FC qty after consumption: 0+750=750.

Sales orders input to ASCP:
SO1: Customer: GM-CAMI, ship_to:Kigstone, qty: 1200
SO2: Customer: GM-CAMI, ship_to:Ingersol, qty: 150
7
Option1: Item-Customer ship to/Bill To level
8
Option2: Item-Customer level
Example: Item 905-1016-006: Time bucket: 01-Jan-2008.
Initial Forecast input to ASCP:
FC1: Customer: GM-CAMI, qty: 1000
FC2: Customer: GM-CAMI, qty: 900
Sales orders input to ASCP:
SO1: Customer: GM-CAMI, ship_to:Kigstone, qty: 1200
SO2: Customer: GM-CAMI, ship_to:Ingersol, qty: 150

After consumption at customer level in ASCP:
Consumed Forecast in ASCP:
FC1: Customer: GM-CAMI, qty: 1000-1200==>0.
FC2: Customer: GM-CAMI, qty: 900-(200+150)=550.
Total FC qty after consumption: 0+550=550.
Sales orders input to ASCP:
SO1: Customer: GM-CAMI, ship_to:Kigstone, qty: 1200
SO2: Customer: GM-CAMI, ship_to:Ingersol, qty: 150
9
Option2: Item-Customer level
10
Option3: Item level
Example: Item 905-1016-006: Time bucket: Jan-2008.
Initial Forecast input to ASCP:
FC1: qty: 1000
FC2: qty: 900
Sales orders input to ASCP:
SO1: Customer: GM-CAMI, ship_to:Kigstone, qty: 1200
SO2: Customer: GM-CAMI, ship_to:Ingersol, qty: 150
SO3:Customer: HONDA, ship_to:Honda Pkwy, qty: 250

After consumption at customer level in ASCP:

Consumed Forecast in ASCP:
FC1: qty: 1000-1200==>0.
FC2: qty: 900-(200+150+250)=300.
Total FC qty after consumption: 0+300=300.

Sales orders input to ASCP:
SO1: Customer: GM-CAMI, ship_to: Kigstone, qty: 1200
SO2: Customer: GM-CAMI, ship_to: Ingersol, qty: 150
SO3:Customer: HONDA, ship_to: Honda Pkwy, qty: 250
11
Option3: Item level
12
ASCP Can not consume at Customer Plant Level
ASCP consumes Forecast against the sales orders only at
one of the following levels:
Item Level
Item-Customer Level
Item-Customer-Ship To/ Bill To Level

Thus, ASCP consumption logic does not recognize the
custom defined DFF for customer plant and can not
consume at customer plant level.

Since the Radley is at Customer dock (EDI Location) level
where as Saphran forecast at customer plant level, the
forecast consumption at Ship To level becomes complex
within ASCP and may not give expected output.

13
Evaluation -Option3: Item level
This Option may not suite GENTEX as it allows consumption across customers for the same
item.
But, may be valid if the items are unique to each customer.

Mapping data Required from Saphran team: The following entities exactly match that in EBS.
Item
Ship-from org

Pros:
1. This will reduce the number of records in the forecast set-up, which reduces lot of maintenance.
2. This will also reduce the risk of data not matching as it is at higher aggregation level.
3. Data mapping between Saphran and EBS forecast tables will be much easier.
4. Number of Forecast names to be set up required per Forecast Set = 1.
Cons:
1. If the same item belongs to multiple customer/ ship_tos, then the customer/ shipto-wise
consumption comparison is not possible.
2. The logic of custom forecast consumption will change to item level. RIE needs modification.
3. The setup and logic of Saphran forecast toggle using DFF (no. of weeks) needs to be modified in
the RIE.

The Saphran toggle weeks may have to be defined at item-Ship from org level rather than
at customer ship-to level.
14
Evaluation Option1: Customer site level:
This option requires forecast data to be setup at customer ship-to level in EBS for both
Radley and Saphran, which will be a huge setup effort and yet incomplete. This in turn
requires data from Saphran at customer ship-to id level, which is a challenge as of now to
get Saphran data at ship-site id level.

Mapping data Required from Saphran team: The following entities exactly match that in EBS.
Item
Ship-from org
Customer (or Customer plant)
Customer Ship-To

Assumption: If customer plant is used as mapping entity instead of customer, then each
customer plant can not belong to more than one customer.

Pros:
1. Consumption and Comparison of forecast will be at a ship-to site level granularity.

Cons:
1. Huge mapping and setup effort from Saphran as well as EBS side and may be incomplete.
2. This requires forecast data to be setup at customer ship-to level in EBS for both Radley and
Saphran. Number of Forecast names to be set up required per Forecast Set = No. of Customer
sites being shipped.
3. Mapping and data inaccuracies have direct impact on plan output.
4. The current Saphran Forecast interface and custom netting between Radley and Saphran may
not be accurate due to mapping challenges.
15
EvaluationOption2:Customer level- Recommended
The comparison of forecast will be at the Item-Customer level rather than item-ship to level. Where ever the
item-customer dock/ship_id relationships are unique , this qty will match even at the granular level of
ship_to.

Mapping data Required from Saphran team: The following entities exactly match that in EBS.
Item
Ship-from org
Customer (Customer plant)

Assumption: If customer plant is used as mapping entity instead of customer, then each customer plant can
not belong to more than one customer.

Pros:
1. This will reduce the number of records in the forecast set-up, which reduces lot of maintenance. Number of
Forecast names to be set up required per Forecast Set = No. of Customers being shipped.
2. This will also reduce the risk of data not matching as it is at higher aggregation level, but at more granular level
than Option1.
3. Data mapping between Saphran and EBS forecast tables will be much easier, but effort will be more than Option1.

Cons:
1. If the same item belongs to multiple ship_tos, then the customer/ shipto-wise consumption comparison is not
possible.
2. The logic of custom forecast consumption will change to item-customer level. RIE needs modification.
3. The setup and logic of Saphran forecast toggle using DFF (no. of weeks) needs to be modified in the RIE.

The Saphran toggle weeks should be defined at customer level. The toggle weeks will be unique for that
customer, but applicable to all items under that customer.
Saphran Forecast Interface, Saphran Netting
against Radley, Derive Truncated Saphran
Forecast Prior to ASCP
Ramananda Nayak, Fujitsu Dec 22, 2008
17
Saphran Forecast Interface Original Forecast
In each Ship from org, setup Forecast sets and Forecast
Names at each customer level for getting Saphran forecast
data.

Receive Flat file from Saphran Team with mapped entities

Clear all the old entries and populate the new forecast data

Send notifications for the failed/ error records

This will be original Saphran Forecast.
18
Saphran Netting Against Radley- Netted Saphran
In each Ship from org, setup Forecast sets and Forecast
Names at each customer level for storing netted Saphran
forecast details.

Netting at item-customer level:
For a given combination of ship from org-item-customer, in a given
time period (month), calculate netted qty using the following
formula:
Saph_Netted in the period= (Saph_Original- (Shipped SO+ Greater
of (Open SO's and Open Radley forecast).

Clear all the old entries and populate the new forecast data
19
Truncated Saphran from Net Saphran Forecast
In each Ship from org, setup Forecast sets and Forecast
Names at each customer level for storing the truncated
Saphran forecast details to be used by ASCP.

Logic to derive Truncated Saphran Forecast:
Set up 2 DFFs to enable toggle and enter toggle weeks
For a given combination of ship from org-customer, get the netted
Saphran forecast quantities available only after the toggle weeks.

Clear all the old entries in the truncated forecast set and
populate the new truncated forecast data.
20
Truncated Saphran from Net Saphran Forecast
21
DFFs to define Toggle Weeks
22
Saphran data mapping- Requirements
Saphran Netting
Earlier it was decided to have Saphran netting at customer plant level.
AS ASCP consumption is recommended at item-Customer level, we will have the same
consumption logic for the customized Saphran Netting.

Saphran Forecast Interface and mapping:
With Option2, the mapping file is expected to have the following minimum information:
Ship from org (Gentex Plant)
Customer Name
Customer Plant
Item
Bucket
Date
Qty

with the following minimum entities matching exactly that in EBS:
Ship from org (Gentex Plant)
Customer Name (or Customer Plant)
Item number

The Customer plant DFF in customer master will be used for mapping the Saphran Customer Name to
the EBS customer Name.
Assumption: If customer plant is used as mapping entity instead of customer, then each customer plant
can not belong to more than one customer.
FORECASTING EBS SETUPS and ACTION
ITEMS -assuming Option2
Ramananda Nayak, Fujitsu Dec 22, 2008
24
Defining Forecast Names
There should be as many number of forecast names as the number of customers in each of the forecast
sets for Radley and Saphran in each Ship-from org.
Radley will transfer the forecast data for different ship-to/ docks to the same forecast name
corresponding to that customer.

Saphran will transfer the forecast data for different customer plants to the same forecast name
corresponding to that customer.

Challenge in defining Forecast names at customer level: If there multiple customers with the same
name in EBS, data loader process fails.
Solution1: need to handle such records manually, which may require a 2 day effort during cut-over.
Solution2: Take help from conversion team to code and upload the forecast names and Source list
using an API.

The Toggle DFFs should be defined at either:
item level. The toggle weeks are unique for that item only. This calls for more setup more coding
effort.
or
customer level. The toggle weeks will unique for that customer, but applicable to all items under
that customer.

This will be a business user setup.

Question: Which of the above two toggle setups can be finalized?

Ans: Recommended based on effort and maintenance: Define toggle at customer level.
Client approved setup:
25
Defining Forecast Names
26
Defining Forecast Items and Forecast Details
27
Defining Source List for Radley EDI Transfer
28
Action Items (in the order of Sl. Nos.)
No Actions Responsible Support
1 Mapping file from Saphran. Saphran Team(Jason V).
2 Upload Value set values in EBS for customer plants from the Saphran
mapped file
Fujitsu Consultant (Ram) Data Load
3 Associate customer to customer plant in EBS customer master based
on the Saphran mapping file
Conversion team (Mark G)
4 Get final list of Customers in EBS for defining forecast Names. Forecast Biz team and
Conversion team (Mark G)
5 Map EBS customer names and EBS ship-from orgs for defining
Forecast names.
Define forecast names in orgs 3,4 and 7 for all Zeeland customers,
with the assumption that all customers will have either one of them
as ship-from org.
Define forecast names in org 11 for all the GMBH customers.
Define forecast names in 4 for GMBH customers that get shipped
from Zeeland. Need to get a list of such customers.
Forecast Biz team (Anna)
and
Fujitsu Functional
Consultant (Ram)
6 Define/upload Forecast Names at customer level in EBS for each
ship-from orgs for
Radley EDI forecast
Saphran Original Forecast
Saphran Netted Forecast
Saphran Truncated Forecast based on toggle weeks
Fujitsu Consultant (Ram) Conversion team
(TBD) and Fujitsu
Tech team (Satish)
7 Upload Source list with all the above Radley Forecast names at
customer level and setup RLM profile option.
Fujitsu Consultant (Ram) Conversion team
(TBD) and Fujitsu
Tech
29
Summary
Forecast Consumption will be at item-Customer level (Option2) in both
ASCP and Custom netting of Saphran against Radley.

Forecast Consumption will not be possible at customer plant level
within ASCP.

One Customer plant should not belong to multiple customer names.
Saphran team to take care in the mapping file.

The Saphran Forecast Toggle will be at item-customer level.

List of Action Items is acceptable and followed

30
QUESTIONS
?
Thank You