ASCP Forecast Consumption

7/22/2019 ASCP Forecast Consumption

1/31

GENTEX ASCP PLAN

Consumption in ASCP, Saphran Forecast

Netting in customization and Saphran

Forecast InterfacePrepared by: Deepak Khosla and Shailender Pushkarna

Ramananda Nayak, FujitsuDec 22, 2008


2/31

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 ForecastPrior to ASCP

Saphran data mapping- Requirements

Forecasting- EBS Setups

Action Items

Conclusions

Questions


3/31

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 thecollected

Forecast sets

ASCP

Receive

Radley EDIForecast into

EBS

Radley Interface

Consume

Forecast

against Sales

orders at Item-

Customerlevel

ASCP

Net Saphran

Forecast

against Radley

at item-Customer level:

Custom logic

Custom-Interface

Derive

Truncated

Saphran Net

forecast asinput 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 n ett ing logic.


4/31

4

Forecasts for ASCP

Receive Radley Forecast from Customers.

Receive Saphran Forecast.

Net Original Saphran Forecast with the Radley Forecast at ship fromorg-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)


5/31

Forecast Consumption within ASCP:

Options and Option Evaluation



6/31

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.




7/317

Option1: Item-Customer ship to/Bill To level


8/318

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



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.





9/319

Option2: Item-Customer level


10/3110

Option3: Item level

Example: Item 905-1016-006: Time bucket: Jan-2008.

Initial Forecast input to ASCP: FC1: qty: 1000

FC2: qty: 900



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.


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/3111

Option3: Item level


12/3112

ASCP Can not consume at Customer Plant Level

ASCP consumes Forecast against the sales orders only atone of the following levels: Item Level

Item-Customer Level

Item-Customer-Ship To/ Bill To Level

Thus, ASCP consumption logic does not recognize thecustom defined DFF for customer plant and can notconsume at customer plant level.

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


13/3113

Evaluation -Option3: Item level

This Option may not suite GENTEX as it allows consumption across customers for the sameitem.

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 inthe RIE.

The Saphran toggle weeks may have to be defined at item-Ship from org level rather thanat customer ship-to level.


14/3114

EvaluationOption1: 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 turnrequires data from Saphran at customer ship-to id level, which is a challenge as of now toget Saphran data at ship-site id level.


Ship-from org

Customer (or Customer plant)

Customer Ship-To

Assumption: If customer plant is used as mapping entity instead of customer, then eachcustomer 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 Customersites 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 maynot be accurate due to mapping challenges.


15/3115

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


Ship-from org

Customer (Customer plant)

Assumption: If customer plant is used as mapping entity instead of customer, then each customer plant cannot 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 ofForecast 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 levelthan 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 thatcustomer, but applicable to all items under that customer.


16/31

Saphran Forecast Interface, Saphran Netting

against Radley, Derive Truncated Saphran

ForecastPrior to ASCP



17/3117

Saphran Forecast InterfaceOriginal 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/3118

Saphran Netting Against Radley- Netted Saphran


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+ Greaterof (Open SO's and Open Radley forecast).

Clear all the old entries and populate the new forecast data


19/3119

Truncated Saphran from Net Saphran 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/3120

Truncated Saphran from Net Saphran Forecast


21/3121

DFFs to define Toggle Weeks


22/3122

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 sameconsumption 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 tothe EBS customer Name.

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


23/31

FORECASTINGEBS SETUPS and ACTION

ITEMS -assuming Option2



24/31

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 namecorresponding to that customer.

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

Challenge in defining Forecast names at customer level: If there multiple customers with the samename 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 listusing 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 codingeffort.

or

customer level. The toggle weeks will unique for that customer, but applicable to all items underthat 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/31

25

Defining Forecast Names


26/31

26

Defining Forecast Items and Forecast Details


27/31

27

Defining Source List for Radley EDI Transfer


28/31

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 FunctionalConsultant (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/31

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/31

30

QUESTIONS

?


31/31

Thank You

Documents

ASCP Forecast Consumption