Gs DP r3 Sb313i CRM Cq44836 Actual Data Loading

SABMP00044836 JBP Actual Data Loading
SB313I Functional Design - Interface

<SABMP00044836 - JBP Actual Data Loading>
Project Name:
<Triumph - Sales>
Team:
<Joint Business Plan>
Document Owner
Document Owner(s)
Project/Organisation Role
Alessio Fiorentino
JBP Functional Designer
Template Version Control

Version
Status
Date
Author
Change Description
v.0.1
Draft
13/04/2011
Alessio Fiorentino
New document
v.0.2
Draft
15/04/2011
Alessandro Volpin
Document review
v.0.3
Draft
19/04/2011
Valentina Pandolfi
Document review
v.0.4
Draft
20/04/2011
Valentina Pandolfi
Inbound Layer InfoCube
v.0.5
Draft
29/04/2011
Alessio Fiorentino
Past two years extraction removed
v.0.6
Draft
09/05/2011
Alessio Fiorentino
P&L list updated. Loading step

described. Costs/Revenues sign.
v.0.7
Draft
19/05/2011
Alessio Fiorentino
P&L sign change. UoM for Volumes

update.
v.0.8
Draft
23/05/2011
Alessio Fiorentino
P&L sign attachment added
v.0.9
Draft
30/05/2011
Alessio Fiorentino
Key Account (ZK Partner Function)

& Open points added
v.0.10
BPE
Reviewed
Document
17/06/2011
Oliver Beck
BPE Review
v.2.0
BPE
Reviewed
Document
20/06/2011
Oliver Beck
BPE Sign Off
v.2.1
Reviewed
Document
28/07/2011
Edwin Royan, Piotr

Stulinski,
Alessio
Fiorentino
Updates according to SAP Review

(i.e. Length of the numeric field)
and Account mapping updated.
Technical Feasibility review. Open
point added.
v.2.2
Reviewed
31/08/2011
Alessandro Santoro
P&L accounts aligned with Finance:
318044004
Confidential and Proprietary

Page 1 of 27
Version
Status
Date
Author
Change Description
Document
Service Discounts added;

Review according to the
architecture
new
V.3.0
Solution
Owner
Reviewed
Document
4/10/2011
Xavery Yurek
Solution Owner Review
v.3.1
Solution
Owner
Reviewed
Document
11/11/2011
Alessio Fiorentino
Information about JBP Attribute

added (CR compliant);
Open Points of BI issue tracker
closed
v.3.2
Solution
Owner
Reviewed
Document
26/01/2012
Alessio Fiorentino
Update during technical build
v.3.3
Solution
Owner
Reviewed
Document
7/02/2012
Alessandro
Santoro
Document Reviewed according to

the CR W3CR018
v.3.4
Solution
Owner
Reviewed
Document
19/04/2012
Alessandro
Santoro & Alessio
Fiorentino
Paragraph 3.1.1 and 3.3 have been

added
v.3.5
Solution
Owner
Reviewed
Document
26/07/2012
Alessio Fiorentino
Actual data Mapping updated to be

aligned to the COMCO structure
Documentation
Reviewed/Approved By
Name
Project / Organisation Role
Version
Approved
Sign-off
Date
Oliver Beck
BPE
v2.0
Approved
27/06/2011
Edwin Royan, Piotr

Stulinski
BI Experts
v2.1
Feasibility
Agreed
27/07/2011
Xavery Yurek
Solution Owner Review
v3.0
Approved
4/10/2011
Anna Rita Coppola
BI Tech Team
3.1
Document
Approved
11/11/2011
318044004

Page 2 of 27
Table of Contents
1
OBJECT OVERVIEW...................................................................................................... 5
1.1 PURPOSE AND SCOPE................................................................................................. 5

1.2 RELATED DOCUMENTS................................................................................................ 8
1.3 BUSINESS REQUIREMENT DETAILS...........................................................................8
1.4 DEVELOPMENT JUSTIFICATION..................................................................................9
2
FUNCTIONAL DESIGN - JBP ACTUAL DATA.............................................................10
2.1 SOLUTION DESCRIPTION........................................................................................... 11

2.2 PROCESS FLOW DIAGRAM........................................................................................ 11
2.3 REUSE CONSIDERATION............................................................................................ 12
2.4 DESIGN ASSUMPTIONS AND DEPENDENCIES........................................................12
2.5 CUSTOMISING DETAIL................................................................................................ 12
3
DETAILED DESIGN - BPC............................................................................................13
3.1 BPC P&L STRUCTURE................................................................................................13

3.1.1
JBP P&L MODEL................................................................................................... 15
3.2 JBP ATTRIBUTE & ZK KEY ACCOUNT PARTNER FUNCTION FOR CUSTOMER. . .16
3.3 MARKETING INVESTMENTS FOR CUSTOMER PBI..................................................17
4
INBOUND LAYER DSO TO STORE ACTUAL DATA....................................................19
4.1 MAPPING DETAILS TO THE INBOUND LAYER..........................................................21

4.2 PROPOSED TRANSFER METHOD / PROGRAM........................................................21
4.3 FREQUENCY................................................................................................................ 21
4.4 REFERENCE CUSTOM TABLES/SEARCH HELP.......................................................23
4.5 CORE SAP PROCESSING DETAIL..............................................................................23
4.6 SECURITY REQUIREMENT.........................................................................................23
4.7 ADDITIONAL TECHNICAL OBJECTS.........................................................................23
4.8 SYSTEM INFORMATION AND DATA FLOW DIRECTION...........................................23
5
FIELD MAPPING........................................................................................................... 25
5.1 SOURCE DATA............................................................................................................. 25

