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.

  • Additional context under phase 3 in slide deck.

Configuration in Sanity (to be determined)

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

• Expecting operators to fully understand price and definition sequence and enter all concatenated PLUs OR separate fields accordingly in Sanity is a big ask and no good reason in asking the operator to fill in that on document-level (e.g. item1, item2, item3). Because price or definitionSequence will be at least standard for all items or all combos, so if we really have to it can be configured on item type-level (once for all items, once for all combos, etc.). 

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

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

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