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