SONY – BI-IP Implementation Project Design...

SONY – BI-IP Implementation Project Design Document

Sony Electronics Asia Pacific Pte. Ltd. SAP BI-IP (Integrated Planning) Design Document for Pilot Project for SMAP RME

SONY BI-IP Implementation Design Document

Doc_id: SON-BBP-001 Ver no: v.0 Date: 17/04/2007 of 72

Design Document

PROJECT SONY BI-IP Implementation

PROJECT CODE

Bristlecone

Name Signature Date

Prepared by:

Chandrakant Veer Jaime Natarajan R Nitin Choudhari Sahana Shetty

Reviewed by: Prashant Waghmare Mandar Kardile

Sony

Name Signature Date

Reviewed & Approved by:

VERSION HISTORY

Version Date Changes & reasons for change

1.0 23-Jun-07 New Document



Table of Contents

1 Project Overview .................................................................................................... 5

1.1 Objective ............................................................................................................................ 5

1.2 Scope................................................................................................................................... 5

1.3 Input Interfaces ................................................................................................................. 5

1.4 Output Interfaces .............................................................................................................. 6

1.5 User Interfaces / Planning Layouts ................................................................................. 6

2 Master Data Parameters ........................................................................................ 7

2.1 List of Masters –................................................................................................................ 7

2.2 Design Architecture for Master data maintenance using Dialog Program. ................ 8

2.3 Design Architecture for Master data maintained directly in BW................................ 8

2.4 Details for Master Data .................................................................................................... 9

3 Design ................................................................................................................... 35

3.1 Process I (Pricing Budgeting & Marketing Forecast) ................................................. 35

3.2 Process 2 (Sales Forecast)............................................................................................... 37

3.3 Process 3 (Consensus & Dependant Forecast) ............................................................. 39

3.4 Process 4 (PO & SO Simulation) ................................................................................... 41

3.5 Design architecture for Planning Data flow ................................................................. 43

3.6 Planning Process flow Output........................................................................................ 44

3.7 Process 5 (Actual Data)................................................................................................... 46

3.8 Complete Architecture for Planning and Actual Data flow........................................ 48

3.9 Data loading Strategy ..................................................................................................... 49

4 Reporting Requirement........................................................................................ 52

4.1 Consol Sales Report – Sales Companies ....................................................................... 52

4.2 Consol Sales Report – Direct/Outside Sales ................................................................. 54

4.3 Regional Sales Report..................................................................................................... 56

4.4 SMAP Inventory Report (Actual & Forecast) ............................................................. 58

4.5 Inventory Devaluation Report ....................................................................................... 60

4.6 MPI3 Format ................................................................................................................... 62

5 Assumptions ......................................................................................................... 64

5.1 Assumptions on actual data management: ................................................................... 64

6 EP Design and Configuration ............................................................................. 65

6.1 Portal layout design ........................................................................................................ 65

6.2 Baseline configuration of EP.......................................................................................... 67

6.3 Portal reports – Iviews.................................................................................................... 68



6.4 Authorizations and Roles in EP..................................................................................... 70

7 Annexure – I (CRP Doc) ..................................................................................... 71

8 Annexure – II (File Formats).............................................................................. 71

9 Annexure – III (BI-IP Technical design) ........................................................... 71

10 Annexure – IV (BI-IP Planning cycle changes handling)................................. 71

11 Annexure – V (BI-IP Key figures Granularity) .................................................. 71

12 Annexure – VI (Roles in EP)............................................................................... 71

13 Annexure – VII (PO Simulation Formulae)....................................................... 71



1 Project Overview

1.1 Objective

The Objective of this project is to provide a holistic solution catering to ease of use, user friendliness, off-line functionality, scalability and simplicity in doing the simulations for Sales, Marketing, Price and Procurement.

1.2 Scope

Scope of the project includes Master Data maintenance as described in section 2.4 and following 4 processes which are explained in detail below in this document in section 3.0

1. Pricing Budgeting & Marketing Forecast 2. Sales Forecast 3. Consensus & Dependant Forecast 4. PO & SO Simulation

Scope of the project includes development of objects required for Master data maintenance and 4 processes (as mentioned above) on BI 7.0 Some of the Master data’s will use Dialog programming screen to maintain Master data parameters (Planning related) as described in detail in section 2.4 Rest of the Master data’s will be maintained directly in BI 7.0 as a Master Data objects. Pl refer to section 2.4 Planning Applications for above 4 mentioned processes will be created on Integrated Planning platform using BI 7.0 Pl refer to section 3.0 Following 6 reports will be created in BI 7.0

1. Consol Sales Report – Sales Companies 2. Consol Sales Report – Direct/Outside Sales 3. Regional Sales 4. SMAP Inventory Report (Actual & Forecast) 5. Inventory Devaluation Report 6. MPI3 Format

1.3 Input Interfaces

Flat file upload interfaces will be used for loading all actual data for Sales, Inventory, Procurement and Master Data. Following are the flat files

1. S039 2. DVAI 3. OSI 4. WD6 5. WD-2 6. N1T14 7. N1T11 8. S006 Model Master 9. S005 Customer Master 10. RCM Layout

For flat file formats Pl refer to Annexure II



1.4 Output Interfaces

Following 4 out put interfaces will be developed. 1. N1T016 2. N1T020 3. PICA interfaces 4. PICA interfaces 5. PSI Interface

1.5 User Interfaces / Planning Layouts

User interface for planning application will be Microsoft Excel base. Planning applications can be run Online as well as Offline. The Offline data management architecture as follows –

Figure 1. Offline Maintenance Flow



2 Master Data Parameters

2.1 List of Masters –

Following master data’s will be maintained in BI 7.0 using Dialog Screens. 1. Local Model Name

2. Level1

3. Level2

4. Level3

5. Level4

6. Level5

7. Customer

8. customer-sales company(Direct Customer)

9. Customer Level 1

10. Customer Level 2




14. Calendar Master

15. Category Level Parameter Maintenance

16. Weekly ratio maintenance table

17. Bill of Material

18. Competitor

19. Seasonality

Following Masters will be maintained in BW directly.

20. Tokyo 8D code

21. Tokyo 6D code

22. Tokyo 4D code

23. Tokyo Biz Group 4D

24. Tokyo Network Company

25. Components

26. Company(Sales Co)

27. Unit of Measure conversion table

28. Currency Maintenance

29. Region

30. Area

31. Country

32. Inter company



2.2 Design Architecture for Master data maintenance using Dialog Program.

Figure 2. Master Data Updating Process using Dialog Program

2.3 Design Architecture for Master data maintained directly in BW.

Figure 3. Direct Master Data Updating Process

Dialog Screen

Execute program and display the data in the screen

Pass data from screen

Pass data from screen

Fetch data from Info Object

Fetch data from Info

Object

Execute program and display the data in the screen

Update ’Z’ table

Master Data Updating Method

Process 1

Process 2

OR

Update info object

Dialog Screen

ABAP Program

ABAP Program

Pass user screen data

Pass user screen data



2.4 Details for Master Data

