Objective and Scope

15/06/2015The purpose of this procedure is to describe the necessary steps to validate the new customers created in RCS database (WP1) and their transfer to PRS (when applicable). This procedure will also provide guidance for the necessary analysis made before, during and after the creation itself in RCS.

This procedure will input on the analysis to be made on PRS.

Finally, this procedure will also indicate key additional actions on Customers that can be used to inform the requesters.

This IOP explains the steps required for the validation of requests for customer creation or modification in RCS; and its transfer and analysis in PRS (when applicable). The scope concerns customer in PRS (PF1_050) and in RCS (WP1).

Support: Anne-Marie D'Inca and Plínio Morgonni
 OtC Data Expert (Master Data): Meire Santos

Main Part

Customer Validation (RCS)

Transaction ZWOC09R

To validate a customer's creation or amendment on RCS , use Transaction ZWOC09R. The screen below will appear :

Transaction ZWOC09R

This transaction lists all blocked customers, new creations and modifications.
The area on the left in blue indicates the status of the customer:
C = Creation
M = Modification
S = New sales area
E = Error ( when the company and credit view has not been generated automatically after validation. Or when someone is trying to validate the code, and someone else is using it, at the same time. Very exceptionally)
V= Validated , when the customer has been validated on RCS and not yet sent to the PRS CWF)

 
+

 
the customer code 
the date 
the user Id of the person who created or amended the customer
the sales area in which the customer has been created

Other information detailed on this screen:

The DUNS code, Name and address of the customer, Company registration code (Siret in France),

VAT ID Number (if applicable), the search term criteria and the account group (Sold to, Ship to, Bill to or Payer)

Note: For customers created until 15/06/2015, the Sold-to has the function of both Sold-to and Payer. Hence, it is not required to create a Payer in WP1. Nevertheless, the transfer to PRS is to be done with a Payer account group.
After 15/06/2015 all customers creations must have a Payer created. This customer is to align with the transfer being done to PRS: 1 Payer code in PRS and 1 equivalent Payer code in WP1.
These codes must be linked via Extra Master Data and such codes are applicable to any other customers created which are linked to the Payer (e.g. Payer-bis, Sold-to).
The exception is all carrier companies (transport, redispatching) and also Natural Persons in BR: only Sold-to creation is necessary and are not to be transferred to PRS (WP1 only).

Note: For customers created until 15/06/2015, the Sold-to has the function of both Sold-to and Payer. Hence, it is not required to create a Payer in WP1. Nevertheless, the transfer to PRS is to be done with a Payer account group.

After 15/06/2015 all customers creations must have a Payer created. This customer is to align with the transfer being done to PRS: 1 Payer code in PRS and 1 equivalent Payer code in WP1.

These codes must be linked via Extra Master Data and such codes are applicable to any other customers created which are linked to the Payer (e.g. Payer-bis, Sold-to).

The exception is all carrier companies (transport, redispatching) and also Natural Persons in BR: only Sold-to creation is necessary and are not to be transferred to PRS (WP1 only).

What to check before validating

The rules below must be applied before validating a customer

• • Before validating any customer creation, it is important to check the customer database to ensure the customer does not already exist.
  • Check by name but also by address ( in case the customer’s name has been misspelt or abbreviated)
  • Before validating an address modification, check that the modification did not lead to the creation of a duplicate (a customer already existing at the amended address)

If a duplication exists, please revert all changes and delete customer, with the information that a duplicated customer already exists

• • The customer name and address details must be completed in Capital Letters
  • Name fields on RCS should only be used to enter names, nothing else.
    
    

If there is a need to have some additional info appearing on the invoice, the rule is to create a contact and then to use the contact code as a partner in the customer sales view (to be done by requester). Example: TSAxxxx in FR to be moved from name to contact person (as ZC partner in sales view)

Important: In order for the interface between RCS and GTS to work correctly, it is important that the address of the customer is entered correctly.

• • Ensure  that the street information is clearly shown in the field ‘street/number’ and not in the field ‘street 2’.
    
    

It is also important to ensure there are no blank spaces at the beginning of each field and that the name of the city contains a maximum of 30 characters.

Information before proceeding

