You are on page 1of 31

GENTEX ASCP PLAN

Consumption in ASCP, Saphran Forecast Netting in customization and Saphran Forecast Interface
Prepared by: Deepak Khosla and Shailender Pushkarna

Dec 22, 2008

Ramananda Nayak, Fujitsu

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

Gentex EBS Forecasting Flow


Receive Corporate forecast from Saphran into EBS Net Saphran Forecast against Radley at itemCustomer level: Custom logic Custom-Interface Derive Truncated Saphran Net forecast as input to ASCPToggle weeks Custom-Interface Collect Radley FC, Truncated Saphran FC, Manual FC and Sales orders ASCP Run & Monitor ASCP Plan (Constrained) with the collected Forecast sets ASCP

Saphran Interface

Receive Radley EDI Forecast into EBS

Manual ForecastAutomotive, Fire Protection Forecast

Radley Interface Analyze consumption details, Compare Forecasts Analyze ASCP Forecast Consumption on the ASCP Workbench Consume Forecast against Sales orders at ItemCustomer level ASCP

Run MRP Detail Report

MRP Report

Custom Report

ASCP

System
Note: Please refer to the MD50 for details on netting logic.

Planner/ Schedule r 3

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

Dec 22, 2008

Ramananda Nayak, Fujitsu

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

Option1: Item-Customer ship to/Bill To level

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

Option2: Item-Customer level

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

10

Option3: Item level

11

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.

12

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.

13

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.

14

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.

2.
3.

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. This will also reduce the risk of data not matching as it is at higher aggregation level, but at more granular level than Option1. Data mapping between Saphran and EBS forecast tables will be much easier, but effort will be more than Option1.

Cons:
1. 2. 3. If the same item belongs to multiple ship_tos, then the customer/ shipto-wise consumption comparison is not possible. The logic of custom forecast consumption will change to item-customer level. RIE needs modification. 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.

15

Saphran Forecast Interface, Saphran Netting against Radley, Derive Truncated Saphran Forecast Prior to ASCP

Dec 22, 2008

Ramananda Nayak, Fujitsu

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.

17

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

18

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.

19

Truncated Saphran from Net Saphran Forecast

20

DFFs to define Toggle Weeks

21

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.

22

FORECASTING EBS SETUPS and ACTION ITEMS -assuming Option2

Dec 22, 2008

Ramananda Nayak, Fujitsu

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:


24

Defining Forecast Names

25

Defining Forecast Items and Forecast Details

26

Defining Source List for Radley EDI Transfer

27

Action Items (in the order of Sl. Nos.)


No 1 2 3 4 5 Actions Mapping file from Saphran. Upload Value set values in EBS for customer plants from the Saphran mapped file Associate customer to customer plant in EBS customer master based on the Saphran mapping file Get final list of Customers in EBS for defining forecast Names. 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. 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 Upload Source list with all the above Radley Forecast names at customer level and setup RLM profile option. Responsible Saphran Team(Jason V). Fujitsu Consultant (Ram) Conversion team (Mark G) Forecast Biz team and Conversion team (Mark G) Forecast Biz team (Anna) and Fujitsu Functional Consultant (Ram) Data Load Support

Fujitsu Consultant (Ram)

Conversion team (TBD) and Fujitsu Tech team (Satish)

Fujitsu Consultant (Ram)

Conversion team (TBD) and Fujitsu Tech

28

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

29

QUESTIONS

30

Thank You

You might also like