1. Local Model Name

In the system, each model has unique model name which is sales company specific, it is called local model name. Each model has specific model code (8D). Tokyo model name is different from local model Name. (But SMAP RME refers Tokyo 8D code as their local model code)

This model information is maintained by marketing and procurement people. Apart from this information there is basic common information which will be derived or maintained at Local 8D model name level.

Local Model Name creation. There will be 3 screens developed for Local Model Name in BW System.

• First Screen - This will have Local 8D Name creation where in system will assign unique code number to it. There will be separate number ranges which are Sales Company specific. Screen will have following input fields in it.

Local 8D Model code Based on Number Range

Local 8D Model Name Input- Mandatory

Sales Company Auto derivation from user master

In configuration, there are two type of number ranges define. 1. Internal – In numbers (100000001 to 10099999) 2. External – Any Alfa Numeric Number

This Number ranges can be assigned to each sales company

Sales Company Type of Range Number Range Last defined Number

SOMAS Internal 10000001 - 10099999 0

SOTHAI Internal 10100000 - 10199999 0

S/Aust External

• Second Screen - Marketing Data screen Following parameters will be maintained in Marketing Data Screen

o Model Name: Local model Name.

o Tokyo 6D category: Dropdown list.

o Local Sales Company Dropdown list.

o Local category code: Level1, Level2 and Level3 etc., local category should be

selected. One Tokyo 6D should have one Level1, Level2 and Level3 etc. to a

maximum of Level5 code.

o Model Status: Dropdown list with 3 status viz. Incoming, Current and Discontinue. Incoming is for new model, it will be used for sales and marketing

* Auto derived Number Range.



forecast to input weekly forecast in the model launch month (Regional Model, not applicable for SMAP RME). Current is a valid models for forecast and Discontinue is not for forecast (means there is no on hand saleable inventory).

o Estimated by Sales: It is used to indicate those Key models that must have both sales and marketing forecast. This model is recognized as consensus Forecast Model (This is for Regional Model). For the models that are not indicated as ‘EST by Sales’, only marketing forecast is needed and this model is recognized as Independent Forecast model. (only for Regional Model)

o Launch Date: It is for model’s launch date and end of life date. If the model status is ‘Incoming’, this date must be filled by users.

o Bundle model set is defined in the Model master. There are 3 types of bundle case:

a) Bundle Set: Dummy header model + components

Forecasting is done on dummy 8D. There is no Tokyo 8D for such bundle models. Bundles are created locally using 50 codes (Codes start with 50).

b) Parent & Child: Dependent model cannot be sold independently.

Forecasting is done on parent. Yes the forecast of child should be dependent on parent based on the relationship set up.

c) Accessory models:

Forecasting is also based on the relationship set up between main model & accessory. For eg. Based on past history, we know that for every 5 units of Main model sold, 1 unit of accessory is sold as well. In this case, the relationship is 1 main unit to 0.2units of accessory. So when let's say 5 units of main is forecasted, the forecast of the accessory is 1 unit.

o Valid From

o Valid To

Figure 4. Marketing Data Screen



The rules for the Model Marketing Information maintenance:

• The New model registration process is as follows:

a) Simple system transmits the model to the system.

b) In Procurement the new local 8D Model will be linked to the Tokyo 8D code.

• Each Local 8D Model will be linked to only one Tokyo model 8D code at a time. If a new version of the model is released, the Tokyo 8D code link will be changed, however, the effective date must be checked before the 8D code is changed. If a model has multiple predecessors, each one will be displayed on the screen for user to check the proper 8D code for linkage.

• Model’s information can be changed.

Third Screen - Procurement Data screen

Following parameters will be maintained in Procurement Data screen

o Planning Cycle: Monthly or Weekly operation

o Order Month Rule(Seihan Lead Time): Purchase Order confirm month / week

o Total Lead Time: Factory goods delivery lead time

o PSI indicator: To differentiate the models from SOEM TV PSI operation

o Initial Ship Week: The model first shipping week from factory - for new models

o Final Ship Week: The last goods shipping week - for models end of life

o Min Carton Qty: Minimum Catron Quantity

o Min Container Qty: Minimum Container Quantity

o OSI file Indicator – Order shipping information file available or not

Figure 5. Procurement Data Screen



The rules for the Model Procurement Information maintenance:

• Each Local 8D Model will be linked to only one Tokyo model 8D code at a time. If a new version of the model is released, the Tokyo 8D code link will be changed, however, the effective date must be checked before the 8D code is changed. If a model has multiple predecessors, each one will be displayed on the screen for user to check the proper 8D code for linkage.

• Model’s information can be changed.

• See Annexure

• If Order Month Rule (Seihan Lead Time) changes, the order fixed week needs to be maintained to reflect the correct confirmed purchase orders, for this Simulation re run is required. ( Regional Model Requirement)

• If factory shipping lead time changes, the inventory in procurement module needs to be recalculated to reflect the correct goods receiving weeks, for this Simulation re run is required .( Regional Model Requirement)

2. Level1 Maintenance for Model

It is top node in product and Local hierarchy.

Following is the screen for creation and change of Level1.

• First Screen - This is the initial Screen

Screen will have following input fields in it.

Level1(Technical name) Based on Number Range

Level1(Description) Input (Mandatory)

Sales Co Auto derivation from user master

In configuration, there are two type of number ranges define.

• Internal – In numbers (100000 to 200000)

• External – Any Alfa Numeric Number





It is 2nd level in hierarchy and will have Level1 as time dependent attribute.




Level2Technical name) Based on Number Range


Level1 Input


Valid From Date Input (Mandatory)





It is 3rd level in hierarchy and will have attributes Level1 and Level2. It is time dependent.






Level2 Input






5. Level4 for Model Maintenance

It is 4th level in hierarchy and will have attributes Level1, Level2 and Level 3. It is time

dependent.










Level3 Input







It is 5th Level in hierarchy and will have attributes Level1, Level2, Level3 and Level4. It is

time dependent.




Level5(Technical name) Based on Number Range


Level4 Input










7. Customer Maintenance

There are two types of customer viz. Inter Company and outside sales. For each customer,

currency is maintained depending upon the country of operation (Eg. If SOMAS (Sony

Malaysia) is intercompany customer then local currency for SOMAS – Ringgit will be

maintained).

For the regional model planning, hierarchy of customer master is as follows:-

Figure 6. Hierarchy for customer master

Following are Customer Specific attributes –

• Customer

• Customer Name

• Region

• Area

• Country

• Type of Customer – Inter company or Outside Customer

• Customer Group

• Sales Channel

• Sales Area

8. Customer-sales company (Direct Customer) Maintenance

These are customers which have been extended to Sales Company.

This is required to identify sales company wise customers.

It is having all attributes of Main customer. (Reference Object of Customer)

Level 1 (eg. Sales Area)

Level 2 (eg. Sales Channel)

MLA3

Level 3 (Eg. Customer Group)

Abenson

Level 4

Level 5



9. Level1 Maintenance for Customer (Eg. Sales Area )

