BP RCM MAPPING

Process Overview

Fields Description
Process Name BP RCM Mapping
Segment Consumer,SMB.Tablet[ST]
Process Family: Lenovo India
Process User(s): Wyzmindz solutions pvt ltd
Process Purpose: This report is instrumental in providing actionable insights, tracking performance, and supporting Lenovo’s sales strategies

Version History:

Version Tag Prepared By Date of Update/Revision Validated by Reviewed by Approved by Revision Details
V 1.0 Kiran Biradar 17-12-2025 Dayanand U Sushruth Vasista Vishwanath Mosale SOP Document Creation

Distribution and Access List:

Designation Read Write Approval
Analyst Yes No No
Team Lead Yes Yes No
Manager Yes Yes Yes

1.1 Purpose

The purpose of this SOP is to define a standardized process for validating Sell-through DSR data, mapping partner details with master records, determining rebate and FYR eligibility, and preparing an accurate, audit-ready dataset for upload to the Data Mart portal. This ensures data consistency, correct payout eligibility, and compliance with approved business rules.

1.2 Scope

  • This SOP applies to downloading, preparing, validating and for Sell thru and Sell Out for All segment BPRCM Master Data.

1.3 Business/Segment Overview

This process supports Lenovo India's sales strategies by delivering actionable insights and monitoring performance. The primary objective is to ensure the accuracy of channel sales data (3S) for Consumer products, focusing on Sell-through, Sell-out, and segmentation across Consumer, SMB, and Tablet categories.

1.4 Responsibility and authority

|Analyst |Kiran Biradar| |Process Owner |Jospha Jeevitha J| |Process Manager |Dayanand| |Escalation Manager |Sushruth Vasista| |Approval Authority |Vishwanath Mosale|

1.5 Escalation matrix: (Wyzmindz and Lenovo)

Escalation Matrix – WyzMindz Solutions Pvt Ltd India

Sl No. Name Designation Email ID
1 Sushruth Vasista Manager sushruth.vasista@wyzmindz.com
2 Vishwanath Mosale Director Vishwanath.mosale@wyzmindz.com

Escalation Matrix – Lenovo India Pvt Ltd

Sl No. Name Designation Email ID
1 Niyaz CDMS Tech Support nkumanali@lenovo.com

1.6 RACI Matrix:

RACI Matrix – WyzMindz Solutions Pvt Ltd India

Report / Process Responsible Accountable Consultation Informed
Data download Kiran Kiran Dayanand Lenovo Ind Pvt Ltd, Wyzmindz – Lenovo Process Team

1.7 Access Required

  • Platform: CDMS
  • URL: https://cdms.lenovo.com/DCSDM/DataMart/FileUpload
  • Access: Email ID and password provided by Lenovo IT Team

1.8 Overview of Tools

  • Microsoft Excel is required for data cleaning.

1.9 Data Dependencies

The process is dependent on the availability and accuracy of the following data sources:

Sellthru_DSR_Validation_Report

Primary input file received from the CDMS IT Team containing sell-through and exception data.

BP-RCM Master File

Used for partner validation, key mapping, and removal of already mapped records.

BP Master File

Used for populating partner, T1, and T2 level details.

City Master File

Used for mapping State from City when city-level partner matching is not available.

Rebate Partner Reference List

Used to determine rebate eligibility, BPCategory, and FYR eligibility (Type).

T1 Reference Master

Used for validating T1_SoldToCode, LPP_T1, and T1_MDM_ID.

Regional Mapping Master

Used for mapping ACM and RCM_Region based on City or State.

1.10 Legends

  • Core Activity: A standard processing step involving data creation, validation, mapping, or update
  • Decision: A validation or condition check that determines the next process path
  • Input: Source file or reference data used in the process
  • Output: File or dataset generated at a specific stage of the process
  • Reference: Master file or supporting document used for validation or mapping
  • End: Completion of the process flow

1.11 Schedule of Reporting

Frequency: Daily

1.12 Process Flow Chart

PFC