318044004

Page 3 of 27
5.2 TARGET DATA.............................................................................................................. 25

5.3 SOURCE/TARGET DATA EXAMPLES.........................................................................25
6
APPENDIX.................................................................................................................... 26
6.1 GLOSSARY OF TERMS............................................................................................... 26

7
318044004
OPEN POINTS.............................................................................................................. 26

Page 4 of 27
1 OBJECT OVERVIEW
This document defines the solution that will be implemented to align and refresh JBP Actual data
into the BPC application in order to support the JBP Process among SAB Miller companies
involved in JBP design (Poland, Czech, Russia and Romania).
1.1 Purpose and Scope

The purpose of this document is to provide a design for the Actual data Interface in inbound from
BI to SAP BPC (JBP Applications). In particular, it outlines what information is required in terms
of:
Actual data flow;
Formats;
Frequency of update;
Rejected records management.
Data managed
The solution described in this document is intended to support the JBP Process. This document
describes the data loading procedure for the Actual data.
The document describes also how to map the different G/L accounts to CO.PA accounts first as
well as to JBP accounts (P&L lines).
Architecture
BPC architecture solution foresees the building of one Appset common to all countries involved
in JBP project. This Appset will contain 4 applications:
Planning;
Reporting;
Exchange Rates;
UoM Conversion Factors.
Planning and Reporting applications will be Country specific (one for each country).
Applications for Exchange Rates and UoM Conversion Factors will be common to all the
countries.
Objects described in this document will feed Planning application with Actual Data.
318044004

Page 5 of 27
Assumptions
In the current document it is assumed that the requirements described in the following sections
are met. It is assumed that:
All the inbound interfaces, excepted the TPM one, will be produced by BI and all the
required mapping, enrichments, trans-coding, etc. will be managed in BI.
BI will provide data according to the format required by BPC. All the transformations
between ECC and BPC will be managed in BI. BPC will carry out only transformations
strictly required by its internal format (replacement of not assigned values, formatting of
period...).
Hence, no direct flow between SAP ECC and BPC or vice versa is foreseen at this stage.
All the changes in the master data hierarchy will affect also the historical data. Standard
SAP BPC application reports data according to the latest hierarchy view (it is not possible
to manage data according to historical hierarchies, no time dependencies are managed
by BPC).
Actual data is managed/updated in SAP ECC (no new code or values can be directly
created/updated in BPC).
Data loadings towards BPC access point will be scheduled via BI Process Chains.
Frequency will be decided according to needs of JBP process.
All the interfaces will have to guarantee the possibility to re-load the actual data
information for the same time period, in case of mistakes or changes in data uploaded.
The picture below shows the complete architecture that will be developed to support the JBP
process. The diagram describes just the following three layers:
Outbound Layer = BI
Planning Layer = SAP BPC (JBP Applications)
Inbound Layer (BPC/BI Staging Layer + BI Extraction Layer) = BI Actual data involved in
the JBP process will be loaded in the Inbound Layer. Structures created at this level will
act as access point for BPC application. Data loaded at this level must already have the
format required by BPC. A unique access point will be created for Actual data. All the
318044004

Page 6 of 27
product items will be collected in this table. Transformations between format in which
data is extracted from ECC and format required by BPC have to be managed in BI during
the loading into these structures.
318044004

Page 7 of 27
1.2 Related Documents

Technical Design
Link to Technical Design
Generic Global Interface

Functional Design
Link to functional design document that documents the generic

structure that this interface maps to e.g. HR employee master data
Other documents
Any other related documents
1.3 Business Requirement Details

Interface ID
ID from ARIS
RTM
SABMP00025915
Clear Quest
CQ44836
RICEFW Number
SABMP00044836
Interface Description
Actual Data
Interface Type
Inbound (BI JBP)
Region
Europe
Release
W3
Functional Area
Sales CRM
Business Object
Actual Data
Initiating Process
Related ARIS process level 4 step
Business Requirement
Actual Data need to be loaded into JBP in order to have updated

data on the ongoing year, being able to compare past data with
future forecast and eventually use the past as driver for planning.
Past periods information need to be aligned with finance.
Business Gaps
Business Benefit
Commercial view available with the latest data from Finance in

order to drive analysis and forecasting.
Business Dependencies
Overall view of the P&L impacted by the availability of Actual Data.
318044004

Page 8 of 27
Business Assumptions
1.4 Development Justification

Functional Designer
Alessio Fiorentino
Priority
High (mandatory)
New/Reuse
New
Consequence of no Delivery
Mandatory requirements not fulfilled
Description of Alternative
Solution
N/A
Why Alternative is not

Acceptable
N/A
Development Complexity
Complex
Legacy Contact name

System Contact name
318044004

Page 9 of 27
2 FUNCTIONAL DESIGN - JBP ACTUAL DATA

