Table Of Contents

<style>
.toc-macro ul {display: block; counter-reset: item}
.toc-macro li {list-style-type:none}
.toc-macro li:before {content: counters (item, ".")". "; counter-increment: item}
</style>


Objective and Scope

Objective of this Procedure

This document describes the process to handle Customer Master Data to create, modify and extend a new/existing customer accounts in PRS (PF1_50) and RCS (WP1_400) environment and describes the roles and responsibilities of each actor in this process.

Scope

Data Operations Team based in Riga is responsible to handle all Technology Solutions, Composites, Novecare Customer Master Data for all regions and Intercompany extensions and Sales area data updates. 

Requests for Intercompany customer record general data creation/general data modification are within Lisbon SBS team’s scope.


Definitions

Abbreviation

Description

Abbreviation

Description

Abbreviation

Description

PRS

Permanent Reference System (PF1_50)

COA

Certificate of Analysis

ICIntercompany

RCS

Rhodia Core system (WP1_400)

MSDS

Material Safety Data Sheet

DBA

Doing Business As

SBS

Solvay Business Services

NAM

North America

T/ATrading as

PO

Purchase Order

LAM

Latin America

C/OCare of

PO BOX

Postal Office Box

EMEA

Europe Middle East Africa



WF / CWF

Customer Workflow

APAC

Asia Pacific



SO

Sales Organization

TrZones / TZ

Transportation Zones



FD

Freshdesk

CRM (a.k.a. SF)

Customer Relationship Management (Salesforce)



CSR

Customer Service Representative

FAO

For the attention of





Systems overview

In Solvay customer master data is being maintained in four systems – PF1_050, PF1_020, WP1_400, PI_020.


CRM - (Customer Relationship Management Tool) - used to manage a company's interaction with current and potential customers. Salesforce (SF) is the CRM tool used at Solvay. 

Salesforce request is initiated in CRM by Customer Service. Once customer general data is completed by Customer Service Representative, created prospect can be converted into SAP account. It happens through Customer Workflow, which is created automatically once request for conversion is submitted. 

CRM/Salesforce is not used by Composite Materials. New customer requests are received via Freshdesk and Workflow is manually created and submitted by Data Operations Representative.

Customer Workflow functionality is used in PRS to request customer creation and changes. Data Management team modifies and approves Workflows initiated by CRM or submits Workflows manually in PRS (PF1_50). After that the Workflow is routed for validation and as soon as it is approved, customer code is generated in the system. Data Operations Representative completes the setup in PRS (PF1_50) and RCS (WP1_400) and Credit Manager completes credit data in CICC (PI1_20). 


PRS (PF1_050) – is used to maintain general data of the customer (name, address, registration number, general contact information, bank details). This information is automatically distributed to the rest of the systems (WP1, PI1, PF1_020 ).

RCS (WP1_400) – is used to maintain customer company code and sales organization information. Once customer general information has been changed in RCS (WP1_400) changes will appear in the CRM system.

PRS (PF1_020) – has similar functionality as RCS, but used by Solvay companies, which are not in Riga Data Operations scope.

CICC (PI1_20) - is used by Credit Management to set up and maintain customer credit data.  


New creations and changes made in PRS will be distributed to one or both of the systems (WP1 and/or PF1_020).

Sales Area Data (sales organization) – created manually by DM Riga in WP1 (shipping information, partner functions etc.).

Company code data is created automatically in WP1 based on the sales organization for which customer was opened, if transaction SWOC06T is used.


Receiving a request

New customer creation (including new ship-to accounts) requests must be initiated only through CRM (SF) by CSR. Once request has been submitted in CRM, workflow will be created in PRS and DM Riga will receive automatically generated CRM request form which should include all necessary documentation. 

CRM/Salesforce is not used by Composite Materials - 75 division. New customer requests are received via Freshdesk and Workflow is manually created and submitted by Data Operations Representative.



Request for Account Conversion

This form should include all necessary general and sales data information. If mandatory information is missing, you must contact requester in order to receive it. Mandatory documentation and information depends on GBU.



Customer creation via workflow

PRS (PF1) is the main system where all customer general data is stored. It’s connected with WP1 where data is transferred after submitting a Workflow.


Once logged you can access your Business Workplace (Workflows) by entering transaction Z1S_CWF_REQUEST.




There will be 3 options available:

New customer creation
Used to create Workflow for new customer creation. To proceed populate customer name, city and country,


Should not be used anymore. All new creations must be initiated in CRM, except Composite materials and Aero (for these GBU’s WF for creation/modification have to be submitted manually using new customer creation).


