Versions Compared

Old Version 14

changes.mady.by.user Yildirim, Semih

Saved on

compared with

New Version Current

changes.mady.by.user Yildirim, Semih

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Info

Fiscal integrations will change market by market. There’s no standard.

Info

...

Khumbu will concatenate 3 IDs for items, combos, modifiers: PLU-DefSeq-PriceSeq. 

For items:

  • 1 dimension - service modes.

  • We can distinguish between service modes using any of the 3 IDs.

  • Recommendation: Use priceSeq and constantPLU, keep definitionSequence constant.

For modifiers, 

  • 2 dimensions - service mode and quantities (multipliers).

  • We can distinguish between service modes and multipliers using a combination of the 3 IDs.

  • Recommendation: Use priceSeq and single constantPLU per modifier, keep definitionSequence constant, no PLUs to be defined for modifier multipliers separately.

For combos, 

  • 2 dimensions - service mode and size.

  • We can distinguish between service modes and size using a combination of the 3 IDs.

  • Recommendation: use priceSeq for service mode, and sizeBasedPlu ID ('large', 'medium', 'small') to distinguish size. Same PLU is used for different combo sizes.

 

Configuration in Sanity (to be determined)

  • Suggestion: Configuration in Sanity at a brand/market-level which abstracts the definition and price sequence from the operator.

    • Pros:

      • The operator only inputs the PLU.

    • Cons:

      • Modifiers use other priceSeq.

      • Not seeing the full PLU in Sanity also complicates debugging.

  • Alternative: Showing the breakdown of the 3 fields in Sanity (PLU, DefSeq, PriceSeq).

    • Pros:

      • More intuitive for operators and removes any 'middleware' logic from Sanity.

    • Cons:

      • More prone to operator errors, likely more work for operators as well.

      • Additional development work to extend the Sanity UI and ensure consistency.

Info

Different pricing between service modes will be managed by priceSequence within the same definitionSequence. Applicable for all products (item, combo, modifier).

  • DefinitionSequence always = 1

    • pricingSequence = 1 → pick-up Service Mode

    • pricingSequence = 2 → delivery Service Mode

