1.PURPOSE AND USAGE OF BUSINESS STRUCTURES IN BFC

Solvay IFRS reporting is organized per legal companies (one reporting package per legal company) reporting their Financial Statements (P&L, Balance Sheet and Cash Flow Statement) on a monthly basis. To allow Businesses to get their Financial results, each legal company will in addition split its results on Business dimensions. 

The following items of Financial Statements require an allocation per Business:

  • P&L until EBIT (Operating Income)
  • Internal sales and external sales
  • Working Capital (stocks, acc. receivables and payables), CAPEX (capital expenditures), Fixed assets and Investments
  • Free Cash flow

It means that Group IFRS Consolidated results can be obtained as sum of legal companies and as sum of Businesses.

This IFRS reporting per Businesses is used by both Businesses and Corporate Controlling teams to prepare the analysis of Solvay Businesses performance included in both Financial press releases every quarter and Annual report.

To be noted that Business structures are also used in Controlling reporting categories (RSB and PREV).


2.BUSINESS STRUCTURES HIERARCHIES IN BFC

Business structures are organized around 5 levels aggregating each others in a global hierarchy (following a "Russian dolls" principle - 1 level can belong to only one upper level and never two):

  • CLUSTER = Operating segment
    • This is the upper level of the hierarchy
    • Codification rule : 4 letters 
    • Corresponds to the level of external communication on Solvay Businesses performance 
    • Example: CHEM "Chemicals", MATE "Materials", SOLU "Solutions"...
    • Approval process for creation of new CLUSTER / update of content: Corporate Controlling
  • SEGMOP = Group of GBU's = Operational Segment
    • This is the 2nd level of the hierarchy
    • Codification rule : 3 letters 
    • Used internally to group GBU's - not a level subject to external communication
    • Examples in Cluster CHEM "Chemicals": GCT "Coatis", GEB "Vinythai"...
    • Approval process for creation of new SEGMOP/ update of content: Corporate Controlling
  • ENTREP = GBU = Global Business Unit
    • This is the 3rd level of the hierarchy
    • Codification rule : 2 letters 
    • Used internally  - corresponds to the Business organization and management with Global Director, Finance teams...
    • Examples in Segmop GCT "Coatis"": CT "Coatis", FI "Fibras"
    • Exception / constraint on codification: do not choose codes starting with "D", "Dx" codes dedicated to Discop GBU's (examples: DO "Discop Acetow" / DM "Discop Performance Polyamides"...), creation subject to request and approval from GAR
    • Approval process for creation of new GBU : Corporate Controlling , on proposal made initially by Businesses
    • Approval process for update of content : Businesses
  • BU = Business Unit
    • This is the 4th level of the hierarchy
    • Codification rule :  5 letters - the 2 first letters are the ones of the belonging GBU code
    • Used internally  - allows each GBU to sub divide its activities (criterias considered to split can be external market, external application, product lines...)
    • Examples in GBU FI "Fibras"": FITEX " Fibras Textile"
    • Exception/constraint: do not choose codes starting with "D", "DxDIS" codes dedicated to Discop BU's (examples: DODIS "Discop Acetow"...)
    • Approval process for creation of new BU / update of content : Businesses
    • Note that Business requests are subject to challenge from SBS FSL teams if they bring complexity (in setup and maintenance) without any demonstrated added value for performance follow up