• • For customers who are in the European Union there must be a VAT Number ID entered for customer account types:- Sold to party or Payer customers, except for:- Committee of establishment (EC) or certain associations.
  • IF a Customer changes their VAT ID Number, a new customer account will need to be raised in RCS, rather than the Sales Assistant modifying the existing customer account.
  • The old VAT ID Number must remain on the old customer account.. The central team «data controllers» will block this customer and mark for deletion, indicating in the texts in Internal Note that the customer has changed their VAT ID Number and to use ‘new customer xxxxx’, once the Sales Assistant has raised a new customer account with the new VAT ID Number indicated.

Language changes

• • If a Sales Assistant modifies the Language of a Customer to English, it is ok to validate this change.
  • It is the responsibility of the Commercial Assistants to contact the Sales Assistant who modified the language, in order to understand the reason for the change of Language and to accept or reject the modification.
  • If the decision is to revert the language back to the original entry, the customer will be blocked, and the central data controlling team will only release the customer if an email is received validating this modification.
  • If the language is changed from English to a different language, the « data controllers » team will not release the customer (unless there is an email validation in the generic Inbox).
  • It will be the responsibility of the Commercial Assistant to contact other Sales Assistants impacted by the change  in order to confirm before informing the « data controllers » team to release the customer.
  • An email must be sent to other CSR, to inform them that the Customer (Name and Customer Number) has had the language modified, and indicate the Sales Areas concerned. However, if the customer has only one Sales View, it is ok to validate the change.

Postal Box

• • When validating a customer, if the Postal Box number has been indicated in the street fields, you must move the postal box information to the correct ‘PO Box’ field.
  • If the Sales Assistant has entered details ‘for the attention of xxxxx’ in the customer address, this must been removed.  Then inform the Sales Assistant to create a Contact Person, and add this contact code as a ZC partner ( bill to contact)  into the Partner Functions tab of the customer (see chapter: Additional Actions on Customers)

Phone & fax numbers

To Brazilian customers, do not introduce “hyphen” (-) between phone & fax numbers. It causes a huge impact on the issuing of invoices in Brazil.

VAT number

For Spanish Customers - It is important to check that the « NIF » code is added (Mandatory). The NIF code corresponds to  the VAT Code without the Iso country code IE: VAT Number: ESA28008167,  NIF Code: A28008167

Upgrade accounts

If the Sales Assistant requires a customer account group type to be upgraded, use transaction XD07.  A customer cannot, however, be downgraded (i.e. from a Sold to, to a Ship to etc)

Validation

To validate a customer, put the cursor on the line corresponding to the customer you want to validate click on Update and start the checks

The following screen will appear :

Press on  to display customers’s details

Open another session and enter transaction VD03. Perform a search on Customers (General) or by Country and search by Name. If needed add further elements (e.g. City or Postal Code) to narrow the search

If the customer is within the European Union, and is a Sold to Party or Payer, it must have a VAT ID Number The validity of the VAT ID Number needs to be checked via the website: http://ec.europa.eu/taxation_customs/vies/vieshome.do

Once the VAT has been checked and is correct, check in VD03 or in SE16 if the VAT has been assigned to a different customer already on RCS (different Name).

In the list you will see all the customers with the same VAT ID Number, and their corporate name:

• • If the names are identical, there is no problem.
  • If the names are different, however, you must contact the Sales Assistant who created the customer to ask for confirmation of the correct VAT ID Number
    

• • The exception to this Rule is GB VAT ID numbers.
  • In the UK it is possible to have several legal entities with the same VAT ID number - They have a Group VAT Registration for all the legal entities:

• • If in doubt, as the sales assistant to check the VAT ID number with the customer

DUNS check (website)

Verification of DUNS in the website

Checking customers on the DUNS Website
DUNS Website : https://solutions.dnb.com/grs/

Choose your country from the drop down list and click 'Submit'

DUNS:

User IDs and Password

Enter the User ID and Password then click ‘Log on’ Accounts for the DUNS website:

Id: 565739  /  password: magda01 (for BR in the name of Paulo Delbel)

Id: 565740  /  password: rhodia08 (for Asia in the name of Ramlah Mohamed)

Id: 454999  /  password welcome1 (for Europe in the name of Martine Guernier)

Note : All User ID/Passwords are open to the whole team, however it is not possible to connect if a User ID is already being used at the same time.

Verification of DUNS in the website

Enter the customer name and then click on ‘Country’ to obtain the list of countries.  Choose the correct entry and click ‘ok’.

Then click on the button ‘ok’ at the bottom of the screen

For Brazilian customers, you only need to fill the CNPJ (Tax Number 1) on ‘National Identification’ field.

If it results a DUNS code (it will be just one), it will be the correct DUNS code even the name /address does not match.