Users can Create, Change and Display the Sales area.

Following is the screen for creation and change of customer groups.



Level1 Based on Number Range




Internal – In numbers (100000 to 200000)

External – Any Alfa Numeric Number

10. Level2 Maintenance for Customer (Eg. Sales Channel )

It is used in sales forecasting. Users can Create, Change and Display the customer groups




Level2 Based on Number Range


Level1 Drop down list for Level1(Mandatory)






11. Level3 Maintenance for Customer ( Eg.Customer Group )



• First Screen – This is the initial Screen –


Level3 Based on number range

Level3(Description) Enter the name(Mandatory)




In configuration, there are two type of number ranges defined.

a. Internal – In numbers (100000 to 200000)

b. External – Any Alfa Numeric Number






12. Level4 Maintenance for Customer







Level3 Drop down list for level3 (Mandatory)




c. Internal – In numbers (100000 to 200000)

d. External – Any Alfa Numeric Number

13. Level5 Maintenance for Customer ( Eg.Customer Group )











e. Internal – In numbers (100000 to 200000)

f. External – Any Alfa Numeric Number

14. Calendar Master

For weekly model, PO simulation is done in PMIS system. In order to cater sales company

specific calendar, Calendar master is created in the system .SO requirement and outside

sales forecasting qty is available in monthly bucket but in PO simulation same will be put in

1st pure week of stream calendar.

There will be calendar ID which will segregate different calendar masters. I.e. Stream

Calendar …

Following is the Logic for Regional Model calendar master.

Following is the Logic for Regional Model calendar master.

The calendar master in the system is used for the following functions:





• For marketing, the forecast can be broken down from monthly to weekly or summed up from weekly to monthly based on the calendar master.

Calendar master will be available in the following fashion:

S/N Planning Data Input / Output Remarks

1 Calendar ID Input Eg. 01

2 Calendar Year Input Eg. 2007

3 Week ID

(Week No + Year)

Input

Valid number is from 1 to 53

(Eg. 01.2007)

4 Calendar Month Input Valid number is from 1 to 12

Eg. 01.2007 means Jan 2007

5 From Date Input System calendar should be provided for user selection. The format should be Year – Month – Day YYYYMMDD

6 To Date Input System calendar should be provided for user selection. The format should be: Year – Month – Day YYYYMMDD

7 Weekly ratio Input The ratio used for monthly data break down to weekly



Figure 7. Stream Calendar

As per finalized discussion, following calendar logic will be built up for calendar Master –

C:\Documents and Settings\Administrator\Desktop\Sony Pilot Project\Design Document\Calendar Master logic.xls

15. Category Level Parameter Maintenance

The pricing function in the system is for marketing users to maintain the values of price

components for model cost and selling price.



Following are the pricing components at local 8D model code level, price calculations

for SMAP RME marketing.

1. Factory FOB

2. SMAP GP

3. IF% - Insurance and Freight

4. STP Avg. Selling Price

Following components are used at Local Model code – 8D Code and at inter company level

price calculation

1. STP - Avg. Selling Price

2. Insurance and Freight %

3. Landed Cost

4. Dealer GP %

5. SRP Mark up %

6. SRP (Sales retail price mark up)

Price components SMAP GP, Insurance and Freight, Dealer GP% and SRP mark up% will be maintained at company, Level1, Level2, Level3, Level4, Level5,(i.e. Levels for Model) calendar year, calendar month level.

Calendar

Year

Company Level

1

Level

2

Level

3

Level

4

Level

5

Pricing

Component

Data

Type

Month Key figure

2007 SMAP V # # # # SMAP GP % Jan 2007 15%

2007 MAP TV # # # # Insurance &

Freight

% Jan 2007 %

2007 SMAP TV # # # # Insurance &

Freight

% Jan 2007 5%

2007 SOMAS TV # # # # Insurance &

Freight

% Jan 2007 %

2007 SOTHAI TV # # # # Insurance &

Freight

% Jan 2007 5%

2007 SOTHAI TV CRT

TV

# # # Dealer GP % Jan 2007 10%

2007 OTHAI TV T TV ” # # Dealer GP % Jan 2007 %

2007 OTHAI TV CRT

TV

” # # SRP Mark up % Jan 2007 12%



The components Factory FOB, STP- Avg. selling price, Landed cost, SRP are determined by model. The values are different for different models. Model wise dealer GP% is defaulted to category dealer GP%. However user can change the % for each model. The data will be maintained for complete year and month. User can change values for future period, but not for historical period. Above components will get reflected in the simulation model but user can over write these values. In cases as above for component value change simulation re run is required. Exchange rate will be derived from exchange rate master.

Following are the pricing components used for ARM and SGMC – DI (Digital Imaging)

Group.

1) SMAP Markup

2) CIF (Cost, Insurance and Freight)

3) GST

4) Kickback

All above components are maintained at Category Level (Level1, Level2 ….Level5).

5) FOB in USD (Free on Board)

6) STP(Markup) in USD

7) STP (Markup) in LOC (Currency will be derived from master)

8) COGS without FOC in LOC

9) FOC in LOC

10) COGS after FOC in LOC

11) GP Nett%

12) Dealer Nett in LOC

13) Kickback in LOC

14) Free Gift in LOC

15) Dealer Incentives in LOC

16) Dealer Nett after Reduction in LOC

17) SRP without GST in LOC

18) SRP with GST in LOC

19) D/M with GST%

20) D/M without GST%

Following pricing components will be used by SGMC– PA (Personal Audio) Group

Exchange rate will be derived from master

1) SMAP FOB in USD

2) Freight and Handling %

3) Free gift %

4) Annual Target Rebate %



Above parameters will be maintained at Category Level (Level1, Level2 ….Level5).

5) Landed Cost in LOC

6) Total cost without free gift in LOC

7) SOSIN GP%

8) Dealer Nett Price in LOC (Yearly Kickback)

9) Dealer Nett (Invoice Price) in LOC

10) Dealer’s Margin % (with 5% GST)

11) SRP in LOC

Following are the pricing Components for the Regional Models

The components to determine a model’s price (cost and selling price) are as follows: 1) STP-FOB: Buffer for dollar to Peso conversion (USD to Peso)

2) FIH: Freight, Insurance, Handling fee

3) Kick-back: Dealer Rebate

4) Exchange Rate: only Peso to USD

5) VAT: Value Added Tax

6) Dealer GP%: Dealer Gross Profit %

7) STP: Stock Transfer Price (from supplier)

8) RBP: Standard Retail Price

9) Duty %

10) FG amount and %: Free Gift amount and the actual promotion coverage %

11) SMI amount and SMI %: Salesman / Promoter Incentive amount and the coverage %

12) 0% and Int%: Interest coverage for promotion

* The pricing components and pricing calculation can be different from company to company. The rules for the model price maintenance:

• The above price components from 1 to 6 are determined by the model’s local category. The values of these components apply to all models for that category. The values can be percentage or amount. The 6 items are a set of components that will be applied to each models price calculation. The components values can be defined at a specific set of Category Level (Level1, Level2 ….Level5).

