[Work_Item] Prevent double-counting list/contracted cost for commitment discounts

[flanakin]

Problem Statement

When calculating savings, you need to compare the sum of ListCost or ContractedCost with the sum of EffectiveCost. When doing that, commitment discount purchase costs are double counted because both the purchase and usage records have a ListCost and ContractedCost.

Objective

Practitioners have a simple method to calculate savings that doesn't accidentally double-count commitment discount purchase costs.

Supporting Documentation

This example demonstrates a commitment discount that gets 50% off list price when the organization has an 20% discount on all usage.

ChargeDescription	ChargePeriodStart	ListCost	ContractedCost	BilledCost	EffectiveCost
Reservation	Jan 1	$365.00	$365.00	$365.00	$0.00
VM usage	Jan 1	$2.00	$1.80	$0.00	$1.00
VM usage	Jan 2	$2.00	$1.80	$0.00	$1.00
VM usage	...	...	...	...	...
VM usage	Dec 31	$2.00	$1.80	$0.00	$1.00
Sum of 365 days	Jan 1-Dec 31	$1,095.00	$1,022.00	$365	$365

Proposed Solution / Approach

Some options:

1. Cut: Split ListCost and ContractedCost into separate columns for actual and amortized cost.
2. Add another column that identifies amortizable costs to make them easier to filter out.

One proposal for option 2:

AmortizationCategory column with values of:

• Principal – Original charge that gets amortized over time (e.g., commitment discount purchases).
• Amortized Charge – Rows that are a breakdown of the principal payment (e.g., commitment discount usage).

I avoided the words "purchase" and "usage" here since we could have purchases amortized down to recurring purchases in the future.

Epic or Theme Association

Savings calculation

Stakeholders

No response

[cnharris10]

2. Add another column that identifies amortizable costs to make them easier to filter out.

Doesn't PricingCategory already do this? Purchases and on-demand usage are Standard and amortized costs are Committed?

[kk09v]

At a minimum, we need to update the Use Case Library because these queries don't use PricingCategory

• Determine Effective Savings Rate by Service
• Determine Effective Savings Rate

[flanakin]

2. Add another column that identifies amortizable costs to make them easier to filter out.

Doesn't PricingCategory already do this? Purchases and on-demand usage are Standard and amortized costs are Committed?

Technically, someone can amortized a standard purchase. In that case, it's not.

Regardless, I do feel this is more complex and error prone than it should be. We should have a usable design where the default behavior leads to accurate summaries. We need to a out the "you're holding it wrong" response.

[jpradocueva]

Summary from the Maintainers' all on Nov 25

Context:
This work item addresses concerns about potential double-counting of costs in the presence of commitment discounts, aiming to provide robust guidance for accurate cost calculation.
Maintainers Assigned:
Michael, Riley
Task Force Assigned:
Task Force 1 (TF1).

[flanakin]

Here's a proposed approach to how we address this:

1. Review design principles to see if it accounts for usability of aggregations
2. Brainstorm options in an offline meeting -- invite as broad of an audience as possible -- Some ideas might include:
3. Run a survey for 1-2 weeks with a broad audience
4. Make the spec/doc changes based on the findings

[flanakin]

Options we brainstormed during the tail-end of a the TF1 call:

1. Better documentation outside the spec with no spec change (e.g., use case library)
   • NOTE: This isn't an option because we need to update cost/quantity columns to account for all amortized purchases
   • Pros:
     • No spec change
   • Cons:
     • No way to require providers to document their amortization scenarios
     • Requires practitioners to know (without documentation) which charges are amortized in order to craft a query
     • Practitioners will still run into the double-counting issue (and will likely not know they're seeing it)
2. Column description changes only in the spec
   • Pros:
     • No spec change
   • Cons:
     • No way to require providers to document their amortization scenarios
     • Requires practitioners to know (without documentation) which charges are amortized in order to craft a query
     • Practitioners will still run into the double-counting issue (and will likely not know they're seeing it)
3. Add provider documentation requirement to the spec
   • Pros:
     • Explicitly documents scenarios where charges are being amortized
   • Cons:
     • Requires practitioners to review provider docs in order to craft a query
     • Practitioners will still run into the double-counting issue (and will likely not know they're seeing it)
4. Add a column to identify amortized purchases
   • Pros:
     • Explicitly calls out what charges ListCost and ContractedCost
   • Cons:
     • Practitioners may still run into the double-counting issue (and will likely not know they're seeing it)
5. Don't specify ListCost or ContractedCost for anything that is amortized
   • Pros:
     • Avoids practitioners from running into the double-counting problem ever
   • Cons:
     • Breaking change
     • Requires practitioners to use native datasets to calculate negotiated savings from amortized purchases
6. Split ListCost and ContractedCost columns into billed and amortized variants
   • Options:
     1. BREAKING: ListCost, ContractedCost, EffectiveListCost, EffectiveContractedCost
     2. BREAKING: BilledListCost, BilledContractedCost, EffectiveListCost, EffectiveContractedCost
     3. ListCost, ContractedCost, BilledListCost, BilledContractedCost, EffectiveListCost, EffectiveContractedCost
   • Pros:
     • Avoids practitioners from running into the double-counting problem ever
   • Cons:
     • May be a breaking change
     • Adds complexity with 2 new columns to differentiate billed and amortized versions of list/contracted cost

[jpradocueva]

Action Items from the Members' call on December 5:

• [#647] Volunteers: Propose clear definitions for list costs and contracted costs, ensuring consistency across providers.
• [#647] Volunteers: Document specific scenarios where double-counting occurs for inclusion in the resolution process.
• [#647] Irena @ijurica : Review dependencies on normative requirement updates under [Work_Item] Augment support for correction handling #556 to ensure alignment.
• [#647] All members: Review and provide feedback on backward compatibility principles to inform the resolution of [Work_Item] Prevent double-counting list/contracted cost for commitment discounts #647.

[jpradocueva]

Action Items from the Maintainers' call on Jan 6:

• [[Work_Item] Prevent double-counting list/contracted cost for commitment discounts #647] TF1 Team - Prioritize discussion on this issue in an upcoming meeting to determine a clear path forward.

[shawnalpay]

Per discussion in Jan 14 TF1:

1. Better documentation outside the spec with no spec change (e.g., use case library)
   Not deemed feasible
2. Column description changes only in the spec
   Possible option
3. Add provider documentation requirement to the spec
   Not deemed feasible
4. Add a column to identify amortized purchases (e.g. the original charge that gets amortized (principal); the amortization of that original charge; things that are not amortized; potentially a fourth state that covers an amortized principal?)
   Possible option
5. Don't specify ListCost or ContractedCost for anything that is amortized
   Not deemed feasible
6. Split ListCost and ContractedCost columns into billed and amortized variants
   Not deemed feasible

Definitely need to add a use case to the library with a query that makes it clear how to avoid double-counting amortizations
Chris: what's the use case query with a new column vs without a new column?

[flanakin]

FYI - I'm syncing with @JGrubb to possibly pick this one up.

[JGrubb]

I still like the option of just zeroing out the affected columns - listCost and contractedCost - for these line items that are amortized into other line items, however I fully believe y'all that you've workshopped this out and it's not feasible.

In that case:

Assuming my understanding is correct, the desired API to work around this problem of double counting would be something like

sumIf(listCost, isAmortized IS NOT FALSE)

and this proposed column is just a simple boolean? It would only appear on the the initial RI or other upfront purchases?

[flanakin]

@JGrubb The main downside of that is practitioners would lose visibility into the negotiated savings on amortized purchases.

But, yes, that's the basic idea. We've avoided Boolean columns so far. That's an option, tho.