In View Results tab, you will be able to view the matched entries

The customer entries will be displayed with the DUNS Number and address according to the search criteria entered on the previous screen

The DUNS Code is displayed on the left of the screen

If you put the mouse cursor over the name, the pop up box will give you the option to ‘View this report’.

You can then see the Customer’s full address and other information.

On the new screen, the customer details will show with the complete address.

The Duns code is displayed in the top right, enter this DUNS code in the field STDC4 on RCS  (the VAT number is also displayed on some entries under ‘National ID’)

You can search using various criteria, Name, City, Postal Code etc to ensure the DUNS Website has been correctly searched if no entries are returned.

Also, take note of DUNS hierarchy to identify the Head Office for the searched customer :

Customer info searched in D&B base

Scroll down the page to « Corporate Structure » section to check the DUNS hierarchy

The Head Office will be the customer identified by  « Immediate Parent »

Take note of the DUNS codes shown here, to populate DUNS hierarchy on « Extra Master Data » section on PRS later.

When you  have finished using the DUNS Website, it is important to click ‘Log Off’ to close down the Session.  Do not click on the cross in the top right hand corner to close down the session

Customer validation and transfer order to CWF

Validation

• • Once all checks are done, now the customer  can be validated.
  • To validate, click on the customer on the list, then click on 'Validate’
  • An email will then be automatically sent to the user, informing them that the customer has been validated.

• • Once the code is validated, its status will change to V (validated).
  • Now, the Customer has to be created in PRS (General Data only). This action is possible only if :

- The customer is a ‘Sold-to’ (0001) or a ‘Payer’ (0003) in RCS

- It has a validated status « V » in ZWOC09R.

- It is not blocked or flagged for deletion

PRS – CWF - Overview

CWF Verification

Verification in PRS

ATTENTION: The checks done in PRS must follow the rules of the mission of the Data Controller. These can be found in detail, under the following link :
http://teamsites.solvay.com/sites/FinOpProc/DBM Docs SemiRestricted/CUSTOMERS CWF procedure DATA CONTROLLER.doc 
 
In this chapter, it is described the emphasis to be made in specific anlaysis, when handling Workflows originated from RCS.

Z1S_CWF_REQUEST_LIST

• • A list of CWF requests is available via tcode Z1S_CWF_REQUEST_LIST where all the requests for the last 30 days are sorted by status
  • The requester name to appear will be the Last Name from the person who validated the RCS code on ZWOC09R

• • Or, with the PRS Workflow Request number in hands, you go directly into transaction Z1S_CWF_REQUEST and put the Request number to be processed

Z1S_CWF_REQUEST

Verification of CWF

Enter transaction XD03 to display a customer. Click at the end of the customer field to display the search window. The search should be done for:

• • Name
  • address
  • RCS code

Then, it will be one of the following options :

1. The RCS customer is not found on PRS
2. The RCS customer is found on PRS and it’s a Sold-To (Zxx8)
3. The RCS customer is found on PRS and it’s a Payer-bis (Zxx5)
4. The RCS customer is found on PRS and it’s a Main Payer (Zxx4)

Go into menu “ Extras > Administrative Data “ and look at the Account group:

1. If the RCS customer is Not found on PRS :

• • Nothing corresponds at all on PRS to the RCS code:

- If the RCS customer is created as a Payer, then a PRS customer should be created as a Payer (Zxx4);

- If the RCS customer is created as a Sold-to, then a PRS customer should be created as a Sold-to (Zxx8), as well

• • If a code on PRS contains the same VIES/Tax code, then analyze:

- The existing PRS code is the Main Payer (Zxx4)

The new RCS code will be a Payer-bis creation (Zxx5)

or

The new RCS code will be an Additional Sold-to creation (Zxx8)

- The existing PRS code is not the Main Payer

Check who is the Main Payer on the Extra Master Data for this existent code.

Sold-to (Zxx8)

2. If an existent matching code is found on PRS. If its a Sold-to (Zxx8)

Locate the PRS Main Payer and the Payer and Go to « Extra Master Data »

and then, select « Solvay Cross Reference » tab

Note: Check the Extra Master Data of these both codes and see if they are already linked to an RCS code. If not, you must link them before proceed

If both codes (PRS Main Payer and PRS Payer) have a RCS Code populated, just link this existent Sold-to code with the new code from RCS.

Link by adding the RCS code created on the field « RCS Customer Code »

