Payloads from Partner API and Oracle for each menu structure.
Partner API structure examples: Orders API - Cart Structure Examples
Contents
STS Gen2
In the Get Menus call we will get all products deployed for a particular store for a particular revenue center.
Items can be tagged – e.g. all kiosk items can be tagged as ‘kiosk products’. Tagging can be used to filter out categories of food (e.g. meals, LTOs…). Filtering lets you perform bulk actions. E.g. we can only retrieve specific menu items from the POS.
Cloud Assist Service is in charge of ensuring standardization of PLUs.
Agreements & Notes
Oracle Symphony API Guide
https://rbictg.atlassian.net/wiki/spaces/ORACLE/pages/edit-v2/5133926800#Agreements
Fiscal Integrations
Fiscal integrations will change market by market.
Managing Pricing & Availability per Service Modes on a Restaurant-level
1) Pricing
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 SM
pricingSequence = 2 --> delivery SM
2) Availability
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:
Call GET Menu - using v1/menus (Khumbu already does)
Call GET Availability endpoint --- using (menus/items/unavailable) (Khumbu already does)
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.
Assumption: In general, menu item availability is not managed specifically differently per service mode (on a store-level).
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
andpickup
should be set toEmpty
respectively for these 2 documents.
This setup is required for the guest application to manage the availability correctly.
Combo Pricing
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.
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.
In general, anything premium (item or modifier) adds up to the total combo price.
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.
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.
Combo Size Configuration
We will aim to manage different combo sizes with different PLUs (e.g. small, medium and large combos all having different PLUs).
We would need defaults selected for each comboslots to be able to show the pricing correctly. We might need to have this default logic on Sanity (either implemented or a small button/toggle will be added to Sanity.)
Modifiers
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”)
Add with 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 used will require some work (e.g. partnersAPI).
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.
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.
Sugar Tax & Fees
In Oracle, sugar tax and cup charges are treated as “forced condiments” (required modifiers) to items - there will be dedicated PLUs.
Pfand has its own PLU and is treated as a condiment (modifier) to drinks.
Likewise, bag fee will be treated as separate PLUs.
Order Firing & Cancelation
In the “Post a new check” endpoint you include the
pickupTime
value which determines at what time the order should be ready in the restaurant. This time can be updated at any point by RBI as long as the order has not been prepared.pickupTime
is the time requested for the order to be collected. If not provided the current time plus the Service Level Time for the given order type is assumed. Time is local in the request but UTC in the response.Oracle adds prep time to that value to have the order ready in the submitted
pickupTime
. In Oracle, prep time is called service level time.pickupTime
can be equal to current time, 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.
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
Webhooks
For menu P&A changes, the Configuration Notification webhook will be subscribed to.
For order status changes Check Notification webhook will be subscribed to.
Oracle to confirm this webhook works.
There is no webhook to get store status updates.
Restaurant Availability
POS is always online, even in outside of operating hours (important for pre-ordering).
Cache for Restaurant Availability & Menu
STS has a 15 minutes cache for both to sync the change to cloud from the POS.
Does it mean menu updated webhook (ConfigurationsNotification webhook) can also take up to 15 minutes to be published after a POS? (TBC with Oracle.)
Items
Single item
Item with modifiers
The following payloads are from BK MX and are not up to date/standard. We won’t use definitionSequence 1, 2 for different service modes.
Combos
Oracle can only handle up to 10,000 combos.
Single combo
Combo with modifiers on items
Combo with premium comboslot
Offers
See Offers & Rewards - Payload Format .