For example:



Price Component Level1 Level2 Level3 Level4 Level5 Value Type

STP_FOB TV # # # # Amount

KICK-BACK TV # # # # Percent

FIH TV # # # # Percent

Exchange Rate # # # # # Percent

VAT TV # # # # Percent

DLR_GP TV CRT TV CRT # # Percent – 10%

DLR_GP TV CRT TV # # # Percent – 15%

DLR_GP TV Front PJ # # # Percent

DLR_GP TV Monitor # # # Percent

DLR_GP TV Rear PJ CPJ TV # # Percent

In the above example, the Exchange Rate applies to all categories – all models. STP_FOB, KICK_BACK, FIH, and VAT apply to all models of which Level1 category is ‘TV’ (Other Levels are not necessary to check). However, the dealer GP should apply to the specific Level models. For a model, if its Level1 is TV, Level2 is CRT TV and if Level3 is CRT, the DLR_GP should be 10%, otherwise the DLR_GP should be 15%.

• The above price components from 6 to 12 are determined by models. The values vary model by model. Model-wise Dealer GP% is defaulted to Category Dealer GP%; however, users can change the percentage for each model. Other details are entered by marketing users.

• For every fiscal year, 12 months price components values (in amount or percentage) will be maintained by users. However, the past year’s data is only for reference. It will not be changed by users.

• The system will be able to upload the quarterly price that is transmitted from regional office.

• Users will be able to add, change or delete any price component. Duplicated records are not allowed.

• To delete a price component from the category, system will check the price master for the affected models. A confirmation window will be displayed on the screen to inform user the affected models. The window will provide options for users to accept the deletion or ignore the deletion. If the user selects deletion, the related component’s values will be changed to zero in price master for all models of the category and the COGS, Selling Price (DNNN) and GP will re-calculated.

• The same will apply to the component’s value change. A confirmation window will be displayed on the screen for user to confirm the component’s value changes. If the user confirms the change, all related models price will be re-calculated in the price master that includes COGS, Selling Price (DNNN) and GP.

• For mode-wise price component change, the COGS, Selling Price (DNNN) and GP will be re-calculated in price master when the user saves the changes to the database.

• Whenever a component’s value is changed or deleted (at category or model level), a remark will be inserted into price master for all the affected models.

• Any component’s value change will be carried over to the remaining months.



• All the 12 price components will be used to calculate the model’s cost and selling price by formula. A separate worksheet will display all models’ cost, selling price, GP and GP% at model level.

The calculation formula is as follows (per model):

S/N Components for Landed Cost

Components for Selling Price

Components for Promotion (w/selling Price)

1 STP RBP SMI, SMI%

2 STP_FOB Dealer GP% FG, FG%

3 FIH VAT % 0%, 0% Int

4 Exchange Rate Kick Back %

5 Duty

a) Cost of Goods Sold (COGS) – model landed cost:

STP_FOB x (1 + FIH) x Exchange Rate x (1 + Duty) b) RBP including VAT % - Input

c) RBP excluding VAT % = RBP including VAT % / (1 + VAT %)

d) Dealer Net (DN):

RBP excluding VAT x (1 – Dealer GP %) e) Dealer Net Net (DNN):

DN X (1 – KICK BACK %) f) DNNN w/Promotion (model selling price) means Dealers Net Price after reduction :

DNNN – SMI Amount x SMI % - 0% INT x RBP x 0% % - Free Gift Amount x Free Gift Coverage %

g) Net GP:

DNNN w/Promotion - COGS h) GP %:

1 – COGS / DNNN w/Promotion x100

• The model’s promotion description will be indicated in the promotion year and month.

Attached consolidated file of Pricing Components

F:\Pricing_usage.xls



Following are the pricing Components –

FIH: Freight, Insurance, Handling fee

CIF{purchase price* FIH)

Exchange Rate: only Peso to USD

Sales Tax %

Dealer GP%: with sales tax

Dealer GP%: without sales tax

Purchase Price USD

Purchase price LC

SRP: Standard Retail Price with sales tax

SRP: Standard Retail Price without sales tax

Duty %

Luxury Tax %

In warranty %

Landed cost

Total cost

Gross GP %

Gross GP AMT

Net GP %

Net GP Amt

Dealer Net

Dealer Net

Sales reduction % {We need a separate table to maintain the various types of sales reduction e.g. kickback, rebates, discounts, zero % interest, SMI coverage for zero interest% and coverage for SMI promotion % but the total of these components need to be reflected in the sales reduction % }

Sales reduction Amt

Other cost % {We need a separate table to maintain the various types of other costs e.g. free gifts etc. but the total of these components need to be reflected in the other cost % }

Other cost amt {We need a separate table to maintain the various types of other costs e.g. free gifts etc. but the total of these components need to be reflected in the other cost amt }

WAC

COGS

The pricing logic will be maintained by the user as per the Diagram Explanation below.



Figure 8. Pricing Maintenance Process



Transparent Table: [ZTABLE 1]

Transparent Table: [ZTABLE 2]

Figure 9. Screen for Model Price Maintenance

Figure 10. Integration Planning Flow



Integrated Planning Layout:

When the user click on button, system will refer to ZTABLE 2 and populate the correct % or value into the planning layout.

Figure 11. Integrated Planning screen



Matrix for the Pricing Components

No. Characteristics Mandatory Optional

1 6D Category √

2 Level 1 √

3 Level 2 √

4 Level 3 √

5 Level 4 √

6 Level 5 √

7 Location √

Location is used for taking care of location specific planning and simulation. For SMAP RME case, it will be default Singapore

8 Valid From (Date) √ -

9 Valid From (To) √ -

7 Components √ -

8 KFs (Amount) √

9 KFs ( % ) √

10 KFs ( Numbers ) √

No 1 to 4 either one must be keyed in. No. 8 to 9 one is mandatory.

16. Weekly ratio maintenance table

• The year and month of the week from and to date will be the same as the year and month defined in the record.

• User will be able to input the Weekly ratio for each week. However, the total weekly ratio of a month will be 100%.

Following is the screen for Weekly ratio maintenance.

Cal year Cal Week Cal Month From Date To Date Ratio

2007 13.2007 03.2007 26.03.2007 01.04.2007 30%

2007 14.2007 04.2007 02.04.2007 08.04.2007 25%

2007 15.2007 04.2007 09.04.2007 15.04.2007 25%

2007 16.2007 04.2007 16.04.2007 22.04.2007 25%

2007 17.2007 04.2007 23.04.2007 29.04.2007 20%

2007 18.2007 04.2007 30.04.2007 06.05.2007 5%

2007 19.2007 05.2007 07.05.2007 13.05.2007 30%

The weeks for April 2007 are week 14, 15, 16, 17, and 18. The total weekly ratios for the 5 weeks are 25+25+25+20+5 = 100



17. Bill of Material

The Dependent Demand Maintenance should allow users to input the followings:

a) Dependent model name

b) Valid from and to date

c) Parent model’s ratio to the dependent model