Populate the DUNS hierarchy according to the D&B website information in the DUNS tab

If there is no DUNS code, one of the following Reasons for absence of DUNS can be used:

• • C-O  -  Care of  :  to be used for Care Of
  • SGL  -  Single location  :  to be used when no hierarchy
  • UKN  -  Not found in DUNS  :  to be used when not found
  • TBD – To be determined : used when the search will be done at a later stage
  • HTC – Hierarchy to complete; to be used when the DUNS code is found , but when the other levels are not yet entered

Then, you must trigger the transfer of updated information from PRS to RCS (by ALE)

Follow the menu path Extras / Additional Data.  Using the matchcode, select 01 (All-in-one) in the Transfer RCS field.

Click ‘Save’.

And now, you must REJECT the CWF coming from RCS to Create a new customer on PRS.

Payer-bis (Zxx5)

3. If an existent matching code is found on PRS. If its a Payer-bis (Zxx5) Locate the PRS Main Payer

• • Repeat the action from slides 49 to 52, only to the Main payer code.
  • And you will REJECT the CWF coming from RCS to Create a new customer on PRS.

Main Payer (Zxx4)

4. If an existent matching code is found on PRS. If its a Main Payer (Zxx4)

• Check if it’s already linked to an RCS code.
• If it is linked:

- This means that the check on RCS was wrong and the customer code has been validated wrongly. It’s a duplicate. It should be rejected on RCS.

• If it’s not linked:

- Just link the RCS code to it and trigger the transfer of updated information to RCS (ALE) (follow the action from slides 50 to 52, only to the actual code)

And you will REJECT the CWF coming from RCS to Create a new customer on PRS.

Customer Validation – Flag for Deletion

If, when checking a customer you find a duplicate, the newly created customer must be marked for deletion.

To delete a customer, first go into the customer in change mode (VD02)

Change the search term to be four asterisks‘****’

Then click on Extras and 'Blocking Data‘

Add '01' in the field Order Block - All Sales Areas (Overall Block), and add a 'tick' in the field All Sales Areas at the bottom of the screen.

Click to go back and then click on 'Extras‘ and Deletion Flags

Add a tick in the boxes 'Deletion flags - All areas‘ and 'Deletion blocks - General data'

Click on ‘Extras’ and ‘Texts’

Click on ‘Internal Note’ and add in the Information of the customer that should be used instead. Click ‘Save’ to save your changes for the customer

Once the customer has been updated, go to transaction ZWOC09R.  Click on the customer and click 'Delete'  

In the pop up box, indicate the reason for the deletion and the correct customer number to use instead.  Then green tick. This message will then be sent automatically to the commercial assistant who created the customer

Customer Validation

Modification

Customer Modification

Customers that have an 'M' indicate the customer has been modified.
To see what has been modified, click on the customer and in 'Display modif.'

If the customer name or address has been changed, first check if a customer with the new name or address does not already exist.

If the modified customer has several sales views, it will be necessary to check with the sales assistant if the sales assistants responsible for the other sales views also agree with this change.

If they agree, then it is ok to release the customer. If the sales assistants do not agree, the changes must be reverted back on the old customer account, and a new account created for the new customer name or address.

Error

Usually it happens with group codes on behalf os Solvay or Rhodia, but also is usual with customers codes, because when performing its validation, the same code should be in use in other processing, generating the error.

In these cases, the validation should be performed manually, following these steps:

• Open a new transaction VD02
• Remove from field ‘Extras-Blocking Data’ the general block – “01”
• Save
• Remove from the List

New Sales Area

When creating a customer in a new Sales Area, assign the Payer to the Sold-to in ‘Sales Area Data-Partner Functions’ tab

Others

This is an additional field to be used , if needed , to enter the reason for the change.

Not a compulsory field , might be useful to keep the changes history 

Unblock Sales Views

The Sales Views blocked in WP1 system are under the Commercial Platforms responsibility.

According to the procedures in place, it’s necessary to send a message to the person who put a deletion flag on the Sales View, and ask if the person agrees with the removal of the flag.

However, Data Controller are able to perform this task to all customers, when asked by any means at the disposal of the requester, with the exception of customers which origin is US.

Additional actions on Customers

Useful Indications to Sales Assistants

Contact creation for partner type ZC

The steps described in this point are to be made by the Sales Assistant, not by data controllers. This point’s purpose is to describe the most common additional action to be engaged by Sales Assistants, when handling requests for creation of customers.