Actual Data requirements are:
1. G/L Accounts and CO.PA Accounts have to be mapped against specific JBP Accounts in
order to be loaded into the system.
2. The mapping between from G/L Accounts to COPA and to JBP P&L lines is specified in
the table available in the below attached file:
GL-COPA Account Mapping.xlsx
GL - COPA Account
Mapping_20120727.xlsx
(Consider that some of the JBP accounts have COPA as source while others are taken
directly from the GL accounts as defined in the attached file)
3. The mapping table contained into the attached file need to be created and further on
maintained into BI according to the mapping rules defined by the Finance Team. This
process involving Finance and BI maintenance will allow JBP to be always fully aligned
with COPA.
4. The Actual data interface will not load any codes or masterdata but have to contain only
values that can be associated to the already existing account structure in BPC.
5. JBP P&L margins for periods containing actual data will not be loaded through the
interface but will be recalculated automatically by the system once the data load is
completed.
6. The Actual data DSO will contain the current year and at least the last two previous fiscal
year actual data (i.e. Current Year, Current Year -1 and Current Year -2 for the Go-live).
7. The load from the staging layer into JBP will involve all months from Current Year-1 until
the current month. Keeping in mind the particularities listed in the further paragraphs for
the current month.
8. Actual data for every single JBP Account have to be available at the bottom level of detail
for all JBP Dimensions, i.e:
o SKU Product dimension;
o National Customer Customer dimension;
o Local Sub-Channel Channel dimension;
o District Country dimension;
o Month Period dimension;
o Local Currency / USD RPTCurrency;
Data will be stored against the Actual scenario, the No Activity activity and BI
Datasource.
9. In case Data are not directly loaded from COPA module the same allocation rules have to
be applied. COPA and JBP figures have to match at the JBP bottom level.
10. JBP Actual data will be reflecting all data restatement, if in BI those are available, after
every loading process.
11. JBP will have to receive all Actual values in Local Currency and in USD.
12. JBP will have to receive all Actual volumes in the four unit of measure: hectolitres, units,
pallets and cases.
318044004

Page 10 of 27
1.5 Solution Description

Actual data will be loaded in BPC to allow Key Account Manager to generate reports in order to
compare past data with future forecast and eventually use the past as driver for planning.
Past periods have to be aligned with Finance/COPA reporting, therefore an interface has been
foreseen to bring Actual data into JBP. Actual loading into the BPC objects will be managed via
packages launched from BPC.
In order to do this, a correspondent DSO will be created in BI to collect values. BI team will load
values at this stage. Data loaded into the Inbound objects is expected to have already the format
required by BPC. All the transformations to match this format will be managed in the data flow
created in BI.
Data loading towards the Inbound stage will be managed automatically via process chains
created in BI.
Data loading from the Inbound stage to BPC application will be performed on demand by JBP
Process Owner, launching a BPC package. The picture contained in next paragraph shows the
structure of data flows for the Actual data.
1.6 Process Flow Diagram

The picture below shows data flow to load Actual Data from BI to BPC.
Data flow will involve 3 layers:

1. BI Extraction Layer (created by BI team and already existing);
2. BI Staging Layer (that will be created by BPC team);
3. BPC Layer (that will be created by BPC team).
318044004

Page 11 of 27
In the BI Staging Layer a unique data target will be created, where the Actual Data will be
collected.
In BPC the number of data targets will depend on the number of appset that will be created. It
will be responsibility of BI team to provide data in the BI Staging Layer according to the format
required by BPC.
1.7 Reuse Consideration

Reuse considerations
Actual Data Upload Process can be reused for all the current JBP in
scope countries.
Reuse reference document

Design Alternatives
None
1.8 Design Assumptions and Dependencies

Design assumptions
All GL and COPA Accounts have been provided to the JBP design
team and then correctly mapped against JBP accounts.
Design Dependencies
N/ATo ensure the actuals are populated with representative data at

the district level, the following CRs have been created.
CQ95254: To split centralised direct sell-in volume, value and costs
into the geographic districts where the actual final sale takes place
(geo-split)
CQ55521: additional changes required within the BI interface layer
to fully deliver geo-split across all the P&L lines required for JBP.
The change is specifically to apply the geo-split to all trade
investment discounts which will involve associating the customer to
the actual transactional posting from FI.
1.9 Customising Detail

N/A for SAP BPC
318044004

Page 12 of 27
3 DETAILED DESIGN - BPC

1.10 BPC P&L Structure
The following table shows the P&L Structure on which the Key Account commercial planning
relies on.
JBP CODE
VOLUMHL
BASELHL
UPACTHL
UPNOAHL
VOLUMUN
BASELUN
UPACTUN
UPNOAUN
VOLUMCS
BASELCS
UPACTCS
UPNOACS
VOLUMPL
BASELPL
UPACTPL
UPNOAPL
PLERLOS
PLDISCO
PLTRADEO
N
PL51110001
00
PL51110003
00
PL51110005
00
PLOH51000
001
PLVVPRMON
PLVVFBI
PLVVDISON
PLVVSET
PLVVODS
318044004
P&L Line Description
Total Volumes (HLs)

