Versions Compared

Version Old Version 24 New Version 25
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.

    1. As is – you need to manually concatenate PLU-defSeq-priceSeq and input that string under ConstantPlu.

    2. Market-level config – you only input PLU under ConstantPlu. priceSeq and defSeq are configured elsewhere for the whole market.

    3. Breakdown of 3 fields – you input PLU, defSeq and priceSeq in different Sanity fields.

    Notes on options:

    • Option 1) and 3) are more prone to operator errors, and involve more manual repetitive work for operators to input concatenations/fields for each applicable menu document.

    • 3) involves additional development to extend the Sanity UI

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

    Detailed Menu Structure guide: Oracle - Menu Structure options 1.pptx

    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:

    ...