The aim of this application is to give a P&L reporting adapted to Soda Ash GBU requirements.
It is based on the corporated P&L query and offered special axis and calculation for Soda Ash.
Specifications: https://drive.google.com/open?id=1Q-QjleNGzLF1tbhALtbjN0hdp9x9Y4zBrR2gURi3yw4
Owner : RtR reporting
IS RtR Reporting coordinator is Charlotte Rollier.
The project was done in 2018.
List of application role + menu role and explanation if we have several applications role with specials rules.
| Role Code | Role Description | Explanation |
|---|---|---|
Link to the BW Catalog of role
https://drive.google.com/open?id=10GEfKYqrT1eeTO_uHYAheL1GX7L5y_pvH0KQU64qh5I
Dataflow overview
https://drive.google.com/open?id=1KvtTRYpRfKjRJNCx0sxGMGQVSe04ARE9V0OnVvd70uI
Reporting documentation drive folder:
https://drive.google.com/drive/folders/1D0RpGQ3rTMDh_7S0AvhWBRkcT-2buhfZ
To enhance the existing P&L flows with axis and calculations required by Soda Ash would have been more risky, more expensive and would have badly impacted corporate P&L flows complexity.
The flow could have been based directly on the multiprovider MVCOPA01, however, tests reveal it was a lot slower than to retrieve the data from a query. Moreover, it permits to retrieve some shared restricted key figures and to manage the quantity translation in the BeX query.
Step 1:
The determination of Soda Ash axis is done using the rules in the table ZBW_PL_SD_RULES.
It consists of interval of values for several criteria : landscape, activity, partner activity, partner GBU, BFC management area, company, product hierarchy, division and GBU zone.
Reading the table ZBW_PL_SD_RULES the tranformation will obtain a scope ID for which corresponds a value of each Soda ash axis: Sourcing (origin), BU Soda Ash (can be Europe, NAFTA or Seaborne), Type of Flow, Type of flow (display).
Step 2:
Then reassignments and new lines are created, each case is identified by a specific SD value type:
It can be #, internal or external.
The type of flow is used for internal / external calculation in Bex formulas: an external key figures has necessarly C_FLOWTSD = # or E, and an internal key figures has necessarly C_FLOWTSD = I.
It is used in order to be able to split a key figures internal and external part under different axis. For instance, for some scenarii, the internal part of the sales costs will be in BU Europe and the external part in the BU Seaborne.
It can be #, internal or external (however, all amounts assigned to an identified Soda Ash scope should be either internal or external).
This type of flow is used for display only and not for the calculation of the internal / external part, which means that external part of a key figure could be displayed as internal in the report (for instance, for the scope E1, the internal sales are displayed as external).
The table is maintained by Reporting Plateform using the program ZBW_PL_BY_BU? (TODO: to confirm).
The file to import is maintained here: https://drive.google.com/open?id=1wHh3FiqF2szGGL4HBR8ARvefk7V-eIl7
Dependencies with other application (BW, QV, Externals tools like PVelocity or Dynasis etc...
Detail of process chain, list + link between or special event done for the loading
Detail of frequency : monthly; weekly or else
if possible, give some information on average process chain duration, amount of data loaded and total data volume example: daily process chain loaded in 30 min, weekly chain loaded in 1h15, with around 2k to 10k lines in DELTA mode for a total of 10M lines in cube. The purpose is to give a general overview of the volume of data managed y the application
| Key Figure | Estimation |
|---|---|
| ~ Average Process Chain Runtime | |
| ~ Average nb of rows loaded per load | |
| ~ Total nb of rows loaded (if full) | |
| ~ Average Runtime for 10k lines |
Give details if any historisation is done, example: keep only data greater than beginning of Y-3
Query end user documentation should be created in the public "Customer Support Wiki" space under the corresponding BW application page : BW - Application. Technical query query documentation, if necessary should be added as a sub-page of this documentation using the BW Technical Query Documentation template.
List the most important and complex queries only with a link to the documentation
Give detail on all complex functionalities: list most important and/or complex KPI, query jump, alerts
Indicate if there are broadcasts and give some details on the broadcast settings.
Give the list and explanation on the known, not-solved, bugs.
List recurring procedures
Detail planned major evolution if already known. Example: complete decommissioning of application is planned in 2017 / Extension to solvay perimeter planned in 2nd semester of 2016