GET Menus call returns all items for a given store, it doesn't take availability into account. To retrieve unavailable items per store, we need to make another call to the UNAVAILABLE endpoint, which returns the list of unavailable items. Hence, whenever we build the store menu (after a guest selects a restaurant in the platform), we need to call both endpoints to determine availability on a store-level:

  1. Call GET Menu - using v1/menus (Khumbu already does)

  2. Call GET Availability endpoint --- using (menus/items/unavailable) (Khumbu already does)

    1. Actively listen to Configuration Notifications webhook for changes to availability (notifications API) (Khumbu doesn't do this currently.)

Operators in the restaurant manage items availability on a store-level using the POS, Oracle POS only supports that on store-level for both service modes - not distinguishing availability per service mode (pick-up and delivery).

Assumption: In general, menu item availability is not managed differently per service mode on a store-level, meaning availability for pick-up and delivery is generally the same.

For specific items whose availability is different for pickup and delivery within the same store, the following will be the suggestion to the operator:

In certain markets, there are menu items whose availability can be temporarily different for different service modes on a restaurant-level. Meaning, item_1 being available for pickup and delivery normally for a given store, but temporarily needs to be made unavailable only for the delivery service mode while still being available for pickup. An example of this is packaged ice creams not being sold via delivery temporarily during heat hours but still sold on pickup. For those items, the configuration requires two distinct PLUs per service mode, as well as 2 separate Sanity menu content documents. To illustrate:

  • The market has 500 menu items in total. Menu item availability for almost all menu is managed per store for both service modes (if a menu item is not available in the restaurant for online pickup ordering, then it also won't be available for delivery).

  • There are only 10 menu items that could have different availability per store and service mode at the same time, like the icecream example mentioned above.

  • The operator configures a single PLU for 490 items, the same PLU is shared for both service modes. Availability is managed for both service modes at the same time on a store-level - always.

  • For the 10 exceptional menu items, distinct PLUs are defined per service mode - in total 20 PLUs.

  • These different PLUs then can be marked available/unavailable via the Oracle POS to manage availability differently per service mode.

  • Similarly, 2 unique Sanity menu documents are created for these items, one for each service mode. Example: Ben & Jerry's Icecream Pickup and Ben & Jerry's Icecream Delivery. Applicable pickup and delivery PLUs are then added to each document. This is different than the remaining 490 items where there is a single Sanity menu item document and the same PLU is entered for both service modes under Vendor Configs. The vendor configs for delivery and pickupshould be set to Empty respectively for these 2 documents.

This setup is required for the guest application to manage the availability correctly.

Note

Note that some existing markets use definitionSequence and priceSequence differently. For example, priceSequence used for indicating different sizes for combos. These markets would be suggested to change their configuration based on the standard guidelines defined by RBI / Oracle with a one-off configuration migration which Oracle can support via an Excel upload.

Info

  • 2 dimensions - service mode and quantities (multipliers).

  • We can distinguish between service modes and multipliers using a combination of the 3 IDs.

    • Most markets support 2 levels of modifiers for mobile ordering: ADD and NO.

      • Remove (“No”). No multiples available.

      • “Add”, which will have several quantities (multiples for each quantity – e.g. 1x ketchup, 2x ketchup).

    • Each modifier has a priceSequence - 1 for pickup and 2 for delivery, just like items and combos.

    • PriceSequences will be used for determining the ADD and NO modifiers, as well as pricing across service modes. Khumbu will manage the mapping for PLU+definitionSeq+PriceSeq as shown in phase 2 on the slide deck.

    • Similarly, for management of modifier multipliers beyond the ADD and NO values for modifiers (light, heavy, 2 bacons, etc.), other pricing sequences or definitionSequence will be used.

  • Recommendation: Use priceSeq and single constantPLU per modifier, keep definitionSequence constant, no PLUs to be defined for modifier multipliers separately.

    • In cases where a modifier is not available in delivery service mode specifically (while available for pickup), this could be managed via empty vendor config in Sanity for display in whitelabel. (The pricing for the modifier will still be managed via the mapping with Khumbu).

Alternative to using PricingSequence or DefinitionSequence for Multipliers - the Quantity Field: This will be enabled by RBI Tech platform by utilizing the multiconstant PLU solution. Having the multiconstant PLU solution work will require additional engineering effort (e.g. there are gaps in partnersAPI, and potentially Menu Service in general).

To improve the experience of the operator, a single Sanity document should be used for management of modifiers on Sanity later on. Therefore, removing the modifier multiplier document from Sanity completely.

image (37)-20241031-101500.pngImage Addedimage (38)-20241031-101503.pngImage Added
Info

Combo pricing can be configured in 2 different ways. RBI Tech needs to support both scenarios, it is not possible to have one standardized way of managing combo pricing due to different taxation requirements of countries.

  1. Price is at the combo level. Menu items inside the combo are priced at 0, unless they’re premium. Examples are markets like BK DE, BK UK, BK MX.

    1. In general, anything premium (item or modifier) adds up to the total combo price.

  2. Price is at the combo items' level. Combo is priced at 0. The sum of the combo items' prices adds up to the combo PLU. This gives operators the flexibility to build a price allocation different from the ALC prices, which can optimize the VAT allocation.

    1. Premium modifier PLU is added to the applicable item price instead of the combo.

In both cases the total combo price = combo price + main item price + side 1 price + side 2 price. Therefore, summing up prices of everything always gives to total.

Info

We will aim to manage different combo sizes with different PLUs (e.g. small, medium and large combos all having different PLUs).

Info

Most markets support 2 levels of modifiers for mobile ordering: Add and No. For those, 2 separate PLUs will be created on digital. For management of modifier multipliers beyond these 2 levels (light, heavy, 2 bacons, etc.), we will use the Quantity field in Oracle instead of defining modifier multiplier PLUs.

Two modifier PLUs:

Remove (“No”). No multiples available.

  • “Add”, which will have several quantities (multiples for each quantity – e.g. 1x ketchup, 2x ketchup).

  • Each modifier has a priceSequence - 1 for pickup and 2 for delivery, just like items and combos.

    • This will be enabled by RBI Tech platform by utilizing the multiconstant PLU solution. Having the multiconstant PLU solution work will require additional engineering effort (e.g. there are gaps in partnersAPI, and potentially Menu Service in general).

    To improve the experience of the operator, a single Sanity document should be used for management of modifiers on Sanity later on. Therefore, removing the modifier multiplier document from Sanity completely.

    image (37)-20241031-101500.pngImage Removedimage (38)-20241031-101503.pngImage Removed
    Note

    Note that the above agreements (especially the service mode management via pricingSequence and using distinct PLUs for different combo sizing) depends on the impact to the restaurant operations. Currently, there are complexities on duplication of buttons for the POS screen which could turn out to be a blocker, will be tested by Jean and then alignment/buy-in will be received from the operations.

    ...

    Info

    • In the “Post a new check” endpoint you include the pickupTime value, which is the time requested for the order to be collected.

    • This time can be updated at any point by RBI as long as the order has not been started.

    • Prep time is called serviceLevelTime in Oracle.

    • Oracle adds prep time to the pickupTime . So if we send pickupTime = now, Oracle will return pickupTime = now + serviceLevelTime. SopickupTime can be equal to current time, and Oracle will add the prep time automatically.

    • Restaurant managers might be able to void orders.

    • If we subscribe to check notification we should get all info about the order.

      • Oracle to confirm how to get information about online orders voided in restaurant, and what order status information we can get.

    • https://docs.oracle.com/en/industries/food-beverage/simphony/19.4/stsgg/F56815_08.pdf Page 109 - 110

    Further context with Q&A: https://rbictg.atlassian.net/wiki/spaces/ORACLE/pages/edit-v2/5133926959#Order-firing-%26-cancelation

    Info

    • Details of all notifications (webhooks) are available in the API documentation here and here.

    • For menu P&A changes, we can :

      • We subscribe to the Configuration Notification webhook.

      • Configuration notification runs on a scheduled job every 15 minutes for pricing changes, whereas it is near real-time for availability changes.

      • The notification doesn't specify what item(s) have become unavailable at a store-level, the whole menu needs to be fetched.

      • Price update can take up to 30min to get to the restaurant. CALC is a cloud call, POST will have old price. A manual update can be forced using the “Update” button in the POS.

    • For order status changes we can :

      • We subscribe to the Check Notification webhook.

      • Order statuses depend on the KDS setup in the store. 2 statuses are received in most cases: Submitted & Done

      • Check notification statuses are based on what happens in the KDS.

      • On the post a transaction, we must say notificationOption - “enabled”: true. This means that when the check is submitted, it will track notification from KDS.

    • There is no webhook to get store status updates.

      Open questions:

      When check notifications would be triggered, for which statuses, what would be the payload?

      When configuration notifications would be triggered, for which type of config changes, what would be the payload?

    Info

    • POS is always online, even outside of operating hours (important for pre-ordering).

    ...