Versions Compared

Version Old Version 21 New Version 22
Changes made by

Yildirim, Semih

Yildirim, Semih

Saved on

Key

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

...

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.

To see configurations in practice:/wiki/spaces/~554304973/pages/5254775064

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

  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:

...

Note

Note that some existing markets use definitionSequence and priceSequence differently. For example, priceSequence used for indicating different sizes for combos. These 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

  • 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.Modifiers will have the followingpriceSequences different than items/combos:

      • priceSeq 2 = In Restaurant Add

        priceSeq 3 = In Restaurant No

        priceSeq 6 = Delivery Add

        priceSeq 7 = Delivery No

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

...