Responsibility area: Ensure consistency of Reporting axis
1. Objective and Scope
1.1. Objective of this Operation
Solvay is organized in:
- Cluster: top level of the Group structure,
- Global Business units (GBU): main operational and financial sub-division,
- Group of activities : sub-division of a GBU,
- BFC activity 1: main level of the BFC reporting,
- BFC activity 2 : sub-division of “activity 1”, based on an “industrial axis” – it is mainly used in WP1 and is also known as “CGU”. In PF1 it has a one to one relation with Activity 1.
- Lower reporting levels : PIF in PF1
This structure is used to provide the proper reports for business follow-up:
The purpose of this document is to provide the operational / technical details describing the maintenance of a Business structure in PF1 & PI1.
1.2. Scope
This procedure covers the implementation of a new business structure in SAP PF1 and PI1.
2. Definitions
See Finance - Glossary:
3. Tasks description
3.1. I receive the information that a new business structure needs to be implemented in PF1
All requests for data under the responsibility of Finance Data & reporting must be made through the “MDWF” workflow .
For complex changes and topics, there are usually several preliminary contacts and the workflow is created when the solution has been designed and agreed.
In terms of reporting axes, the information can also be provided by an email from Corporate Controlling.
3.2. I analyze and validate the information provided in the request
The description of the process to define Reporting axes in PF1/PI1 can be divided into 5 sub-processes, for an easier understanding :
- New “BFC activity 1”
- New PIF in existing “BFC activity 1”
- New profit center for existing PIF and “BFC activity 1”
- Reorganization of reporting elements below "BFC activity 1”
- Reorganization of reporting elements above “BFC activity 1”.
The business structure is maintained by Group & Accounting Reporting team and the updated list can be found in AODocs.
3.3. I implement a new “BFC activity 1”
The creation of a new “BFC Activity 1” is requested by the GBU and approved by GAR / Corporate Controlling, who assigns its code in BFC, as well as its position in the global organization chain up to the “Cluster” and the related BFC Activity 2.
After GAR’s approval, the GBU needs to communicate to Finance Data & Reporting the necessary elements in order to activate the set-up process.
3.4. I implement a new PIF (product division) in existing “activity 1”
This sub-process deals with the request of a new product division within an existing “BFC Activity 1”.
The GBU needs to communicate to Finance data & Reporting the necessary elements in order to activate the set-up process.
We need to make sure that the new PIF is “independent” from existing ones and that they do not ask a PIF under or above an existing one.
The PIF (“Produit Issu de Fabrication”) is a level of the “commercial hierarchy”. It is materialized in SAP by three objects :
level of the “commercial hierarchy”, under the responsibility of SCMS (Supply Chain, Marketing & Sales)
product division maintained in the material master data
profit centers for finished goods.
3.5. I implement a new profit center for existing PIF and “BFC activity 1”
This sub-process deals with the request of a new F* profit center for an existing PIF, without change of “BFC activity 1”. It is much simpler because it only involves the creation of profit centers.
It can be prompted by a new industrial origin or the need of a specific partner. The decision is usually made by a GBU Controller.
The GBU needs to communicate to Finance data & reporting the necessary elements in order to activate the set-up process.
The first thing to check is that the requested hierarchy of the profit center corresponds to a PIF, neither under nor above. If not, the request cannot be accepted.
3.6. I implement a reorganization of reporting elements “below activity 1”
The “chain” of reporting axes below "BFC activity 1" is materialized in the ERP Solvay (PRS / PF1) and the CICC (PI1) by the following tables :
- PF2 - Table ZZR_REPO_DIV - Reporting : Division
- PF2 - Table ZZF_BFC_MARKET - BFC Activity 1
- PF2 - Table TGSB (view ZZRTGSBV) - Business area
- PF2 - Table ZZF_BFC_DIV_COVV - Trans codification between “reporting division” and BFC Act1
T134G/H Business Area determination for material movements
All these tables are managed in PRS (PF1-050), from which they are transported automatically every hour to PF1_020 and PI1_020.
In addition, the PF2 - Table ZZF_BFC_MARKET - BFC Activity 1 is automatically transported to WP1 including the corresponding “development”, “quality” and “pre-production” systems.
3.6.1. I verify and update tables ZZR_REPO_DIV, ZZF_BFC_MARKET, ZZF_BFC_DIV_COVV
Table ZZR_REPO_DIV
PF2 - Table ZZR_REPO_DIV - Reporting formalizes the “BFC Activity 1” in PF1.
There are 2 possibilities :
The code received by Corporate Controlling is a 2-character code starting with a digit : the code can be taken as such.
The code received by Corporate Controlling is a 4-character code starting with a letter : the code must be trans-codified to a 2-char code. The first digit represents the GBU
- T - Technology Solutions
- C - Novecare
- F - Fibras
- G - Energy
- K - Aroma Performance
- M - Composite Materials
- O - Coatis
- S - Silica
- 3 - Special Chem
The second letter is a sequential letter for the "BFC Activity 1", except for the “GBU Non allocated”, for which we systematically select letter N.
Example :
- TA for TSMIN - TSAL - 609 ALUMINA
- TB for TSADT - TSPA - 049 POLYMER ADDITIVES
- TC for TSDPH - TSPR - PROBAN
- ...
Exceptions
- For the Non allocated "BFC Activity 1" of a GBU - the second letter is always N (ex: TN for TSNAL for TSNR - TECHNOLOGY SOLUTIONS UNALLOCATED)
- For the GBU Special Chem - the second letter is the last character of the "BFC Activity 1" code. (ex: 3B for CH3B - BATTERIES)
Enter :
the 2-character code resulting from the determination described above
the description :
- if the "BFC Activity 1" is a 2-character code : keep the description received in the field “Division medium name” and in “Division long name” (abbreviating the text if too long)
if the "BFC Activity 1" is 4-character log : enter the code of the "BFC Activity 1" + “ – “ + description received in the field “Division medium name” and in “Division long name” (abbreviating the text if too long)
the 5-character code of the “group of Actities” to which the "BFC Activity 1" belongs to
the date at which the new "BFC Activity 1" is active (for information only, one record per organization can be entered)
by default 31.12.9999 as “end date” (for information only, one record per organization can be entered)
Whenever, Corporate Controlling informs us that a "BFC Activity 1" becomes obsolete :
change the “end date” to the one specified by them
insert “DO NOT USE – EX ” in front of the description.
Table ZZF_BFC_MARKET
PF2 - Table ZZF_BFC_MARKET - BFC Activity 1 formalizes the “BFC Activity 1” with its code and official description.
Enter :
the 2-digit or 4-character code received from Corporate Controlling
the description of the "BFC Activity 1"
Whenever, Corporate Controlling informs us that a BFC Activity 1 becomes obsolete : insert “DO NOT USE – EX ” in front of the description.
Table TGSB – view ZZRTGSBV
PF2 - Table TGSB (view ZZRTGSBV) - Business area is used to maintain the Business Area by IT Materials & Structure Data team, upon request from Finance Data & Reporting.
The request is done using Service one when the previous tables have been updated.
The business area code contains the following data, which must be specified in the request to IT Materials & Structure Data team
The Business Area code is made of three parts:
- 1 character : Rules - PF2 - Sector code
- 2 character : "BFC Activity 1" = Reporting Division available in the PF2 - Table ZZR_REPO_DIV - Reporting
- Last character : 0, except for German companies who can use sub-divisions.
Description = description of Reporting division.
Initial validity = determined automatically by the system when the record is created.
End of validity = 31.12.9999 by default.
The dates “valid from” and “valid to” are only attributes. They are present “for information only”. Thus only one record per organization element can be entered.
When a BFC Activity 1 becomes obsolete, a Service one request must be raised asking the IT Materials & Structure Data team to update :
the description, inserting a ZZZZ in front of the previous description.
the end of validity = date on which the "BFC Activity 1" becomes obsolete.
Table ZZF_BFC_DIV_COVV
PF2 - Table ZZF_BFC_DIV_COVV - Trans codification between “reporting division” and BFC Act1 converts the Reporting Division into the official "BFC Activity 1" codes in the interfaces to Reporting systems such as BFC or BW.
It is managed by validity date.
Example until 31.12.2016, the division 33 corresponded to the "BFC Activity 1" = CH3X but from 01.01.2017 it corresponds to the "BFC Activity 1" = CHNR
In case of new reporting division, enter :
Code of the Reporting Division – from PF2 - Table ZZR_REPO_DIV - Reporting.
Valid to = 31.12.9999 by default.
Valid from = date on which the new reporting division is active – should be rather near the “begin validity date” of Business area in PF2 - Table TGSB (view ZZRTGSBV) - Business area.
BFC Activity 1: the official 2 or 4-character code used in BFC, with an existence check in Table ZZF_BFC_MARKET - BFC Activity 1
BFC Activity 2: the code supplied by Corporate Controlling – in case several values exist for a given "BFC Activity 1", take the one corresponding to the region which has the most business in that "BFC Activity 1", often EMEA.
BFC Partner Activity 1 = BFC Activity 1.
In case of a change of a "BFC Activity 1" or "BFC Activity 2" for an existing reporting division:
Copy the existing record to a new one, changing the “end of validity date” to the last day that record is valid.
Update the original record :
Valid from = date on which the new combination becomes active – must be the day after the one used in the previous step, to avoid gaps or overlaps
New "BFC Activity 1" and/or New "BFC Activity 2" – Partner Activity 1 according to the instruction from Corporate Controlling.
In case of obsolescence of BFC Activity 1:
Copy the existing record to a new one, changing the “end of validity date” to the last day that record is valid.
Delete the original record.
3.7. I implement a reorganization of reporting elements above “BFC Activity 1”
At the end of each year, Corporate Management decides on the modifications of the group structures, in terms of clusters, GBU, group of activities, “BFC Activity 1" and "BFC Activity 2".
The present section only deals with the situation in which the changes are made only above the "BFC Activity 1" level.
Examples: GBU A is split into two GBUs, A1 and A2. Or GBU B1 and GBU B2 are merged into GBU C.
Finance Data & Reporting receives this information from GAR, who communicates the required changes.
3.7.1. I verify and update tables ZZR_REPO_CLU, ZZR_REPO_SCLU, ZZR_REPO_BU and ZZR_REPO_SBU
All tables listed above are managed in PRS, from which they are transported automatically every hour to PF1_020 and PI1_020. In addition, tables ZZR_REPO_BU is also transported to WP1. This automatic transport system also includes the corresponding “development”, “quality” and “pre-production” systems.
Note
In these tables, the dates “valid from” and “valid to” are only attributes. They are present “for information only”. Thus only one record per organization element can be entered.
Table ZZR_REPO_CLU
The PF2 - Table ZZR_REPO_CLU - Clusters is maintained in PRS (PF1-050), it formalizes the highest level in the Solvay Business hierarchy.
Enter:
- the 4-character code received from Corporate Controlling
- the description received from them
- the date at which the new cluster will be active
- by default 31.12.9999 as “end date”.
Whenever, Corporate Controlling informs us that a cluster becomes obsolete :
- change the “end date” to the one specified by them
- insert “ZZZZ ” in front of the description.
Table ZZR_REPO_SCLU
The PF2 - Table ZZR_REPO_SCLU - Sub Cluster is maintained in PRS (PF1-050), it formalizes the second level in the Solvay Business hierarchy.
Enter :
- the 3-character code received from Corporate Controlling
- the description received from them both in “medium name” and in “name”, abbreviating the latter if too long
- the 4-character code of the cluster to which the sub-cluster belongs to
- the date at which the new sub-cluster will be active
- by default 31.12.9999 as “end date”.
Whenever, Corporate Controlling informs us that a sub-cluster becomes obsolete :
- change the “end date” to the one specified by them
- insert “ZZZZ ” in front of the description.
Table ZZR_REPO_BU
The PF2 - Table ZZR_REPO_BU - Reporting: Business Unit is maintained in PRS (PF1-050), it formalizes the third level in the Solvay Business hierarchy: the “Global Business Unit”
Enter :
- the 2-character code received from Corporate Controlling
- the description received from them both in “medium name” and in “name”, abbreviating the latter if too long
- the 3-character code of the sub-cluster to which the GBU belongs to
- the date at which the new GBU will be active
- by default 31.12.9999 as “end date”.
Whenever, Corporate Controlling informs us that a GBU becomes obsolete :
- change the “end date” to the one specified by them
- insert “ZZZZ ” in front of the description.
Table ZZR_REPO_SBU
This PF2 - Table ZZR_REPO_SBU - Reporting: Sub Business Unit is maintained in PRS (PF1-050), it formalizes the fourth level in the Solvay Business hierarchy: the “Group of activities”.
Enter :
- the 5-character code received from Corporate Controlling, starting with the 2-character code of the GBU
- the description received from them both in “medium name” and in “name”, abbreviating the latter if too long
- the 2-character code of the GBU to which the “group of activities” belongs to
- the date at which the new GBU will be active
- by default 31.12.9999 as “end date”.
Whenever, Corporate Controlling informs us that a GBU becomes obsolete :
- change the “end date” to the one specified by them
- insert “ZZZZ ” in front of the description.
3.8. I request the creation of the new business structure elements
Open a Service one request requesting the update of PF2 - Table TGSB (view ZZRTGSBV) - Business area with the new business area code
3.9. I request to create / update the COPA characteristics
For new entries/codes, COPA characteristics are automatically updated.
Check in transaction KES2 - COPA Characteristics if the new COPA characteristics code is already available.
If not, open a Service one request, asking to update it accordingly:














