Page tree

1. Functional Process
Process Overview
Products are products sold by Solvay. We can also have few products under development.
They are created with a possible hierarchy on 5 levels. 
Definition & use cases


Novecare Marketing Managers Permissions to manage MSP information on Novecare products

Novecare Marketing Managers are people in charge of managing MSP information in Novecare products, specifically on level 4 products. However, they could edit the information in the sections mentioned below, on level 4 or level 5 products that are active.

Novecare Marketing Managers are able to read only (but not modify) the fields in Product Information, Product details, Description information and Translations sections. On the other side, they are only be able to read the remaining info on products.

The Novecare Marketing Manager users are:

Their profile is End Users Lightning to see the information in products. They have the Reports and Customer Product Association Management""permission set assigned to have edit access on the fields in the MSP product sections. Additionally, there is a rule to prevent them from editing the product name and the active checkbox.

They cannot activate or deactivate products and they can never change a product name.



Definition

 

A Product contains the following information:

  • Name
  • Code
  • GBU
  • Status: Standard or Product in Dev.
  • MDG code (for Level 4 and 5 if MDG interface is active for the GBU)
  • Active flag
  • Unit of Measure
  • SAP origin
  • Density
  • Concentration
  • Level
  • Parent (except for Level 1)
  • Translations
  • SAP External ID: Used with MDG interface


Use cases

Creation process

2. Security

Product security model

Who can create?


Who can see?

Any user

Who can update?


Who can delete?


3. Specific rules & automation

Product Creation 

The following fields are mandatory at Product creation:

    • Name
    • GBU
    • Level

Product Update

4. MDG Interface

Interface Specification Document

MDG is a SAP system where products are defined with all their information (production, sales, plant, ...). It's interfaced with back end system: WP1 and PF1 and with CRM.

For the moment, only 3 GBUs are live in this system: Soda Ash & Derivatives, Special Chem and Novecare. And so only them are interfaced with Core CRM.

The interface runs once a day around 1:00 AM french time. Each time a product is created or updated in MDG, it's sent to CRM.

As depending on the GBU, the level 4 is not managed the same way in SAP, the creation or update of such products is sent only with the update of a products Level 5. For example if you have product level 5 named AAA linked to level 4 named BBB, if BBB is updated, nothing is sent to Core CRM. BUT if AAA is updated, then the interface will send the information of AAA AND the information of BBB.

If we receive an update for a product which doesn't exist in Core CRM, it will be created.

Only level 5 have a MDG code. That's why it's not the MDG code which is used as interface key. We've created a specific field visible only by Admin named "SAP External ID". This field is the concatenation of 3 information: SAP origin + GBU code on 2 characters + Product Code. 

Example of SAP Exernal ID for product 90076419 from Novecare: RCSCS90076419.

The GBU codes are stored in the custom settings "GBU Code". But to summarize, we have:

  • Novecare: CS
  • Soda Ash & Derivatives: SD
  • Special Chem: CH
  • Peroxides PE

DANGER: if a user creates manually a product, he will not populate the SAP External ID as he can't see this field. Then if we receive this product with the interface, the system will not find it and create a new one. So at the end, we'll have duplicate. That's why, if some one from Soda Ash, Special Chem or Novecare creates a product Level 4 or 5, he must advise us, so we can update this field. BUT as there is an interface, this should not happen as all products should be created with it. But, as very often they forget, it's good to run a report to track situation. There is one in the folder SBS User Support named "Products with no SAP External ID".  There can be few exception when there is no code or no real one.


There is a logic involved to map ISACTIVE Level 4/5 fields from SAP to Salesforce's "IsActive" field:

For Level 4 products- 

  • If ISACTIVE_L4 from SAP=true, check  level 1/2/3 flag in Salesforce for  (SLV11_PRO_SAP_External_ID__c = ORIGIN_L4+GBU_L4+PROD_CODE_L4 )
    • If  level 1/2/3 are set in Salesforce, only then set Salesforce IsActive=true
    • Else set Salesforce IsActive=false
  • If ISACTIVE_L4 from SAP=false or blank, set Salesforce IsActive=false


For Level 5 Products-

  • If ISACTIVE from SAP=true, check level 1/2/3 flag in Salesforce for (SLV11_PRO_SAP_External_ID__c = ORIGIN+GBU+PROD_CODE )
    • If  level 1/2/3 are set in Salesforce, only then set Salesforce IsActive=true
    • Else set Salesforce IsActive=false
  • If ISACTIVE from SAP=false or blank, set Salesforce IsActive=false


Rules in Webmethods 

