Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Related task:

Jira Legacy
serverSystem JIRA
serverId255417eb-03fa-3e2f-a6ba-05d325fec50d
keyIBFEC-1046

...

Table of Contents

Table of Contents
minLevel1
maxLevel6
include
outlinefalse
indent
exclude
typelist
class
printablefalse

...

Related task:

Jira Legacy
serverSystem JIRA
serverId255417eb-03fa-3e2f-a6ba-05d325fec50d

...

keyIBFEC-1046

Tech refinement related to this discovery: Delivery fee improvement - Technical refinement (WIP)

...

Business problems to be solved

  1. The checkout doesn’t show the savings (from a customer's point of view) as it should be

...

  1. For some use cases when the user is qualified to receive a free delivery fee, we saw a strange UI

  • Here the expected/desired behavior is to show what the user is saving (FREE $0.00 doesn't make sense)

    Image Modified

  1. How can we improve the “Delivery Order Fees” modal to be something that will bring more value to the user?

...

Design proposals

[WIP Augusto Romao, Vinicius - ADD BK/FHS screenshots from what we have today]

Schroer, Gabriel (Deactivated) feel free to add here and organize this part of the doc to your needs.

...

Places where we have the Delivery fee information

PS: click on the images inside the table to open (I don’t want to flood the document). Besides that I forced the other fees and the discount value just to show how they will be on the screen… please, disregard the values.

Page

Evidence

Delivery order confirmation page - Regular fee

Image Added

Delivery order confirmation page - Fee with discount

** I force in code to show all the information that we can have here (including the Tax). Please, disregard the 0.00 value**

Image Added

Recent orders page (receipt) - Regular fee

Image Added

Recent orders page (receipt) - Fee with discount

Image Added

Hypothesis

The hypothesis is that the cart should provide a clear understanding of the savings when you are paying less (1.99) or the free delivery and any other relevant information avoiding duplicate or not valuable content.

Design Analysis

How is the design that we have today (by brand)

...

PS: I tried to check on FHS but wasn’t able to reach the delivery option. On FHS CH in production for example they only have a pick-up option and don’t have delivery.

Design proposals

Figma link (provisory branch): https://www.figma.com/file/XiL2LP23TgvwqVgzu2hUah/2023---Q4---%5BIBFEC-1046%5D---Free-delivery-fee-error?type=whiteboard&node-id=0%3A1&t=Bv6tmCED4yG96sKr-1

Partial discount use case design

...

Free delivery Fee use case design

...

For this proposal we can’t show the original fee value (when delivery fee is free) because of backend limitations. See the Inconsistencies and finds below for the explanation.

Partial discount with "Shipping costs"

...

Total discount with "Shipping costs"

...

Technical discovery analysis

The values come from the

...

getOrder query (deliveryFee and deliveryFeeDiscount). In the frontend, this query will come from the usePriceOrder hook. More details here: /wiki/spaces/CPT/pages/3623190582

Payload example:

...

  • deliveryFee = feeCents from back

  • deliveryFeeDiscount = feeDiscountCents from back

We can’t change or manipulate the values directly. This will not be recommended

I found two feature flags used in delivery fee code (not directly related to what we have in the “Your Cart” section and with our proposals… just a mention):

Regarding the problem n.3, we have the “Delivery Order Fees” modal. The objective of this modal is to show all fees needed. We’ll not have any problem to customize this (if aligned with INTL)

  • Delivery fee cents (deliveryFeeCents)

  • Geographical fee cents (geographicalFeeCents)

  • Service fee cents (serviceFeeCents)

  • Small fee cents (smallCartFeeCents)

From a front-end perspective, we’re able to manipulate all the visuals without problem from what I saw.

Inconsistencies and finds

Testing in QA I noted that when the user reaches the minimum threshold value and the delivery fee is free the back-end part returns zero as value for the delivery fee reference.

...

The thread opened to understand this with Intl/transactions guys: https://rbidigital.slack.com/archives/C04D0V74P0D/p1698180312609469

Talked with Maciej and he said that no one has knowledge about this part of the code and his feeling is that we’ll need to change the backend code.

...

With that, we understand:

  • The backend holds the logic of which value will be returned to the frontend part and we don’t know anything about that

  • The backend has a limitation with the fee delivery returning zero and no other info. With that, the frontend part can’t do anything about it

    • If the user enters the checkout page below the threshold backend will return the info for the delivery fee. We can save this value on the browser and use this latter, but

    • If the user enters the checkout page already above the threshold the backend will not return the values and the frontend only knows that the fee will be zero = free and can't save anything for future use

    • We can think of a solution using that but we need to have consistency on this UX/UI

  • If we need to go deep down on this backend part we don’t have a estimate for this because will be a discovery and as Maciej said any change should be done in a very careful way to not introduce regressions tests or bugs

Update - Calculation in FE logic

The calculation in FE is weird ( it subtracts not only discount, but also other fees from the main delivery fee ) and needs review:

2462725f-9bc3-45be-b469-da365e0f3622

...

image-20240208-221432.pngImage Added