Baseline (HLs)
Uplift Activity (HLs)
Uplift Non Activity (HLs)
Total Volumes (Units)
Baseline (Units)
Uplift Activity (Units)
Uplift Non Activity (Units)
Total Volumes (Cases)
Baseline (Cases)
Uplift Activity (Cases)
Uplift Non Activity (Cases)
Total Volumes (Pallets)
Baseline (Pallets)
Uplift Activity (Pallets)
Uplift Non Activity (Pallets)
Gross Sales Income
Discounts
Trade discount (on invoice)
Dom Trade Discs (Excl. Free Product)
Dom Trade Discs- Performance Discount
Dom Trade Disc - Price Discount
Other Trade Discounts ( on invoice)
Promotional Discount (On Inv)
Promotional Discount - FBI
Distribution Discount (On Inv)
Settlement Discount
Other discounts
Page 13 of 27
PLNIVAL
PLTRADEO
F
PL51110002
00
PL51110004
00
PL51110006
00
PLSDISC
PLOH51000
002
PLVVPRMOF
F
PLVVDISOFF
PLVVPDS
PLVVCEX
PLNETPR
PLROYAL
PLVVCOS
PLVVBT1
PLVVGEO
PLVVPRV
PLVVUSG
PLVARDC
PLVVOVC
PLADCTS
PLGPROF
PLMKTGI
PLDMATL
PLDMBTL
PLVVMOT
PLVVPOS
PLVVAGF
PLVVSDP
PLVVLEF
PLVVPRO
PLVVBTR
PLVVPIS
PLVVINM
Net Invoice Value
PLNETCO
Net Contribution
318044004
Trade discount (off invoice)

Dom Trade Discs (Excl. Free Product) - Off Invoice
Dom Trade Discs-Performance Discount-Off Invoice
Dom Trade Disc - Price Discount - Off Invoice
Service Discounts
Other Trade Discounts (Off Invoice)
Promotional discount (Off-Inv)
Distribution discount (Off-Inv)
Pub discount (volume related)
Excise & Sales Taxes
Net Producers Revenue
Beer Royalties
Standard Production Cost
By-Prod Income
Geographical Variance
Price Variance
Usage Variance
Variable Distribution Cost
Variable Cost Other
Additional Cost to Serve
Gross Profit
Marketing Investment
Direct Marketing ATL
Direct Marketing BTL
BTL Merch / POS
POS
BTL - Agency Fees
Secondary Placements
Leaflets
Promotions
Other BTL
Pub Investment Spend
Indirect Marketing
Option 1
Net
Contribution

Page 14 of 27
PLVVPOS
PLVVSDP
POS
Secondary Placement
PLVVLEF
Leaflets
PLRELNET
Relevant Net Profit
PLPBIND
Profit Before Indirect
Option 2
Relevant
Net Profit
CUSTOMER VIEW
JBP CODE
P&L Line Description
CSTSINCR
Customer Sales Income (RRP)
R
CSTSINCFC Customer Sales Income (FCP)
Following the table above, actual values for all the elements in grey cells will not be loaded
through the interface but their value will be calculated by the system.
The Relevant Net Profit is calculated as Gross Profit without the expenses for Secondary
Placement, Leaflets and POSM.
In order to have the Actual data values aligned with COPA, the loading interface will bring in JBP
values already converted according to the same conversion rate that COPA uses: as (W) SAB
YtD Weighted Avg rate for closing. Being this type of rate at daily level it has to be used the
one available for the last day of the month.
There is a different account of Volume for each unit of measure considered. Therefore the
volume expressed in each of the unit of measure will need to be assigned correctly as follow:
VOLUMHL Total Sales Volumes in Hectolitres
VOLUMUN Total Sales Volumes in Units
VOLUMCS Total Sales Volumes in Cases
VOLUMPL Total Sales Volumes in Pallets
The UoM for volumes that will be loaded in the staging layer are different according to the
source system: Actual volumes will reach COPA either as Each or Cases and in COPA
calculation will be triggered to have volumes in the other units of measure as well. On the other
hand volumes from INFOR DP will reach BI in hectolitres only.
The UoM conversion factors have to be aligned with the one loaded through the JBP UoM
Interface
described
in
the
RICEFW
#
SB313I_JBP_SABMP00044823
Functional_Design_Interface.
All values coming from ECC need to be allocated against one of the above P&L line according to
the mapping table available in Chapter 2.
1.10.1 JBP P&L Model

318044004

Page 15 of 27
Please find in the excel file attached below all the detailed information about the JBP P&L Model,
on which all JBP RICEFWs rely on:
SABM JBP Design - PL Model v5 1.xlsx
SABM J BP Design PL Model v5.2.xlsx
1.11 JBP Attribute & ZK Key Account Partner Function for Customer
JBP need to store all actual data against either one of the three main groups of Customers: JBP
Accounts, Non JBP Key Accounts, and Fragmented Business.
Actual Data have to be mapped against the proper JBP Customer according to the hierarchy
proposed and described into the Customer RICEFW # SB313I_JBP_SABMP00044832.
This means that Actuals need to be aggregated following the JBP Attribute (to be within the first
group) and the ZK-Key Account Partner Function criteria. Therefore the Actual Data that are
related to a customer that is highlighted as JBP relevant, will remain mapped against the same
customer. On the other hand if that customer has the ZK value assigned, its actual will be
mapped against the Non JBP Key Account, together with all the other key accounts without JBP
attribute. In a similar way actual data belonging to all non JBP relevant customers and non Key
accounts will be mapped against the Fragmented Business branch.
A ZK-Key Account value is assigned to each element of the bottom level of the standard
customer hierarchy (ZALB level Local Branch), while the JBP Attribute is associated to the
highest level of the hierarchy (ZE12 National Purchasing Group).
BI will have to check if the ZE12 related to the ZALB under investigation is a JBP Account. Then,
if it not JBP relevant, BI needs to check if any sold to party non JBP relevant are linked to a Key
Account National Customer (through the ZK) otherwise it will have to map actuals against the
Fragmented Business. Its important to highlight the assumption that if a ZALB is marked with
the ZK Business Partner function, also all the other ZALB related to the same National
Purchasing Group will be marked as well.
National Customer is the correct level of detail (bottom) required by JBP for the Customer
dimension.
Example: (simplified as number of dimension involved)
Product, Customer, Month, Value
SKU1, Ship-to-party1, Apr, 1000
Customer Hierarchy (reduced number of levels)
L6
ZE12_NationPurchGroup1 (JBP Attribute = missing,),
318044004

