Rebates Configuration - Lab 2

Lab Info

Lesson	Rebates
Category / Topic / Level	Pricefx Core / Rebates / CFG 2
Target Audience	Certified Configuration Engineer
Estimated Time to complete	0:45

Learning Outcomes

At the end of the Lab, you should be able to:

Create a logic, which will create the Rebate Records for the Agreement Line Item.
Create a logic, which will recalculate the results (like accruals or rebate estimations) on the Rebate Record.
Setup the mapping from the Rebate Record calculation results to its "attribute" columns for easier/faster usage of those numbers later.
Setup a scheduled job, which will periodically recalculate the Rebate Record results, so that the business people have the results available often for analysis.

Figure 1. Sneakpeek to the page with list of Rebate Records with relalculated results (in their attribute columns)

Pre-requisites

In order to be able to complete this laboratory exercise, please complete the prerequisites before you proceed.

Labs

This lab expects, that you already have in your partition a solution of the preceding labs:

Rebate Manager Configuration - Lab 1

Provided resources

Review the provided resources, to get familiar with their content

Provided partition with pre-configured

Product master data table
Customer master data table
Datamart "Transactions"

Requirement Broad Overview

This exercise focuses only on certain part of the Rebate Configuration process. The parts marked with "[OOS]" (Out Of Scope) are not covered in this exercise and are mentioned only for completeness to give you broader context.

This is a broad requirement, which gives you solid outline of the story behind all the Rebates configuration/implementation labs.

The customer needs to be able to manage their rebates in Pricefx to be able to reward their customers for performance. The process has several phases:

Phase 1: Prepare Rebate Agreement

Sales Manager needs to negotiate the Rebate Agreement – to capture the negotiated parameters/conditions.
The system generates the Rebate Records to be used for regular recalculations during the year.

Phase 2: Regular actions during the year

Payout (Rebate Records) calculations – to capture the current state of the rebates and to get better estimations.
Prepare the Rebate Record for Export and for Allocation
Rebate Allocation (of the Rebate Records created from approved Rebate Agreements) – every time new data is loaded into transactions.
[OOS] Sales Managers review the report on customer rebates.
1. During the year they want to be able to see the updates of the estimated rebates per customer (targets, payouts) to be able to discuss with the customer when they’re not compliant.
[OOS] Rebate Records (aka "Payouts") approvals
[OOS] Export of approved Rebate Records (or Payout Records).

Phase 3: After a year

[OOS] Payouts approval of the yearly payouts.
Final allocation of the approved rebates.
[OOS] Export of approved payouts (Rebate Records).
[OOS] Review of last year rebates impact.
1. For analytics purposes, they need to see the actual rebate paid to the customer reflected/allocated in the transactions (to track the effectiveness, to see the real margin).

Important Assumptions for this Exercise

You are working on a given testing transactions dataset which has data for several past years, but also future years. (Remember, in a regular project you would have transactional data only until the present day.) Of course for testing, you need to somehow simulate the state of having certain partial dataset (i.e. until "today") in the Datamart. To handle this, use the Calculation Date as indication of "today" – i.e. in your calculation logic you will pretend that there’s nothing in the Datamart after that date. You do not want to physically remove this data from Datamart because you will need to test calculations simulating different calculation dates.
Whenever the instructions mention "today", use the Calculation/Target date for the actual calculations.

User Story / Requirements for Phase 2: Rebate Record creation and calculations

As a Pricing Manager I want to create Rebate Records based on rebate agreement and setup recalculation of Rebate Records so I can easily check rebate calculation results for all agreed payment periods.

Acceptance Criteria

When a rebate agreement is created, the rebate logic will generate rebate records based on the payment periods (in this exercise there’s only 1 payment period).
The Rebate Calculation job "RR_Calculation" is scheduled to run the calculation. This job runs every night.

User Story Details

The sales team needs the system to periodically recalculate the rebate record payment numbers to understand the current state of the rebates. The payment calculations should happen automatically every day in the night, so that the users can easily review the current state during the day.

Acceptance Criteria Details

