FOCUS #314: SKU ID, SKU Price ID and SKU Price Details clarification

[ijurica]

This PR provides clarification on the specifications, purpose, and guidance for the following columns:

• SKU ID,
• SKU Price ID,
• and SKU Price Details,

ensuring a better understanding and consistent usage of these columns across providers.

[flanakin]

This feels like a lot to put into this one requirement. Can we break it into 2?

Suggested change

	* SkuPriceId MUST define a single unit price used for calculating the charge, reflecting a stable grouping of core properties of a SKU Price while excluding fluctuations in dynamic or negotiable properties such as unit price amount, currency, temporal validity (e.g., effective dates), and contract- or negotiation-specific elements.
	* SkuPriceId MUST define a single unit price used for calculating the charge, reflecting a stable grouping of core properties of a SKU Price.
	* SkuPriceId MUST be consistent across dynamic or negotiable properties for a specific provider such as unit price amount, currency, temporal validity (e.g., effective dates), and contract- or negotiation-specific elements (e.g., billing account).

[ijurica]

What about this:

• SkuPriceId MUST NOT reflect (or be influenced/affected by) dynamic or negotiable properties such as unit price amount, currency, temporal validity (e.g., effective dates), and contract- or negotiation-specific elements (e.g., billing account).

[ijurica]

Nit:
Consider 'quantifiable/measurable/trackable' instead of 'billable' since some charges (e.g., committed charges) are not necessarily billable.
I understand that this column does not define what is billable and what is not, so 'billable' is not necessarily incorrect - I just prefer 'quantifiable' 😄

[ijurica]

Consider mentioning that SKUs are priced, tracked, measured, and billed, rather than used or purchased.

We don't directly use or purchase SKUs; rather, we interact with resources and services, while SKUs represent specific elements of those resources and services that are priced, tracked, measured, and eventually billed.

[flanakin]

Suggested change

A SKU ID is a provider-specified unique identifier that represents a specific [*SKU*](#glossary:sku) (e.g., billable good or service offering) that can be used or purchased. Each SKU ID represents specific functionality and technical specifications of a single *SKU* that are common across one or more [*SKU Prices*](#glossary:sku-price). SKU ID is consistent across different billing accounts, pricing models (e.g., flat-rate, tiered, committed, spot pricing), and regions for a single provider to facilitate price comparisons for the same functionality, regardless of where the functionality is provided or how it's paid for.

A SKU ID is a provider-specified unique identifier that represents a specific [*SKU*](#glossary:sku) (e.g., measurable good or service offering) that can be used or purchased. Each SKU ID represents specific functionality and technical specifications of a single *SKU* that are common across one or more [*SKU Prices*](#glossary:sku-price). SKU ID is consistent across different billing accounts, pricing models (e.g., flat-rate, tiered, committed, spot pricing), and regions for a single provider to facilitate price comparisons for the same functionality, regardless of where the functionality is provided or how it's paid for.

[ijurica]

These also apply to both SkuPriceId and SkuPriceDetails, right?

[ijurica]

I prefer this:

A SKU Price ID is a provider-specified unique identifier that represents the core, stable properties of a SKU Price, excluding fluctuations in dynamic or negotiable properties such as unit price amount, currency, temporal validity (e.g., effective dates), and contract- or negotiation-specific elements.

over this:

A SKU Price ID is a unique identifier that defines the unit price used to calculate the charge.

If we proceed in this direction, I’ll need to adjust the rest accordingly, including the normative requirements.
Additionally, we must not forget to update the glossary.