2024-04-10: Add fee field to create delivery webhook
Participants
@Caes, Guilherme
Reviewers
Due to a miscommunication the proposed solution was only shared intl-delivery-plataform slack channel (https://rbidigital.slack.com/archives/C03DVSBAT18/p1707220483855759 ) and is already implemented but not activated. After the feedback from this ADR the code will be refactored to address any necessary changes.
Context
As we proceed with the implantation of the https://rbictg.atlassian.net/wiki/x/wYBUAwE, there is a gap that delivery partners currently do not receive any detailed information regarding the fees charged in the order. As a consequence, they are left on their own to figure a value and print it in the restaurant ticket. Using DMP as an example, they calculate a delivery cost by subtracting the value of the cart items from the total, as follows:
DELIVERY_COST = ORDER_TOTAL - SUM(ITEMS_IN_CART)
This will create a source of confusion when restaurant workers compare the tickets generated by the restaurant and POS, which will show different values. Besides WL App orders, the same issue will happen with food aggregators that charge a service fee, e.g. Glovo when Iberia closes a service agreement with them and a service fee value is defined.
Proposal
Include a new optional fee field on the Create Delivery Webhook for the partners to receive this information and enable them to display it accordingly.
export interface IWebhookCreateDelivery {
additionalDetails?: {
key: string;
value: any;
}[];
callbackUrl: string;
cart: ICart;
channel?: Platform | ReferralVendor;
deliveryMode?: DeliveryMode;
customer: ICustomer;
deliveryAddress: IUserAddress;
fireOrderInSeconds: number | null;
instructions?: string;
number: string;
orderId: string;
fees?: IPartnerFee[]; // New field
payment: IPayment;
quoteId: string;
storeId: string;
}
Adding a new field to CreateDeliveryWebhook payload may cause problems depending on how partners servers are configured. For example, in NestJS whitelist
and forbidNonWhitelisted
parameters control if fields not declared in the DTO will be stripped or will throw an exception (ref: https://docs.nestjs.com/techniques/validation )
Since this is a possibility (confirmed in air touch case), this configuration will have to be enabled on a per restaurant basis. Currently this configuration is already implemented using the enable-relaying-new-fees-to-pos FT in Launch Darkly. Another possible option is moving it from LD to sanity.
Consequences
With this changes delivery partners will be able to print the correct fees charged in the order to avoid discrepancies with POS reports, but the feature has to be enabled on a per restaurant basis to avoid breaking changes.