5th and last level combines 2 different dimensions : MARK "Activity1" and CGU "Activity2"

  • MARK "Activity1"
    • Level for data entry in the IFRS reporting packages to enter P&L components and Acc Receivables
    • Level also directly used in BFC customizing (category scenario, consolidation rules, reports, Business users accesses...) and in Journal manual entries from Corporate (GAR and Controlling)
    • Codification rule :
      • Different practices coming from the past Solvay legacy (letters & digits - digits corresponding to Division codes from former Cheops conso tool from Solvay) and Rhodia legacy (letters)
        • example on the right side on GBU CH "Special Chem":
          • BU CHRAR coming from the Rhodia legacy includes Activity 1 codes made of letters only (ex CHAT)
          • while BU CHFLO "Fluorine" coming from the Solvay legacy includes Activity1 codes made of both letters & digits (ex CH3A)
      • Best practice: it is recommended to cross check that any new Activity1 code proposed for BFC (for both Solvay and Rhodia legacies) does not exist already :
        • 1) in Solvay ERP's (PF1, WP1) with FSL SU MAC Master Data team
        • and 2) in BFC dimension builder
  • CGU "Activity2"
    • Level for data entry in the IFRS reporting packages to enter Working capital, Fixed assets and Investments
    • Level also directly used in BFC customizing (category scenario, consolidation rules, reports, Business users accesses...) and in Journal manual entries from Corporate (GAR and Controlling)
    • Codification rule :
      • As for MARK dimension, different practices coming from the past Solvay and Rhodia legacies
        • example on the right side on GBU CH "Special Chem":
          • BU CHRAR coming from Rhodia legacy includes Activity 2 codes made of letters & digits (ex CHCGU113)
          • while BU CHFLO "Fluorine" coming from the Solvay legacy includes Activity2 codes made of letters & digits but not organized with the same sequence (ex CHCGU3AP)
      • Best practice: it is recommended to cross check that any new Activity2 code proposed for BFC (for both Solvay and Rhodia legacies) does not exist already:
        • 1) in Solvay ERP (PF1, WP1) with FSL SU MAC Master Data team
        • and 2) in BFC dimension builder
  • Approval process for both MARK and CGU:
    • Approval process for creation of new MARK and GBU : Businesses
    • Note that Business requests are subject to challenge from SBS FSL teams if they bring complexity (in setup and maintenance) without any demonstrated added value for performance follow up







3. OVERALL PROCESS FOR BUSINESS STRUCTURES UPDATES 

3.1. PLANNING

Process of Business structures updates is organized yearly through a "3 steps / waves" cycle

Best practice is to start in Q3 Y the identification and setup of Business structures changes expected for Go Live Jan 1st Y+1

Wave 1 - October Y: 1st set of expected changes needed for Budget

  • Needed for budget exercise in PREV reporting category
  • Only new structure items are created with "NEW " value in "Changes" characteristic of both Actvity1 and Activity2 reference tables from Dimension builder (to avoid usage in Y Actuals)

Wave 2 - December Y : 2nd set of changes (late answers from GBU's) / Creation of New objects in BFC

  • Late decisions from GBU's (not communicated earlier in October)
  • Only new structure items are created with "NEW " value in "Changes" characteristic of both Actvity1 and Activity2 reference tables from Dimension builder (to avoid usage in Y Actuals)

Wave 3 - end of January Y+1 : Activation/Deactivation in BFC for January Y+1 reporting

  • GO to be given by Corporate Controlling - when Year end Y-1 results finalized
  • Around January 25th to have few days for BFC set up before January reporting generation
  • In this last round:
    • "NEW" values removed to blank
    • "OLD" values set up to block usage on Activity 1 & 2 not to be used anymore in Y+1 ACTUALS
    • updates in hierarchies content (change of links)
    • update of descriptions to add OLD when required
  • Not forgetting impacts on Business users accesses: as Business accesses are based on GBU codes, any creation of a new GBU code is expected to require updates (new GBU code to be added) of accesses of Businesses users working for the new GBU
  • Not forgetting impacts on Filters from Dimension builder: such filters have been created to allow artificial combination of several GBU's (to keep track of historical business structures)


Any change of Business structures out of this yearly cycle (i.e. during the year) is technically feasible in BFC structures. However never recommended as restatement of past months (since Jan 1st Y+1) is a heavy exercise in ERP's


3.2. ACTORS AND REFERENCE FILE TO COLLECT Y+1 BUSINESS STRUCTURE CHANGES

The following actors are involved:

  • Corporate Controlling
    • Coordinates the collection of changes with Businesses and inside Corporate Controlling
    • Challenges, when appropriate, the proposed changes - can consult for advice BFC Admin and FSL SU MAC Master Data team
    • Communicates the changes received to BFC Admin and FSL SU MAC Master Data team
    • Controls the BFC set up of changes of Business structures before piloting to BFC Production database


  • BFC Admin team:
    • Create and update the reference file collecting the BFC Business structures changes for Y+1

    • Reference file is created from save as of "Y current business structures"
    • Then it is updated highlighting the different type of changes required for Y+1 (received from corporate Controlling): 
      • new objects to be created and used from Y+1 reportings - yellow back ground in the example above
        • As explained earlier in this procedure, BFC Admin will propose the BFC codification, checking with FSL SU MAC Master Data team that no constraint with ERP's
      • old objects not to be used anymore from Y+1 reportings - red back ground in the example above
      • change of links inside hierarchies - pink back ground in the example above


  • Once changes collected and new required codifications are validated, BFC Admin will perform the associated BFC customizing
  • Updates Business users accesses and Business filters, when required, before January Y+1 reporting


  • FSL SU MAC Master Data team:
    • Challenges when needed the requested changes
    • Ensure coordination of Business structures updates in the ERP's with Business Data Administrators, FSL Master data teams and IT
    • Collaborates with BFC Admin to align on BFC codifications
    • Ensure communication within Finance network (FSL, Businesses...)


4. CREATION / UPDATES OF BUSINESS STRUCTURES IN BFC

4.1. CREATION OF NEW OBJECTS

Sequence of creation: From TOP to BOTTOM

  • In case of creation of new objects at each level of the hierarchies and linked each others , it is recommended to start the creation at the upper level of the hierarchy.
    • Example below creation of new Activity 1 associated to a new BU => 1st BFC Admin will create the upper level (BU) and then after the lower one (MARK)


  • Also recommended to start 1st creating new CGU "Activity2" codes and then after new MARK "Activity1"


Connect to BFC_Top:

Select the “Dimension Builder” module in the "Setup" domain.

Then select the MARK and CGU dimensions and expand the hierarchy to access to the upper levels.





4.1.1 Creation of new CGU "Activity 2"

A CGU can be created from the scratch in the option "New Reference Member", or through “Save As” from an existing CGU code.















In the tab “General” and Translation, enter the information in the following fields according to the requested change:

  • Code
  • Short description - EN &FR (same ones)
  • Long description - EN &FR (same ones)


In the tab “Properties”,

  • Group of activities: COMPULSORY field
    • enter the belonging BU value defined in the Reference File











  • Changes: 
    • Before Jan Y+1: NEW value to be entered - this is will prevent from usage in Y reportings
    • End of January Y+1, NEW will be remove and field will stay empty => the new object will be available for usage in Y+1 reportings






  • CGU used in RSB transfer: OPTIONAL field
    • this filed is used in RSB consolidation rules to automate some transfers between CGU from an old to a new code) 
    • value , if any, has to be communicated in the Reference file - if empty, filed has to stay empty