Existing customer data modificationIf customers general data needs updating, it should be changed through WF by entering PRS account code and modifying as requested. Both Payer and Sold-to should be updated accordingly.
Display or change an existing request 

Used to display or modify WF. Workflow created in Salesforce has status - N-SAVED, therefore it’s not visible in WF inbox before Data Team modifies and saves it by using Display or change an existing request. 




Transaction Z1S_CWF_REQUEST_LIST can be used to review the list of requests and their current status.

If Salesforce generated WF for incorrect account group, or you want to create payer and sold-to in one WF, in order to avoid double work caused by separate account creations, you can use the steps described below:

  1. Use transaction Z1S_CWF_REQUEST
  2. Fill in search term, city and country, which exactly matches with information from Salesforce request for account conversion.
  3. Select new account group you need.
  4. In the result list click “Create from Request number “ and specify the request number received from Salesforce.
  5. Check if the account group has been changed correctly.


See below fields to be completed/verified in the Workflow:


Header

FieldDescription
Company codedefault 4274
GBUcorresponds to GBU for which customer creation, modification is needed - can be determined by division provided.



General Data

FieldDescription
NameThe legal name of the customer. In this line the name should not be longer than 35 characters. If the name exceeds 35 characters, second line (Name 2) is to be used for next 35 characters. 
Name 2Most commonly used for DBA, T/A, C/O, FAO name. If it is too long, DBA, T/A, C/O, FAO name can be added to Street 2 field. 
Name 3Not used
Search Term 1Should capture the "essence" of the customer name
PreviewAllows to preview the format of customer address entered. Can be used only after all mandatory fields has been populated in CWF. 
StreetDisplayed after Street 2 (when Street 2 is also maintained). Max number of characters is 35.
House NumberHouse Number
Street 2Max number of characters is 40
Street 3Is not printed on Order confirmation, but is printed on Invoice. Max number of characters is 40.
Street 4Max number of characters is 40
DistrictAuto-filled for Canada and USA
Postal Code

Postal code/ZIP code as part of the address. SAP provides standard postal code format checks depending on the country maintained. If there is no postal code for the address created but it’s mandatory to have it for the country, use ZERO(s) (replacing each expected character by zero).

For US always populate full postal code (5 digits)-(4 digits). You can locate full postal code in USPS homepage.


CityCity name as part of the address
CountryThe country key. Based on this system checks entries such as the length of the postal code or mandatory registration numbers.
RegionMandatory for all countries. Select from the drop-down list. 
Transportation zone

Use default value ‘XXXXXXXXXX’.

For  modifications, if TZ is already populated with any other value, leave it as it is. Correct it in WP1 only.

Jurisdiction codeMandatory or US and Latin America, not necessary for Europe. Automatically populated.
Account GroupSelected customer account group.
Language

Language used for customer documentation. This is the language used commercially by the customer. It is used at sales text level (will be printed on all commercial forms: order acknowledgement, dispatch notes, etc.)

Language of existing customer account  should not be changed without notifying responsible CSRs, since it has a direct impact on current documentation for customers.  Language can be modified only after all assigned CSRs confirm, that there are no text notes or documentation which can be impacted by this change.




Postal Address

FieldDescription
PO Box

If a PO Box address is specified, the printing of the PO box will be used instead of the physical address for Sold-to, Payer and Bill-to accounts.

PO Box should never be the only address information for Sold-to or Payer account. If needed, it can be set as bill-to address directly in WP1.

Never add PO Box for ship-to accounts.


PO Box Postal codeIf PO Box field has a value, PO Box Postal Code field has to be populated. 
PO Box CityTo be populated if the City of PO Box address is different from City of main physical address.  
Payer to Sold-toAlways check-mark it if Payer address matches Sold-to address. If Payer and Sold-to address is different, separate CWF's needs to be created for each account group.   

International Versions

Specific requirements for Thai, Korea, Japan & China entities. Translation to local language should be maintained in SAP through CWF for all relevant accounts. This information should be provided as part of CRM request or in request form. 

Mandatory for local China customers


General Data 2

FieldDescription
VAT Reg. No.VAT registration number for EU countries. This code is mandatory for European Union customers, it allows Intrastat reporting and this code has an impact on invoicing. VAT structures and validation steps can be found in Tax number validation (Europe). Mandatory for payer and sold-to accounts, optional for ship-to.
Tax Code 1, 2, 3, 4Corresponding tax codes will appear based on the country of the customer. Validation steps for countries outside EU can be found in Appendix Tax number validation (LAM, NAM, APAC). For more information of these requirements you can refer also to Appendix 17 -  Requirements for Tax Numbers. Alternatively, you can press F1  in the selected field in order to determine which of the fields is to be used for each country and purpose. If the Tax field needed is not appearing in CWF it can be added manually in PRS and RCS. 
Tax Code 5Mandatory field to be populated for customers located in China.
City codeChoose from the drop-down list - city which matches the address or the closest one. Drop-down list options is based on selected region. If incorrect regions selected, you will not be able to locate the correct city code.
DUNS data