d) Dependent model’s ratio to the parent model

Entry screen looks as below

Figure 12. Dependant Demand Screen

The relationship set-up is to create the dependent model’s sales forecast automatically when the parent model’s sales forecast is maintained by either Sales or Marketing people. The dependent model’s sales forecast generated is based on the dependent model’s ratio.

18. Competitor

Following is the screen for creation and change Competitor.



Competitor Based on Number Range

Country Drop down list for Country



Internal – In numbers (100000 to 200000)

External – Any Alfa Numeric Number




19. Seasonality factor:

The monthly seasonality factors will be inputted (for 12 months) (This is for Regional Model).

This seasonality factor is used by SMAP RME for distributing half Yearly and Quarterly forecast into monthly basis.

This will be maintained at sales company level as follows.

Sales

Company

Month/Year Month/Year Month/Year ………… Month/Year

SOMAS 10% 20% 15% ………… 5%

SOTHAI 20% 15% 10% ………… 10%

Total should be 100%

20. Tokyo 8D code

Tokyo 8D code will be updated daily from the harmonized layout format S006 from simple system. There are two more RCM layout file which will update the Masters of Tokyo Network company, Tokyo Business Group, Tokyo 6D, Tokyo 4D and relationships.

Tokyo 8D code will have the following attributes.

Model_Code Model code

Model_Description Model Description/Name

Material_Type Material Type

Biz_Grp_4D Tokyo Business Group

6D_Code Product Category 6D

Tokyo_4D Tokyo 4D

Unit_Weight Net weight of Unit in KG

no_of_pack_in_mc No of packs per carton

MC_Weight Gross weight of Carton in KG

MC_Depth Depth of the Master Carton in CM

MC_Height Height of the Master Carton in CM

MC_Width Width of the Master Carton in CM

MC_Volume Volume of the Master Carton in cubic metres

Unit_Volume Volume of product in cubic metres (calculated)

New_Ch_Indicator Newly Created or Changed Indicator

Base_UOM Base Unit of Measure

EAN_POS_Code EAN / POS Code

Country_Orgin Country of Origin

Supplier code Current Supplier company code

Deletion Flag Indicator that model is set for deletion

Deletion date Date on which the deletion flag is set

War_app Indicator that model is applicable for warranty with the brand and warranty period

Serial_no_ind Indicator if the model is with a serial no or not

Predecessor model The Product Name of the product being replaced.

User entered



Successor model The Product Name of the replacement product.

Product Launch Date

Product Withdraw Date

Controlled Item Y or N (not used)

Create_Date Creation date

Change_Date Changed Date

The same flat file layout will be used to update the masters of Tokyo 6D, Tokyo4D and Tokyo Business Group.

Model Master Hierarchy.

There are two type of hierarchy for particular model.

1. Tokyo Hierarchy –

Figure 13. Tokyo Hierarchy

Tokyo Network Company

Tokyo Business

Group

6D Code

T4D

Tokyo 8D Code



2. Local Hierarchy for SMAP-

Figure 14. Local Hierarchy for SMAP

This hierarchy is a time dependent hierarchy and change every 6 months.

21. Tokyo 6D code

It is used for product categorisation and will have all the Category levels as attributes. It is

flat file upload.

22. Tokyo 4D code

It is used for product categorisation and will have Category levels as attributes. It is flat file

upload.

23. Components

24. Company(Sales Co)

It used for identifying Sales Companies. It will have currency and Local currency as

attributes.

25. Unit of Measure conversion table

Base unit of measure and unit of measure will be treated as same. If the conversion factor

available in future user can upload the same and maintain.

26. Currency Maintenance

Currency translation is required for Planning Simulation and reporting purpose to translate

values from one currency to other currency. Exchange rates will be uploaded to the system

from a flat file.

The following exchange rate types are used.

FC - FORECAST TTB RATE (SALES)

ACTL – ACTUAL TTB RATE (SALES)

SMAP LEVEL 1

Major

SMAP LEVEL 2

Mid

6D Code

4D Code

8D Code



RB - REVISED BUDGET RATE

OB - ORGINAL BUDGET RATE

Depending upon the usage, the currency type will be selected.

(Eg. For forecast value from Ringgit to US dollars conversion, exchange rate type FC will be

used.)

27. Region

All regions used under customer master will we uploaded once through a flat file. Region is

an attribute to customer master.

28. Area

Customer Area used under different sales companies will be uploaded by a flat file. Area

will be an attribute to customer master

29. Country

All countries will be loaded to this master to identify Customer country. Country will be an

attribute to customer master

30. Inter company

Inter companies are nothing but sales companies all sales companies information will be

uploaded through a flat file.



3 Design

3.1 Process I (Pricing Budgeting & Marketing Forecast)

• Objective

The objective of pricing, budgeting and marketing forecast is to help the sales companies and SMAP do marketing forecast based on various criteria and also work a Price and costing estimation.

• Process Description As per CRP Document – Pl refer to Annexure I

• Design Architecture for Pricing Budgeting & Marketing Forecast

Figure 15. Pricing Budgeting & Marketing Forecast



• Technical Design Following Cubes will be created for Pricing, Budgeting & Marketing Forecast

o Planning Cube 2 – OB/RB Original Budget / Revised Budget o Planning Cube 3 – Marketing Forecast o Planning Cube 1 – Pricing Cube o Basic Cube S – Actual Sales Data o MC1 – Multi Cube based on above 3 Planning Cubes and 1 Basic Cube

Following 4 Aggregation levels will be created on MC1 to create Planning applications for Pricing, Budgeting & Marketing Forecast

o AL1 – Aggregation Level 1 o AL2 - Aggregation Level 2 o AL3 - Aggregation Level 3 o AL4 – Aggregation level 4

Following 6 Planning Applications will be created on above 4 mentioned Aggregation Levels

o Application 1 - Tender Business by S/Co half year o Application 2 - Price & Budget by S / Co – half year o Application 3 - Pricing, Budgeting & GP Simulation by SMAP RME half year o Application 4 – S /Co Pricing Monthly o Application 6 – Sales Co Marketing Forecast - Monthly o Application 7 – Sales Co Marketing Forecast - Weekly

Detail technical design - Refer Annexure – III



3.2 Process 2 (Sales Forecast)

• Objective The objective of the sales Forecast is to help the Sales Companies improve the process of Sales forecasting based on area wise sales, based on seasonality etc.


• Design Architecture

Figure 16. Sales Forecast



• Technical Design

Following Cubes will be created for Sales Forecasting by Sales Companies o Planning Cube 2 – OB/RB Original Budget / Revised Budget o Planning Cube 4 – Sales Forecast o Planning Cube 1 – Pricing Cube o Basic Cube I – Actual Inventory Data o Basic Cube S – Actual Sales Data o MC2 – Multi Cube based on above 3 Planning Cubes and 2 Basic Cube

Following 7 Aggregation levels will be created on MC1 to create Planning applications for Sales Forecasting by Sales Companies

