Skip to Content
User Experience Insights
Author's profile photo Narasimha Prasad Bhat

SAP Warranty – Dealer merger business process-4

Purpose: In the warranty business, Dealers play an important role. They are usually under a distributor. They register customers, raise warranty claims, and get paid by the distributor/OEM based on some warranty guidelines formed by the OEM and distributor. One distributor would have multiple dealers under him at any given point in time. Due to several reasons, dealerships get dissolved and merged with another dealer under the same dealership or registered under a new dealership. When a merger/de-merger happens, many warranty master and transaction data must be carefully transferred. This blog post discusses an SAP approach to such business scenarios.

Business Process:   The customer warranty network consists of dealers, distributors, branches, service centers, etc.

Multiple dealers would be under one distributor. It is common for one dealer to merge with another due to various business reasons. Multiple scenarios of mergers & acquisitions can happen

      • Dealer merging with another dealer under the same distributor.
      • Dealer migrating from one distributor to another
      • Dealer merging with another dealer who is under a different distributor.
      • One distributorship merging with another.
      • Mass dealership migration of one specific location to another distributorship.

In such cases, businesses would require a solution to transfer open warranty claims, open extended contracts, record new dealer customer code in all the serial numbers/equipment, and parts master data with partner data change in historical records.

Sap solution back end :

Dealer and distributor records are created as Business partners in S/4 Hana. A dealer would have a distributor ID assigned as a partner function. There are many approaches to do this. Some possible suggestions are made below.

      1. Dealer merging with another dealer under the same distributor.
      2. Checking open claims, especially approved ones, but credit still not given to the dealer. These should be settled immediately and then carried out the transfer of available claims to the target dealer.
        1. Change dealer ID from all claims (Open claims would be settled with the new dealer, and old claims will appear against the new dealer in reports)
        2. Since the distributor is the same, you may not need another dealer ID
        3. Change the partner in open contracts also.
        4. Change dealer ID in all the customer installed base where old dealer ID was present (This is customer base transfer)
        5. Change dealer ID in all historical transactions with new Dealer ID (To get correct information report under new dealer ID)
        6. Old dealer SAP ID to be made inactive, so that old dealer doesn’t access the warranty application.
      3. Dealer migrating from one distributor to another
        1. New dealer code to be created under the new distributor.
        2. Change dealer ID  as per the above scenario in all warranty objects.
      4. Dealer merging with another dealer who is under a different distributor.
        1. Same as above scenario, however, new dealer ID is not required as by replacing old dealer ID with new dealer ID, distributor data automatically gets assigned
      5. One distributorship merging with another.
        1. This has effects not only on warranty but also on other objects (Needs detailed design workshop)
      6. Mass dealership migration of one specific location to another distributorship.
        1. Same as scenario 3, but a mass tool is needed.

Sap Configuration requirement: No special configuration requirement.

Sap solution front end :

  • Distributor requesting a transfer of dealership code from another distributor under himself. Since many checks and balances have to be done while transferring, this could be a background job that will keep track of object by object transfer. At any point in time, the app should show the transfer status of each object along with the count (Target count Vs. .actual count). There should be a provision to see error logs to identify and correct the issues and retrigger the transaction.

Data migration design: There is no need for this. If the scenario happens during cutover, the actual data would be transferred to the new system, and the transfer program should be triggered.

Persona Design: This is usually done OEM warranty team; however, request triggering (Later to be approved by the OEM warranty team) could also be given to the distributor persona.

Unique Controls/Requirements: Master data transfer from one dealership to another is a time-consuming backend job. Hence warranty team may request an email on any failure. There could be a requirement to store logs on which claims, equipment, contracts, the dealer ids were changed. If the IDs are distributed across many platforms, then the status of the ID needs to be in sync with others too.

This process under warranty business is a master data process. However, it is complicated. Hope this blog post gives an idea of what all processes one should be aware of while taking care of the master data of partners when partners merge/demerge.

Your feedback is essential to keep me motivated to post more.

 

 

 

 

 

Assigned Tags

      2 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Harsh Banda
      Harsh Banda

      Good overview of possible master data migration

      Author's profile photo Narasimha Prasad Bhat
      Narasimha Prasad Bhat
      Blog Post Author

      Thanks Harsh