NoSAP ProductsSAP statusWebemethods LogicCRM user Action
1New L4 + New L5 CreatedL4 and L5 is  activeQuery CRM to check L4 is active with L3,L2,L1. Send L4 and L5 as inactive if both not presentFor the first time creation User will manually update the L4,L3,L2,L1 in L5 and set them as active.
2Old L4  + New L5L4 and L5 is  activeQuery CRM to check L4 is active with L3,L2,L1. If L4 is active, send L4 and L5 as active. Elseif L4 is not active set L5 as InactiveL4 needs to be updated correctly by CRM user
3Old L4  + Old L5L4 and L5 is  activeQuery CRM to check L4 is active with L3,L2,L1. If L4 is active, send L4 and L5 as active. Elseif L4 is not active set L5 as InactiveNo Action required
4New L4 + New L5 CreatedL4 is inactive and L5 is  inactiveQuery CRM to check L4 is active with L3,L2,L1. Send L4 and L5 as inactive.No Action required
5Old L4  + New L5L4 is active and L5 is INactiveQuery CRM to check L4 is active with L3,L2,L1. If L4 is active, send L4 as active and L5 as inactive. Elseif L4 is not active with sublevels set L4 & L5 as InactiveL4 needs to be updated correctly by CRM user
6Old L4  + New L5L4 is inactive and L5 is activeQuery CRM to check L4 is active with L3,L2,L1. If L4 is active, send L4 as inactive and L5 as inactive. Elseif L4 is not active with sublevels set L4 & L5 as InactiveNo Action required
7Old L4  + Old L5L4 is inactive and L5 is  activeQuery CRM to check L4 is active with L3,L2,L1. If L4 is active, send L4 and L5 as inactive. Elseif L4 is not active set L5 as InactiveNo Action required
8Old L4  + Old L5L4 is active and L5 is  inactiveQuery CRM to check L4 is active with L3,L2,L1. If L4 is active, send L4 as active  L5 as inactive. Elseif L4 is  inactive set L5 as InactiveL4 needs to be updated correctly by CRM user



5. Alternative Units of Measure Object and Interface

The Alternative Units of Measure (UOM) object serves as an object for managing and integrating alternative units of measure used in One quotes, Opportunites, Reports. This object ensures consistency with the SAP MARM table, supports reporting, and automates critical processes related to UOM configuration.

Key Features and Configurations

1. Object Setup

  • Label: Alternative Units of Measure
  • API Name: GEN_SAP_Units_of_Measure__c
  • Fields:
    • Name: Auto-generated UOM ID in the format UOM-{0000}
    • Product: Lookup to Product2 (Product Level 5 association)
    • Unit of Measure: Picklist aligned with SAP's UOM values
    • Counter: Numerical value for UOM conversion
    • Denominator: Numerical value for UOM conversion
    • Conversion: Formula (Counter / Denominator)
    • Active Status: Boolean indicating whether the UOM is active
    • Reference Value: Boolean to mark the reference UOM
    • Quote Ready: Boolean indicating readiness for quoting
    • SAP External ID: Composite identifier (SAP Origin + GBU Code + Product Code + UOM)

Included GBU's:

  • Novecare,
  • Technology Solutions,
  • Aroma Performance 
  • Oil & Gas





UOM Interface with SAP

Key Points:

  1. Integration Strategy:

    • Source: SAP (MARM tables via Data Hub/Talend).
    • Target: Salesforce GEN_SAP_Units_of_Measure__c object.
    • Master Data: SAP is the master for all UOMs.
    • Changes in SAP (create, update, delete) are reflected in Salesforce through automated integration.
  2. Product and UOM Matching:

    • UOMs in Salesforce are linked to Product2 objects using SLV11_PRO_SAP_External_ID__c (SAP Origin + GBU Code + Product Code).
    • Products without this external ID are updated via workflows or data fixes.
  3. Data Operations:

    • Upsert: Combines insert and update operations for UOM records.
    • Soft Delete: Deactivates UOMs in Salesforce if not found in SAP (via GEN_Is_Active__c flag).
  4. UOM Data Validation:

    • Only UOMs associated with active and inactive products from specific GBUs (Novecare, Technology Solutions, Aroma) are processed.
    • Validations ensure data consistency between SAP and Salesforce.
  5. Automation:

    • Flows and integration tools populate missing fields and ensure data integrity.
    • Automated handling of cases where products are manually created in Salesforce.
  6. Bulk API Usage:

    • Bulk operations for querying and upserting data, ensuring efficient processing of large datasets.
  7. Key Fields:

    • GEN_Product__r.SLV11_PRO_SAP_External_ID__c: Links UOMs to products.
    • GEN_Is_Active__c: Indicates if the UOM is active.
    • GEN_SAP_External_ID__c: Unique identifier for UOM records.

Reference Value on Product2 Flow Configuration

Each product that has alternative units of measure (UOMs) should have a designated "Reference UOM" (Reference_Value__c = true). This UOM must be standardized (e.g., G, Kg, Lb, T) and its conversion factor should be set to "1". However, the Reference UOM may not always match the SLV5_PR_Unit_of_Measure__c field on the Product2 object. To address this, we need to introduce a new field called Reference_UOM__c on the Product2 object, which will store the Reference UOM.

Having this new field is crucial to maintain performance since we want to avoid querying and checking for reference values in the Alternative UOM table.

  1. Create a new field called Reference_UOM__c on the Product2 object.

    1. This field should store the Reference UOM from the Alternative UOM object for each specific product.

  2. Develop a flow that populates the Reference_UOM__c field on the Product2 object. This flow should handle the logic to fetch the appropriate Reference UOM and assign it to the field.


Last modifications :

UserLast Update
Alves, Susana 471 days ago
MENDES, Dina 1451 days ago
PEYTRAUD, Josiane 1926 days ago
MILIC-ext, Nikola 469 days ago
GILLES, Anne 793 days ago
BRAHIM, Walid
KANJA-ext, Zakaria
NWANGWU, Daniel

The best way to get IT support is to use the new Service One Platform.