Page 16 of 27
L5
L2 - L4 .
L1
L1
ZD12_NatCustomer1
Ship-to-party1 (ZK=3000; Key Account)

Ship-to-party2 (ZK=3000; Key Account)
L6
ZE12_NationPurchGrou2 (JBP Attribute = missing,),
L5
ZD12_NatCustomer2
L2 - L4 .
L1
Ship-to-party3 (ZK = 9999-Dummy; Non Key Account)
L1
L6
ZE12_NationPurchGroup3 (JBP Attribute = missing, )
L5
ZD12_NatCustomer3
L2 - L4 .
L1
L1
L6
ZE12_NationPurchGroup4 (JBP Attribute = Available; JBP Relevant Account )
L5
ZD12_NatCustomer4
L2 - L4 .
L1
Ship-to-party7 (ZK = Not Needed)
L1
Ship-to-party8 (ZK = Not Needed)
After JBP Mapping
Ship-to-party 1 and Ship-to-party 2 belong to the same ZE12 element that is also a Key Account
(ZE12_NationPurchGroup1) without JBP attribute. In JBP the two Ship-to-party have to be
aggregated to the National Customer level of detail (corresponding to the ZD12 level) against
the element called JBP_ZD12_Non JBP Key Account.
Both ZE12_NationPurchGroup2 and ZE12_NationPurchGroup3 are not Key Accounts as well as
non JBP relevant and therefore the actual values of the Ship-to-party belonging to them (from 3
to 6) will have to be aggregated against the JBP_ZD12_Fragmented Business.
On the other hand, Ship-to-party 7 and Ship-to-party 8 belonging to the same JBP Relevant
ZE12 element, will be aggregated against the same ZD12 keeping the original Account Name
(i.e. JBP_ZD12_NatCustomer4)
Total Product, April, JBP_ZD12_NatCustomer4, value 2240
Total Product, April, JBP_ZD12_Non JBP Key Account, value 1700
Total Product, April, JBP_ZD12_Fragmented Business, value 400
318044004

Page 17 of 27
1.12 Marketing Investments for Customer PBI

A major consideration which influences the design approach for Customer PBI is the logic
required to calculate Net Contribution.
As can be seen in the summary below, the 2 margin calculations use conflicting logic.
Net Contribution
Customer PBI
Marketing Investment needs to include all costs assigned to WBSs:

This includes WBSs which are KA specific (e.g. Secondary Placement on
Tesco, Leaflets on Tesco, etc..) and those that are not (e.g. TV campaign,
Consumer research, etc.. ) which are indirectly allocated
Only Marketing costs assigned directly to customers through WBSs are
included.
In order to calculate the proper Net Contribution margin, the Marketing Investments need to
include all costs assigned to WBSs: both the ones KA specific and those that are not (indirectly
allocated). On the other hand the Customer PBI has to consider only those Marketing costs
assigned directly to customers through WBSs KA related.
In order to meet both requirements, Marketing Investments accounts need to be duplicated in
order to have different levels of detail which are needed for the Customer PBI and Net
Contribution calculation.
For each Key Account, a group of Marketing Investments will take only the costs assigned
directly to the specific customer (Group A), while a second group will take all the Marketing
Investment costs assigned to the specific customer plus the ones indirectly allocated to it
through the profitability analysis (Group B).
The JBP agreed P&L will display only the Marketing Investments which are required for
theconcur to the Net Contribution calculation, while the Marketing Investments strictly assigned
to customers will be hidden and only used for the Customer PBI calculation.
The Actual Data loading interface and a transformation rule within BPC will be used set, in order
to manage what stated above, as following:
An attribute will identify for each Marketing Investment account if the cost is customer
related (Direct) or not (Indirect). In particular:
o Attribute value = D The cost is directly allocated to a customer
o Attribute value = I The cost isn not customer related (Indirect)
o Attribute value = T The cost is the sum of the direct and indirect costs, for a
specific customer (i.e. D+I).
For the calculation of Customer PBI, the values which have assigned the attribute D in
the staging layer will be only one considered. They will be loaded into BPC in the Group
A of Marketing Investment accounts through an ad hoc transformation rule.
For the calculation of Net Contribution the values which have assigned the attribute TD
and I in the staging layer will be considered. A transformation rule within BPC will sum
for each Marketing Investment account both the values with attribute I and D.
Therefore a single value, for each specific combination of dimension, will be loaded into
the Group B of Marketing Investment accounts.
318044004

Page 18 of 27
Please find below the account details:

GROUP A
Account used for Customer PBI calculation (NOT displayed on P&L)
KA specific costs (Directly allocated)
PLDMATL_CPBI
PLVVMOT_CPBI
PLVVPOS_CPBI
PLVVAGF_CPBI
PLVVSDP_CPBI
PLVVLEF_CPBI
PLVVPRO_CPBI
PLVVBTR_CPBI
PLVVPIS_CPBI

