Sales Cloud Report Sharing Center

Sales Cloud Shared Reports

Topic

    Harshavardhan Konathala
    Incentive compensation: CRM SALES and IC dimensions linking...
    Topic posted May 28, 2019 by Harshavardhan KonathalaBlue Ribbon: 750+ Points, tagged Activity, BI Publisher, Business Plan, Business Plan Objective, Channel Account Manager, Channel Sales Manager, Chart, Competitors, Customer, Dashboard, Data Visualization, Forecast, Infolets, Leads, MDF, Opportunity, Opportunity Management, Partner, Partner Announcements, Pipeline, Quota, Reporting and Analytics, Sales, Sales Campaign, Sales Executive, Sales Manager, Sales Representative, Shared Reports, Trends, Users 
    26 Views
    Title:
    Incentive compensation: CRM SALES and IC dimensions linking using common 'Resource Hierarchy'
    Summary:
    The below prototype helps in building common reporting solutions across fusion CRM and IC Pillars, current DWH model doesn't have direct reporting solution across the pillars.
    Content:

    Background & Business Case - 

    • Customers who are using both CRM SALES and IC, as of now they are unable to create the report with common dimensions and metrics from both the pillars.
    • Any customer whose sales representatives involved in SALES activities and to check their compensation details till now customers are importing the same sales representatives data into IC and creating the reports.
    • Any customer if wants to create the report using SALES and IC dimensions there is no proper linking between these pillars and end up creating a cross SA with completely improper data.
    • Hence to resolve this we have an idea on joining CRM sales resource hierarchy and IC participant hierarchy, functionally which is same but technically there is no implementation.
    • CRM resources or sales representatives are the same IC participants who are getting compensation in IC. Hence using this functional derivation we are joining the CRM resource hierarchy and IC participant hierarchy details to get the common report across both the pillars.
    • CRM sales data ends once the order details have been placed, from there IC starts with the order data and ends with payment information.
    • As of now, we don't have any direct reports which have complete sales details along with the Incentive compensation metrics.
    • With this joining, we can get a complete report with SALES dimensions and metrics followed by IC metrics.

    FA Implementation - 

    To implement this requirement we have to make a couple of table joins from FA side which was not implemented as of now.

    Customers which are importing sales data into IC and creating reports from them we have to provide a solution with FA database tables join like below:

     

    FA%20DB%20Joins.png?version=1&modificationDate=1549990664000&api=v2

    • JTF_RS_REP_MANAGERS_CF is used to fetch manager/hierarchy for resources stored in JTF_RS_RESOURCE_PROFILES in Sales. IC participants are stored in CN_SRP_PARTICIPANTS_ALL and the hierarchy is sourced from HCM table  PER_MANAGER_HRCHY_REPORTEES_DN
    • Sales resource hierarchy and participant hierarchy are not stored in a common table. There is no process to sync this data either. The only link is the hz_parties.party_id (TCA) present in both Sales and IC tables.
    • Ideally, a customer implementing both IC and Sales will import sales resources in IC as participants. So, yes, jtf_rs_resource_profiles.party_id can be looked up for matching party_id records in cn_srp_participants_all

    Data Mockups - 

    Need to consider the participant's data directly from the database, so that we can cross-compare the same when implemented in OTBI.

    SALES DATA with PARTYID as main columns followed by all the main dimensions columns BASE ID values, FOR IC data, we have participant ID for the equivalent PARTYID columns followed by all the base dimensions columns BASE ID values. Please refer to attached Mockups  

    Points to note - We have to make the join between PARTID from sales and PARTYID from IC.

    Mandatory Join, We have to join ORDER_ID from sales and TRANSACTION_ID from IC. Because functionally OREDR_ID = TRANSACTION_ID. I.E. SALES REPS who are making orders, only those are considered as TRANSACTIONS in IC. Hence we have to consider this joins for PROPER reporting data.

     

    SALES%20AND%20IC%20REPORT.PNG?version=1&modificationDate=1549991819000&api=v2

    REPORT WITH BOTH SALES AND IC ATTRIBUTES - 

     

    COMMON%20REPORT.PNG?version=1&modificationDate=1549991989000&api=v2

     

    Final Dashboard - Entire Prototype built on Oracle Data visualization Desktop Tool.

     

    Final%20Report.jpg?version=1&modificationDate=1556281441000&api=v2

     

    Note - 

    1) Credit AMOUNT calculated based on the SPLIT PCT for each transaction handled by the participant.

    2) SPLIT PCT was given if two participants involved in one single transaction.

    3) Earning AMOUNT will be 5% of the credit amount.

    4) Transactions with status "CREDITED" are only considered for credit amount calculations

    5) Similarly credits with status "Credited" are only considered for earning calculations.

     

    Please find the complete observations and current standings –

    • The entire idea of building this prototype is to provide a reporting solution which has both SALES and IC metrics.

    • The current model doesn’t support continuous reporting from sales to IC, hence to achieve this we want to integrate common dimensions shared across both the pillars i.e. joining both the pillars data using employee resource hierarchy from sales and participant hierarchy from IC. Similar to the partner dimension project.

    • By considering the above assumption we have started building the prototype by using SALES mockup (The one used for all the SALES POCS) and IC mockup(One we built completely new).

    • Sales mockup flow “Campaign-Lead-Opty-Order”, IC mockup flow “Transaction-Credit_earning-Payment”.

    • Joins established to build the prototype are SALES.PartyID = IC.PartyID and SALES.OrderID = IC.TransactionID.

     Pointes to Note:

    • Entire data model and dashboard was completed by considering above joins.

    • Current joining flow is “IC → Resource Hierarchy → SALES”, from the current FA model we were able to identify the joins to link IC facts to resource hierarchy dimensions(PFA FA tables screenshot).

    • Whereas we are encountering trouble finding the joins to resource hierarchy → sales facts. Because in the current model Order details are coming from ORDER management and SALES data ending with Opportunity data.

    • using Order_num from transactions table we can join IC data with Order management data but later from order management to SALES Oppty, we don't have proper joins to establish. 

    • There are no proper joins to get SALES Oppty data and SALES facts to build the solution at RPD level.

    Version:
    Oracle DV Version 12.2.5.0.0-20180829155113
    Image:
    Document:
    Document: