Presentation is loading. Please wait.

Presentation is loading. Please wait.

White Master Replace with a graphic 5.5” Tall & 4.3” Wide Copyright 2009 Adobe Systems Incorporated. All rights reserved. Adobe confidential.1 Deal Registration.

Similar presentations


Presentation on theme: "White Master Replace with a graphic 5.5” Tall & 4.3” Wide Copyright 2009 Adobe Systems Incorporated. All rights reserved. Adobe confidential.1 Deal Registration."— Presentation transcript:

1 White Master Replace with a graphic 5.5” Tall & 4.3” Wide Copyright 2009 Adobe Systems Incorporated. All rights reserved. Adobe confidential.1 Deal Registration Payout Process 2013 Automated Payout – Business Logic and Data Flow Prepared By: Gary Spencer

2 ® Copyright 2009 Adobe Systems Incorporated. All rights reserved. Adobe confidential.2 Deal Registration Payout – Phase 1  We have currently implemented the Payout process for Americas Desktop Products.  EMEA and VIP are now developed and will launch April12.  New UI will be launched May 1 for all Deal registration programs  The Data Processing Frequency is once a week in SQL and in new technology it should be daily process.  Report Delivery  SFDC  Micro Strategy

3 ® Copyright 2009 Adobe Systems Incorporated. All rights reserved. Adobe confidential.3 Design Flow

4 ® Copyright 2009 Adobe Systems Incorporated. All rights reserved. Adobe confidential.4 Data Integration  We extract the rolling 360 days data based on Claim Expiration date from SFDC opportunity and other tables based on following condition  Adobe Sales Order Number not equal to Null, 0  Approval Status equals Approved, Expired  Opportunity Record Type not equal to Adobe Internal opportunity, Alliance Partner Tracking  Payout Status equals Null, Not Processed, Reprocess  We extract the rolling 360 days data based on order date from SAP.  The two sources (SAP and SFDC) are merged based on the Sales order number.

5 ® Copyright 2009 Adobe Systems Incorporated. All rights reserved. Adobe confidential.5 Data Integration - Continued  We update the geo specific Open and active promotion information based on below conditions.  Submit Date time Between Promo Start Date and Promo End Date  Order Date <= Promotion Order By Date  Claim Expiration Date <= Promo Claim Expiration Date  LOGIC for Assigning record a Program Code Name  Deals that passed the first set of revalidation rules and are imported to the back end system are then matched by Region, Program and submit date to get the program capsule code.  If Region <> EMEA then match Region, Program Rollup and submit date falls within Effective Start Date and Effective End date of SFDC.DR_Program_Capsule__c

6 ® Copyright 2009 Adobe Systems Incorporated. All rights reserved. Adobe confidential.6 Data Integration - Continued  If Region = EMEA then match Country Code to Country code in Program capsule, Program and submit date is between effective start date and effective end date and assign Program Capsule Code that contains EMEA_EU in the program code name.  If Region = EMEA and Country code <> Program Capsule country code, match program from order to capsule and submit date from order is between effective start date and effective end date of program capsule assign program code that contains EMEA_EmergingMkt/MENA_ in the program code name.

7 ® Copyright 2009 Adobe Systems Incorporated. All rights reserved. Adobe confidential.7 Eligibility Criteria(s)  Already Claimed Line items are Ineligible  If Payout Status <> Reporcess and Memo Reference is not NULL Then “Deal has been claimed”  Line items with missing Programs are Ineligible  Line items with below combination are Ineligible  ([Major Product Configuration] = 'Consulting' AND [Super Product config] = 'Consulting' )  ([Major Product Configuration] = 'Licensing M&S' AND [Super Product config] = 'New' AND [Prod. Configuration] not in ( 'MSEA','MREA') )  ([Major Product Configuration] = 'Other' AND [Super Product config] = 'Other' )  ([Major Product Configuration] = 'Upgrade Plan' AND [Super Product config] = 'Renewal' )  ([Major Product Configuration] = 'Upgrade Plan' AND [Super Product config] = 'Other' AND [Prod. Configuration] <> 'TERM2')  ([Outlook Product Grp] = 'LIVECYCLE')