BTL Merch / POS
POS
BTL - Agency Fees
Leaflets
Promotions
Other BTL
Note: The proper calculation for Customer PBI are detailed into the paragraph 3.1.1
GROUP B
Account used for Net Contribution calculation (displayed on P&L)
Total Marketing costs (Directly and Indirectly allocated)
PLDMATL
PLVVMOT
PLVVPOS
PLVVAGF
PLVVSDP
PLVVLEF
PLVVPRO
PLVVBTR
PLVVPIS

BTL Merch / POS
POS
BTL - Agency Fees
Leaflets
Promotions
Other BTL
Note: Please note that any technical details provided to support the business requirement
described (e.g. attribute values D, or I or T, two type of groups of accounts) can be
amended after the technical review that will be performed by the JBP Tech team. In case the
technical details will be modified, the distinction between costs relevant for Net Contribution
margin vs those relevant to calculate the Customer PBI will remain the same described above.
318044004

Page 19 of 27
4 INBOUND LAYER DSO TO STORE ACTUAL DATA

In order to be loaded into the BPC applications, Actual Data will be stored in the Inbound Layer
DSO created in BI. DSO will have the structure described in the table below.
OBJECT
Dimensions
318044004
FIELD NAME
FIELD
DESCRIPTIO
N
PNLACCOUNT
Represents
the national
JBP (code) to
which the
value refers
PRODUCT
Represents
the SKU
(code) which
is the SAP
element code,
starting with
the Country
code
to which the
value refers
CUSTOMER
Represents
the National
Customer
(code) to
which the
value refers
CHANNEL
Represents
the Local SubChannel
(code) to
which the
value refers
ORGLEVEL
Represents
the District
(code) to
which the
value refers
PERIOD
Represents
the Month
(code) to
which the
value refers
TYPE
CHAR
Lengt
h
(max)
20
Mandator
y Field
NOTE
The code has to be

aligned with what
described in this
document
No spaces are
allowed
SAP Element code
Prefix code is
required. The two
digit prefix indicates
the Country where
that SKU is sold
(e.g. CZ)
Represents the
bottom level of the
Product dimension
The code has to be
aligned with JBP
masterdata
Represents the
bottom level of the
Customer
dimension
Yes
CHAR
20
Yes
CHAR
20
Yes
CHAR
20
Yes
CHAR
20
Yes
CHAR
20
Yes
The code has to be

aligned with JBP
masterdata
Represents the
bottom level of the
Channel dimension
The code has to be
aligned with JBP
masterdata
Represents the
bottom level of the
Country dimension
The code has to be
aligned with JBP
Time dimension
Represents the
bottom level of the
Time dimension

Page 20 of 27
Navigational
Attributes
Key Figures
SCENARIO
Represent a
JBP
dimension
CHAR
20
Yes
This value will be:

ACTUAL
ACTIVITY
Represent the
key activity
CHAR
20
YES
This value will be:

NO_ACT
DATASRC
Represent a
technical JBP
dimension
CHAR
20
YES
This value will be: BI
RPTCURRENC
Y
Represent a
JBP
dimension
CHAR
20
Yes
This value will be:

LOCAL or USD
COUNTRY
Represents
the Country
where that
SKU is sold
(e.g. CZ)
CHAR
Yes
SAP Country code
Dot as decimal
separator
The unit of measure
is intended to be
Local Currency or
USD.
VALUE
Actual Amount
in Local
Currency
DEC
Yes
Notes:
1.
2.
3.
4.
DSO must not contain duplicated entries/records.

No spaces are allowed in ID fields as well as in the numeric fields.
Country Navigational Attribute of Product must be activated in the DSO.
Only uppercase digits are allowed in the text fields of this table.
Product field will be the same of BPC SKUs codes; so it will be created as the SAP Product code
with a prefix code of 2 digits indicating the Country where an SKU is sold.
Then every record coming from the Extraction Layer with the detail of SKU will generate a
number of records equal to the number of countries where SKU is sold.
Rule can base on Staging infoobject created for Product in BI, in order to retrieve SKU codes
that will be used in BPC.
318044004

Page 21 of 27
As mentioned above, Actual Data have to be available for each element at the bottom level of
the BPC time, customer, channel and country dimensions. In order to do this, BI team has to
provide Actual data at month, national customer, local sub-channel and district levels of detail in
the Inbound Layer DSO.
The table below shows an example of elements loaded into the Inbound Layer DSO.
PNLACCOU
NT
PL511100
0100
PL511100
0200
PLVVPRM
PLVVCOS
PLVVPRV
PLVVPUA
PRODUCT
CZ00100080
0310105001
CZ00100080
0310105001
CZ00100080
0310105001
CZ00100080
0310105001
CZ00100080
0310105001
CZ00100080
0310105001
CUSTOME
R
CHANN
EL
CZ0010
CZ009
CZ0010
CZ009
CZ0010
CZ009
CZ0010
CZ009
CZ0010
CZ009
CZ0010
CZ009
ORGL
EVEL
PERIO
D
SCEN
ARIO
ACTIVI
TY
DAT
ASR
C
RPT
CUR
R
COU
NTR
Y
CZ01
0P3
CZ01
0P3
CZ01
0P3
CZ01
0P3
CZ01
0P3
CZ01
0P3
2011.
APR
2011.
APR
2011.
APR
2011.
APR
2011.
APR
2011.
APR
ACTU
AL
NO_A
CT
BI
LOC
AL
CZ
ACTU
AL
NO_A
CT
BI
LOC
AL
CZ
ACTU
AL
NO_A
CT
BI
LOC
AL
CZ
ACTU
AL
NO_A
CT
BI
LOC
AL
CZ
ACTU
AL
NO_A
CT
BI
LOC
AL
CZ
ACTU
AL
NO_A
CT
BI
LOC
AL
CZ
VALUE
210,5
00
303,0
30
312,6
26
871,9
02
302,0
00
15,62
6
*Note: Codes of Products, Customer, Channel, Organizational Level have been created for explanation
purposes only.
1.13 Mapping Details to the Inbound Layer

