...
...
...
...
...
...
Table of Contents |
---|
Front-end
Say we have the following order:
...
Similar to what we have in the current app (airtouch):
...
gastos de envio → delivery fee
otros gastos → management fee
...
Mapping of how delivery fee is set:
PriceOrder
Calls partner service API PriceOrder to get price related info including fees.
Persists taxes into the database
FE tech discovery can be found here
Mapping of how delivery fee is set (BE):
PriceOrder
Calls partner to get price related info including fees.
Persists fees into the database
GetOrder
Retrieves order related info from the database, including fees
Backend discovery
priceOrder
intl-whitelabel-app →
priceOrder
intl-whitelabel-graphql →
priceOrder
intl-fullfilment-service →
priceOrder
updateDeliveryEntry
intl-delivery-service
getFeeAndDiscountByBrand
( using intl-packages delivery lib or intl-delivery-service?)
Delivery fees are managed by the fee service ( intl-delivery-service):
getFeeAndDiscountByBrand
getFeeChargeByTier
It get the values from launchdarkly based on the service mode.
If catering , it uses
tiered-catering-delivery-fees
Otherwise, it uses
tiered-delivery-fees
Searches the tier list from highest to lowest key, stopping when requestedAmountCents exceeds that tier.
Said that, we can to analyze the following "return” to propose the management fee. Apart from that, looks like Launchdarkly existing configuration (variations) were thought to enable "free delivery” and we can leverage this approach.
Code Block return { baseDeliveryFee: fee, --> LD fee deliverySurchargeFee, --> LD expandedFees (based on delivery quotation value) discount, --> LD discount fee: fee + geographicalFee + serviceFee + smallCartFee + deliverySurchargeFee, geographicalFee, --> LD geographicalFee serviceFee, --> Calculated with LD serviceFeePercent of the requested amount smallCartFee, --> LD smallCartFee };
We may introduce a new fee named "management fee” to fulfill the current use-case or explore existing fees.
Expandexpand | ||
---|---|---|
| ||
{ |
...
SNS: dev-plk-delivery-quote-outcome
SQS: aws-rbi-dev-plk-apply-delivery-service-quote
Lambda: sls-rbi-dev-plk-orders-delivery-service-apply-quote ( intl-orders-service)
Which get the message and updates the current order in the database (dynamodb)
...
BE Proposal
...
Enhance this lambda function (dev-plk-delivery-on-apply-quote) to not overwrite discount and service fees with zeroes. It should keep the value from launchdarkly.
Configure launchdarkly to fit business needs enabling FE to show fees and discounts properly.
discount <> 0
serviceFee <> 0
fee <> 0
Configured webhooks*:
...
title | Integration for store 1111 (zaragoza) - exists dev DELIVERY_QUOTE_CREATE and fallback(DELIVERY_QUOTE) |
---|
...
Lucidchart | ||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
Note |
---|
Note: The calls to the BE in priceOrder is being executed through intl-gateway-service in the envs (enable-fulfillment-service-price-order = true) for Iberia Prod markets. Since in both flows (gateway and graphql) the impact is in intl-delivery-service, no major issues may be found with intl-whitelabel-graphql, but a double check plus tests are needed to ensure no major issues. |
Proposal validation with transactions team:
https://rbidigital.slack.com/archives/C04D0V74P0D/p1702672116251489
FE impacts
When discount, fee and service fee come to FE, intl-whitelabel-app can be changed to display FREE fees as according to UX (figma). The design screens should be adapted to consider them accordingly. In such case, depending on the launchdarkly config ( fee tier), we may have a different value for fee, service and discount. In principle, to minimize BE impacts, we may continue using a single field for discount. It’s up to the FE display "FREE” for the related use-cases. E.g:
discount == fee + servicefee
FREE fee
FREE service fee
discount == fee, but discount < fee+servicefee
FREE fee
X.XX service fee
discount < fee
X.XX fee
X.XX service fee
Other configurations may not be supported
...
Feature control
As usual the activation of this feature should be done using LD feature flag in both FE and BE. Later it can leverage a new sanity config (toogle) under guest checkout.
Enhancements
Since, in the future, we may have partners who calculates delivery fees not only based on LD, we can have an additional config for FREE delivery fee / FREE delivery service fee, where BE (intl-delivery-service) would override LD values - meaning that discount can be set with the same amount of the fee or fee + service fee.
...
Architecture
...
In partners service, create quote flow calls both in delivery : quote_create and quote_apply
Configured webhooks*:
Expand | ||
---|---|---|
| ||
|
Expand | ||
---|---|---|
| ||
|
In partners service, create quote flow calls both in delivery : quote_create and quote_apply
Architecture
...
Problems detected in DEV:
Added 9 sauces of 2.00 in the cart
After resulting in 18, it multiplied by 9 again:
Button + reached limit of 5, and kept varying between 4 and 5 in upsell cart modal
...
Threshold issue:
During the initial analysis, we were informed that fees would not come to FE when threshold is reached, however the behavior looks the same of when threshold is not reached.
...
...
Possible existing bugs
During this discovery, strange behaviors were detected. They are detailed here
Hints:
How to run local lambdas:
Example:
yarn start:function on-apply-quote
A suggestion from trx team is to use partners-service repo as reference, where it shows also how to mock local events simulating (local queues). It ensures that you will be able that your lambda “consumer” will really read the event (and not the lambda that is AWS).