The Rebate Records are created - based on the payment periods (1 period only in this case) - each time the Rebate Agreement is recalculated & saved.
The Pricing Manager can recalculate the Rebate Record manually on the Rebate Record detail screen and he gets correct actual numbers.
The scheduled Rebate Recalculation is set up:
- To run every morning at 1 am.
- Target Date = 2020-08-01
Upon recalculation of the Rebate Record (either manual or scheduled), the system calculates the actual/current numbers for:
- Actual Sales - i.e. how much money (invoice price in EUR) the customer already spent with us from the beginning of the RR until today (calculation date) or until the RR end date – use the sooner one.
- Actual Rebate - based on the Actual Sales or the RR and the negotiated Rebate Percentage.
- Sales Forecast – how much money will the customer spend during the validity of the RR. Use the information about
  - Actual Sales,
  - how many days are included in the Actual Sales,
  - and what is the duration of the RR.
- Rebate Forecast – based on the Sales Forecast and Rebate Percentage

Implementation Steps for Phase 2: Create and recalculate Rebate Records

Generate Rebate Records

Once the Rebate Agreement is approved, you will not be able to change it. But during the validity period of the agreement (usually a year) we need to recalculate the Actual Sales and Forecasted Sales many times, so we need an object, which we’re able to repetitively recalculate and store the calculation results – the Rebate Record.

The Rebate Records are created by the Rebate Agreement Line logic.
one Line creates/has one or more Rebate Records - they usually represent more payment periods, when the rebate of the line should be paid e.g. quarterly. In such case, it can be implemented in the way, that one Line creates 4 RRs, where each RR has different validity period (i.e. different startDate and endDate).

The Rebate Line Logic has additional binding variable available

rebateRecords	binding variable available in the Rebate Agreement [line] logic. This object has method add() which you use to add new Rebate Records to the line item. You can generate more Rebate Records for every line item, e.g. if you have more Payout periods during the validity of the agreement (e.g. during the year).
rebateRecords.add()	this function call adds one Rebate Record with all many out-of-the-box field values copied from the line item. In our case here, we need only the default fields populated, so we will not set anything special, but if you need more Rebate Records for one line item, you can also supply the argument, and override as many fields as you need.

Generate a Rebate Record
1. Edit your Rebate Logic BonusOnSales
2. Create a new Element named "RebateRecords"
  Example 1. Code of Element "RebateRecords"
```
rebateRecords.add(
    /* use parameters if need to make a record with different validity */
    //  startDate: "2020-01-01",
    //  endDate:  "2020-03-31",
    //  payoutDate:  "2020-04-15",
)

/* for testing purposes, you can show the link to the screen with RRs of this Line Item */
//  return rebateRecords.asLink()
```
  1. set Calculation Context to "Agreement"
    you can generate the Rebate Record only in the phase/context of recalculation of the Rebate Agreement, not in any other time, so it’s important to set the “Calculation Context” of such element to “Agreement”.
  2. set Display Mode to "Never"
Test the logic in Studio (the same way as in Rebate Manager Lab1)
Deploy the logic to the partition
To generate the Rebate Records:
1. Open your saved Rebate Agreement (at screen RebateManager → Rebate Agreements)
2. Recalculate the Agreement – because of the change in logic, it will generate the Rebate Record(s). Note: they’re not saved yet.
3. Save the Agreement, it will cause:
  1. the Rebate Record(s) will be stored to database
  2. the new Rebate Record Set named "Default" will be created
    as you create the RR the 1^st time and by default the name of the Rebate Record Set (that’s one of the RR’s field) is set to "Default", the system creates a new Rebate Record Set, named "Default". The user interface might not be aware of this new RRS, so it could be needed to reload the UI in a browser.
Navigate to Rebates → Rebate Records. Rebate Records appear on the screen.
Figure 2. Screen with list of Rebate Records (which belong to the "Default" Set of records.)
1. Review all the columns of the generated Rebate Records. You should find a lot of out-of-the-box columns automatically pre-populated with values from your agreement line item.
Review the detail of the Rebate Record
1. when you click on the ID of the Rebate Record, it opens a detail screen for the Rebate Record
  Figure 3. Screen with detail of one Rebate Record
2. review the following sections on the screen:
  - Agreement Terms - a copy of the input fields from the RA Line Item and RA Header
  - Inputs - optionally, the Rebate Record can also have its own input parameters. There’s no input field defined on the RR itself (i.e. defined by the RR’s logic)
  - Results - calculated results of the RR. There’s no result yet, as you’ve never re-calculated this new Rebate Record.