o AL6 – Aggregation Level 6 o AL7 - Aggregation Level 7 o AL8 - Aggregation Level 8 o AL9 – Aggregation level 9 o AL10 – Aggregation level 10 o AL11 – Aggregation level 11 o AL12 – Aggregation level 12 o AL18 – Aggregation Level 18 o AL19 – Aggregation Level 18

Following 7 Planning Applications will be created on above 4 mentioned Aggregation Levels o Application 5 – Direct Sales Pricing o Application 8 - Customer Group Level Planning, Direct Sales Forecast – Monthly o Application 9 - Sales Channel Level Planning - Monthly o Application 10 - Sales Area Level Planning - Monthly o Application 11 – Sales Simulation +GP - Monthly o Application 12 – Customer Group Level Planning, Direct Sales Forecast - Weekly o Application 13 – Sales Channel Level Planning - Weekly o Application 14 – Sales Area Level Planning – Weekly o Application 20 – Monthly Pricing of Sales Co by SMAP o Application 21 – Monthly forecast of sales co (SMAP) o Application 22 – Weekly forecast of Sales Co (SMAP)




3.3 Process 3 (Consensus & Dependant Forecast)

• Objective

The objective of consensus forecast is to reach an agreement in between the sales and Marketing on the forecast projection made by them. The dependant forecast process is planning of child components and bundling them together with the parent.



Figure 17. Consensus & Dependant Forecast



• Technical Design Following Cubes will be created for Consensus and Dependent Forecast

o Planning Cube 4 – Sales Forecast o Planning Cube 3 – Marketing Forecast o Planning Cube 2 – OB/RB Original Budget / Revised Budget o Basic Cube P – Actual Procurement Data o Basic Cube I – Actual Inventory Data o Basic Cube S – Actual Sales Data o MC3 – Multi Cube based on above 3 Planning Cubes and 3 Basic Cube

Following 2 Aggregation levels will be created on MC3 to create Planning applications for Consensus and Dependent Forecast

o AL13 – Aggregation Level 13 o AL14 - Aggregation Level 14

Following 2 Planning Applications will be created on above 2 mentioned Aggregation Levels o Application 15 - Consensus + Dependent Forecast (Monthly) o Application 16 - Consensus + Dependent Forecast (Weekly)




3.4 Process 4 (PO & SO Simulation)

• Objective The objective of the PO simulation is to plan the procurement for monthly models for 7 months and for weekly basis for 33 weeks considering several parameters. The PO placement in the simple system happens on the based on the results of the simulations.



Figure 18. PO & SO Simulation




Following Cubes will be created for Sales Forecasting by Sales Companies o Planning Cube 5 – SO o Planning Cube 3 – Marketing Forecast o Planning Cube 4 – Sales Forecast o Planning Cube 6 – PO Simulation o Basic Cube P – Actual Procurement Data o Basic Cube S – Actual Sales Data o Basic Cube I – Actual Inventory Data o MC4 – Multi Cube based on Planning Cubes and Basic Cube as shown in above fig o MC5 – Multi Cube based on Planning Cubes and Basic Cube as shown in above fig

Following 3 Aggregation levels will be created on MC4 and MC 5 as shown in above fig to create Planning applications for SO / PO Simulation

o AL15 – Aggregation Level 15 o AL16 - Aggregation Level 16 o AL17 - Aggregation Level 17

Following 3 Planning Applications will be created on above 3 mentioned Aggregation Levels as shown in above fig.

o Application 17 - SO Simulation o Application 18 - PO Simulation - Weekly o Application 19 - PO Simulation - Monthly




3.5 Design architecture for Planning Data flow

Figure 19. Overall Architecture for Planning Data Flow



3.6 Planning Process flow Output

Appl Description of Application Process/Application Output This process output reflected in (Which)application

1 Half Yearly Planning for Tender Budgeting

Sale company's sales budget and price gets updated for Tender Business

Application 3

2 Pricing and Budgeting for Regular Business by S/CO- Half Yearly

Sale company's sales budget and price gets updated for Regular Business

Application 3

3 Pricing, Budgeting and GP simulation by SMAP RME - Half Yearly

SMAP RME simulates the data which keyed in Application 1 and 2. Calculate Tokyo FOB and after that decide SMAP final transfer to each sales company and budget is finalized. GP amount is also simulated.

End Budgeting process.

4 Pricing by S/CO Mkt- Monthly

Monthly pricing maintenance in order to calculate Mkt Forecast amount

Application 6,

5 Pricing by outside Sales - Monthly

Monthly pricing maintenance by outside sales in order to calculate Sales Forecast amount

Application 11, Consol sales report for Outside sales

6 Marketing Forecast and 8D - Monthly

Sales company's Mkt Forecast data capture for Monthly forecasting cycle

Application 15, Consol sales report by sales co.

7 Marketing Forecast of Sales Co and 8D - Weekly

Sales company's Mkt Forecast data capture for Weekly forecasting cycle

Application 16, Consol sales report by sales co.

8 Sales Forecasting by Customer Grp Level - Monthly

Outside sales forecast data capture at customer grp level (Monthly)

Application 9

9 Sales Forecasting by Sales Channel - Monthly

Outside sales forecast data capture at sales channel level (Monthly)

Application 10

10 Sales Forecasting by Sales Area - Monthly

Outside sales forecast data capture at sales area level (Monthly)

Application 15,18

11 Sales Forecasting and GP Simulation - Monthly

Final sales forecasting and GP simulation data capture (Monthly)

Application 18, Consol sales report of outside sales.

12 Sales Forecasting by Customer Grp Level - Weekly

Outside sales forecast data capture at customer grp level (weekly)

Application 13

13 Sales Forecasting by Sales Channel - Weekly

Outside sales forecast data capture at sales channel level (weekly)

Application 14

14 Sales Forecasting by Sales Area - Weekly

Outside sales forecast data capture at sales area level (weekly)

Application 10, 15

15 Consensus + Dependent Forecast (Monthly)

Capturing of total finalized forecast data Application 18

16 Consensus + Dependent Forecast (Weekly)

Capturing of total finalized forecast data Application 19

17 SO Simulation Sales company sales order requirement analyzed and simulated

Application 18, 20

18 PO Simulation-Monthly Final PO simulation file layout generation Flat file for interface to Simple or OPS system.

19 PO Simulation-Weekly Final PO simulation file layout generation Flat file for interface to Simple or OPS system. SMAP inventory report



20 Monthly pricing of Sales Co by SMAP

Sales company's pricing data capture (SMAP RME)

Application 11. Consol sale report by sales co.

21 Monthly forecast of Sales Co (SMAP)

Sales company's Mkt Forecast data capture for Monthly forecasting cycle (SMAP RME)


22 Weekly forecast of Sales Co (SMAP)

Sales company's Mkt Forecast data capture for Weekly forecasting cycle (SMAP RME)




3.7 Process 5 (Actual Data)

• Objective The objective is to display the Actual Data to help in carrying out different simulation.

This is reference information for users and to map different reporting requirement.


• Design Architecture for Actual Data flow

Figure 20. Actual Data flow




