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)
...
)
...
:
...
2-)Totally Dynamic Calculation based on the HIGHER TIER (fee + serviceFee - discount - serviceFeediscount) - LOWER TIER (fee +serviceFee - discount - serviceFeeDiscount) -
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. One alternative is to call quotation process for the higher tier.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
...