Participants

• Caes, Guilherme

🔍 Reviewers

• Fernandez Pranno, Marco Manuel
• Franca, Helio
• Nunes de Oliveira, Henrique (Deactivated)
• Souza, Rafael
• Raphael Ferreira Gomes
• Krajewski, Piotr (Deactivated)

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 IDeliveryFees {                      // New DTO
  deliveryFee: IPrice;
  serviceFee: IPrice;
}

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?: IDeliveryFees;                               // 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.