Create a contact, for partner type ZC

To create a Contact: In customer modification (VD02), click on the Contact Person tab and add in the name for your contact in the 'Name' column: i.e. M58 then click save.

Once saved, go back into your customer on the Contact Person tab, double click on your new contact to obtain the code for your new contact.

Then click on Sales Area Data

Click on the Partner Functions tab, then add in the new contact persons code with the Partner Type ‘ZC - Bill to complement’. Then click save.

The Contact Person's name will now appear on the invoice below the invoice address.

How to change a customer account group via transaction XD07

You can change the group of account of a customer i.e: A Ship to Customer can be upgraded to a Sold to Customer.

Once a customer is upgraded to a Sold to, the customer will have all the functions (sold to, ship to, bill to & payer). A customer cannot be downgraded, however.

If you upgrade a European Customer, beware a VAT Number will need to be added into the customer.

To upgrade a customer, you will first need to know the Sales office & Sales group details from the Sales Assistant.

Transaction XD07 - add in the customer number and click enter

On this screen you can see the current account group of the customer as well as the sales views.

You will be unable to select a specific sales view, you will only be able to take the first sales view even if it is an obsolete sales view.

Click Enter until the selection option of account group appears:

Select ‘Sold-to Party’ from the drop down list and green tick

Add in the Sales Office and Sales Group details on this screen.

Before saving, make sure if it is a European Customer, to complete the VAT Number.

Once saved a message will appear to confirm the customer has been upgraded.

Then, this customer code will need to be manually matched and inserted (or not) in PRS CWF and have the Extra Master Data populated accordingly on both systems

Useful Instructions

Customer Validation

• • DO not enter anything in the “Solvay Cross Reference” tab on RCS customer master data.
  • THE ALE WILL AUTOMATICALLY UPDATE THEM ONCE THE CODE IS CREATED OR MATCHED ON PRS ( the same fields will be available on PRS side and will be populated there )

• 1. PRS Customer code: Code of the corresponding customer in PRS
  2. PRS Main Payer: Customer credit account code in PRS
  3. PRS Payer: Customer code in PRS for collection & A/R
  4. RCS Customer Code: Automatically populated
  5. RHO Customer Code: Not used on RCS
  6. PRS sold-to-party: Not used(for the moment)
  7. PRS acc.group type: Last digit of the PRS account group

MATCHING RULES on PRS

Look in PRS for a matching code (only for payer, payer-bis and sold-to) if found: look at the acct group last digit and populate field [7]:

• • if 4 - main payer: same code on fields [1] , [2] and [3]
  • if 5 - payer-bis: same code on fields [1] and [3] and locate the main payer on PRS to populate field ‘PRS Main Payer’
  • if the main payer does not exist on RCS , it has to be created first on RCS
  • if 8 - sold-to: same code on fields [1] and  locate the main payer on PRS to populate fields [2]  and [3]
  • if the main payer does not exist on RCS , it has to be created first on RCS

A customer that works as both soldto and payer in RCS (for example 64621) will have in the PRS customer code the corresponding PRS sold to customer, and in the PRS payer the corresponding PRS payer code. The PRS main payer is the payer code corresponding to the credit account and can be the same as the PRS payer.

I confirm that for credit and collections purposes the code taken into account is the one inside the PRS payer code, in the extra master data screen. So even if you change the PRS customer code, this will not have impact on the credit operations.

New fields to check in the customer creation procedure

New fields to check: 

• • CFOP Category
  • ICMS Taxpayer

Rules to check the fields :
- ICMS Taxpayer

 
If customer country is Brazil and field Tax Number 3 has the value 'ISENTO'
    ICMS taxpayer = 2

 
If customer country is Brazil and field Tax Number 3 is filled
    ICMS taxpayer = 1

 
If customer country is Brazil and field Tax Number 3 is empty
    ICMS taxpayer = 9

 
If customer country is different from Brazil
    ICMS taxpayer = EX

CFOP category
If customer country is Brazil and field Tax Number 3 is empty
    CFOP category = 6

 
*rules approved by the fiscal area

Technical information

Customer WF Process

MODIFICATION

Customer Creation for data harmonization between RCS and PRS

Europe

When there is a need of customer creation inside RCS (without sales view) for purposes of coherence with PRS, as solution was defined by Meire dos Santos together with Françoise V., Aude M. and Marie-Ange.

Hence, the flow to be implemented is the following:

• •  Use of a “standard” mail to communicate with the CSR (see hereafter a proposal) the need of customer creation inside RCS 
  •  ALWAYS copy Aude Mermin
  •  Provide Name, address and ID TVA
    
    

The control of the VAT number is under the responsibility of Lisbon team.

NO PROCESS MODIFICATION FOR THE PROCESS OF CUSTOMER VALIDATION.

Below is the template of email:

TEMPLATE E-MAIL to be sent to the sales assistant that will be in charge of customer replication inside RCS.

“Dear colleague

To ensure coherence between Solvay and Rhodia customers master data, we kindly ask you to create in RCS, without sales view:

Customer name……………………………………….....

Address……………………………………………………

VAT number……………………………………………....

Please enter the PRS number in the “comments field” below the address

When done, please return this mail back by only completing the title of the mail DONE

RCS Number………………………...............................

Thanks for your kind cooperation”

Asia

When there is a need of customer creation inside RCS (without sales view) for purposes of coherence with PRS, the flow to be implemented is the following:

• • Use of a “standard” mail to communicate with the CSR (see attached the template) the need of customer creation inside RCS 
  • ALWAYS copy Gauthier Blesbois AND Teresa Liang
  • Provide Name, address and ID TVA
    
    

The control of the VAT number is under the responsibility of Lisbon team.

NO PROCESS MODIFICATION FOR THE PROCESS OF CUSTOMER VALIDATION.

Below is the template of email:

TEMPLATE E-MAIL to be sent to the sales assistant that will be in charge of customer replication inside RCS.

“Dear colleague

Title : Customer in Solvay environment (PRS) n°………………     DONE

RCS Number………………………

To ensure coherence between Solvay and Rhodia customers master data, we kindly ask you to create a customer in RCS, without sales view , by only entering name, address and VAT Number. (Please refer to explanation attached or ask the support of Teresa Liang (China) Gauthier Blesbois (other Asian Countries)

Informations needed are available in the hereunder screen copy:

Please enter in RCS, in the field comment below the address, the customer number (PRS) mentioned in the title of the mail

When done, please return this mail back by only completing the title of the mail DONE

RCS Number………………………

Thanks for your kind cooperation"

North America

• • If no  Payer already exists for a given customer (e.g. Sold-to) that US Sales teams require for their activity, then the Customer Service team of US should request the creation of a Payer.
    
    
  • This Payer should only be created if no Payer already exists. 
    • Note: in case US team insists on a new Payer and one already exists, then escalate to Meire;
      
      
  • D&A team should check all the Sales Org. already using the customer (e.g. Sold-to) and through ZI contact in Partner Function tab, detect and inform the ZI contact of the new Payer and the need to link it at Sales Org level;
    • Note: if ZI is not defined, escalate to Meire;
      
      
  • D&A team should update the cross-references, as usual for new Payer creations;
  • Local Customer Services team should extend the sales views to all impacted sales org and the necessary updates to accommodate the usage of the new Payer in current and future orders;

DOMESTIC and INTERNATIONAL  shipping, billing, payer & sold to addresses

• • •  Upper case
    •  Type complete full legal company name in -  abbreviate as follows (if applicable): 

1)     CO (Company)

2)     INC (Incorporated)

3)     CORP (Corporation)

4)     MFG (Manufacturing)

5)     LTD (Limited)

6)     LLC (Limited Liability Corp)

7)     LLP (Limited Liability Partnership)

• • • Do not use punctuation

• • • Abbreviations to be used:

8)     ST  (Street) RD (Road) DR (Drive) CT (Court) AVE (Avenue) Blvd (Boulevard) LN (Lane)  HWY (Highway)  PKWY (Parkway) PL (Place)

9)     S (South) E (East) W (West) N (North)

10)  SE (South East) NE (North East) NW (North West) SW (South West)

11)  1^ST 2^ND 3^RD 4^TH 5^TH  etc.

• • •  No spaces are to be entered for company names with alphabetical abbreviations
       ABC COMPANY and not A B C COMPANY

DOMESTIC shipping addresses only

• • • Enter 5 digit zip code or 5 digit “-“ four digit when available
       08520 or 08520-3022

Do not place Attn’s, Building #’s, Dock #’s etc… in the address screen.  This information must be placed in unloading points/or contacts.

Link : https://docs.google.com/a/solvay.com/document/d/1BQc0lWWxSeDyNXhyG14YpsbkzEAuPIhQgZz_IHnGZhA/edit