8 ® Copyright 2009 Adobe Systems Incorporated. All rights reserved. Adobe confidential.8 Eligibility Criteria(s) - Continued  Line items with missing Partner Role are Ineligible.  Line items with Programs in ('CSBU', 'PPBU', 'Acrobat') and [Order Date] prior to ' ‘ are Ineligible.  If Program Code for line item doesn’t matches with that of Program Capsule Code then it is ineligible.  If Same sales order is claimed in different Deals then the one with latest submit date is ineligible.  If Partner name doesn't match with either of Distributor or reseller then line item is Ineligible.  If [Claim Date] <= [Order Date] + 60 then line item is ineligible  If Submit Date] < [Order Date] AND [Order Date] < [Expiration Date] then line item is Ineligible

9 ® Copyright 2009 Adobe Systems Incorporated. All rights reserved. Adobe confidential.9 Determining Pay Basis  Default Pay basis for Latin America is Net Adobe  Pay basis is Net Adobe for Adobe Demand Generation  Pay basis is ESP for Sourcing Only partners and Where Distributor Administrated Rebate is True.  If Partner Name matches with both Distributor and Reseller then Pay basis is Net Adobe.  If Partner Name only matches with Distributor Net Adobe.  If Partner Name only matches with Reseller then Pay basis is ESP.

10 ® Copyright 2009 Adobe Systems Incorporated. All rights reserved. Adobe confidential.10 Calculating Eligible Revenue and Eligible Total  Eligible Revenue is Calculated at each eligible line item level and is based on Pay basis.  If Pay basis is Net Adobe then Net Adobe Amount.  If Pay basis is ESP then ESP Amount  Eligible total is calculated at Deal Registration Level.  It is sum of each eligible revenue at Deal Registration Id level.

11 ® Copyright 2009 Adobe Systems Incorporated. All rights reserved. Adobe confidential.11 Determine Payout Percentage and Pay Type  We get the payout percentage and pay type from the SFDC.DR_PayCode__c  Threshold codes are matched to the threshold.Threshold_ID  Threshold Level that was assigned to order record is looked at then the payout amount(percentage to be calculated or flat amount) is assigned to the record.

12 ® Copyright 2009 Adobe Systems Incorporated. All rights reserved. Adobe confidential.12 Calculating Payout Amount  Calculation of Payment Amount Depends upon Pay Type.  If Pay Type = ‘Percent’ Then [Eligible Revenue] * [Total Payout Percentage]  If Pay Type = ‘Flat’ Then [Payout Flat Rate]  [Total Payout Percentage] = [Payout Percentage ]+ [Promo Percentage] + [Adjustment Percentage]  Total Payout amount  Sum of Payment Amount at Deal Registration level.

13 ® Copyright 2009 Adobe Systems Incorporated. All rights reserved. Adobe confidential.13 Override Logic  We can override line items marked as Ineligible in previous run due to below mentioned reasons:  Submit Date  Claim Date  Partner Mismatch  Pay basis  Override Logic is also used to adjust payout percentage and Payout amount Based on below reasons:  Payout Percentage Adjustment  Additional Total Rebate Amount

14 ® Copyright 2009 Adobe Systems Incorporated. All rights reserved. Adobe confidential.14 DR USER Interface  We are pull data from SFDC for rolling 360 days based on Claim Date for following criteria:  Adobe Sales Order Number not equal to Null, 0  Approval Status equals Approved, Expired  Opportunity Record Type not equal to Adobe Internal opportunity, Alliance Partner Tracking  Payout Status equals Null, Not Processed, Reprocess