During the data load into the Inbound Layer DSO codes for the different dimension used have to
be compliant and aligned with the masterdata set within JBP, defined in all the different
RICEFWs for interfaces.
1.14 Proposed Transfer Method / Program

Masterdata load from BI to BPC will be organized in two steps:
1. In the first step, data load will be scheduled via a BI Process Chain and will fill the Inbound
Layer infoobjects;
2. In the second step, data will be loaded from the Inbound Layer to the BPC Layer via a BPC
package launched manually by the JBP Process Owner.
1.15 Frequency
Two different loading procedures are available in order to manage Actual Data import:
Daily Actual Data Loading
Weekly Month-end-closure Actual data loading
318044004

Page 22 of 27
Daily Actual Data Loading:

The daily Actual Data loading will consider only the current month accounts (P&L lines) that are
refreshed in a daily basis in the BI DSO receiving information from COPA. These data comes
from the SD module and are the following:
Volumes (HLs)
Volumes (Units)
Volumes (Cases)
Volumes (Pallets)
Gross Sales Income
Trade discount (on invoice)
Dom Trade Discs (Excl. Free Product)
Dom Trade Discs- Performance Discount
Dom Trade Disc - Price Discount
Other Trade Discounts ( on invoice)
Promotional Discount (On Inv)
Promotional Discount - FBI
Distribution Discount (On Inv)
Settlement Discount
Other discounts
The loading process will be performed off line during the non working hours and triggered by the
Data Maintainer or scheduled.
Note1: It has been accepted the risk of misalignment between the daily loaded actual data and
the weekly uploaded master data.
Weekly Actual Data Loading:

The loading from the staging layer into BPC is scheduled weekly and can be triggered on
demand by the Key Account Data Maintainer (during the non-working hours).
The weekly loading will consider all the JBP P&L lines considering up to the last closed month
only (since the open month actual are managed by the daily flow).
Note2: Due to the system architecture selected, only one Appset will be created and every JBP
country in scope will rely on it. In this way every time the actual data are manually triggered the
system will not be put off-line. Obviously the user of the country that is loading the new data (and
only that country) need to be careful since data on which hes inputting might be affected by the
new load.
318044004

Page 23 of 27
All the information and timings highlighted above are referred to the flow of data from the staging
layer to JBP. On the other hand the loading of Actual data from BI to the staging layer will be
performed daily. The process is a scheduled process and no manual trigger is foreseen for any
user.
1.16 Reference Custom Tables/Search help

To be completed by BI design team
1.17 Core SAP Processing Detail

N/A
1.18 Security Requirement

N/A
1.19 Additional Technical Objects

N/A
1.20 System Information and Data Flow Direction
Sending System
System Name
System Technology
File Type Sent
To be completed by BI team
Middleware System
System Name
System Technology
Additional Information
Receiving System
System Name
System Technology
Technology
Type
File Type Received
Joint Business Plan (Country appset)

SAP BPC NW 7.5
INFOOBJECT
318044004

Page 24 of 27
5 FIELD MAPPING
1.21 Source Data
The proper fields from where Actual Volumes should be extracted from are (within ZFC_COPA):
Sales qty (L) BW field: ZKF_VVHTL; (ECC field: VVHTL)
Sales qty (cases) BW field: ZKF_ABSMG; (ECC field: ABSMG)
Sales qty (pallets) BW field: ZKF_VVPAL; (ECC field: VVPAL)
RE Question on
frequency of refresh of data in COPA.msg
1.22 Target Data

TARGET DATA:
Field ID.
File Name/Table
Field Name
P001
PNLACCOUNT
P002
PRODUCT
P003
CUSTOMER
P004
CHANNEL
P005
ORGLEVEL
P006
PERIOD
P007
P008
P009
P010
SCENARIO
ACTIVITY
DATASRC
RPTCURRENCY
P011
COUNTRY
P012
VALUE
Field Description
Represents the national JBP (code) to
which the value refers
Represents the SKU (code) which is
the SAP element code, starting with
the Country code
to which the value refers
Represents the National Customer
(code) to which the value refers
Represents the Local Sub-Channel
(code) to which the value refers
Represents the District (code) to which
the value refers
Represents the Month (code) to which
the value refers
Represent a JBP dimension
Represent the key activity
Represent a technical JBP dimension
Represent a JBP dimension
Represents the Country where that
SKU is sold (e.g. CZ)
Actual Amount in Local Currency
Type
Size
CHAR
20
CHAR
20
CHAR
20
CHAR
20
CHAR
20
CHAR
20
CHAR
CHAR
CHAR
CHAR
20
20
20
20
CHAR
20
DEC
1.23 Source/Target Data Examples

BI team to complete the source example.
318044004

Page 25 of 27
TARGET DATA EXAMPLE:

