...
Info |
---|
Pricing & Availability per Service Modes on a Restaurant-levelTerminology & overview: Oracle Config POS - Overview 1) PricingDifferent pricing between service modes will be managed by priceSequence within the same definitionSequence. Applicable for all products (item, combo, modifier).
2) AvailabilityGET Menus: check for PLU + DefSeq + PriceSeq to verify if item is active or not in the restaurant. Items that are not active areAvailability Management
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: |
...
Info |
---|
Summary for Pricing & AvailabilityKhumbu will concatenate 3 IDs for items, combos, modifiers: PLU-DefSeq-PriceSeq. For items:
For modifiers,
For combos,
Configuration in Sanity
|
...
Menu Product Type
...
priceSequence
...
definitionSequence
...
Item
...
Delivery → 2
In-restaurant → 1
...
Delivery → 1
In-restaurant → 1
...
Combo
...
Modifier
...
Reward
Info |
---|
To see configurations in practice:/wiki/spaces/~554304973/pages/5254775064 Detailed Menu Structure guide: Oracle - Menu Structure options 1.pptx |
Note |
---|
Note that some existing markets use definitionSequence and priceSequence differently. For example, priceSequence used for indicating different sizes for combos. Even though we would be able to support some of these configurations, 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. |
...
Modifiers
...
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).
...
Only 2 levels of modifiers will be supported for mobile ordering: ADD and NO. Additional modifier multipliers (more granular levels of customization such as ‘heavy ketchup’, ‘light ketchup’) won’t be supported for mobile ordering in the initial scope.
...
priceSequences will be used for determining the ADD and NO modifiers, as well as pricing across service modes:
priceSeq 2 = In Restaurant Add
priceSeq 3 = In Restaurant No
priceSeq 6 = Delivery Add
priceSeq 7 = Delivery No
...
A single Sanity document will be used for each modifier, with a single PLU used for both in-restaurant and delivery service modes.
For Add and No, a toggle will be added to the Sanity document under item → Options.
Option 1 (tentative):
...
A single modifier document called Ketchup in Sanity.
...
If a given item needs to have Ketchup, it is added under Item --> Options as it is currently done (example here).
...
Upon clicking on Ketchup under Options, today we see additional Options (Item --> Options --> Options) for ketchup (its modifier multipliers):
...
Scenario
...
UI Configuration
...
If a guest can remove a modifier from an item and can also add more.
...
Both the Add and No UI selections will be selected/turned on.
...
If a guest cannot remove a modifier from an item but can still add more of it.
...
The Add UI selection will be selected/turned on.
...
If a guest can remove a modifier from an item but cannot add more.
...
The No UI selection will be selected/turned on.
...
If a guest cannot do anything about a modifier from an item.
...
No need to add that modifier under Item --> Options.
Info |
---|
Later on, additional toggles (or any other UI mechanism) can be added to allow for multiples of Add (light, heavy, 2x, 3x.). Configuration of Definition Sequence and Price Sequence
|
Menu Product Type | priceSequence | definitionSequence |
---|---|---|
Item | Delivery → 2 In-restaurant → 1 | 1 for both Delivery and In-restaurant. |
Combo | Delivery → 2 In-restaurant → 1 | 1 for both Delivery and In-restaurant. |
Modifier | priceSeq 2 = In Restaurant Add priceSeq 3 = In Restaurant No priceSeq 6 = Delivery Add priceSeq 7 = Delivery No | 1 for both Delivery and In-restaurant. |
Info |
---|
To see configurations in practice:/wiki/spaces/~554304973/pages/5254775064 Detailed Menu Structure guide: Oracle - Menu Structure options 1.pptx |
Note |
---|
Note that some existing markets use definitionSequence and priceSequence differently. For example, priceSequence used for indicating different sizes for combos. Even though we would be able to support some of these configurations, 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 |
---|
Modifiers
|
Info |
---|
Open questions to answer in the implementation:
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.
|
Info |
---|
Combo PricingCombo 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.
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. Most of the logic here should be handled by Khumbu. Additional context under phase 3 in slide deck. |
...