Content Comparison

Summary for Pricing & Availability

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.

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 Service Mode

  • pricingSequence = 2 → delivery Service Mode

2) Availability

1. GET Menus

1. : 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

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

1. . Unavailable items from GET Unavailable must be removed from the active list retrieved from GET Menus.

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

2. Call GET Availability 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.

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: