GENTEX ASCP PLANConsumption in ASCP, Saphran Forecast Netting in customization and Saphran Forecast InterfacePrepared by: Deepak Khosla and Shailender PushkarnaRamananda Nayak, FujitsuDec 22, 2008

*ContentsGentex EBS Forecasting FlowForecasts for ASCPForecast Consumption within ASCP: Options and Option EvaluationSaphran Forecast Interface, Saphran Netting against Radley, Derive Truncated Saphran Forecast Prior to ASCPSaphran data mapping- RequirementsForecasting- EBS SetupsAction ItemsConclusionsQuestions

*Gentex EBS Forecasting Flow Note: Please refer to the MD50 for details on netting logic.

*Forecasts for ASCPReceive 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 ForecastSales OrdersSaphran-Truncated ForecastManual ForecastSafety Stock Targets (Bucket days and Percent)

Forecast Consumption within ASCP:Options and Option EvaluationRamananda Nayak, FujitsuDec 22, 2008

*Option1: Item-Customer ship to/Bill To levelExample: Item 905-1016-006: Time bucket: 01-Jan-2008.Initial Forecast input to ASCP: FC1: Customer: GM-CAMI, ship_to:Kigstone, qty: 1000FC2: Customer: GM-CAMI, ship_to:Ingersol, qty: 900Sales orders input to ASCP:SO1: Customer: GM-CAMI, ship_to:Kigstone, qty: 1200SO2: 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: 1200SO2: Customer: GM-CAMI, ship_to:Ingersol, qty: 150

*Option1: Item-Customer ship to/Bill To level

*Option2: Item-Customer levelExample: Item 905-1016-006: Time bucket: 01-Jan-2008.Initial Forecast input to ASCP: FC1: Customer: GM-CAMI, qty: 1000FC2: Customer: GM-CAMI, qty: 900Sales orders input to ASCP:SO1: Customer: GM-CAMI, ship_to:Kigstone, qty: 1200SO2: 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: 1200SO2: Customer: GM-CAMI, ship_to:Ingersol, qty: 150

*Option2: Item-Customer level

*Option3: Item levelExample: Item 905-1016-006: Time bucket: Jan-2008.Initial Forecast input to ASCP: FC1: qty: 1000FC2: qty: 900Sales orders input to ASCP:SO1: Customer: GM-CAMI, ship_to:Kigstone, qty: 1200SO2: Customer: GM-CAMI, ship_to:Ingersol, qty: 150SO3: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: 1200SO2: Customer: GM-CAMI, ship_to: Ingersol, qty: 150SO3:Customer: HONDA, ship_to: Honda Pkwy, qty: 250

*Option3: Item level

*ASCP Can not consume at Customer Plant LevelASCP consumes Forecast against the sales orders only at one of the following levels:Item LevelItem-Customer LevelItem-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.

*Evaluation -Option3: Item levelThis 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.ItemShip-from orgPros: This will reduce the number of records in the forecast set-up, which reduces lot of maintenance.This will also reduce the risk of data not matching as it is at higher aggregation level.Data mapping between Saphran and EBS forecast tables will be much easier.Number of Forecast names to be set up required per Forecast Set = 1.Cons:If the same item belongs to multiple customer/ ship_tos, then the customer/ shipto-wise consumption comparison is not possible.The logic of custom forecast consumption will change to item 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 may have to be defined at item-Ship from org level rather than at customer ship-to level.

*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.ItemShip-from orgCustomer (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: Consumption and Comparison of forecast will be at a ship-to site level granularity.

Cons:Huge mapping and setup effort from Saphran as well as EBS side and may be incomplete. 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.Mapping and data inaccuracies have direct impact on plan output.The current Saphran Forecast interface and custom netting between Radley and Saphran may not be accurate due to mapping challenges.

*EvaluationOption2:Customer level- RecommendedThe 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.ItemShip-from orgCustomer (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: 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: 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.

Saphran Forecast Interface, Saphran Netting against Radley, Derive Truncated Saphran Forecast Prior to ASCPRamananda Nayak, FujitsuDec 22, 2008

*Saphran Forecast Interface Original ForecastIn 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.

*Saphran Netting Against Radley- Netted SaphranIn 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

*Truncated Saphran from Net Saphran ForecastIn 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 weeksFor 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.

*Truncated Saphran from Net Saphran Forecast

*DFFs to define Toggle Weeks

*Saphran data mapping- RequirementsSaphran NettingEarlier 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 NameCustomer Plant ItemBucketDateQty

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 Option2Ramananda Nayak, FujitsuDec 22, 2008

*Defining Forecast NamesThere 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:

*Defining Forecast Names

*Defining Forecast Items and Forecast Details

*Defining Source List for Radley EDI Transfer

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

NoActionsResponsibleSupport1Mapping file from Saphran. Saphran Team(Jason V).2Upload Value set values in EBS for customer plants from the Saphran mapped fileFujitsu Consultant (Ram) Data Load3Associate customer to customer plant in EBS customer master based on the Saphran mapping fileConversion team (Mark G) 4Get final list of Customers in EBS for defining forecast Names. Forecast Biz team andConversion team (Mark G) 5Map 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) andFujitsu Functional Consultant (Ram)6Define/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)7Upload 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

*SummaryForecast 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

*QUESTIONS?

Thank You

*ASCP PLANNING High Level Planning Cycle Note: This flow is subject to changes based on further developments. Changes in Items, BOM, Routings, Flow Schedules, Line Rate, Sourcing, Calendar, Supply, Safety Stock etc. are collected for ASCP

*******