Following 4 Cubes & 9 ODS objects will be created for loading Actual Data for planning applications

o Basic Cube S – Sales Actual Data o Basic Cube I – Inventory Actual Data o Basic Cube P – Procurement Actual Data o Basic Cube SO – Sales Order Actual Data o ODS 1 – Sales Data o ODS 2 – Inventory Data o ODS 3 – PO Data o ODS 4 – Receipts Data o ODS 5 – DVAI Data o ODS 6 – OSI Data o ODS 7 – SO Data o ODS 8 – SO Backorder o ODS 9 – PO Backorder



3.8 Complete Architecture for Planning and Actual Data flow

Figure 21. Complete Architecture for Planning and Actual Data flow



3.9 Data loading Strategy

All Master Data and Transaction Data (Actual data) will be loaded through flat files. Flat file

load to the system will be from the Server location. A separate Validation ABAP program will

run to check and validate these flat files. Once the validation is over then Control M will

trigger the jobs for data loading. The flat file loading strategy is as follows. Control M

monitoring team will monitor and trigger the jobs and error report will get distributed to

the respective team. After successful load of the flat files the files will be moved to the

backup folders.

Data Loading Strategy Architecture

Flat File Loading Strategy

Simple

OSI

Others

Flat

Files KRONOS File system

Folders

ABAP

Controller

(Job Scheduling & Monitoring)

Error /

Warning

Message Load

Success

Move

Old File

Backup

Data Loading

Err. Report

Email

PSA Info Obect

PSA Deletion

Strategy

Transformation

DTP

Figure 22. Data Loading Strategy Architecture

Master data change attribute jobs will be scheduled during non peak hours. Depending upon

change requirement this job can be during day time or night time.

The following Master data source files available to load Master data.

• Tokyo 8D code - (S006)

• Tokyo 6D model code – RCM Layout1

• Tokyo 4D Code - RCM Layout 2

• Customer Master – (S005)



• Calendar

• Currency

These three files will update Tokyo model master and its attributes as well as the

relationship of 4D with 6D and Business group 4d with Tokyo Network Company.

The following transaction files are the incoming files to KRONOS system.

• Purchase (Daily – Delta) (S039)

• Sales (Daily – Delta) (S039)

• Inventory (Daily – Delta) (S039)

• N1T011 S O Back order (Daily – Delta)

• N1T014-P O Back order (Daily – Delta)

• Stock order (Monthly – Full) (N1T030)

• ORS Data (Monthly – Full) (N1T031)

• OSI file layout (shipping forecast – 33 Weeks)

• DVAI file layout from SIMPLE (Actual shipping Daily)

Data Load Architecture for Master Data

Data Load Model Master

IF Layout

S006

& RCM

Layout

Data Staging

PSA

Flat file Load

Strategy

Transformation

DTP

Tokyo 8D

Code

6D Model

Name

4D Model

Name

Error Handling

Techniques

Model Master Info objects

Tokyo

Network Grp

Tokyo

Biz 4D

Figure 23. Data Load Architecture for Master Data



Data Load Architecture for Customer Master Data

Data Load Customer Master

IF Layout

S005

CustomerMaster

Data Staging

PSA

Flat file Load

Strategy

Transformation

DTP

Tender

Customer

Customer

Master

Error Handling

Techniques

Model Master Info objects

Figure 24. Data Load Architecture for Customer Master Data



4 Reporting Requirement

Following 6 reports will be created in BI 7.0

1. Consol Sales Report – Sales Companies 2. Consol Sales Report – Direct/Outside Sales 3. Regional Sales 4. SMAP Inventory Report (Actual & Forecast) 5. Inventory Devaluation Report 6. MPI3 Format

4.1 Consol Sales Report – Sales Companies

Figure 25. CONSOL Sales Report – Sales Companies

Characteristic Technical Name Description

Sales Company ZCH_COMP This contains the Sales Company code used for Marketing cubes.

Six Digit ZCH_6D This contains the Six digit code

Value Type 0VTYPE Actual, Forecast , OB, RB and PY

Tokyo 8D Code ZCH_TOK8D This contains the Tokyo 8D Code

Level 1 This contains the SMAP Lvl 1 Data

Level 2 This contains the SMAP Lvl 2 Data



Data Targets – Multi Provider MP1 Info Cube Technical Name Description

Planning Cube1 ZPC_0001 This Contains the Pricing Information

Planning Cube2 ZPC_0002 This contains the OB/RB data

Planning Cube3 ZPC_0003 This contains the Marketing Forecast Data

Sales Cube ZIC_SALES This contains the actual data of sales

Assumptions: Actual PICA (Sales co to Outside sales). Need to

have the interface from PICA DW MPSI for the S/Co to Outside customer sales data for SMAP RME

Forecast Kronos

OB/RB Data Kronos

Currency Conversion Available from the Exchange rate table

Key Figure Technical Name Description

Sales Amount ZKF_SAMT This Contains the Sales Amount Data

Sales Quantity ZKF_SQTY This Contains the Sales Quantity Data

Time Characteristics Technical Name Description

Calendar Year This contains the Calendar year data

Calendar month This contains the Calendar month data

Fiscal quarter This contains the Calendar Quarter data

Fiscal Half Year This contains the half year data



4.2 Consol Sales Report – Direct/Outside Sales

Figure 26. Consol Sales Report – Direct/Outside Sales






Level 1 This contains the SMAP Lvl 1







Data Targets – Multi Provider MP2

Info Cube Technical Name Description



Planning Cube4 ZPC_0003 This contains the Sales Forecast Data


Assumptions:

Actual Simple

Forecast Kronos

OB/RB Data Kronos









4.3 Regional Sales Report

Figure 27. Regional Sales








Model Sub Group This contains the Model Sub Group data










Planning Cube4 ZPC_0003 This contains the sales Forecast Data


Assumptions: Actual Simple

Forecast Kronos

OB/RB Data Kronos









4.4 SMAP Inventory Report (Actual & Forecast)

Figure 28. SMAP Inventory Report (Actual & Forecast)




Value Type 0VTYPE Actual




Total Inventory This Contains the Total Inventory Data Monthly level

Stock Sales Summation of Distributor Sales & Intercompany sales + Dep + Sales Simulation - Sales Adj

D/S Ratio This is calculated key figure

COGS This is calculated key figure

INV WAC This is calculated key figure





Planning Cube6 ZPC_0006 This contains the PO Simulation data

Inventory Cube ZIC_INV This contains the Actual PO Data


Forecast Kronos (PO Simulation + SO Simulation) WD-2 data


FOR WAC If there is no stock, WAC will be zero. System cannot retrieve the last WAC value from SIMPLE because WAC is available at 8D level and report is on 6D level.

Forecast data Is available for next 3 months

GAP:

FOR WAC :

If there is no stock, WAC will be zero. System cannot retrieve the last WAC value from SIMPLE because WAC is available at 8D level and report is on 6D level.

Possible Solutions :

a. Alert for such 6D code if the stock is zero.

b. User needs to maintain the price for such 6D

