1.INTRODUCTION

1.1 Objective and Scope

The objective of this procedure is to add an overview of all concepts and anchors to detailed procedures on how to manage E-catalog operations for Solvay WW

1.2 Concept and Overview

SRM7 is the main platform to host e-procurement in Solvay Group.

As so, one of the buying channels available inside SRM7 is the E-Catalog option, hence the needs for creation and management for this specific database.

The main goal of the designated channel is to have in place a simplified process flow to create a Purchase Order from a predefined list of references. (described below)

1.3 Types of E-Catalogs

SRM7 hosts two types of e-catalogs. Service Center is bound to develop the process of creation, management, deletion and support for this buying channel.

• Internal (usually mentioned as MDM e-catalogs)
  1. Previously negotiated between our Purchasing structure and the Supplier
  2. All the information is hosted in our database MDM
  3. Service Center creates and maintains all the information submitted through a template.
     
     
• External (usually mentioned as Punch-out e-catalogs)
  1. Hosted and maintained by the Supplier.
  2. Access via a dedicated URL provided by the Supplier and setup inside SRM7
     
  3. Authentication set is required
     

1.4 Detailed Data Operations Flow

1.5 Interaction Between Partners

2. DATA VALIDATION

In order to start the process of e-catalog creation and modification, it's required to verify all the information first, as of it's dependency, and consequences if a bad input is created.

2.1 Authorized Requester

• Site Buyer
• Domain Buyer
• Application Manager

Starting on JAN 1st of 2019, request should always be also validated by IS Data and Reporting team

2.2 Template Information

Information for creation should always be received via template currently available in PTP Portal section and submitted by the authorized requester ( described in PTP portal section) and created via Freshdesk. 

This is currently the TEMPLATE example for EMEA region.

2.3 Scope of the E-catalog

E-catalog is restricted to a specific COUNTRY , with no exceptions.

It's important to be clear what is the e-catalog scope. By default an e-catalog is opened to all sites for the country.

The scope will also define if contracts should be created for what system(s). 

The country is mainly defined by the Company Code (Both Systems) and P.Org (only in PF1) set in the contract to be created, and by default you should create it with the reference values. 

As an example if you receive a request to create an E-Catalog for France :

• Two contracts need to be created (WP1 and PF1 systems)
• You should consider using the company codes ZFR3 in WP1 and 0244 in PF1
• You should use a P.Org defined for the segment of the material groups to be included in WP1
• You should use P.Org FA00 in PF1
  
  

Another example for Finland:

• Only one contract is created in PF1
• You should consider using company code 0143
• You should use KVO as P.Org.

2.4 General Details

Below you may find the information requested to create an e-catalog

YELLOW information is mandatory , so you should be back to your requester is one of the yellow fields is not filled in.

Template is divided by:

Main page (2 Sections)

• General Details (where we will analyze the scope)
• Contract creation details

2nd TAB

• Content for the internal e-catalog creation (item details to upload or modify)

GPS Table

• Reference table to align and validate material group information between systems. It will be needed for contract creation and validation.

The first information that should be checked is as follow:

By this information you should be able to partially validate contract data (next section) mainly :

• How many contracts should you create 
• What Company codes + P.Orgs should be used ( reference to the table above in 2.3)

So by Country information we may know that mandatory information is needed to create contracts and for what system.

Purchase Organization and Company Code information set in the contract(s) should be standard and wider as possible in order not to block future Shopping carts in SRM7

If both legacies are present in the target country we need to insure that the Vendor is aligned in both systems, with SAME DUNS code and opened for target P. Org. and Company.

2.5 Contract details

By the Vendor information and material group information , we can validate:

• If vendor is linked between systems (for the cases where you need to create contracts in both systems more details in 2.8)
• If the Vendor has DUNS setup in the back ends.
• Material  group domain, thus identifying the P.Org to set in WP1 contract if applied.
• Valid material group  and correspondence using GPS Table

2.6 Choose the correct P.ORG in WP1

IMPORTANT , if an e-catalog is set to have a contract in WP1, the material groups to set in the contract should belong to the same domain with no exception.

if it's not the case you may need two or more contracts depending on the domains of the material groups expressed in your request. 

If possible creating two or more contracts in one system for the same e-catalog should be avoided and the correct action should be to confirm the material groups to include.

There is a relation between the material group domain and the target P.Org to set in the contract. as follow:

You may access the material group domain information either:

• In the submission template (GPS Table)
• Running ZZM_GPS_MATKLV -> SE16
• Or in the following file 

2.7 Material Group Correspondence

Additional for the material group we have a correspondence between systems as the native material group tables in PF1 and WP1 have differences.

In order to simplify the process, a mapping was created in a 3rd table . Called SRM Material groups

SRM Material groups will be used to populate e-catalog PF1 contracts only

The check required is to cross the information between the material groups setup for each contract. 

Example:

A catalog is requested for France and should include :

Material groups : 0330 and 0193 in Contract data for WP1 and Material groups : ZM1052 and ZM1062

The action to be performed is to find :

ZM1052 correspondence in WP1 table 

ZM1062 correspondence in WP1 table

and by data validation rules

1. Two contracts are to be created (WP1 -> PF1)

2. P. Org in WP1 contract should be 3004 (Mat grps belong to domain 4 and both belong to the same domain)

3. Contract in PF1 should be replicated with the same WP1 code

4. Material grps to use in PF1  contracts should be ZMS0330 and ZMS019

2.8 Vendors Validation

Vendors are the last check to be performed

We need to access all the previous checks first before taking action in Vendor Master data

Vendors need to be aligned/linked between WP1 and PF1 if we are creating two contracts.

Vendors need to be opened to Target Purchase Org. and Company Codes for the target systems in order to complete the contract creation.

Vendors need to have a DUNS code defined and for aligned Vendors it’s MANDATORY that DUNS should be EQUAL

2.9 List of Validations (Conclusion)

1. Identify if contracts need to be created for both legacies depending on country requested

2. Always check WP1 information first.

3. Relate the P.Org to use in WP1 contract with the domain of WP1 material groups to be include in the contract.

4. PF1 contract will use the SRM material group similar to WP1 material grps.
5. Check if WP1 and PF1 Vendors are created /aligned.
6. Both Vendors needs to have the same DUNS defined in VMD
7. Identify the Payment terms in the template to use
8. Identify the Incoterms in the template to use
9. Identify the Tax Code to use
10. Identify the Purchasing group to use

VOD File with a practical example on how to validate information