[DISCUSSION]: Handling of corrections in the event of USAGE errors

[ahullah]

Description

In discussion it has become clear that we have a specific desired behaviour for how we wish to handle COST corrections over time, however we do NOT have a specific desired behaviour on how we handle USAGE corrections over time. This needs further exploration as the original intent was to ensure that mis-billed services that were corrected after an invoice period has closed would be identified as specific CORRECTION line items in the current BILLING PERIOD and referencing the previous CHARGE PERIOD where the error occurred. This is desirable from a financial transparency perspective. However in the event that an entire service is omitted from a CHARGE PERIOD (i.e a new service launched, and was used but due to a billing engine error no usage records were reported for multiple months) what is the desired behaviour?

Proposed Approach

Current understanding is that it would be beneficial to retrospectively update the USAGE data to show USAGE records on the BILLING & CHARGE PERIODS where the usage was actually incurred. However we would want to preserve the current CORRECTION rules so that CORRECTION COST related data is reported in the current BILLING PERIOD only. i.e if you look back at the historic usage data the actual usage at that point in time will be correct,, however the service will appear to be 'free'. If you look at the COST data however there will be one or more CORRECTION COST records that all are incurred in the most recent BILLING PERIOD, giving you a noticeable cost spike.

GitHub Issue or Reference

No response

Context

Triggered as a result of Chris & Zach's discussion on the members call 1.8.24

Data Submission for Discussion

No response

[jpradocueva]

Action Items from Maintainers call on Aug 5th:

• [Maintainers] Develop a standardized protocol for handling usage corrections.
• [Maintainers] Create a proposal for a new column or format in the specification to document corrections.
• [Maintainers] Review and finalize the proposal in upcoming meetings.

[AWS-ZachErdman]

This looks accurate to me Alex. However, the interesting thing here is that your recommendation really impacts multiple columns - we will need to come up with a way to either describe that (1) here in ChargeClass, (2) in each relevant column, or (3) in an attribute where we describe how corrections should be created.

[ijurica]

Several discussions pointed out that we should introduce a correction handling attribute and define the minimum content that correction records should include.
Generally, up until now we referred to correction records in the normative requirements paragraphs of the costs and quantities columns (Metrics) and accompanying unit columns (Dimensions).
Considering that corrections are expected not only for Usage-related charge records but also for other ChargeCategories, we plan to address multiple use cases (covering all charge categories) and take into account/specify normative requirements for all relevant columns.

I suggest we reference this and any other relevant issues in Issue #556 and close the rest, moving forward with that issue.
It goes without saying that Issue #556 needs to be supplemented with all necessary information, i.e., aligned with the Work Item template requirements.

@shawnalpay @ahullah @AWS-ZachErdman do you agree with the proposed approach?

[shawnalpay]

Closing in favor of #556, which is more inclusive of all values.

[jpradocueva]

TF-2 call on Oct 15:

Topic: #511 Handling corrections in the event of usage errors
Discussion Summary: The conversation focused on how corrections should be handled in charge records, particularly in cases of usage errors. The issue was found to overlap with another broader issue (#556), which covers all charge categories.
Resolution: The team agreed to close issue #511 and link it to #556, which encapsulates the necessary corrections for all charge types. Closing the redundant issue was seen as progress.