3. review the buttons:
  - Calculate – to recalculate the Rebate Record right now (using the logic and target date mentioned at the top of the screen). This is also really useful for testing purposes.
    - Remember, here the logic is executed in the context of Rebate Record
  - Save – to save the new results
  - View Workflow – the Rebate Record can have its own Workflow (usually to approve the rebate money to be paid to the customer)
4. click on the button Calculate and observe if there’s any change - did anything change in the Results section? Why?

Calculation of Rebate Record - Regular actions during the year

Business Motivation

During the validity of the Rebate Agreement, the business would like to know the actual accruals, how much rebate we need to pay to the customer based on the actual sales until now.

So we would like to regularly recalculate the rebate size, based on the new transactional data (sales records) uploaded to the Datamart.

Technical details of the Rebate Record logic

Rebate record is a standalone object, so you would expect it to have its own logic type, but because many of the calculations needed to be done on it are the same as for the Rebate Agreement Line item, most of the Rebate Record logic and Rebate Agreement Line logic would use the same code.

That’s why there’s only one logic for both – Rebate Agreement Line and the Rebate Record.

Of course, sometimes there’s a need to have a code specific only for either RALI or RR. In that case, the logic element must have the “Calculation Context” property set:

Agreement - code of the element will be executed when the logic is used to calculate the RA Line
Rebate Record - code of the element will be executed when the logic is used to calculate the RR
Agreement Read-only - code of the element will be executed when the logic is used to calculate the RA Line on Approved Agreement.
[nothing] - when NO Calculation Context is crossed, it behaves the same as if ALL Calculation Contexts are selected for the Element.

Proceed with the following steps:

Modify your rebate logic “BonusOnSales”
1. Create an element “ActualRebate”, to calculate the Actual Rebate.
  Example 2. Code of Element "ActualRebate"
```
if (out.ActualSales != null && out.RebatePct != null) {
    return out.ActualSales * out.RebatePct
}
```
  1. Ensure the result of the element will be visible.
  2. Keep the Calculation Context empty
    This result could be interesting also on the Agreement itself, because we’re negotiating the agreement already during the beginning of the validity year. So let’s keep the "Calculation Context" empty for this element, to be able to use it also in the Agreement
2. Test the logic, if works ok and verify the correctness of the calculated result numbers
3. Deploy the logic to the partition
Open detail of your Rebate Record:
1. Navigate to Rebates → Rebate Records.
2. A screen with list of Rebate Records appears.
3. Click on the ID (it looks like link) of your Rebate Record created before, to open the detail of the Rebate Record.
  Figure 4. Screen with detail of a Rebate Record, which was not yet calculated.
Recalculate the Rebate Record:
1. Click on the Calculate button
2. the Rebate logic will be executed (in the context of Rebate Record)
3. results will be displayed in the Results section
  Figure 5. Detail of one Rebate Record with Results calculated after click on Calculate button.
Experiment with the Target Date modification and always recalculate the record, to see the impact on Actual Sales and Rebate.
remember, we’re using the Target Date to simulate the Today, so by changing the TargetDate you can simulate how the rebate will change during the validity period of the agreement (e.g. during the year). Also, we already have all the Transactional data in the Datamart for the whole year of agreement validity, which is not possible in the real world scenario.
Save the Rebate Record
To close this detail screen, you can either use the navigation menu, or you can also use the "breadcrumb" navigation in the left top corner.

Schedule the automated recalculations of the Rebate Records

Prepare the scheduled job
1. Navigate to Rebates → Calculations
  Figure 6. List of the Rebate Calculation jobs, which regularly recalculate the Rebate Records
  1. (if there’s no "Default" process available in the list on the left side, then click on the "Add" button to add one, with Label "Default" and Set "Default")+
2. Click on the "Default" calculation, to see the detail of the calculation process
  Figure 7. "Default" Rebate Calculation job without any scheduling
  Notice the are 3 sections:
  - Schedule - to setup when the recalculations should run
  - Rebate Records - list of Rebate Records to be recalculated
  - Calculation - optional to set details for the calculation process