Only DUNS direct & global ultimate codes to be added if available. Detailed explanation can be found in Appendix 6.

Reason absence DUNS:

  • Leave blank if DUNS direct & global ultimate codes have been populated.
  • UKN (not found in DUNS) - if  customer does not have any of DUNS codes.
  • SGL (Single location) - if customer has only the Direct DUNS code on the website. Populate direct code and select SGL.
  • TBD (To Be Determined) – should not be used. Either you find the DUNS number or determine the reason of absence. Used in rare cases if DUNS website cannot be accessed etc.
  • DEL (Deleted) – when we are inactivating customer, DUNS codes must be deleted and Reason of DUNS absence must be replaced with value “DEL”.
  • C-O (Care Of) – if it is a Care of customer, leave DUNS code fields empty and add the reason

If customer changes their address, DUNS Code also must be changed. Each address has its own unique code. As it is a modification, the DUNS code should be updated through WF.





Phone/Fax/Mail

General contact information of customer. Most commonly can be found in header or bottom line of Purchase order. 

FieldDescription
TelephoneTelephone number, consisting of dialing code and number, but without the country code. If the telephone number consists of a company number and an extension, the extension must be entered in the field ‘extension’.
Fax numberFax number, consisting of dialing code and number, but without country dialing code. If the fax number consists of a company number and an extension, the extension must be entered in the field extension.
E-Mail AddressCustomer general email address. 



Credit (for Payer only)

Information populated in Credit tab is automatically sent to Credit Management once workflow has been submitted for approval to Data Controller.



FieldDescription
Cred. Contr. Areadefault value “SOLV”
Bus. Credit Need

depends on the requested payment terms. Check CRM request.

  • AD Advanced Payment - used for Payment terms Cash in advance
  • ON Online Payment - used for Payment terms Credit Card
  • SP Secured Payment - used for Payment terms Cash against documents
  • UN Unsecured Payment - used for all other Payment terms 
Currencyautomatically populated as EUR.
Est. Yrly TurnoverCheck CRM request. Note that this value needs to be entered in currency EUR.
1st Order valueCheck CRM request. Note that this value needs to be entered in currency EUR.
Req Payment termsselect requested payment terms if available in the drop-down list. If not available, leave blank.
Dunning procedurePayer contact information. Check CRM request.






Credit (for Payer-bis only)

If payer-bis needs to be created in case main payer already exists, WF setup remains the same as for payer, except credit tab.


In credit account field customer PRS main payer number should be indicated. It is needed, since credit limit is applied for customer on main payer level, but on payer-bis level, only payment terms are maintained. In order to apply main payer credit limit to new created payer-bis, this WF field must be populated.





Once payer-bis is created, make sure that   correct account numbers are populated (should be different)  in  PRS main payer and payer fields (should be checked in PRS & RCS systems).





Distribution



FieldDescription
Distribution tab

Indicate Target System WP1.

Do not remove already indicated systems, when processing WF for modification.


Salesforce ID (SF ID)

Used only for sold-to and ship-to accounts. Accounts created through CRM SalesForce ID should be populated automatically.

For Aerospace customers SF ID is not relevant for them as they do not use CRM.


Reason absence SFID

Most of the GBU’s are CRM users and should submit sold-to and ship-to creations through CRM. However, in few cases we might need to populate reason of SF ID absence.

  • NRL Not relevant for GBU - used for Aerospace customers (division Composite materials)
  • TBD To be determined - used mostly for exceptional cases. E.g. customer manual creation as for some reasons customer creation cannot be initiated in CRM.






Communication Area


Use this Tab in order to add some clarification or specific requirement for Data Controller, if needed.







Save record: 

Confirm Sold-to creation (if needed):

Once confirmed, workflow is submitted and will appear in the inbox of Data Operations teams. Once the record is reviewed and approved by Data Controller you will receive a notification to your e-mail containing sold-to/payer or ship-to number in PRS - for sold-to and payer you will receive two separate notifications to your personal mailbox with PRS account numbers provided.


Test for Info


Test for Note


Test for Tip


Test for Warning


Panel Example




<style>
#backToTopButton {
	position: fixed;
	right: 20px;
	bottom: 20px;
	Z-index: 1;
}
</style>


SAP PF1 & WP1 Customer Maintenance 2