Lab Info

🎯 Learning Outcomes

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

...

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

...

• Product master data table

• Customer master data table

• Datamart "Transactions"

Requirement Broad Overview

...

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

1. Sales Manager needs to negotiate the Rebate Agreement – to capture the negotiated parameters/conditions.

2. The system generates the Rebate Records to be used for regular recalculations during the year.

Phase 2: Regular actions during the year

1. Payout (Rebate Records) calculations – to capture the current state of the rebates and to get better estimations.

2. Prepare the Rebate Record for Export and for Allocation

3. Rebate Allocation (of the Rebate Records created from approved Rebate Agreements) – every time new data is loaded into transactions.

4. [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.

5. [OOS] Rebate Records (aka "Payouts") approvals

6. [OOS] Export of approved Rebate Records (or Payout Records).

Phase 3: After a year

1. [OOS] Payouts approval of the yearly payouts.

2. Final allocation of the approved rebates.

3. [OOS] Export of approved payouts (Rebate Records).

4. [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.

...

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.

...

1. Generate a Rebate Record

   1. Edit your Rebate Logic BonusOnSales

   2. Create a new Element named "RebateRecords"

      Example 1. Code of Element "RebateRecords"

      Code Block
      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"

2. Test the logic in Studio (the same way as in Rebate Manager Lab1)

3. Deploy the logic to the partition

4. To generate the Rebate Records:

   1. Open your saved Rebate Agreement (at screen Rebates → 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.

5. 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.

6. 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.

...

1. Modify your rebate logic “BonusOnSales”

   1. Create an element “ActualRebate”, to calculate the Actual Rebate.

      Example 2. Code of Element "ActualRebate"

      Code Block
      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

2. 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.

3. 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.

4. 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.

5. Save the Rebate Record

6. 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

1. 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.

2. 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.

3. Rename the Label to "RR_Calculations" and Save the Job.

Store

...

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.

...