3. In the "OPTIONS" section:
  1. Un-tick the "Incremental"
4. In the "Schedule" section, add the schedule for automatic recalculations:
  1. click on "Add Task"
  2. set the Start Date from tomorrow
  3. set the Period to be a DAY
  4. set Interval to 1
  5. the Name is optional, for users to recognize the reason behind this specific schedule
    Figure 8. Set the scheduling of the recalculation process.
5. In the “Rebate Records” section, select (by a filter) which Rebate Records should be recalculated.
  Remember, there can be more Records created during the validity of the agreement (e.g. during the year), that’s why the filter must be generic - i.e. not selecting particular Rebate Records IDs - but rather something like date range or similar.
  Figure 9. Setup the filter, to say which Rebate Records you want to recalculate by this job.
6. Select specific Calculation settings for recalculation your Rebate Records. Nothing is mandatory in the "Calculation" section, but for this exercise we will setup the "Target Date"
  Remember: we’re using here the “Target Date” to simulate “Today”.
  Figure 10. Setup (optionally) the calculation logic and parameters for the Calculation process.
7. Save the scheduled Calculation.
Verify, if the scheduled job runs correctly.
1. Click on “Run Calculation” to execute manually, to test the calculation.
2. Then, after a while, use the Refresh button (in the "Job/Task Tracking" table below the Schedule) to verify, that the process finished successfully – i.e. with “Ready” state.
  Figure 11. The button Run Calculation will start the Job/Task. The section "Job/Task" Tracking show the status of it.
Rename the Label to "RR_Calculations" and Save the Job.

Store the RR’s calculated results also to its attributes

The calculation results of the Rebate Record (RR) are stored in a field (in a map data structure) named "calculationResults", nevertheless for further processing of those records (like Export, Allocation, or Dashboards) we need the values directly stored in the attributes fields of the RR.

Every RR has 100 "attribute" fields, which you can use for such purposes. You only need to set the mapping between the calculated results and the attribute fields. The mapping is given only by a naming convention.

Once you setup the mapping, then when the RR is saved, it will map the calculationResults into the attributes columns.

Setup the Mapping of calculated result ActualSales and ActualRebate to the attribute columns
1. Navigate to Rebates > Rebate Records
2. Make the fields the attribute1 and attribute2 columns
  Figure 12. The columns attribute1 and 2 will be used to store the values of ActualSales and ActualRebate
3. Use "Rename and Customize" to change the name of "attribute1" column to "ActualSales"
  - When setting the “Name” of the attribute column - it must exactly match the name of the calculated result, in order to be mapped automatically (and the name of the calculated result came up from the name of the logic element used to calculate the result). Remember, the logic element must have “Display Mode” set to “Everywhere”, otherwise its result value will not be mapped.
  - Set the “Type” of the column to “Real”.
  - Optionally (as it’s useful only for viewer, but not for the process which reads the data of the column), you can set “Format Type” to “Money”.
4. Use "Rename and Customize" to change the name of "attribute2" column to "ActualRebate"
  - apply the same rules as for the previous one
Reload the browser window, so that the UI reloads the new metadata settings properly
Verify the Mapping
1. Recalculate the Rebate Record
  1. Navigate to RebateManager → Rebate Records
  2. Click on the ID (the link) of your Rebate Record to open the detail of it
  3. Recalculate the Rebate record results - click the "Calculate" button. This is just to be sure, you have the Results available, in case you haven’t saved the calculated results already before.
    Figure 13. Save the Results of the Rebate Record to copy the Results to the attribute columns
2. Perform the mapping
  1. once you click on the "Save" button, the system will take the results and map them to the attribute columns.
3. Verify the values of columns “attribute1” and “attribute2” of the Rebate Record
  1. Navigate to RebateManager → Rebate Records
  2. Refresh the list
  3. Review the content of columns attribute1 and attribute2 columns (now called ActualSales and ActualRebate). Verify, if the numbers are correct (i.e. only from first 3 months of 2020). Your numbers can be different that on the screenshot, so ensure you know, what numbers you should expect.
    Remember: you can quickly summarize data in DataMart using the built-in DataTable tool under PriceAnalyzer → Data Analyzer → Data Table.
    Figure 14. Rebate Record with calculation results mapped to the attribute columns