1.13 Steps of Procedure`

1.13.1 Input File Receipt and Validation

  1. Receive the Sellthru_DSR_Validation_Report via email from the CDMS IT Team.
  2. Save the file in the designated working folder for the processing week.
  3. Open the file and verify:
    • File name and week alignment
    • Sheet availability, especially the RCM and Exception sheets
    • Presence of mandatory columns such as PARTNER_SEGMENT, CUST_CODE, CITY, T2_GSTIN, and DISTY
  4. Confirm there are no file corruption issues or missing data before proceeding.

1.13.2 Initial Key Creation and Exception Cleansing

  1. Navigate to the RCM sheet in the Sellthru_DSR_Validation_Report.
  2. Create a composite key by concatenating:
    • PARTNER_SEGMENT
    • CUST_CODE
    • CITY
  3. Open the BP-RCM Master file.
  4. Create the corresponding key using:
    • CodeCity + Segment
  5. Map the BP-RCM Master key to the Exception file using lookup or mapping logic.
  6. Identify records already present in the BP-RCM Master.
  7. Remove matched records from the Exception file to ensure only unmapped or new records remain for further processing.

1.13.3 Duplicate Identification and Removal

  1. In the cleaned Exception file, create a refined composite key by concatenating:
    • PARTNER_SEGMENT
    • CUST_CODE
    • CITY
    • T2_GSTIN
  2. Use Excel’s Remove Duplicates functionality:
    • Shortcut: Alt + A + K
  3. Select the newly created composite key column.
  4. Confirm duplicate removal to retain only unique partner-segment-location-GSTIN combinations.
  5. Review the record count before and after de-duplication for control validation.

1.13.4 Field-Level Data Mapping to BP Master

  1. Open the BP Master File.
  2. Copy data from the Exception file and paste into BP Master as follows:
    • DISTY → Disty
    • CUST_CODE → InternalBPCode
    • RESELLER NAME → BPNameDSR
    • CorrectCity → CityDSR
    • CorrectCity → RCM_City
    • PARTNER_SEGMENT → Segment
    • T2_GSTIN → GSTIN
  3. Ensure data is pasted as values to avoid formula dependency issues.
  4. Validate that row alignment is maintained correctly after pasting.

1.13.5 T1 Level Mapping and Validation

  1. Using Disty + Segment, identify the corresponding T1 details.
  2. Populate the following columns:
    • T1_SoldToCode
    • LPP_T1
    • T1_MDM_ID
  3. Cross-verify T1 details with the approved T1 reference master.
  4. Ensure no blank values exist for valid Disty-Segment combinations.
  1. Apply filters on the BPNameDSR column.
  2. Search partner names individually.
  3. Normalize partner names where required by:
    • Removing extra spaces
    • Expanding abbreviations such as “P. Ltd” to “Private Limited”
    • Adjusting short or partial names to match master references
  4. Document name variations used during search for traceability.

1.13.7 T2 Partner Mapping Using City and State

  1. Create the primary matching combination:
    • BPNameDSR + Segment + RCM_City
  2. If a match is found, proceed with data enrichment.
  3. If no match is found:
    • Refer to the City Master file
    • Map the corresponding State
  4. Retry the matching using:
    • BPNameDSR + Segment + State
  5. Upon successful match, populate:
    • ContrNo
    • RegBPName
    • BPCategory
    • T2_BPCategory
    • Type
    • LPP_T2
    • T2_MDM_ID
    • T2_BP_Type
    • T2_BP_Sub_Type
    • T2_D365
    • Old Contract Number

1.13.8 Rebate Eligibility Mapping

  1. Validate the partner against the Rebate Partner Reference List.
  2. Identify rebate eligibility based on:
    • BPCategory
    • Segment
    • Geography (State or Pan-India)
  3. Apply state-specific or Pan-India rebate logic as applicable.
  4. Ensure Consumer, Tablet, and SMB segments are evaluated independently.

1.13.9 Type Assignment and FYR Eligibility Logic

  1. Assign Type based on BPCategory, Segment, and Rebate status.
  2. Follow approved logic, for example:
    • One Time Partner in Consumer without rebate → Inactive
    • COMM in Tablet without rebate → Managed
    • Non Rebate – Breadth in SMB without rebate → Unmanaged
    • RD, LMB, LES, Online, LFR with rebate → Active or Managed
  3. Ensure Type assignment aligns with FYR eligibility rules.

1.13.10 New Partner Handling (Not Eligible for Payout)

  1. If no record is found in master or rebate reference:
    • Treat the partner as a new, non-eligible partner.
  2. Apply segment-specific defaults:
    • Consumer: One Time, Inactive
    • Tablet: COMM, Managed
    • SMB: Non Rebate – Breadth, Unmanaged
  3. Populate LPP_T2 using InternalBPCode.
  4. Clearly mark such records for audit visibility.

1.13.11 ACM and RCM Region Mapping

  1. Map ACM and RCM_Region using:
    • RCM_City + Segment + T2_BPCategory
  2. If not available, map using:
    • State + Segment + T2_BPCategory
  3. Validate region consistency with regional master references.

1.13.12 Handling Non-Eligible Partner Records

  1. For partners not eligible for payout, do not populate:
    • ContrNo
    • T2_MDM_ID
    • T2_BP_Type
    • T2_BP_Sub_Type
    • T2_D365
    • L3 HQ MDM ID
    • Old Contract Number
  2. Ensure these fields remain blank to avoid incorrect payouts.

1.13.13 Final Review and Upload

  1. Perform a final review to ensure:
    • No duplicate records exist
    • Mandatory fields are populated correctly
    • Eligibility logic is applied consistently
  2. Save the final file with the correct naming convention.
  3. Upload the file to the Data Mart Portal using the appropriate dropdown selections.
  4. Confirm successful upload and retain the file for audit and reconciliation purposes.

1.14 Output Overview

  • Final cleaned and de-duplicated Sell-through DSR file prepared for upload to the Data Mart portal
  • Contains validated partner, location, T1, and T2 details after master mapping and eligibility checks
  • Rebate and FYR eligibility reflected through BPCategory, T2_BPCategory, and Type fields
  • Non-eligible partners retained with default classification and without payout-related fields
  • File is upload-ready and used for rebate processing, reporting, and audit reference

1.15 Validation checklist

  • Confirm correct Sellthru_DSR_Validation_Report is received from CDMS IT Team
  • Verify required sheets and mandatory columns are available
  • Validate key creation:
  • PARTNER_SEGMENT + CUST_CODE + CITY
  • Mapping completed with BP-RCM Master and matched records removed
  • Confirm de-duplication using:
  • PARTNER_SEGMENT + CUST_CODE + CITY + T2_GSTIN
  • Verify accurate data mapping from Exception to BP Master:
  • Disty, InternalBPCode, BPNameDSR, CityDSR, RCM_City, Segment, GSTIN
  • Check T1 fields populated correctly:
  • T1_SoldToCode, LPP_T1, T1_MDM_ID
  • Validate partner search logic:
  • BPNameDSR + Segment + RCM_City
  • BPNameDSR + Segment + State (if required)
  • Confirm T2 mapping and rebate eligibility applied as per reference list
  • Verify Type assigned correctly based on Segment, BPCategory, and rebate status
  • Ensure new partners handled correctly and marked as not eligible where applicable
  • Validate ACM and RCM_Region mapping using City or State logic
  • Confirm non-eligible partner fields remain blank:
  • Contract, MDM, BP Type, D365 related fields
  • Perform final review and confirm successful upload to Data Mart Portal

1.16 Communication

Final processed files are uploaded in Lenovo CDSM plat form Below the Snapshot of platform.

Communication

If issue with CDMS

To CC
cdmsit@lenovo.com svasista@lenovo.com
nk@lenovo.com
du@lenovo.com
nkumanali@lenovo.com

1.17 Repository Details

Field Details
Name City Master
Type .xlsx
Path / URL https://cdms.lenovo.com/DCSDM/DataMart/FileUpload
Access Daya/Kiran
Owner / Team Daya
Last Updated 14-12-2025