WAC for forecasted period to be manually uploaded every month in Kronos; Simple interface is required or data to be manually extracted from MBEW table in simple and upload in Kronos








4.5 Inventory Devaluation Report

Figure 29. Inventory Devaluation Report



Tokyo 8D Code ZCH_8D This contains the Tokyo eight digit code

Value Type 0VTYPE Actuals,Forecast




Forecast Quantity This is calculated key figure (Outside Sales And Inter company Stock Sales





Planning Cube6 ZPC_0006 This contains the PO Simulation data

Inventory Cube ZIC_INV This contains the Actual PO Data


Forecast Kronos (PO Simulation + SO Simulation)


Forecast Data Data is available for next 3 months sales qty by model








4.6 MPI3 Format

Figure 30. MPI3 Format



6D Code ZCH_6D This contains the Six digit code

Value Type 0VTYPE Actuals,Forecast




SO Quantity This contains the SO Quantity

Time Characteristics Technical Name

Description









Planning Cube5 ZPC_0005 This Contains the SO Simulation Data

Planning Cube4 ZPC_0004 This contains the Sales Forecast Data


Assumptions:

Actual Simple

Forecast Kronos SO Simulation

GAP:

FOR Price :

How to manage the Unit price for Inter Company Sales

Possible Solutions :

a. Needs to be maintained in pricing sheet or should make Unit price interface available from Simple

From the Price master in S004 Condition to be used

For Outside Sale Average Selling price (Minimum of three prices) to be considered from KRONOS

For SMAP

STK - 1

DIR - 2

3 SAP condition tables

ZSTP - Sales org/Customer/SO Number/Material

- Sales Ord/Customer/Material

ZSTK - Sales Org/Customer/Material

CMU Code relationship to be maintained as a part master data

SMAP LVL2 – 6D – Customer type



5 Assumptions

5.1 Assumptions on actual data management:

1. Data used in the NIT* files will be made available in the harmonized layout which as of

today is not available. Even the data in these files shall be made available only for the Delta and not for the past 6 months to improve the performance.

2. Missing data shall be made available to meet the requirement of the KRONOS system.

(E.g. Dependant, independent sales etc, cancelled line items of an existing PO).

3. No delivery date of a purchase order is pre-pone in the confirmed period.

Assumptions on the authorizations.

1. The info objects proposed in the design are enough to meet the authorization requirement at a broad level.

2. Information on authorization requirement for SMAP and sales companies shall be shared

during the realization to enable work out a role based authorization matrix.

Assumptions on the planning data.

1. Aggregation shall be done only on the same basis as proposed in the design document to ensure that design does not change.



6 EP Design and Configuration

6.1 Portal layout design

• Customized Initial Login screen

The Enterprise Portal will be accessed through a regular browser.

Figure 31. Accessing the Enterprise portal

The URL for login is http://uxt03.sony.com.sg:50000/irj/portal The login language is English .

After entering user-id and password the user can successfully login to the portal. This will provide end users a uniform single point of access to applications, services and information they need for their daily work.

• Customized Header area

The header area will be customized with the SONY Branding image. The background color of the welcome area and functional links will be as shown below.

The portal page looks as shown below.

Figure 32. Screen elements of Enterprise Portal

Launch Web browser

Enter URL of Enterprise portal Enter user ID and password

Masthead



o Header area The Mast head consists of the following –

Welcome area Branding image Functional Logo

Links

- Welcome text (welcome message and user name) - Branding image (Company Branding) - Functional links (to get help, and to log off) - Logo (Company Name and Logo)

o Navigation Panel This is kept in the user’s cockpit. In the detailed navigation all the reports and planning applications assigned to the role will be visible. For the managers cockpit it’s hidden.

o Content Area This area will contain the reports. It can have one single report or multiple reports on one page giving a Dash Board image.

• Portal themes The portal theme defines the overall look-and-feel of user interface elements in a portal desktop, such as aspect of font usage, color, and contrast of the user interface elements of a portal desktop.

• Portal desktops The Portal desktop is a container for the portal theme and default frame page, and is assigned to users through Portal Display Rules.

• Framework pages The default framework page defines the layout, structure or contents of a portal desktop. In the framework page Masthead and Desktop Inner Page iView is kept.

• Desktop Inner Page : This page, contained in the framework page, controls the content rendering and supplies some additional services. The inner page contains Detailed Navigation and Content Area iViews.



Figure 33. Framework Page and Desktop Inner Page

• Edit Master Rule Collection

Using portal display rules, organizations can present portal desktops with varying designs, branding, or layouts to different departments or sub-companies. Users are seamlessly presented with the appropriate portal desktop assigned to their role, group, user or scenario.

6.2 Baseline configuration of EP

• System Landscape

KRONOS system will be integrated with EP in order to project reports and planning applications from the system. The reports will open in the content area in the same window. The planning applications will open a new Excel window which van be saved after editing. OPS system access is provided through EP.



6.3 Portal reports – Iviews

Report development in BI (Sony Team)

• Cockpit Design Two cockpits will be designed one for user and another for manager

• User cockpit – This cockpit will provide access to user specific reports and planning applications. The planning applications will open in a separate window (Bex Analyzer) where the workbook can be viewed and saved after data entry.

Single sign-on will be enabled in this, the users are not required to enter user-id and Password to open Bex analyzer after logging on to the portal.

Eg. SMAP RME Direct Sales head He will be authorized to see only sales function data. On enterprise portal, he will see User Cockpit. He will have SALES role as in Tab or hierarchical form.

Figure 34. Sample User Cockpit

Reports for user based on Role in Organization 1. Sales: All the reports related to Sales. 2. Marketing: All the reports related to Marketing. 3. Procurement: All the reports related to Procurement.

List of Planning Application & Reports specific to user

role



• Manager cockpit – This cockpit will display the reports such as totals sales, Top Category wise Budget and Forecast data. Eg. SMAP RME Divisional head. On Enterprise Portal, he will only see Management Cockpit (Work set) by default. Apart from this, there will be basic function specific roles (Sales, Marketing and Procurement) provided in TAB or Hierarchical form. These roles are created in BI but and will be replicated in Enterprise Portal.

Figure 35. Sample Manager Cockpit

Reports on total Sales

Top 3 Category wise reports on budget and forecast

Reports on Key Customers



6.4 Authorizations and Roles in EP

Figure 36. Roles in EP

Refer Annexure – VI



7 Annexure – I (CRP Doc)

CRP Document

Annexure 1.doc

8 Annexure – II (File Formats)

File formats

Annexure 2.xls

9 Annexure – III (BI-IP Technical design)

BI-IP Design

Annexure 3 .xls

10 Annexure – IV (BI-IP Planning cycle changes handling)

Annexure 4.doc

11 Annexure – V (BI-IP Key figures Granularity)

Annexure 5.xls

12 Annexure – VI (Roles in EP)

Annexure 6.doc

13 Annexure – VII (PO Simulation Formulae)

PO Simulation.doc

SONY – BI-IP Implementation Project Design...

Documents

Transcript of SONY – BI-IP Implementation Project Design...