Versions Compared

Version Old Version 41 New Version 42
Changes made by

Yildirim, Semih

Yildirim, Semih

Saved on

Key

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

...

Info

Terminology & overview: Oracle Config - Overview

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

  1. GET Menus: check for PLU + DefSeq + PriceSeq to verify if item is active or not in the restaurant. Items that are not active are unavailable. However, this endpoint doesn’t take restaurant-level availability into account fully.

  2. To retrieve unavailable items per store, we need to make another call to the GET 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. Unavailable items from GET Unavailable must be removed from the active list retrieved from GET Menus.

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

  4. Call GET Unavailable 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.)

    2. If an item is unavailable in this endpoint, is means it is unavailable in all service modes.

    3. Note that the Configuration Notification will only indicate there’s been a change in availability but will not specify what items are impacted by the change (additional details on the webhooks section).

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

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

  • Market-level Configuration – Operators only input PLU under ConstantPlu.

  • priceSeq and defSeq are configured elsewhere for the whole market, not inputted by operators.

    1. Regardless of the standardization between brands/markets, the priceSequence or definitionSequence should only be configured once for a given menu item type (item, combo, modifier) in a given brand/market. E.g. priceSequence & defSequence always same for all items (no difference between individual item documents).

    2. Example configuration matrix - for each brand/market:

...

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).

  • 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 for the 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).

      • image-20241120-101852.png

      • Upon clicking on Ketchup under Options, today we see additional Options (Item --> Options --> Options) for ketchup (its modifier multipliers):

      • image-20241120-101802.png

      • Instead of defining Add and No modifier multipliers and adding via Item --> Options --> Options, we will have a selection option for Add and No under Item --> Options, available by default for all modifiers added.:

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.).

  • Note: The new toggles will be specific to Oracle POS in order to not introduce breaking changes for existing markets. For example, BK UK having both NCR that uses Modifier Multiplier, and Oracle that will use the toggles. For NCR, the PLUs will be sent from the modifier multiplier document as it is done today and new toggle values won’t be sent. For Oracle, the modifiers will be managed via toggle values.

  • To understand if a modifier document in Sanity is ‘'Add’' and ‘'No’' to be able to assign the correct priceSequence, the UI selections for these options in Sanity should be exposed to Khumbu.

  • No PLU defined for modifier multiplier.

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

  • Different quantities of modifiers (e.g. 2 bacons) will be managed with the Quantity field.

  • Khumbu will manage the mapping for PLU+definitionSeq+PriceSeq as shown in phase 2 on the slide deck.

    • 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 (38)-20241031-101503.png

...