Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
Manish_Parchure
Discoverer

In today’s world where we talk about massive data in system of records as in a SAP ERP Production system, it is necessary for organizations to have clean and updated master data records especially for key object types like Vendor and Customer which are primary building blocks for most of the  transactions. A typical problem scenario which is commonly observed in our experiences in varied clients across industries is that of duplicate records for these object types in a SAP ERP production system. Duplicate Vendors and Customer in a system typically refers to multiple master data records for the same Partner say sold-to-Party, Bill-to-Party or a vendor which results in not only causing frustration for end-users to work with duplicate records, it also makes analysis challenging and hinders in business functions such as using credit limit etc. It is true and equally important to prevent getting duplicate records by a root cause analysis to know how did the duplicate records get there in production system. But on the other hand as an immediate step it is important to have a de-risked and faster way of treating duplicate live master data records in the system. I want to focus here to present in this blog an effective and a standardized approach for carrying out such a de-duplication for Vendor and Customer Master data.


It is easy to  set a flag for deletion of vendor or customer and later archive duplicate instances if no transaction data is crated on them. However, this approach of removing duplicates by the way of archiving cannot be used if you have dependent transaction data like sales order, purchase order, invoices etc. which is meaningful to business and you want to keep it in production system.

SAP Landscape Transformation Version 2.0 (LT 2.0)  is a licensed SAP software product. LT2.0 offers solution to most common use cases in areas of consolidation, restructuring and harmonization. In harmonization portfolio, LT 2.0 provides a tool driven and standardized transformation technique to rename and de-duplicate (merge) the Vendor or Customer records. A mapping table is required which provides new values corresponding to old/existing Vendor/Customer Number. This mapping table draws up target state by providing all merge and rename requirement in one place. The real strength of using the solution 'Customer/Vendor Number Conversion' of LT 2.0 is that after the go-live, users will get the system in such a state that they will feel as if they never had any duplicate and they always had new values (target Vendor/Customer Numbers) in the system. Because this database transformation technique will not only rename or merge Vendor/Customer Number, it will also update the new values in the transaction record created on old values. Example- For a Vendor 'xyznamecorp ltd.' there are 2 records of Vendor Number say 'A' and 'B'. Each record has various documents -Purchase Order (PO) with Good receipt (GR) and Invoices (IR) posted on it. In this example, if records 'A' and 'B' are decided to be merged into record 'A', then after conversion, in the system you will not find Vendor Number 'B',  and you will see all documents (POs, GRs and IRs) originally created on Vendor Number 'B' have the key replaced with 'A' after conversion. In summary, LT 2.0 will refer mapping table provided and rename or merge keys in all pertinent SAP tables for the Customer/Vendor Number conversion.


Data harmonization tasks of Conversion of Vendor and Customer can be taken together and delivered in one project. Similarly, Material Rename can be combined too. This saves lot of time and efforts as conversion, testing and reconciliation can be worked together.

Benefits of using this solution are far reaching, as you get system with consistent data and harmonization reaching deep into all layers of data - configuration data, master data, open transaction data and historical (closed transaction records) data. Users have no obligation to do any special treatment (for example on in-process document flows) before go-live. The problem statements which actually prompted de-duplication are correctly addressed. Standardization in naming can be achieved by providing a new vendor/customer number based on a new naming convention or organization.
1 Comment
Labels in this area