Customer related attribute requirements
| Target model dimension | Requirements | Description | Comment | Existing source in transparency | Technical name in transparency | Transformation | SF source | Comment about SF | Decision on the source for data lake |
|---|---|---|---|---|---|---|---|---|---|
| Customer | Customer ID | In SF known as account. An account can be sold-to or ship-to | BW | No | table ACCOUNT in CORE | ||||
| Customer | Parent ID | A customer might not have any parent | BW | No | |||||
| Customer | Ship to ID | SAP code for customer to whom Solvay is shipping the products | BW QVSBS_BW_QRY_CPCOPA03_0001 QV_BW_QRY_MVSDSO61_0001 QV_BW_QRY_CPCOPC07_0001 | [C_SHIPID] Ship_to_party Key_[C_SHIPID].[2C_SHIPID] | No | The attributes in the CORE in the table ACCOUNT Partner_Sub_type | There is no relation between the ship to and sold to in SF | ||
| Customer | Sold to group | = parent ID | Only available in Leo's sheet (not available in the transparency model) | No | |||||
| Customer | Sold to ID | SAP code for customer to whom Solvay is selling the products | No | ||||||
| Customer | Ship to KA ID | No | |||||||
| Customer | Final consignee ID | =Ship to KA ID | Only SpP related. | No | |||||
| Customer | Sales rep ID | No | In CORE, Sales Rep (CSR Customer Service Representative) and account manger master data available in ACCOUNTTEAMMEMBER → attributes: Account ID, USER, Team member role (coming from SAP). One account can be managed by several GBUs so there is a one to many relation between account and CSR In icare it is different. | Master data of Sales rep and account manger are in SAP. The data flows daily basis to SF per GBU. This info are coming from sales area of the SAP side. Related to sales area in SAP. ??When data integrated from SAP to SF, there are rules to make it at GBU level | |||||
| Sales rep | Sales rep name | No | |||||||
| Sales rep | Sales rep email | No | |||||||
| Customer | Customer Short name | No | |||||||
| Customer | Customer Long name | No | |||||||
| Customer | Country | Country ship to: Country of the customer delivered ---------- Country sold to: Country of the sold-to company- Invoice party | QVSBS_BW_QRY_CPCOPA03_0001 QV_BW_QRY_MVSDSO61_0001 QV_BW_QRY_CPCOPC07_0001 ---------------- QV_BW_QRY_MVSDSO61_0001 | Country (Key)_[C_SHIPID].[20COUNTRY] [4CPCOPA03-SHIP_COUNTRY] Country of destination [10COUNTRY] Ship-to party > Country (Name) C_SHTCTRY ------------ Country (Name)_[C_SOLDID].[10COUNTRY] "[0COUNTRY] Country if empty => [C_SHIPTID] Ship-to party\Attributes\[0COUNTRY] Country key" | No | ||||
| Customer | Zone | GBU Ship-to zone (BW) 1_[4CPCOPA03-TGB2_ZONEH1] | No | available in SF What table? | |||||
| Customer | PRS code | No | In CORE, there is PRS=PF1 (PRS ID) , RCS = WP1 (RCS ID) . (other ERP ID). Available in ACCOUNT table. | To check→ in SAP it happens that there are two accounts for one customer. For example if customer change the VAT, a new account will be created. In SF it doesn't happen so that there is no one to one from SF to SAP. In such a case, the new account is replaced but all the changes in SAP are tracked an another attribute (PRS_ID_history) . Note: In general to track the changes in an attributes in SF, ACCOUNTHISTORY is the table that include historical and changes of the records. Example, if a customer number change, the new one is in the main table and the old number is backed up in ACCOUNTHISTORY table. | |||||
| Customer | RCS code | No | Refer to RCS code comment | ||||||
| Customer | SAP code | No | Refer to RCS code comment | ||||||
| Customer | SF code | No | |||||||
| Customer | Account manager | No | Refer to Sales rep ID comment | ||||||
| Customer | Team cluster | Where is the source of this info? | ? | ? | No | This concept is only available in iCare. it is a way in in SpP to associate an account to a team (Sales team?) Corresponding concept in CORE might be BU (to check) Notes: -Team cluster refers to the sales team in Solvay that handles a specific (market?) like automotive. battery, etc. One account might be purchasing from various teams. in that case, team cluster is the one with the biggest sale. → that makes the Market cluster different from team cluster. | |||
| Market | GBU customer segment | A customer receiving different service levels could be classified as KA for one GBU and Standard for other. Exceptions: GSKA- they remain GSKA for all GBUs. | QV_BW_QRY_CPCOPC07_0001 | GBU Segm. (Sold-to)_[C_CUSTSAL__0CUST_GRP2] | No | In CORE, the table name is GBU_CUSTOMER_SEGMENTATION . | GBU customer segmentation shows what GBUs are related to an account. There is one GBU segmentation per account for a GBU | ||
| Customer ? | Group customer segment | It refers to Solvay group level of segmentation for customer. Depends on the service level a customer receives from Solvay, it can be classified as KA, or standard, etc. The same customer segmentation can be applied at GBU level (below) | Where is the source? | QV_BW_QRY_MVSDSO61_0001 QV_BW_QRY_CPCOPC07_0001 | Bus_Rank__Corp_ Group Segm. (Corp) (Name)_[C_SOLDID].[1C_CUSTGRC] | No | it is not available in SF |