24 lines
1.6 KiB
Markdown
24 lines
1.6 KiB
Markdown
|
# Data Requirements for New Dash/New Pricing
|
|||
|
|
|
|||
|
|
# Revenue reporting
|
|||
|
|
|
|||
|
|
We need to report revenue at different aggregation levels. For that, we need a source of truth on billing at service level. This should be append-only, and record any change on the applied services over time, so we can replicate the exact reality of a service applied in any point in time.
|
|||
|
|
|
|||
|
|
After the new release, we need confirmation that:
|
|||
|
|
|
|||
|
|
1. `ProductServiceBillingItem` and `ProductProtectionPlanBillingItem` are the go-to tables for the source of truth
|
|||
|
|
2. That the abovementioned tables will contain future and any historical record that needs to be charged for data completeness
|
|||
|
|
3. That the abovementioned tables are append-only, despite having an `UpdatedDate` field.
|
|||
|
|
4. That the abovementioned tables will reflect any change by adding a negative line that removes previous lines if a change needs to be applied in a Billing Item (and perhaps even a reference to what is getting cancelled out?)
|
|||
|
|
|
|||
|
|
# Excluding test users
|
|||
|
|
|
|||
|
|
All real users should have a Deal ID. All fake/test/demo/etc users should NOT have a Deal Id.
|
|||
|
|
|
|||
|
|
We cannot exclude them until the above conditions are filled, once it’s done, we will exclude all users that do not have a Deal Id.
|
|||
|
|
|
|||
|
|
We need to be notified once this change is in place to modify the code in Data to reflect the users exclusion accordingly.
|
|||
|
|
|
|||
|
|
# Backfill BookingViewToService with the missing Ids
|
|||
|
|
|
|||
|
|
For some historical cases on `BookingViewToService` that affect Basic Screening service we do not have the `ProtectionPlanId` nor the `ProductServiceId`. In order to guarantee consistency in DWH, having these filled would simplify our work and allow to do some proper data tests.
|