Design:
...
{
"0":{
"app":{
"discount":0,
"serviceFeeDiscount":0,
"fee":199,
"serviceFee":100
}
},
"10":{
"app":{
"discount":99,
"serviceFeeDiscount":50,
"fee":199,
"serviceFee":100
}
},
"20":{
"app":{
"discount":199,
"serviceFeeDiscount":100,
"fee":199,
"serviceFee":100
}
}
}
Frontend:
MAXIMUM_POTENTIAL_SAVING (E.g: 2.99) → Possible solutions:
...
1-) Semi Dynamic Calculation based on the HIGHER TIER (discount + serviceFeeDiscount)
Pros: Flexible, marketing configuration freedom to explore saving values (A/B testings)
Cons: requires some manual configuration / new fee interface changes
...
:
LOWER TIER (fee + serviceFee ) - LOWER HIGHER TIER (fee +serviceFee ) -
Pros: More flexible.
Cons: More calculations to handle different tiers / more efforts/ new fee interface changes
| Note |
|---|
This calculation uses maximum delivery fee (higher tier) as reference. The source of this truth is DMP/Homeria. There are chances to generate inconsistences due to misconfiguration and this solution is not subject to the dynamism of delivery fee configuration/evolution. It reduces the purpose of the create quote process.DMP and Homeria are Delivery fee source of truth. Therefore, LD need to be in sync with them to avoid inconsistences of the information |
THRESHOLD( E.g: 20.00) → Possible solutions:
1-)Calculation based on FF discounted-delivery-threshold-cents
Pros: Existing approach / minimum efforts
Cons: Less flexible/ requires caution when configuring / changing config
2-) Dynamic Calculation based on the HIGHER tier ( service from fee table modal can be reused)
Pros : flexible (recommended)
Cons: Requires more effort to read the higher tier and return it via new field in the interface
AMOUNT_AWAY_FROM_MAXIMUM_SAVINGS (E.g.: 8.00 ) →
Threshold - (requestedAmountCents OR
(subTotalCents+taxCents)cart price without fees)