🛠️ Potential Solutions

Enhance the process by incorporating additional details regarding transactions and include pre-calculated mathematical formulas.

Figma: https://www.figma.com/design/Ti8Qr6jeSEPaencIDyYfcJ/branch/TUewzfszNkgUDFemwkpmwV/Burger-King?node-id=1828-36267&t=jxqIxrDss4fghjtP-0

✅ Proposed Solution

A proposed solution we will add new fields and mathematical calculates in the system to give this information to customer user agent.
Example:

This form provides the agent with more detailed information; therefore, we need to modify certain parts of the code.

Acceptance Criteria

1 - Display of Information on Screens

• Given that the user accesses the Loyalty Transactions, Orders, and Recent Orders screens,

• When the transactions are loaded,

• Then the system should display the following information in order:

  • Initial Points

  • Points Earned (regular points and bonus points)

  • Points Used (displayed as a negative value, e.g., “-60”)

  • Transaction Points (points earned minus points used)

  • User's Final Points in that order.

2 - Display of Orders and Status

• Given that the support user accesses the orders screen and understands the meaning of each status,

• When the screen is loaded,

• Then all orders should be displayed, including all relevant statuses:

  • Claimed: Success status where points are credited or debited.

  • Confirmed: Order completed but not finalized (e.g., delivery not completed), where the points do not impact the user's total.

  • Void: Canceled order where the points do not impact the user's total.

3 - Feature Flag

• Given that there is new data to be displayed,

• When the feature flag is activated,

• Then the new data should be displayed in the user interface.

• And when the feature flag is deactivated, the new data should be hidden.

4 - Points Calculation

• Given that the points received, used, bonus, and final points are derived from the loyalty system,

• When the transactions are processed,

• Then no changes should be made to the existing calculations.

• And we will not be responsible for correcting and/or altering loyalty rules.

Development

Backend:

transactionDetails {
  person {
    currentPoints
  }
}

Frontend:

Potential Challenges

💰 Cost

🎛️ Configuration

LaunchDarkly

Create and enable a new feature flag: point-balance-information

Sanity

We need a product to utilize the points, but we are not sure how to configure it yet. However, we can use the existing products. For example, in DEV PLK ES, we can utilize the product [LOYALTY] Menú 8 alitas picantes mediano.
We can configure parameters such as the required points to use this product and the number of times it can be used per day.

Status Order

The order has a status to inform if need to add, remove or ignore the points.

More details here /wiki/spaces/PBP/pages/4856185403

Exist the CONFIRMED status as well, and this status is added for the orders that placed, but not finished, for example, a delivery order is placed, but it's in the delivering progress, not marked as delivered.
In this status the system doesn’t calculate the points.
More details here INMS-763 - Getting issue details... STATUS

We made some questions to loyalty-team in this thread https://rbidigital.slack.com/archives/C04FZ5HTH35/p1723558227000749

📈 Metrics

🗓️ Delivery Plan

🧑‍🚒 QA Plan

Step	Expected Results
If the FF is enable	Show new fields on the screens: Loyalty Transactions Orders Recent Orders
Existing orders with the status CLAIMED	Show the order with earned values, used values, transactions, initial points, and final points. In this status, the calculation must change the user's final points.
Existing orders with the status CONFIRMED	Show the order with earned values, used values, transactions, initial points, and final points. In this status, the calculation must not change the user's final points. After complete delivery this status change to CLAIMED or VOID
Existing orders with the status VOID	Show the order with earned values, used values, transactions, initial points, and final points. In this status, the calculation must not change the user's final points.
If the user has 2 or more order with CONFIRMED	Show the order with earned values, used values, transactions, initial points, and final points. In this status, the calculation must not change the user's final points. After complete delivery this status change to CLAIMED or VOID For each order, the initial and final points are the same because confirmed transactions do not accumulate points.
If the user has 2 or more order with CONFIRMED and change to VOID	Show the order with earned values, used values, transactions, initial points, and final points. In this status, the calculation must not change the user's final points. The order change to VOID and don’t change the final poins
If the user has 2 or more order with CONFIRMED and change to CLAIMED	Show the order with earned values, used values, transactions, initial points, and final points. In this status, the calculation must not change the user's final points. The order change to CLAIMED and change the final poins
If the user has 2 or more order with CONFIRMED and change one to CLAIMED and other to VOID	Show the order with earned values, used values, transactions, initial points, and final points. In this status, the calculation must not change the user's final points. Attetion: If the oldest order is successfully completed (CLAIMED) and the most recent one fails (VOID), the value of the CLAIMED order will impact the final points. However, the VOID order will not impact the points and will retain its initial and final values as outdated, since when an order is marked as VOID, it is not considered.

⚠️ Call-outs