| Table of Contents |
|---|
Business problem
Several fees can be included in an order price, such as geographical, service, small cart and delivery. Currently, DMP only shows a delivery fee in the ticket it generates, calculated using the following formula:
...
For the example above we have 17.57 - (8.99 + 2.99) = 5.59. These discrepancies between the tickets generated by DMP and the POS can confuse the restaurant when the workers compare them. This document analyses possible solutions for this problem.
Tech discovery
Architecture AS-IS
An order incoming to DMP can come from either whitelabel or a food aggregator (eg. Glovo, Uber Eats). Although created using different endpoints, both receive a list of fees included.
...
For the food aggregator workflow we have the following sequence of events:
...
Known issues
Fulfillment service aggregating all fees into delivery fee for orders from food aggregators (eg. glovo, uberEats)
This is part of the first implementation that we can see here :Code Block language typescript const deliveryFees = input.charges?.fees?.reduce((acc, fee) => { if (fee.type === PartnerFeeType.DELIVERY_FEE) { acc = fee.total?.amount ?? 0; } return acc; }, 0);DMP never receive the fees associated with the order
Although DMP calculates the delivery fee in the WL during the quote workflow, this information does not persist when the order is created. Besides that, no information regarding the other fees is received by it, as we can see in the create delivery webhook documentation.
Proposed solution
A simple solution is fixing the delivery fee in fulfillment calculation and altering the delivery integration to receive this information. Fixing the calculation is important since the fees returned for the POS will be used by them to create the delivery later (to be confirmed).
IMPORTANT CONSIDERATIONS:
The proposed solution assumes that the POS will send the fee breakdown, either on the commitOrder endpoint or the submitOrder. This was proposed by Winrest and the ground work is already laid off in partners API given the list of fees it receives.
The exact fee structure may change to include new fields in the near future, so this feature should be implemented after
is done.Jira Legacy server System JIRA serverId 255417eb-03fa-3e2f-a6ba-05d325fec50d key IBFEC-1467 Although the POC focuses on aggregators, the changes will work for WL orders as well, since the create delivery process is the same.
...
Let’s dive into more details in each one:
1. Fix the fee calculation in fulfillment service
For the first problem, we’ll need to map all the possible received fees (including new values to come) into the fee fields of the RBI Order. Take delivery and service fees as examples:
...
Will create an order with the appropriate fees in DynamoDB:
...
2. Send fee information in partners service
In this step, it is necessary to include the new fee structure in the create delivery payload and format the values received to the currency format.
...
After configuring the webhook to hit a local Mockoon server, I could confirm the new fees would indeed be sent to the delivery provider:
...
3. Receive and persist fee information in DMP
The create delivery request sent by partners-service is received by DMP /orders endpoint, which creates an OrderResponseDTO object in Dynamo DB. First, we need to include the fee field in the three relevant DTOs: OrderResponseDto, DeliveryWebhookRbiDto and DeliveryWebhookDto.
...
And now the orders are created in dynamo with the fee information:
...
4. Display fee breakdown in expeditor tablet, including printed tickets
We’ll have to align with the UI/UX team to find the best way to display the new information, but as long as the backend is returning it, the expeditor tablet has only to adjust the Order interface and create the new react components responsible for showing the fees.
5. Display fees in driver app
TBD
Task breakdown
[intl-fulfillment-service]
...