4.1.2 Creation of new MARK "Activity 1"


A MARK "Activity 1" can be created from the scratch in the option "New Reference Member", or through “Save As” from an existing MARK code.









In the tab “General” and Translation, enter the information in the following fields according to the requested change:

  • Code
  • Short description - EN &FR (same ones)
  • Long description - EN &FR (same ones)




In the tab “Properties”,

  • Group of activities: COMPULSORY field
    • enter the belonging BU value defined in the Reference File














  • MARKET type: COMPULSORY field
    • 4 different possible values:
      • M "Market " - most common value
      • E "Entreprise" - this value has to be selected for new MARK created to host unallocated activities of the GBU (codes such as xxNR)
      • PM "Gnereic market partner code"  - this value has to be used for new fictive MARK created to host inter BU's sales (codes XX-INTERBU where xx stands for the GBU code) - usually 1 generic market partner code for each GBU
      • DISCOP - this value has to be used for new MARK created to host Discontinued activities (post M&A items)
    • Refer to the value inidicated in the Reference File




  • CGU value (valeur de CGU des marchés): COMPULSORY field


  • Changes: 
    • Before Jan Y+1: NEW value to be entered - this is will prevent from usage in Y reportings
    • End of January Y+1, NEW will be remove and field will stay empty => the new object will be available for usage in Y+1 reportings
  • MARKET used in RSB transfer: OPTIONAL field
    • this filed is used in RSB consolidation rules to automate some transfers between CGU from an old to a new code) 
    • value , if any, has to be communicated in the Reference file - if empty, filed has to stay empty










4.1.3 Creation of new BU





4.1.4 Creation of new GBU / SEGMOP / CLUSTER

Customizing principles are the same than the ones explained for the BU "Business Unit level.

4.2. UPDATE OF OBJECTS: OLD & EMPTY VALUES


4.3. CHANGE OF LINKS INSIDE HIERARCHIES


4.4. FINAL VALIDATION & CONSISTENCY CHECKS


5. PILOTING TO BFC_PRODUCTION


6. DOCUMENTATION UPDATES IN GAR AODOC


7. RELATED IMPACTS ON BFC USERS ACCESSES


END OF THE PROCEDURE