WI #636: Corrections - Credits - Refunds

[ahullah]

No description provided.

[ijurica]

ChargeClass Correction and corrections to charges in the current/open billing period

ChargeClass Correction is currently defined as a correction to a previously invoiced billing period (e.g., refunds and credit modifications). We are considering the following options:

• Leaving it as-is.
• Expanding the definition of ChargeClass Correction to include corrections to any previous charge, regardless of the billing period status.
• Introducing an additional value to represent corrections to charges in the current/open billing period, with a preference for renaming the existing value for clarity.

Introducing an additional value to capture corrections to charges in the current/open billing period, along with renaming the currently available value, would require changes but is the preferred approach.

• Benefits of Introducing a dedicated ChargeClass Value for current billing period corrections:
  • Improved clarity: Clearly distinguish between regular charges and correction scenarios.
  • Enabled value range specification: Define allowed value ranges for regular charges (per ChargeCategory), while permitting broader ranges (e.g., any valid decimal) for correction charges. The end goal is to specify value ranges for regular charges across all Cost and Quantity metrics (note: Pricing Units are already restricted to non-negative values).

Notes:

• Value range BUGs:
  While value ranges are currently defined for some Cost and Quantity metrics, this is a bug, and we will need to allow any valid decimal value if we decide to leave the ChargeClass definition as-is (to be conducted as part of PR WI #557: Preview - Refinement of FOCUS Columns Normative Requirements #664 ).

• Allowed discrepancies limitations:
  Enabling clearer identification of corrections in the current/open billing period MUST NOT alter the rule limiting discrepancies to previously invoiced periods. This ensures fairness by preventing providers using incremental/decremental charge records (ledger style) from gaining greater flexibility than those who restate charges.

Something to consider:

Regardless of whether we decide to expand the ChargeClass definition, we should consider tightening the rules around allowed discrepancies within Correction Handling, particularly concerning allowed nulls for [Pricing|Consumed|CommitmentDiscount] Units. For example, while the Pricing Unit MAY be null in the case of a correction to a previously invoiced billing period, we should consider allowing this only if the Pricing Quantity is null. In other words, we might specify that:

• PricingUnit MUST be null if PricingQuantity is null.
• PricingUnit MUST NOT be null if PricingQuantity is not null.

---

Current ChargeClass Correction mentions across FOCUS columns

Column Type	Column Name	Allow NULL Discrepancies	Allow C = P * Q Discrepancies	Address Value Ranges (BUG)	Other
Dimension	ChargeCategory				Credit definition
Dimension	ChargeClass				Correction definition
Metric	CommitmentDiscountQuantity	Yes		Yes	-
Dimension	CommitmentDiscountUnit	Yes			-
Metric	ConsumedQuantity	Yes		Yes	-
Dimension	ConsumedUnit	Yes			-
Metric	ContractedCost		Yes		-
Metric	ContractedUnitPrice	Yes	Yes		-
Metric	ListCost		Yes		-
Metric	ListUnitPrice	Yes	Yes		-
Dimension	PricingCategory	Yes			-
Metric	PricingQuantity	Yes	Yes	Yes	-
Dimension	PricingUnit	Yes			-
Dimension	SkuId	Yes			-
Dimension	SkuPriceId	Yes			-

[ahullah]

how much do we care about the month end boundary for defining correction?
what about corrections to non numeric columns do they go through the same process?
do an example where dimension data changes i.e service in wrong az / region (are these always itemized ???)

[rileyjenk]

This is tricky because many vendors have the concept of a credit that fall under the scenario that we are giving either some level of usage for free OR some $ figure free. The specificity here indicates we are only considering an amount of usage. We may have pushback simply from the perspective that we are redefining something fairly well cemented in the market.

[ijurica]

Suggested change

	A positive balance or amount remaining for free/discounted usage of services that is provided independently of other charges.

[ijurica]

AI: Merge definitions from #675 into #636 and remove the glossary term in #675.

Suggested change

<a name="glossary:credit"><b>Credit</b></a>

Current definition in PR #636, based on this definition and an in-meeting discussion

Credit
A financial incentive or allowance granted by provider independently of other charges to offset costs in various scenarios.

[ijurica]

AI: Merge definitions from #675 into #636 and remove the glossary term in #675.

Suggested change

	<a name="glossary:refund"><b>Refund</b></a>
	A return/repayment of funds that have previously been charged.

Current definition in PR #636

Refund:
A return of funds that have previously been charged.

[shawnalpay]

A few things to consider here, applicable to all the tables that follow:

• Need to be consistent on spaces vs no spaces in the column headers. ChargeCategory vs Item Description.
• What FOCUS columns are Volume, Rate, and Cost? We need to use the names of whatever those are.
• Would prefer the rate in the examples to use something other than 1, so that Volume and Cost are different.