P&L application provides reports fully aligned with BFC structure (BFC Headings) down to REBIT/REBITDA able to analyze P&L starting from the BFC view (Company/Activity) and ability to drill down to Customer Material level.
A profit and loss statement (P&L) is a financial statement that summarizes the revenues, costs and expenses incurred during a specific period of time, usually a fiscal quarter or year.
These records provide information about a company's ability – or lack thereof – to generate profit by increasing revenue, reducing costs, or both.
It was done in 2 phases :
Phase 1 : COPA model of Rhodia legacy (RCS)
Phase 2 :
Integrated Margin is linked with P&L data and providers BW and BO reports with details of the calculation of the integrated costs
Reporting coordinator is Sandrine Micollet.
More than 500 users have access to WC applications. Those users are worldwide and most of them are controllers.
P&L was done in 2015 and IM in 2016
| Role Code | Role Description | Explanation |
|---|---|---|
| ZR_RCS_CA_M432 | P&L – Upload Data - Non-ERP ZPL_FILE | Role menu for non ERP |
| ZR_RCS_CA_M12 | PL - P&L Reporting | Role menu |
| ZBI_RCS_FI_A33 | P & L – Profit and Loss - End User role | End user role |
Link to the BW Catalog of role
https://drive.google.com/open?id=10GEfKYqrT1eeTO_uHYAheL1GX7L5y_pvH0KQU64qh5I
WP1
BFC
Non ERP
PQ1
Reporting documentation drive folder:
https://drive.google.com/open?id=0B_p_Afe8sjVlN1J3YzYzdE8taDg
https://drive.google.com/open?id=0B_p_Afe8sjVlTEVnc3NjdDV5U0U
Query documentation folder:
COPA module is the ancestor of BW
COPA is divided in “tight” perimeters (in customizing, in VV list, for certain characteristics, for BW data sources) : Operating concern
The lines of the ERP data (COPA value fields from WP1 system) must be translated in BFC account. This translation should be dynamic.
Historic data have be recalcuted with the new allocation Value Field / BFC Account
Historic views are avaible in BFC (not restated)
Value Fields
Value Fields are the lowest key figures in COPA module (For BCS sourcing)
Value Fields are the central elements of the BFC account determination
The organization determination must be as flexible and as dynamic as possible. We had to consider 2 cases:
Existing application in PQ1 with a lot of intelligence
Easier to load from PQ1 than redoing what has already been done
Loaded by flat files
3 levels:
Version 1: Total P&L
Version 2: Interco Sales
Version 3 : Third Party
Another DSO for data without version
Loaded by BFC flat files
Only for CICC companies
Loaded by BFC flat files only for companies loaded in Non ERP
Some companies are in Solvay group but don’t use RCS of Solvay ERP
companies belonging to NOVECARE or SODA GBU
Rhodia ERP WP1
Solvay BW PQ1
BFC (flat files)
BFC GBU
BFC Group of Activities
BFC Activity
In the queries, we keep only the company with Intercompany flag as X. This flag is determined in PRS source system.
The flag is stated as X for the consolidation methods 10 (IG - Fully consolidated), 30 (IP - Proportionately consolidated) and 55 (ME - Equity method futur IP). The table used is ZZF_T001_MGT.
For data coming from FIAR, the base is the Sub-Activity 0G_CWWE01. It's a mix of IECRA (WP1 and RHO systems) and Business area (PF1 and PI1). Functionnally speaking IECRA and Business area are similar so we decided to mix it an existing object, 0G_CWWE01.
We load some master data from PRS system (PF1_050).
With this some source system, we can be sure to have an unique code for companies, customers and vendors.
In RCS and Acetow, the link between ERP and PRS is managed in tables ZZR_T001_MAP (company), KNA1 (customer) and LFA1 (vendor).
For Solvay and CICC, the PRS code is the same than ERP code.
PRS master data are stored in dedicated info objects: C_COMPPRS, C_CUSTPRS and C_VENDPRS.
We also have dedicated info objects from the ERP with the ERP system and code and the PRS attributes: C_COMPCDE, C_CUSTID and C_VENDID.
At the beginning we used C_COMPPRS, C_CUSTPRS and C_VENDPRS in the info providers in order to use their attributes but due to poor data quality we had too oftenly the case of missing link in the ERP between ERP and PRS codes. That's why we decided to replicate PRS attributes in C_COMPCDE, C_CUSTID and C_VENDID info objects.
The BW working capital reports are all based on amounts in Local Currency Those amounts come directly from the source systems.
If user selects a currency in the prompt the query will convert, otherwise it will return the values in local currency.
This conversion is based on the ZRHO rate (coming from WP1).
The current available rate s applied to ALL data (even past data) independently of the date.
For base amount we use the Debit/Credit Amount 0DEB_CRE_LC or FIGL/FIAR/FIAP data and the Stock Value for IM data.
We then apply conversion type ZRH2 for Working Capital - CTK_ZRHWC :
This part of the Working Capital has been done via ITC project. Please check ITC page for more details.
FIAP data re also be used for SPRINT (Purchasing) and CAPEX (Project costs) applications.
The net due date is managed at the document item level and is calculated in the ERP. A new net due date managed manually has been set in each system.
It's available in ZZF_BSEG table.
For each system we created a new data source based on this table and a dedicated DSO (DPFIWC01 to 04).
In BW, there is a direct loading between Net due date DSO and Business layer DSO and also a look-up between Propagation and Business layers to read DPFIWC DSO.
In the ERP, when a profit center or a business area is set, it's not possible to modify it later.
In order to resolve that issue, mecanisms have been created in the ERP.
In WP1
Documents can be modified in ZWFAT205 table (transaction ZWFAT205).
In the example below, document has been modified with a different profit center:
This table is loaded in DSO_FI11 in BW and data are updated in Business layer DSO.
In PF1 and PI1
In PI1 system, the mecanism is different and is not managed document by document, like in WP1.
It's done in PI1 (for PI1 and PF1) through data source ZZFCM_BU_EXCEPTIONS_NEW.
This table is loaded in DBFIWC01 DSO in BW.
Between Propagation and Business layers, we read this DSO to determine the new business area.
For example, document for company code 0005 and business area 3240, the new business area will be 8500.
Initial loading was done from existing DSO ODSFIAP1 and not from WP1 system due to archived document not loadable anymore.
A split of data is done between propagation and business DSO (DPFIAP01 and DBFIAP01), in the start routine inside program z_start__dpfiap01__dbfiap01.
The split is also done in WP1 system, in ZWFAT123 table. This table is filled in WP1 when the data source 0FI_AP_4 is launched. The data are retrieved in ODS_FIWC.
A split of data is done between propagation and business DSO (DPFIAP02 and DBFIAP02) but the mecanism and the logic is much more simple.
We split data using DPFIGL02 DSO (FIGL data) for document with reference procedure RMRP (Invoice receipt) with detail by material, plant, purchase order number and item.
We calculate the item's quote part in FIGL and apply this quote part on amount from FIAP document. For the last splitted item, amount is the total amount minus the sum of other splitted lines.
For CICC, there isn't specific rule.
The same split that Solvay legacy is done.
In business layer, we filter to keep posting on account types S (G/L Account) and M (Materials)
We continue to use ODSFIGL3. This DSO is very huge so it would have been to long to load other DSO and it would be to heavy in WBP system.
A split of data is done between propagation and business DSO (ODSFIGL1 and ODSFIGL3), in the start routine of the transformation.
The split is also done in WP1 system, in ZWFAT143 table. This table is filled in WP1 when the data source 0FI_GL_4 is launched. The data are retrieved in ODSFIGL2.
For Solvay and CICC systems, initialization was done using PQ1 system. We made this choice for performance reasons.
No specific rules.
No specific rules.
New master data C_MATPNT3
Technical object
Based on MBEW table
Attributes Valuation class, company code, GL account
To “correct” accounting from SAP systems : to have same BFC GBU account allocation as in SAP Logistic (could be different from allocation in Accounting)
Need to split FIGL-IM in two silos
Silo S with accounting on G/L account => based on postings
Silo M with accounting on Material => based on C_MATPNT3
2014 and after only
Snapshot at 31.12.2013
Rhodia legacy rules:
Snapshot was made at 31.12.2013 from CUB_IC001
Solvay legacy rules:
Snapshot was made at 31.12.2013 from PQ1.
Acetow legacy rules:
Snapshot was made at 31.12.2013 with flat files from RHO system.
We tried to use standard data sources 2LIS_03_BX, BF and UM to make an initialization at 31.12.2013.
Initialization with 2LIS_03_BX worked but we failed with the other data sources.
No dependencies
List on info providers inside the technical cockpit.
Around 1h for WP1 and 1h for other systems.
We keep all records.
All the reporting is available throught workbooks in the role "WCAP - Working Capital Solvay Group" ZR_RCS_CA_M41
There are 2 sub-folders, 1 for GBU usage and 1 for Accounting and BFC usage.
All workbooks are based on the same info providers.
Query documentation:
There is a lot of queries but the main one are:
BW_QRY_MVFIWC01_0002 BW - Working Capital (Core Query)
BW_QRY_MVFIWC01_0003 BW - Working Capital Receivables (Core Query)
BW_QRY_MVFIWC01_0004 BW - Working Capital Payables (Core Query)
BW_QRY_MVFIWC01_0005 BW - Working Capital Inventories (Core Query)
All queries use structures for key figures. There are many key figures, using calculated and restricted key figures inside.
Jump query available
A broadcast is sent to users. The schedule is determined in the BW process chains. Actually, the broadcasts are sent the 6th, 10th, 15th and 20th working day of the month.
For those days, at the end of the process chain, a file is put in the BO server. When the BO server idenfity this file (an empty txt) file, it triggers the broadcasts.
All the design and settings are managed in BO.
No known bug
FIGL Clearing zones
https://drive.google.com/open?id=1EcYdNGfbiOdFa1TSuqyoxYTKiW2ie9laDbZ1iM1YGUA
FIAP & FIGL Data recovery
https://docs.google.com/document/d/1RWQ2gvcuVVPAHMlYB1SFCtjPZfHtWM9tsIlblghbfkE/edit
No planned evolution