15 ® Copyright 2009 Adobe Systems Incorporated. All rights reserved. Adobe confidential.15 Flow- Data Cleansing  The Sales Order number column from SFDC opportunity table has got different separators for sales order as it is a text field in SFDC and depends on user who enters the data in it. We have identified below separators for Sales order number : ,  &  +  -  ;  |  :  AND  /  ‘ ‘  In our logic we are converting each of above separators to a common separator ( ;). Then we are creating formatted sales order number (one SO# in each row) and replicating same information for other columns in our table.

16 ® Copyright 2009 Adobe Systems Incorporated. All rights reserved. Adobe confidential.16 FLOW –Data Cleansing  We delete the data where formatted sales order number is NULL or blank. And we make each sales order number of fixed length (9) by prefixing leading zeros.  Till point 3 we have a table called SFDC_STG_Deal_REG which contains data from SFDC with formatted sales order number.  Next we pull data from BW licensing query (Licensing Details – CL) on each Monday for rolling 360 days based on order date and load it in a temporary table temp_DR_Process. This table contains columns from BW and also SFDC columns (opportunity, opportunityLineitem, account and promotion object) as well.  We update the SFDC columns in the temp_DR_Process table based on the matching sales order number between SFDC_STG_Deal_REG and temp_DR_Process.

17 ® Copyright 2009 Adobe Systems Incorporated. All rights reserved. Adobe confidential.17 FLOW Data Cleansing  The unmatched list of sales order number between SFDC_STG_Deal_REG and temp_DR_Process along with the opportunity ID will be mailed to Program Managers in CSV format.  Next we update the promotion info in the temp_DR_Process table based on below conditions  ( Submit_Date_Time__c )  AND ( OrderDate )  AND ( Claim_Expiration__c )  AND (Geo  Till this point we have temp_DR_process table with columns from BW and SFDC.

18 ® Copyright 2009 Adobe Systems Incorporated. All rights reserved. Adobe confidential.18 FLOW CONT- Load cleansed Data and start Validation  Next Step is to populate DR_Process table from temp_DR_Process table.  Also we check for below condition:  If Payout status not equal ‘Reprocess’ and either of Memo reference or Distributor Credit Memo is Not null then Flag a Message in message column stating  ‘Deal has been previously processed and paid’ and also update the Flag [Program Line item Eligible] = ‘NO’  Next we check for the matching eligible code between our SQL table (DR_Eligible_Lkp) corresponding to the DR_Payout_Descision_Tracking_Matrix__c SFDC object and the DR_Process table. If Eligible code is not found DR_Eligible_Lkp table, then

19 ® Copyright 2009 Adobe Systems Incorporated. All rights reserved. Adobe confidential.19 FLOW CONT- Validation  We flag a message in the Message column stating  'Program Doesn't have valid Eligible Code’ and also update the Flag [Program Line item Eligible] = ‘NO’  Then we check for the Duplicate order where same sales order number is part of the different Deal Reg ID. If same sales order number is present in the different Deal Reg ID then  We Update a flag [Duplicate Order] = ‘YES’ for order with latest claim date. We also flag a message in the Mesaage column stating  'Already Claimed in ' + Deal RegID and also update the Flag [Program Line item Eligible] = ‘NO’  (if 2 SO in same batch flag both as ineligible and list both Deal reg ID)’SO Claimed on multiple Deals’ + Deal reg ID

20 ® Copyright 2009 Adobe Systems Incorporated. All rights reserved. Adobe confidential.20 FLOW CONT- End User and Account Cleansing  Next we clean the EndUserName and AccountName based on below logic.  UPPER(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPL ACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLAC TY'),' UNIVER','UNIVERSITY'),'HIGH SCHOOL','HIGH'), 'CO ','COUNTY '),'INC', ''),' AND ',''),'&',''),'.',''),'-',''),',',''),'''',''),'#',''),' ',''))  After cleaning the EnduserName and AccountName we match these two columns based on 75% Fuzzy Match geo = ‘Americas’.  For unmatched we keep Pay Basis as NULL and Flag a message in the message column stating ‘'Validaton of endUserName is required. Similarity of EnduserName and AccountName is ‘ + Similarity %age’ and also update the Flag [Program Line item Eligible] = ‘NO’

21 ® Copyright 2009 Adobe Systems Incorporated. All rights reserved. Adobe confidential.21 FLOW CONT- Determine Pay Basis  Now we determine the Pay basis for EMEA and other geo(s) based on below condition:  If Geo =’EMEA” and Account Level = ‘Platinum Certified’ THEN Pay Basis = ‘INV’  If Geo =’EMEA” and Account Level <> ‘Platinum Certified’ THEN Pay Basis = ‘ESP’  If Geo Not in (‘EMEA’, ‘Americas’) THEN Pay Basis = ‘INV’  Next we Fuzzy match SoldToPartyName and ResellerName with PartnerName from SFDC ( for 90 % similarity) for geo =’ Americas ‘ and Partner Role not equal to ‘Sourcing Only’. We update the Pay basis based on below logic:  If PartnerName matches with SoldToPartyName and ResellerName Then Pay Basis = ‘INV’ else

22 ® Copyright 2009 Adobe Systems Incorporated. All rights reserved. Adobe confidential.22 FLOW CONT-Pay basis  If Only PartnerName matches with SoltoPartyName Then Pay Basis = ‘INV’ else  If Only PartnerName matches with ResellerName Then Pay Basis = ‘ESP’  We Update the Eligible revenue and Eligible Total based on Pay basis  If Pay Basis = ‘INV’ Then Eligible Revenue = InvoiceValue(USD)  If Pay Basis = ‘ESP The Eligible Revenue = ESP.  Eligible total = Sum(Eligible Revenue) grouped at Deal RegId level.

23 ® Copyright 2009 Adobe Systems Incorporated. All rights reserved. Adobe confidential.23 Pay Flow- Threshold  Next we compare the Eligible total against the Threshold amount column present in the DR_Eligible_Lkp table and assign the matched row threshold ID to the [Thres Id] column of DR_Process table.  If Eligible Total doesn’t match the we Flag the message in the message column stating ‘Threshold was not met’ and also update the Flag [Program Line item Eligible] = ‘NO’.

24 ® Copyright 2009 Adobe Systems Incorporated. All rights reserved. Adobe confidential.24 Update Rules and compare against deal  We update the below columns for DR_Eligible_Lkp table based on below logic:  UPDATE DP  SET DP.[Thresh ID] = DEL.Threshold_ID,  DP.PayCode = DEL.Pay_Code,  DP.[Std Percent] = DEL.Payout_Percentage,  DP.[Eligible Points] = DEL.Points,  DP.[Days Expire] = DEL.Days_To_Expire,  DP.[Partner Country]= DEL.Country,  DP.Tier = DEL.Tier,  DP.[Pay Type] = DEL.Pay_Type,  DP.[Pay Basis Multiplier] = DEL.Note,

25 ® Copyright 2009 Adobe Systems Incorporated. All rights reserved. Adobe confidential.25 Update Rules and compare against deal-cont  DP.[Payout Flat Rate] = DEL.Payout_Flat_Rate  FROM DR_Process DP  LEFT JOIN DR_Eligible_Lkp DEL ON DP.[Eligibility Code] = DEL.Eligible_Code  AND DEL.Threshold_ID = DP.[Thresh ID]  AND DEL.Pay_Basis = DP.[Pay Basis (INV, ESP, ACV)]  AND DEL.Program = DP.[Program Name]  AND DEL.Product_Group = DP.[Outlook Product Grp]  AND DEL.Major_License_Program = DP.[Major Licensing Program]  AND DEL.Major_Product_Config = DP.[Major Product Configuration]  AND DEL.Super_Config = DP.[Super Product config]  AND DEL.Partner_Role = DP.[Partner Role]

26 ® Copyright 2009 Adobe Systems Incorporated. All rights reserved. Adobe confidential.26 Update Rules and compare against deal-cont  Next we check for eligibility date criteria based on below condition:  DP.[Claim Date] <= [Order Date] + 60  If above condition are not met then we flag a message in the message column stating  ‘Deal is outside eligible claiming period'  AND DP.[Submit Date] < [Order Date]  AND [Order Date] < [Expiration Date)  If above condition are not met then we flag a message in the message column stating  'Order date is prior to submit date' and also update the Flag [Program Line item Eligible] = ‘NO’

27 ® Copyright 2009 Adobe Systems Incorporated. All rights reserved. Adobe confidential.27


Download ppt "White Master Replace with a graphic 5.5” Tall & 4.3” Wide Copyright 2009 Adobe Systems Incorporated. All rights reserved. Adobe confidential.1 Deal Registration."

Similar presentations


Ads by Google