Inheritance¶
What is inheritance?¶
In several domains, inheritance is used to pass information, assets, etc from parent to child. For example, a puppy will inherit a parent’s genetic makeup, like fur or eye color. In the context of configuration, children will inherit the rules of their parent. Packaging is the parent and the products are the children. Attributes of a pricebook are the default value for each product pricing combination. This can be seen in the Wikipedia example where invoice_delivery and invoice_schedule are not specified for some prices. These prices aren’t without values, instead these fields inherit the pricebook value for the same columns: ARREARS and 1 respectively.
id |
durable_id |
name |
billing_target |
invoice_delivery |
invoice_schedule |
created_at |
|---|---|---|---|---|---|---|
1 |
a |
Standard |
ARREARS |
1 |
2023-11-01 |
list_prices.id |
products.id |
products.name |
list_prices.price |
list_prices.invoice_delivery |
list_prices.invoice_schedule |
list_prices.pricebook_uid |
list_prices.created_at |
|---|---|---|---|---|---|---|---|
1 |
1 |
Updates |
0.10 |
1 |
2023-11-01 |
||
2 |
2 |
Creates |
0.05 |
1 |
2023-11-01 |
||
3 |
3 |
Platform fee |
1000.00 |
ADVANCED |
12 |
1 |
2023-11-01 |
Why is inheritance important?¶
In order to keep up with the demands of a growing enterprise, methods to reduce manual configuration are required. The goal is to reduce overhead as much as possible. Inheritance is one of the tools that can be used to accomplish this. Instead of setting a value on every object, it can be set once on the parent and inherited automatically. The fewer moving pieces in a business model the easier it is to maintain.
Below is what it would look like if we specified every single product in the example above. While this is manageable with three products, this can become burdensome as a product catalog grows. Specificity is important but it has a cost. This is a tradeoff that needs to be made with care.
id |
durable_id |
name |
billing_target |
invoice_delivery |
invoice_schedule |
created_at |
|---|---|---|---|---|---|---|
1 |
a |
Standard |
ARREARS |
1 |
2023-11-01 |
list_prices.id |
products.id |
products.name |
list_prices.price |
list_prices.invoice_delivery |
list_prices.invoice_schedule |
list_prices.pricebook_uid |
list_prices.created_at |
|---|---|---|---|---|---|---|---|
1 |
1 |
Updates |
0.10 |
ARREARS |
1 |
1 |
2023-11-01 |
2 |
2 |
Creates |
0.05 |
ARREARS |
1 |
1 |
2023-11-01 |
3 |
3 |
Platform fee |
1000.00 |
ADVANCED |
12 |
1 |
2023-11-01 |
How is inheritance modeled?¶
Inheritance automatically occurs when a higher specificity field has a value within it. The order of operations for inheritance is as follows:
Pricebooks < Contracts < List prices < Contract prices
When a value is populated in a field with a more specific context it overrides the higher level value. The rest of this section describes several of the overrides available within configuration.
Invoice schedule and delivery¶
Varying delivery and schedules are useful for different types of products. While these aren’t always paired together it is a common combination. Professional services, platform fees and other types of products occur upfront and may not share the same cadence with other products. Usage based products specifically need to be measured in arrears, since they are based on consumption, and having dual delivery and cadences can provide that flexibility.
The canonical Wikipedia case study uses an override on these two fields. Specifically the platform fee is modeled on an annual basis with an advanced delivery, while the top level pricebook is invoiced in arrears on a monthly basis.
Period start and end¶
If desired, a specific product can override the start and end period. This can be useful when a specific product will always have a time frame associated with it, like a trial feature. Since configurations don’t have specific dates associated with them all calculations use standard date units (months) and are anchored to the start of the contract.
Overriding start and end periods at the product level can allow for varying prices over time. For each period, a new set of pricing can be specified, allowing for trials, price ramps and recurring professional services. While powerful, this method can complicate the data modeling for the pricebook. Alternatively, multiple pricebooks can be created to model a similar invoicing schedule. Ultimately, it’s up to the practitioner to decide on the right path.
The example below has a free trial for usage based charges for the first two periods and normal pricing otherwise. In this case, the service fee is not a part of the free trial. One thing to note is that the end_period is exclusive and the start_period is inclusive, additionally the units are zero-indexed. So within this example a start_period of 0 indicates from month 1 up to the end_period, which is month 3.
products.id |
products.name |
list_prices.id |
list_prices.price |
list_prices.start_period |
list_prices.end_period |
pricebooks.durable_id |
pricebooks.name |
invoice_delivery |
invoice_schedule |
list_prices.created_at |
|---|---|---|---|---|---|---|---|---|---|---|
1 |
Updates |
14 |
0.00 |
0 |
2 |
h |
Standard (+ trial) |
ARREARS |
1 |
2023-11-01 |
1 |
Updates |
16 |
0.10 |
2 |
12 |
h |
Standard (+ trial) |
ARREARS |
1 |
2023-11-01 |
2 |
Creates |
15 |
0.00 |
0 |
2 |
h |
Standard (+ trial) |
ARREARS |
1 |
2023-11-01 |
2 |
Creates |
17 |
0.05 |
2 |
12 |
h |
Standard (+ trial) |
ARREARS |
1 |
2023-11-01 |
3 |
Platform fee |
18 |
1000.00 |
h |
Standard (+ trial) |
ADVANCED |
12 |
2023-11-01 |