PNLACCOU
NT
PRODUCT
CUSTOME
R
CHANN
EL
ORGL
EVEL
PERIO
D
SCEN
ARIO
PL511100
0100
CZ00100080
0310105001
CZ0010
CZ009
CZ01
0P3
2011.
APR
PL511100
0200
CZ00100080
0310105001
CZ0010
CZ009
CZ01
0P3
2011.
APR
PLVVPRM
CZ00100080
0310105001
CZ0010
CZ009
CZ01
0P3
2011.
APR
PLVVCOS
CZ00100080
0310105001
CZ0010
CZ009
CZ01
0P3
2011.
APR
PLVVPRV
CZ00100080
0310105001
CZ0010
CZ009
CZ01
0P3
2011.
APR
PLVVPUA
CZ00100080
0310105001
CZ0010
CZ009
CZ01
0P3
2011.
APR
NO_S
CENA
RIO
NO_S
CENA
RIO
NO_S
CENA
RIO
NO_S
CENA
RIO
NO_S
CENA
RIO
NO_S
CENA
RIO
ACTIVI
TY
DAT
ASR
C
RPT
CUR
R
COU
NTR
Y
VALUE
NO_A
CT
BI
LOC
AL
CZ
210,5
00
NO_A
CT
BI
LOC
AL
CZ
303,0
30
NO_A
CT
BI
LOC
AL
CZ
312,6
26
NO_A
CT
BI
LOC
AL
CZ
871,9
02
NO_A
CT
BI
LOC
AL
CZ
302,0
00
NO_A
CT
BI
LOC
AL
CZ
15,62
6
*Note: Codes of Products, Customer, Channel, Organizational Level have been created for explanation
purposes only.
1.24 Source/Target Interface Structure Fields

1.24.1 BAPI/IDOC/RFC EXAMPLE
Standard DTP functionalities will be used to load inbound layer Infoobjects.
1.24.2 FLAT FILE EXAMPLE

Flat File not required. Integration performed via BI data flows.
1.25 Middleware Mapping

1.26 Folder Structure

Flat File not required. Integration performed via BI data flows.
6 OTHER REQUIREMENTS
1.27 Contingency
No specific requirements
1.28 Back-up Requirement

318044004

Page 26 of 27
1.29 Reporting
7 TESTING REQUIREMENTS
1.30 Testing Configuration Requirements
All Masterdata and Hierarchies to be set up in source systems.
8 APPENDIX
1.31 Glossary of terms
Term
Definition
9 OPEN POINTS
Item
Numbe
r
1
318044004
Open Point
Resolution
Date
Final feasibility approval from BI team missing

Concerns about Actual data availability due to the
fact that GL Accounts might not be available at the
proper level of detail.
Piotrs team will search

for the availability of the
info needed within the
GL Items (FI GL14)
(e.g. Sales document
item). Potential option
could be by using the
GLPCA (currently not
used).
16/06/2011
Open Points 1 & 2

Closed. Info available
in the document above.
28/11/2011
27/7/2011

Page 27 of 27

Gs DP r3 Sb313i CRM Cq44836 Actual Data Loading

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Gs DP r3 Sb313i CRM Cq44836 Actual Data Loading

Uploaded by

Copyright:

Available Formats

SABMP00044836 JBP Actual Data Loading

SB313I Functional Design - Interface

<Joint Business Plan>

JBP Functional Designer

Template Version Control

Inbound Layer InfoCube

Past two years extraction removed

P&L list updated. Loading step

P&L sign change. UoM for Volumes

P&L sign attachment added

Key Account (ZK Partner Function)

BPE Sign Off

Edwin Royan, Piotr

Updates according to SAP Review

P&L accounts aligned with Finance:

Confidential and Proprietary

SABMP00044836 JBP Actual Data Loading

Service Discounts added;

Solution Owner Review

Information about JBP Attribute

Update during technical build

Document Reviewed according to

Paragraph 3.1.1 and 3.3 have been

Actual data Mapping updated to be

Project / Organisation Role

Edwin Royan, Piotr

Solution Owner Review

Anna Rita Coppola

Confidential and Proprietary

SABMP00044836 JBP Actual Data Loading

1.1 PURPOSE AND SCOPE................................................................................................. 5

FUNCTIONAL DESIGN - JBP ACTUAL DATA.............................................................10

2.1 SOLUTION DESCRIPTION........................................................................................... 11

DETAILED DESIGN - BPC............................................................................................13

3.1 BPC P&L STRUCTURE................................................................................................13

JBP P&L MODEL................................................................................................... 15

INBOUND LAYER DSO TO STORE ACTUAL DATA....................................................19

4.1 MAPPING DETAILS TO THE INBOUND LAYER..........................................................21

5.1 SOURCE DATA............................................................................................................. 25

Confidential and Proprietary

SABMP00044836 JBP Actual Data Loading

5.2 TARGET DATA.............................................................................................................. 25

6.1 GLOSSARY OF TERMS............................................................................................... 26

Confidential and Proprietary

SABMP00044836 JBP Actual Data Loading

1.1 Purpose and Scope

Actual data flow;

Rejected records management.

UoM Conversion Factors.

Confidential and Proprietary

SABMP00044836 JBP Actual Data Loading

Planning Layer = SAP BPC (JBP Applications)

Confidential and Proprietary

SABMP00044836 JBP Actual Data Loading

Confidential and Proprietary

SABMP00044836 JBP Actual Data Loading

1.2 Related Documents

Link to Technical Design

Generic Global Interface

Link to functional design document that documents the generic

Any other related documents

1.3 Business Requirement Details

Inbound (BI JBP)