Contents

Table of Contents

minLevel	1
maxLevel	6
outline	false
style	none
type	list
printable	true

Store Availability

...

Action

...

Tests

...

Expected Vendor Behavior

...

Expected Result

...

Update Store Status

To Online

...

Authenticated user inputs restaurant address on restaurant search in App.

...

Update Store Status to Online (docs).

...

→ Partners API reports store is offline through Get Store Status call.

→ Ordering buttons become eligible for the store.

...

Note: Store ordering availability is not only affected by the POS status, as there are other configurations required to activate stores.

→ RBI admins have access to the Store Diagnostics and can verify that isRestaurantPosOnline: true

...

Update Store Status

To Offline

...

Authenticated user inputs restaurant address on restaurant search in App.

...

Update Store Status to Offline (docs).

...

→ Partners API reports store is offline through Get Store Status call.

→ Ordering buttons become grayed out for the store. Mobile ordering is not available at this store warning appears.

...

Note: Store ordering availability is not only affected by the POS status, as there are other configurations required to activate stores.

→ RBI admins have access to the Store Diagnostics and can verify that isRestaurantPosOnline: false

...

Store Menu Pricing & Availability

...

Action

...

Tests

...

Expected Vendor Behavior

...

Expected Result

...

Make an item available for a certain store

...

Authenticated user selects ordering for the corresponding store and navigates to the menu section of the item.

...

Make a request with price and availability : true for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint.

...

→ Partners API GET Store Menu PLUs endpoint returns the PLUs with the corresponding price and availability.

→ Item appears in App Menu section with correct price.

Consider a cache of up to 1 minute for updates to reflect in FE.

...

Make an item unavailable for a certain store

...

Authenticated user selects ordering for the corresponding store and navigates to the menu section of the item.

...

Make a request with price and availability : false for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint.

...

→ Partners API GET Store Menu PLUs endpoint returns the PLUs with the corresponding price and availability.

→ Item disappears from App Menu section.

Consider a cache of up to 1 minute for updates to reflect in FE.

...

Make a combo available for a certain store

...

Authenticated user selects ordering for the corresponding store and navigates to the menu section of the item.

...

Make a request with price and availability : true for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint.

...

→ Partners API GET Store Menu PLUs endpoint returns the PLUs with the corresponding price and availability.

→ Combo appears in App Menu section with correct price.

Consider a cache of up to 1 minute for updates to reflect in FE.
Combos availability is not only affected by the Combo PLU, as other menu structures are required. Read about it here.

...

Make a combo unavailable for a certain store

...

Authenticated user selects ordering for the corresponding store and navigates to the menu section of the item.

...

Make a request with price and availability : false for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint.

...

→ Partners API GET Store Menu PLUs endpoint returns the PLUs with the corresponding price and availability.

→ Item disappears from App Menu section.

Consider a cache of up to 1 minute for updates to reflect in FE.

...

Make a combo available:

→ Make a request with price and availability : true for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint.

Including the PLU for the main item of the combo - a combo cannot be made available without its main item is available. (E.g. whopper medium burger is the main item of the whopper meal medium combo)
Ensure at least one comboslot within the combo has availability : true - a combo cannot be made available before at least one item in its comboslots are available.

Note that combos only appear in the whitelabel if they are correctly configured in the CMS (Sanity). For further context about combos' configuration: Combo

...

→ Combo appears in App Menu section, with correct price.

→ Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the same price and availability value in the API response.

Consider a cache of up to 1 minute for updates to reflect in FE.

...

Make a combo unavailable:

→ Make a request with availability : false for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint.

→ Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the same availability value in the API response.

→ Confirm that the combo(s) no longer appear on the Whitelabel App’s menu section

Consider a cache of up to 1 minute for updates to reflect in whitelabel.

For further context about combos' configuration: Combo

...

Make a modifier multiplier available:

Modifier Multipliers are the options guests can have for each of the ingredients that the brand allows to get modified in each item, they have a PLU related to each of them in a lot of cases but there might be POS exceptions. These are what you might know as ingredients that are modifiable in each of our items like No Tomato (Sandwich), Regular Tomato (Sandwich), Extra Tomato (Sandwich).

→ Make a request with availability : true for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint. Including the modifier PLUs (if applicable).

→ Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the same price and availability values in the API response

→ Confirm that the modifier multipliers appear on the product detail page of products which the modifiers are configured, with correct price (if defined)

Consider a cache of up to 1 minute for updates to reflect in whitelabel.

Note that modifier multipliers only appear in the application if they are correctly configured in the CMS (Sanity), and only for products for which modifiers are configured. Further context about configuration: Modifier Modifier Multiplier

...

Make a modifier multiplier unavailable:

Modifier Multipliers are the options guests can have for each of the ingredients that the brand allows to get modified in each item, they have a PLU related to each of them in a lot of cases but there might be POS exceptions. These are what you might know as ingredients that are modifiable in each of our items like No Tomato (Sandwich), Regular Tomato (Sandwich), Extra Tomato (Sandwich).

→ Make a request with availability : false for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint

→ Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the same availability values in the API response

→ Confirm that the modifier(s) and/or modifier multipliers no longer appear on the product detail page of products which the modifiers are configured

Consider a cache of up to 1 minute for updates to reflect in whitelabel.

Further context about configuration: Modifier Modifier Multiplier

...

Make a systemwide offer available:

→ Make a request with availability : true for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint

Ensure an incentive has been correctly defined: https://rbictg.atlassian.net/wiki/spaces/COG/pages/4041670827/Systemwide+Offers#Incentives

→ Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the same price and availability values in the API response

→ Confirm that the systemwide offers appear on the whitelabel application.

Consider a cache of up to 1 minute for updates to reflect in whitelabel.

Systemwide offers only appear in the application if they are correctly configured in the CMS (Sanity). For further context about configuration: Systemwide Offers

Note that there may be additional rules defined for systemwide offers https://rbictg.atlassian.net/wiki/spaces/FEP/pages/3499851975/Incentives+Definitions+Rules

...

Make a systemwide offer unavailable:

→ Make a request with availability : false for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint

→ Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the same availability value in the API response

→ Confirm that the systemwide offer(s) no longer appear on the Whitelabel App’s menu section

Consider a cache of up to 1 minute for updates to reflect in whitelabel.

For further context about configuration: Systemwide Offers

Make a premium comboslot item available as part of a combo:

→ Make theIs Premium Item flag enabled (TRUE) in the CMS Sanity for a given comboslot option:

...

→ Tweak the Launch Darkly flag https://app.launchdarkly.com/intl-platform/staging-plk/features/enable-premium-combo-slots/targeting to serve Composite PLU for the given PosVendor.

→ Make a request to Partners-API updateMenuPlus endpoint to define price (if it was 0 previously), and availability : true.

The PLU for the premium comboslot option should follow the pattern comboPlu-itemPlu. (E.g. for the whopper meal medium (PLU=123) to have onion rings (PLU=456) as a premium comboslot option, the price would have to be posted using the plu 123-456.

→ Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the same availability values in the API response

→ Confirm that the premium comboslot appear on the product detail page of products for which it has been configured, and the price reflects as well.

...

Contents

Table of Contents

minLevel	1
maxLevel	4
outline	false
style	none
type	list
printable	true

References

Table of Contents

minLevel	5
maxLevel	6
outline	false
type	flat
separator	pipe
printable	true

🏪 Restaurant Management

Action

How to test

Vendor Action

Expected Result

Update store status

To Online

User inputs restaurant address in the store locator in RBI’s platform.

Update store status to online via Update Store Status endpoint.

Info
RBI's platform will request a recurring update on store status via the Store Heartbeat Webhook.

→ Partners API reports store is online through Get Store Status endpoint.

→ Select button is available and not grayed out.

Image Added

Info
Store ordering availability is not only affected by the POS status, as there are other configurations required to activate stores.

→ RBI admins have access to the Store Diagnostics and can verify that isRestaurantPosOnline: true

Image Added

Update store status

To Offline

User inputs restaurant address in the store locator in RBI’s platform.

Update store status to offline via Update Store Status endpoint.

Info
RBI's platform will request a recurring update on store status via the Store Heartbeat Webhook.

→ Partners API reports store is offline through Get Store Status endpoint.

→ Ordering buttons become grayed out for the store. Mobile ordering is not available at this store warning appears.

Image Added

Info
Store ordering availability is not only affected by the POS status, as there are other configurations required to activate stores.

→ RBI admins have access to the Store Diagnostics and can verify that isRestaurantPosOnline: false

Image Added

🍔 Menu Management

Availability

Info
For all the cases below, for further debugging you can use the Get Store Menu Diff endpoint to identify the changes to the store’s menu after each request.

Note
For all the cases below, consider a cache of up to 1 minute for updates to reflect in

...

RBI’s frontend.

Further context about configuration: Combo Slot

Detailed scenarious are described below:

Image Removed

Make a premium comboslot item unavailable:

→ Same as ‘Making an item unavailable’.

Make a reward available:

→ Make a request with availability : true for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint

Make sure the reward incentive has been correctly defined on Sanity. The incentive is the item or combo that you can apply the reward to. This is the ‘normal’/'regular' item or combo document, not a separate one created like we do for offers. For further context about the configuration: Loyalty Rewards

→ Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the availability values in the API response

→ Confirm that the systemwide offers appear on the whitelabel application.

Consider a cache of up to 1 minute for updates to reflect in whitelabel.

Note that there may be additional rulesets (e.g. only for certain time-between, payment method, etc.) defined for rewards: Mechanics

Make a reward unavailable:

→ Make a request with

Action

Tests

Vendor Action

Expected Result

Make an item available for a certain store

User selects ordering for the corresponding store and navigates to the menu section of the item.

Make a request with price and availability : true for the respective PLU using the Update Store Menu PLUs endpoint.

→ Partners API GET Store Menu PLUs endpoint returns the PLUs with the corresponding price and availability.

→ Item appears in App Menu section with correct price.

Make an item unavailable for a certain store

User selects ordering for the corresponding store and navigates to the menu section of the item.

Make a request with price and availability : false for the respective PLU

(s) to Partner’s API

using the Update Store Menu PLUs endpoint.

→

Make a request to the

Partners API GET Store Menu PLUs endpoint

to validate

returns the

same

PLUs

are returned

with the

same availability value in the API response

→ Confirm that the reward(s) no longer appear on the Whitelabel App

Consider a cache of up to 1 minute for updates to reflect in whitelabel.

For further context about configuration: Loyalty Rewards

Order Creation

Service Modes

Alternative Flows

Order ID

Tender ID

Order Modes

Order Events

Panel

panelIconId	atlassian-question_mark
panelIcon	:question_mark:
panelIconText	:question_mark:
bgColor	#E6FCFF

Potentially unclear points for integrator:

Curbside pickup extra details

Menu: Pricing & Availability

Make an item available:

→

corresponding price and availability.

→ Item disappears from App Menu section.

Make a combo available for a certain store

User selects ordering for the corresponding store and navigates to the menu section of the combo.

Make a request with price and availability : true for the respective PLU(s) using the Update Store Menu PLUs endpoint.

→ Partners API GET Store Menu PLUs endpoint returns the PLUs with the corresponding price and availability.

→ Combo appears in App Menu section with correct price.

Note

Combos availability is not only affected by the Combo PLU, as other menu structures are required. Read about it here.

Combo’s availability depends on its children’s availability as well.

Make a combo unavailable for a certain store

User selects ordering for the corresponding store and navigates to the menu section of the combo.

Make a request with price and availability :

true

false for the respective PLU(s)

to Partner’s API

using the Update Store Menu PLUs endpoint.

Note that items only appear in the whitelabel if they are correctly configured in the CMS (Sanity). For further context about items' configuration: Item

→ Item appears in App Menu section with correct price.

→ Make a request to the

→ Partners API GET Store Menu PLUs endpoint returns the PLUs with the corresponding price and availability.

→ Combo disappears from App Menu section.

Make a modifier multiplier available for a certain store

User selects ordering for the corresponding store and navigates to the item containing the modifier multiplier.

Make a request with price and availability : true for the respective PLU using the Update Store Menu PLUs endpoint.

→ Partners API GET Store Menu PLUs endpoint

to validate

returns the

same

PLUs

are returned

with the

same

corresponding price and availability

value in the API response.

Consider a cache of up to 1 minute for updates to reflect in FE.

Make an item unavailable:

→ Make a request with

.

→ Modifier Multiplier appears in App Menu section with correct price.

Make a modifier multiplier unavailable for a certain store

User selects ordering for the corresponding store and navigates to the item containing the modifier multiplier.

Make a request with price and availability : false for the respective PLU

(s) to Partner’s API

using the Update Store Menu PLUs endpoint

For further context about items' configuration: Item

→ Item disappears in App Menu section

.

→

Make a request to the

Partners API GET Store Menu PLUs endpoint

to validate

returns the

same

PLUs

are returned

with the

same

corresponding price and availability

value in the API response.

Consider a cache of up to 1 minute for updates to reflect in FE.

Make a combo available:

→ Make a

→ Combo appears in App Menu section, with correct price.

→ Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the same price and availability value in the API response.

Consider a cache of up to 1 minute for updates to reflect in FE.

Make a combo unavailable:

→ Make a request with availability : false

.

→ Modifier Multiplier disappears from App Menu section.

Make a Systemwide Offer available for a certain store

User selects ordering for the corresponding store and navigates to the offers page.

Make a request with price and availability : true for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint.

Including the PLU for the main item of the combo - a combo cannot be made available without its main item is available. (E.g. whopper medium burger is the main item of the whopper meal medium combo)
Ensure at least one comboslot within the combo has availability : true - a combo cannot be made available before at least one item in its comboslots are available.

Note that combos only appear in the whitelabel if they are correctly configured in the CMS (Sanity). For further context about combos' configuration: Combo

→ Partners API GET Store Menu PLUs endpoint returns the PLUs with the corresponding price and availability.

→ Offer appears in App Offers page and is available for Mobile redemption with correct price.

Note

Offers availability is not only affected by the offer PLU, as other menu structures are required. Read about it here.

Offer’s availability depends on their benefit’s item availability.

Make a Systemwide Offer unavailable for a certain store

User selects ordering for the corresponding store and navigates to the offers page.

Make a request with price and availability : false for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint.

→ Partners API GET Store Menu PLUs endpoint returns the PLUs with the corresponding price and availability.

→ Offer button for Mobile redemption is grayed out. Offer displays text indicating that it isn't available at the selected location.

Make a premium item (within a comboslot) available as part of a combo

Image Added

Info
Only applicable if the POS supports premium comboslots, that is, combo sides which increase the total combo price

User selects ordering for the corresponding store and navigates to the combo containing the premium item.

Internal configurations should be applied to serve Composite PLU for the given POS Vendor / market.

Make a request with price and availability : true for the respective PLU(s) to Partner’s API using the Update Store

Menu PLUs endpoint. → Make a request to the

Menu PLUs endpoint.

The PLU for the premium comboslot option should follow the pattern comboPlu-itemPlu. E.g. for the whopper meal medium (PLU=123) to have onion rings (PLU=456) as a premium comboslot option, the price would have to be posted using the plu 123-456.

→ Partners API GET Store Menu PLUs endpoint

to validate

returns the

same

PLUs

are returned

with the

same availability value in the API response.

→ Confirm that the combo(s) no longer appear on the Whitelabel App’s menu section

Consider a cache of up to 1 minute for updates to reflect in whitelabel.

For further context about combos' configuration: Combo

Make a modifier multiplier available:

Modifier Multipliers are the options guests can have for each of the ingredients that the brand allows to get modified in each item, they have a PLU related to each of them in a lot of cases but there might be POS exceptions. These are what you might know as ingredients that are modifiable in each of our items like No Tomato (Sandwich), Regular Tomato (Sandwich), Extra Tomato (Sandwich).

→ Make a request with availability : true for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint. Including the modifier PLUs (if applicable).

→ Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the same price and availability values in the API response

→ Confirm that the modifier multipliers appear on the product detail page of products which the modifiers are configured, with correct price (if defined)

Consider a cache of up to 1 minute for updates to reflect in whitelabel.

Note that modifier multipliers only appear in the application if they are correctly configured in the CMS (Sanity), and only for products for which modifiers are configured. Further context about configuration: Modifier Modifier Multiplier

Make a modifier multiplier unavailable:

Modifier Multipliers are the options guests can have for each of the ingredients that the brand allows to get modified in each item, they have a PLU related to each of them in a lot of cases but there might be POS exceptions. These are what you might know as ingredients that are modifiable in each of our items like No Tomato (Sandwich), Regular Tomato (Sandwich), Extra Tomato (Sandwich).

→ Make a request with availability : false

corresponding price and availability.

→ Item appears inside the Combo with the desired premium price.

Make a premium item (within a comboslot) unavailable as part of a combo

Image Added

Info
Only applicable if the POS supports premium comboslots, that is, combo sides which increase the total combo price

User selects ordering for the corresponding store and navigates to the combo containing the premium item.

Internal configurations should be applied to serve Composite PLU for the given POS Vendor / market.

Make a request with price and availability : false for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint.

The PLU for the premium comboslot option should follow the pattern comboPlu-itemPlu. E.g. for the whopper meal medium (PLU=123) to have onion rings (PLU=456) as a premium comboslot option, the price would have to be posted using the plu 123-456.

→ Partners API GET Store Menu PLUs endpoint returns the PLUs with the corresponding price and availability.

→ Item disappears from the Combo.

Make a Reward available for a certain store

Authenticated user selects ordering for the corresponding store and navigates to the rewards page.

User must have enough points to redeem applicable reward.

Make a request with price and availability : true for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint.

→

Make a request to the

Partners API GET Store Menu PLUs endpoint

to validate

returns the

same PLUs are returned with the same availability values in the API response

→ Confirm that the modifier(s) and/or modifier multipliers no longer appear on the product detail page of products which the modifiers are configured

Consider a cache of up to 1 minute for updates to reflect in whitelabel.

Further context about configuration: Modifier Modifier Multiplier

Make a systemwide offer available:

→ Make a request with availability : true

PLUs with the corresponding price and availability.

→ Reward appears in App Rewards page and is available for Mobile redemption with correct price.

Note

Rewards availability is not only affected by the reward PLU, as other menu structures are required. Read about it here.

Reward’s availability depends on their benefit’s item availability.

Make a Reward unavailable for a certain store

Authenticated user selects ordering for the corresponding store and navigates to the rewards page.

User must have enough points to redeem applicable reward.

Make a request with price and availability : false for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint.

→ Partners API GET Store Menu PLUs endpoint

Ensure an incentive has been correctly defined: https://rbictg.atlassian.net/wiki/spaces/COG/pages/4041670827/Systemwide+Offers#Incentives

→ Make a request to the

returns the PLUs with the corresponding price and availability.

→ Reward button for Mobile redemption is grayed out. Rewards displays text indicating that it isn't available at the selected location.

Pricing

Action	Tests	Vendor Action	Expected Result
Change price for an item	User navigates through App Menu.	Make a request with updated price for the respective PLU using the Update Store Menu PLUs endpoint.	→ Partners API GET Store Menu PLUs endpoint

to validate

returns the

same

PLUs

are returned

with the

same price and availability values in the API response

→ Confirm that the systemwide offers appear on the whitelabel application.

Consider a cache of up to 1 minute for updates to reflect in whitelabel.

Systemwide offers only appear in the application if they are correctly configured in the CMS (Sanity). For further context about configuration: Systemwide Offers

Note that there may be additional rules defined for systemwide offers https://rbictg.atlassian.net/wiki/spaces/FEP/pages/3499851975/Incentives+Definitions+Rules

Offer PLU 4017

Make a systemwide offer unavailable:

→ Make a request with availability : false for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint

→ Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the same availability value in the API response

→ Confirm that the systemwide offer(s) no longer appear on the Whitelabel App’s menu section

Consider a cache of up to 1 minute for updates to reflect in whitelabel.

For further context about configuration: Systemwide Offers

Make a premium comboslot item available as part of a combo:

→ Make theIs Premium Item flag enabled (TRUE) in the CMS Sanity for a given comboslot option:

Image Removed

→ Tweak the Launch Darkly flag https://app.launchdarkly.com/intl-platform/staging-plk/features/enable-premium-combo-slots/targeting to serve Composite PLU for the given PosVendor.

→ Make a request to Partners-API updateMenuPlus endpoint to define price (if it was 0 previously), and availability : true.

The PLU for the premium comboslot option should follow the pattern comboPlu-itemPlu. (E.g. for the whopper meal medium (PLU=123) to have onion rings (PLU=456) as a premium comboslot option, the price would have to be posted using the plu 123-456.

→ Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the same availability values in the API response

→ Confirm that the premium comboslot appear on the product detail page of products for which it has been configured, and the price reflects as well.

Consider a cache of up to 1 minute for updates to reflect in whitelabel.

Further context about configuration: Combo Slot

Detailed scenarious are described below:

Image Removed

Make a premium comboslot item unavailable:

→ Same as ‘Making an item unavailable’.

Make a reward available:

→ Make a request with availability : true for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint

Make sure the reward incentive has been correctly defined on Sanity. The incentive is the item or combo that you can apply the reward to. This is the ‘normal’/'regular' item or combo document, not a separate one created like we do for offers. For further context about the configuration: Loyalty Rewards

→ Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the availability values in the API response

→ Confirm that the systemwide offers appear on the whitelabel application.

Consider a cache of up to 1 minute for updates to reflect in whitelabel.

Note that there may be additional rulesets (e.g. only for certain time-between, payment method, etc.) defined for rewards: Mechanics

Make a reward unavailable:

→ Make a request with availability : false for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpoint

→ Make a request to the GET Store Menu PLUs endpoint to validate the same PLUs are returned with the same availability value in the API response

→ Confirm that the reward(s) no longer appear on the Whitelabel App

Consider a cache of up to 1 minute for updates to reflect in whitelabel.

For further context about configuration: Loyalty Rewards

Order Injection: Cart

→ Place Order in Whitelabel App

Order’s cart contains an Item → Order successfully sent and placed in Partner’s POS.

Order’s cart contains a Combo → Order successfully sent and placed in Partner’s POS.

Order’s cart contains an item, with a Modifier Multiplier without (0)

→ Order payload contains Modifier Multiplied PLU

→ Order successfully sent and placed in Partner’s POS, describing the without modifier.

Modifier Multiplier

Order’s cart contains an item, with Modifier Multiplier with (1)

→ Order payload contains Modifier Multiplied PLU

→ Order successfully sent and placed in Partner’s POS, describing the “with” modifier.

Order’s cart contains an item, with Modifier Multiplier extra (2)

→ Order payload contains Modifier Multiplied PLU

→ Order successfully sent and placed in Partner’s POS, describing the “extra(2)” modifier.

Order’s cart contains a combo, with an item that has a Modifier Multiplier without (0)

→ Order payload contains Modifier Multiplied PLU, inside the item, inside the combo.

→ Partner Integration successfully handles a 3 level nested structure in the cart.

→ Order successfully sent and placed in Partner’s POS, describing the without modifier.

Modifier Multiplier

Order’s cart contains a Combo with Premium Items

→ Order payload contains a Combo, with it’s children priced at 0, and premium items priced normally.

→ Order successfully sent and placed in Partner’s POS, priced at combo + premium item cost.

Order’s cart contains a System Wide Offer (Item)

→ Offer contains an item

→ Order successfully sent and placed in Partner’s POS, offer is applied successfully. (Burillo, Alejandro)

The offer is added into cart with correct price

Order’s cart contains a System Wide Offer (Combo)

→ Offer contains a Combo

→ Order successfully sent and placed in Partner’s POS, offer is applied successfully.

The Offer is added into cart with correct price

Order’s cart contains a Config Offer (Item)

→ Offer contains an item

→ Order successfully sent and placed in Partner’s POS, offer is applied successfully.

The Offer is added into cart with correct price

Order’s cart contains a Config Offer (Combo)

→ Offer contains a Combo

→ Order successfully sent and placed in Partner’s POS, offer is applied successfully.

The Offer is added into cart with correct price

Order’s cart contains a Config Offer (Percentage Discount)

→ Offer contains a Order level percentage discount(e.g. 10% discount)

→ Order successfully sent and placed in Partner’s POS, offer is applied successfully.

The price of the Order is 90% of the original price

Order’s cart contains a Loyalty Reward (Item)

→ User with enough loyalty points, selects loyalty reward in loyalty page on Whitelabel App.

→ Order is placed in Whitelabel App, with a cart containing a Loyalty rewards item.

→ Order successfully sent and placed in Partner’s POS.

→ Loyalty reward Item is applied successfully.

Order’s cart contains a Loyalty Reward (Combo)

→ Reward contains a Combo

→ Order successfully sent and placed in Partner’s POS.

→ Loyalty reward Combo is applied successfully.

Example calls:
Identify: During the order placement - We send the offers/rewards so the POS may apply them.
Endpoint: [stage]-[brand]-loyalty-middleware.rbictg.com/loyalty/identify

Code Block
{ "identifier": "number", "posVendor": { "posType": "pos", "storeId": "number", "terminal": "number", "operator": "number", "transactionId": "number" } }

Validate: After totalization - We send a confirmation if everything is okay with the order and the guest's updated point balance if the order is payed (It is a dry run of the update)
Endpoint: [stage]-[brand]-loyalty-middleware.rbictg.com/loyalty/transaction/pos/[orderId]

Code Block

{
    "serviceMode": "serviceMode",
    "channel": "channel",
    "loyaltyId": "LoyaltyId",
    "transactionId": "transactionId",
    "status": "PENDING",
...
    "created": "date",
    "transactionDetails": {
        "payments": [...],
        "posVendor": {...},
        "appliedDiscounts": [
        {
            "details": {
                "displayName": "displayName",
                "type": "REWARD"
            },
            "productId": "number",
            "referenceId": "referenceId"
        }
    ]
 
    }
}

Update: After Payment - We confirm the transaction and update the guest's point balance. We also send loyalty receipt information

Code Block

{
    "loyaltyId": "loyaltyId",
    "transactionId": "transactionId",
    "channel": "RESTAURANT",
    "serviceMode": "TAKEOUT",
    "status": "PENDING",
    "created": "date",
    "transactionDetails": {
        ...
        "posVendor": {
            ...
        },
        "order": [
            {
                "referenceId": "referenceId",
                "name": "name",
                "productId": "productId",
                "incentiveId": "incentiveId",
                "loyaltyEngineId": "loyaltyEngineId",
                "quantity": number,
                "price": price,
                "productType": "reward"
            }
        ]
    }
}

Order’s cart contains a Loyalty Reward (Percentage Discount)

→ Reward contains a Order level percentage discount(e.g. 10% discount)

→ Reward successfully sent and placed in Partner’s POS, offer is applied successfully.

The price of the Order is 90% of the original price

Order discounts -

Jira Legacy

server	System Jira
serverId	255417eb-03fa-3e2f-a6ba-05d325fec50d
key	IREQ-1709

?

Order Injection: In Store
- Service Modes (if applicable)

Pickup Order

→ Pickup Order successfully sent and placed in Partner’s POS.

→ Order shows in the POS as already paid

→ Order shows in the POS with RBI’s order number

→ (If Time Slots flows is activated in the Front-End) Order is kept in the POS and only fired to the kitchen after the amount of seconds sent in the fireOrderInSeconds attribute

→ POS prints the receipt with order number

→ Order shows in the KDS with RBI’s order number

→ Order shows in the ORB with RBI’s order number

Expand

title	Generic testing case

Navigate to the Store Locator.
Select a restaurant using the Pickup option.
Choose an item from the menu and add it to the cart.
Open the cart.
Verify that a loading process occurs, this process is named "GET PRICING".
AC: The pricing process must complete successfully.
AC: The total amount should be displayed and equal to the sum of the item price and applicable tax (if any).
AC: The tax (if applicable) should be displayed near the total amount.
Click on "Continue".
Select the CASH option.
Click on "Place Secure Order".
AC: Ensure the user is redirected to the order confirmation page with a success message.
AC: Confirm that the order is correctly injected into the POS system, including the cart contents and total amount.

Eat in Order

→ Pickup Order successfully sent and placed in Partner’s POS.

→ Order shows in the POS as already paid

→ Order shows in the POS with RBI’s order number

→ (If Time Slots flows is activated in the Front-End) Order is kept in the POS and only fired to the kitchen after the amount of seconds sent in the fireOrderInSeconds attribute

→ POS prints the receipt with order number

→ Order shows in the KDS with RBI’s order number

→ Order shows in the ORB with RBI’s order number

→ The order should include an additional information “Eat in order”

Table Service Order

→ Pickup Order successfully sent and placed in Partner’s POS.

→ Order shows in the POS as already paid

→ Order shows in the POS with RBI’s order number

→ (If Time Slots flows is activated in the Front-End) Order is kept in the POS and only fired to the kitchen after the amount of seconds sent in the fireOrderInSeconds attribute

→ POS prints the receipt with order number

→ Order shows in the KDS with RBI’s order number

→ Order shows in the ORB with RBI’s order number

→ The order should include an additional information “Table service”

→ The order should include the table number provided by the customer in Cart page

Curbside Pickup Order

→ Pickup Order successfully sent and placed in Partner’s POS.

→ Order shows in the POS as already paid

→ Order shows in the POS with RBI’s order number

→ (If Time Slots flows is activated in the Front-End) Order is kept in the POS and only fired to the kitchen after the amount of seconds sent in the fireOrderInSeconds attribute

→ POS prints the receipt with order number

→ Order shows in the KDS with RBI’s order number

→ Order shows in the ORB with RBI’s order number

→ The order should include an additional information “Curbside”

→ The order should include the car plate provided by the customer in Cart page

Order Injection: Delivery orders (if applicable)

Delivery

→ Delivery Order successfully sent and placed in Partner’s POS.

→ The delivery fee should be included in the order information.

Expand

title	Generic testing case

Navigate to the Store Locator.
Select a restaurant using the Delivery option.
Choose an item from the menu and add it to the cart.
Open the cart.
Verify that a loading process occurs, this process is named "GET PRICING".
AC: The pricing process must complete successfully.
AC: The total amount should be displayed and equal to the sum of the item price, delivery fee and applicable tax (if any).
AC: The delivery fee should be displayed.
AC: The tax (if applicable) should be displayed near the total amount.
Click on "Continue".
Select the CASH option.
Click on "Place Secure Order".
AC: Ensure the user is redirected to the order confirmation page with a success message.
AC: Confirm that the order is correctly injected into the POS system, including the cart contents and total amount and the delivery information.

Delivery cancelation

→ Delivery Order successfully sent and placed in Partner’s POS.

→ If a delivery cancellation is requested:

The order should be canceled in the POS.

Delivery rejection

→ Delivery Order successfully sent and placed in Partner’s POS.

→ If the delivery partner rejects the order:

The order should be canceled in the POS.

Order Injection: Time to Kitchen

When an explicit fire order (send to kitchen) event is expected:

Place Order in Whitelabel App

→ Order should be triggered to POS with fireOrderInSeconds=null

On confirmation page click I'm Here button

→ POS receives webhook “Fire Order” (ref: https://eu-bk-partners.rbictg.com/docs/market/#tag/OrderWebhook/operation/webhookOrdersFire )

→ KDS receives the order

When orders are expected to reach the kitchen immediately:

Select Slot Now on checkout page (/cart) and finish process of placing order.

→ Order should be injected to POS with fireOrderInSeconds=0

→ The order should be fired immediately to the Kitchen.

→ KDS receives the order

When pre-ordering is expected, orders to reach the kitchen after a determined delay:

Select Future Slot of pickup on checkout page (/cart) and finish process of placing order.

→ Order should be injected to POS with fireOrderInSeconds={delay} . delay being equal in seconds from now to selected time on the checkout page.

→ After delay seconds have passed, order should be sent to the kitchen, and be displayed in KDS.

Order Events

Test cases for all order events and its flow to mParticle → Braze, etc. Need to create tests for each event.

Expand

title	CREATED

Pre-Conditions:
- User logged in
- Restaurant Selected
Steps:
- Navigate to menu
- Add an Item in the cart
- Place order (Checkout).
AC:
- Partner API should receive the order with partner status as CREATED.

Expand

title	PRICED

Pre-Conditions:
- User logged in
- Restaurant Selected
Steps:
- Navigate to menu
- Add an Item in the cart
- Place order (Checkout).
AC:
- The order needs to have total and tax applied
- Partner API should receive the order with partner status as PRICED.

Expand

title	COMMITED

Pre-Conditions:
- User logged in
- Restaurant Selected
Steps:
- Navigate to menu
- Add an Item in the cart
- Place order (Checkout).
- Click to Continue
- Choose the payment method
- Fill the necessary informations
- Click to pay
- Wait the
AC:
- The partner should receive the order payload
- Partner API should receive the order with partner status as COMMITED

Expand

title	PREPARING

Steps:
- Partner sends an event to update order status
AC:
- Partner API should receive the order with partner status as PREPARING

Expand

title	PREPARED

Steps:
- Partner sends an event to update order status
AC:
- Partner API should receive the order with partner status as PREPARED

Expand

title	ERROR

The error can happen between all described stages and to cover it properly we need to describe some scenarios:
- Error on Pricing → I.e.: The price isn’t configured for the Item and store chosen.
- Error on Payment → I.e.: The information provided for payment is incorrect.
- Error on Commit → I.e.: Error by sending information to the partner end-point
- Error on Update → I.e.: Error on payload sent by partner when changing the status to PREPARED
- Error on Refund → I.e.: Error when trying to refund an order.

Order Cancellation

After execution call to Partners API with the CANCELED Order Event

→ Check whether the status has been changed to cancel

→ Check whether the automatic refund has been processed (if applicable)

→ Check whether the cancellation email was triggered

→ Check whether delivery has been cancelled (if applicable)

Payment

→ Ensure payments are successfully processed using each payment method

Order cancelation

→ When the order is canceled in the POS the payment should be refunded

corresponding updated price.

→ Item price appears updated in the App Menu section with correct price.

This test should be run for all menu structures described in the previous section.

💰 Checkout

Order Creation

You can learn about the checkout actions in the Partner API here: Order API - Checkout

Action

How to test

Vendor Action

Expected Result

Pricing Order

Info

Orders are priced at the checkout to confirm how much a user will be charged.

Regardless of the pricing and availability information cached at the application level, the POS is queried one last time to provide the final answer for Pricing and Availability of the selected cart products.

Authenticated user selects ordering for the corresponding store, adds items to cart and navigates to checkout.

All available Cart Structures must be tested:

Item
Item with modifiers
Combo
Combo with items with modifiers
Systemwide Offer Item
Systemwide Offer Combo
Systemwide Offer Combo with modifiers
Reward Item
Reward Combo
Reward Combo with modifiers
Promo Codes - Amount Discount
Promo Codes - Percentage Discount

Partner is subscribed to the Price Order webhook. The payload of the webhook includes the order contents for the selected store ID, service mode, and other details.

Partner must return the price and availability for each item in the order, the total price and any errors using the Price Webhook Callback endpoint.

Error Handling must follow the message and code standards:

Message: Include a clear and concise error message. Include information that would lead to the fixing and understanding of the error occurred. (e.g.: Offending PLUs, store status, etc.).
Do not include redundant information like: Error occurred while processing request.
Code Enum: "MENU" "STORE" "TIMEOUT" "UNKNOWN"

→ /cart page loads total price of the cart, corresponding to the sum of all products within.

→ Loading time does not exceed 3 seconds for p99.

→ Tax, Subtotal, and Total are visible at checkout

Info
Requirement for tax information varies from market to market. For example, some markets don't require a separate tax line as tax is included in the menu item price.

→ (OPTIONAL) Fees, such as “Bag Fee”, are visible in the /cart page, separately from total cart amount.

Commit Order

Info
After a successful pricing and payment, the order needs to be acknowledge by and registered in the POS.

After pricing an order, an authenticated user pays, and continues with the placement the order.

All available Cart Structures must be tested in this category:

Item
Item w/ modifiers
Combo
Combo with items w/ modifiers
Systemwide Offer Item
Systemwide Offer Combo
Systemwide Offer Combo w/ modifiers
Promo Codes - Amount Discount
Promo Codes - Percentage Discount
Reward Item
Reward Combo
Reward Combo with modifier

Partner is subscribed to the Commit Order webhook. The payload of the webhook includes the service mode, order id, total order price and customer details, among other details.

All order information can also be fetched from the GET Order endpoint, at any time.

The POS must respond to the webhook request by using the Commit Webhook callback endpoint.

Error Handling must follow the message and code standards:

Message: Include a clear and concise error message. Include information that would lead to the fixing and understanding of the error occurred. (e.g.: Offending PLUs, store status, etc.).
Do not include redundant information like: Error occurred while processing request.
Code Enum: "MENU" "STORE" "TIMEOUT" "UNKNOWN"

→ Order is registered in the POS.

Note

Committing and order does not mean that the order should be prepared immediately.

In the Commit Order webhook payload we include the fireOrderInSeconds field which indicates when the order should be sent (or 'fired') to the kitchen for preparation. In some case the fire webhook will be needed to determine when the order should be fired.

This will vary by service mode and payment method – see tables below.

Cancel Order – Initiated by guests or delivery fulfillment providers

Info
Orders might get canceled either by guests or delivery providers.

Initiated by guest: for pick up order, guest selects the Cancel Order option.

Image Added

Initiated by delivery provider: order is canceled by the delivery provider in their Driver Management Portal.

Partner is subscribed to the Order Event webhook. Upon cancelation, the webhook will return an event with status CANCELED.

The POS must acknowledge the cancelation and mark the order as canceled in the POS.

→ Order status is changed to CANCELED. You can check it using the GET Order endpoint.

→ An automatic refund is processed (if applicable).

→ A cancellation email is triggered.

Cancel Order – Initiated by POS

Info
Exceptionally, the POS vendor may cancel an order.

Restaurant team member cancels order in the POS.

Partner send status CANCELED using the Order Event endpoint.

→ Order status is changed to cancel. You can check it using the GET Order endpoint or in the Order Event webhook.

→ An automatic refund is processed (if applicable).

→ A cancellation email is triggered.

Order firing for in-restaurant service modes

Below you can find the how to deal with order firing for paid in-restaurant orders.

Info

In the below cases, when we reference the Order Number from RBI, the following is expected:

RBI’s order number should substitute the POS order number in the receipt.
RBI’s order number is configurable – it can contain numbers and/or letters.

Info

KDS = Kitchen Display Screen.

ORB = Order Ready Board, which are the customer-facing screens in the restaurant.

DSS = Dynamic Service System. It consists on a set of operational procedures which improve order accuracy and speed of service. From a POS standpoint it requires the printing of sticky labels.

You can find more details about the order firing mechanism here: https://rbictg.atlassian.net/wiki/spaces/RDP/pages/5003083791/Order+API+-+Checkout#Fire-webhook-%26-endpoint

Action

How to test

Vendor Action

Expected Result

Place a Dine In / Pickup

Immediate order (Now)

Authenticated user selects ordering for the corresponding store, builds a cart and navigates to checkout.

User selects Dine In or Pick Up and order time Now.

Image Added

Partner injects order the POS using the corresponding service Mode and number.

The Partner has received all relevant information to the order previously via the pricing webhook: service mode (TAKEOUT) , order number, etc.

All order information can also be fetched from the GET Order endpoint, at any time.

fireOrderInSeconds: 0 indicates the order should be fired to the kitchen immediately.

→ Order is registered in the POS.

→ KDS identifies the service mode.

→ DSS ticket printed according to the service mode.

→ Receipt printed with Order Number from RBI.

→ ORB displays Order Number from RBI.

Note
Guests rely exclusively on this number to identify their online orders.

Place a Drive-Thru order

Immediate order (Now)

Authenticated user selects ordering for the corresponding store, builds a cart and navigates to checkout.

User selects Drive Thru. No time selection appears at checkout.

Partner injects order the POS using the corresponding service Mode and number.

The Partner has received all relevant information to the order previously via the from pricing webhook: service mode (DRIVE_THRU) , order number, etc.

All order information can also be fetched from the GET Order endpoint, at any time.

fireOrderInSeconds: null indicates the order should be held in the POS until the order is released.

→ Order is registered in the POS but not sent to the kitchen.

→ When the guest arrives at the restaurant, a team member manually fires the order to the kitchen from the POS.

At that point,

→ DSS ticket printed.

→ Receipt printed with Order Number from RBI.

→ ORB displays Order Number from RBI.

Place a Table Service order

Immediate order (Now)

Authenticated user selects ordering for the corresponding store, builds a cart and navigates to checkout.

User selects Table Service and inputs the desired table number.

Image Added

No time selection appears.

Partner injects order the POS using the corresponding service Mode and number.

The Partner has received all relevant information to the order previously via the from pricing webhook: service mode (TABLE_SERVICE) , order number, etc. The table service is provided under the instructions field.

All order information can also be fetched from the GET Order endpoint, at any time.

fireOrderInSeconds: 0 indicates the order should be fired to the kitchen immediately.

→ Order is registered in the POS with reference to the table number.

→ KDS identifies the service mode.

→ KDS identifies the table number.

→ DSS ticket printed according to the service mode.

→ DSS ticket printed with the table number.

→ Receipt printed with the table number.

→ Receipt printed with order number from RBI, though at a less relevant place, since table number should take precedence to the order number.

Note
Crew members rely on an easy identification of the table number to identify where this order should be taken to.

Place a Dine In / Pickup order

Future order (Scheduled)

Authenticated user selects ordering for the corresponding store, builds a cart and navigates to checkout.

User selects Dine In or Pick Up and order time equivalent to any slot in the future.

Image Added

Partner injects order the POS using the corresponding service Mode and number.

The Partner has received all relevant information to the order previously via the pricing webhook: service mode (TAKEOUT) , order number, etc.

All order information can also be fetched from the GET Order endpoint, at any time.

fireOrderInSeconds: X indicates the order should be fired to the kitchen X seconds after the order is placed.

→ Order is registered in the POS.

→ Order appears in the KDS X seconds after POS order injection.

→ KDS identifies the service mode.

→ DSS ticket printed according to the service mode.

→ Receipt printed with Order Number from RBI.

→ ORB displays Order Number from RBI.

Note
Guests rely exclusively on this number to identify their online orders.

Place a Curbside order

Authenticated user selects ordering for the corresponding store, builds a cart and navigates to checkout.

User selects service mode. No time selection appears.

User inputs the car plate number, places the order and is taken to an order confirmation page with an “I’m here” button.

Partner injects order the POS using the corresponding service Mode and number.

The Partner has received all relevant information to the order previously via the pricing webhook: service mode (CURBSIDE) , order number, etc.

All order information can also be fetched from the GET Order endpoint, at any time.

fireOrderInSeconds: null indicates the order should be held in the POS until the order is released.

→ Order is registered in the POS but not sent to the kitchen.

→ When the guest clicks on I’m here, the order is sent to the kitchen.

Info
When that happens, the the fire webhook will be triggered. Partner should be listening to that webhook to know when to fire the order.

At that point:

→ KDS identifies the service mode.

→ KDS identifies the table number.

→ DSS ticket printed according to the service mode.

→ DSS ticket printed with the table number.

→ Receipt printed with the car plate.

→ Receipt printed with order number from RBI and car plate, which should be more visible than the order number.

Note
Crew members rely on an easy identification of the car plate number to identify where this order should be taken to.

Expand

title	Payment methods for in-restaurant orders (WIP)

Payment methods for in-restaurant orders

Note
Applicable only to In-Restaurant orders.

Action

How to test

Vendor Action

Expected Result

Place a cash (or any other unpaid) in-restaurant order

Same process described in previous table for any service mode (Dine In, Pick Up, Table Service…).

User selects cash in the payment page.

Image Added

Partner collects the payment method from the GET Order endpoint (CASH or UNPAID) and injects in the appropriate POS field.

Typically, POS systems define Tender IDs for this purpose.

→ Order is injected in the POS.

→ Order is not sent to the kitchen.

→ Order is sent to the kitchen after user performs the payment.

E.g. guest places a Pick Up order for 5:30pm and pays with cash. Guest arrives at the restaurant and pays for order at front counter, team member sendd order to the kitchen.

Place an online payment (paid) in-restaurant order

Same process described in previous table for any service mode (Dine In, Pick Up, Table Service…).

In the payment page, user selects credit card or any other alternative payment method that leaves the order paid.

Image Added

Partner collects the payment method from the GET Order endpoint and injects in the appropriate POS field.

Typically, POS systems define Tender IDs for this purpose.

Any payment method besides CASH and UNPAID falls under this category.

→ Order is injected in the POS and sent to the kitchen, following the fireOrderInSeconds logic explained in the table above.

Delivery orders

Action

Tests

Vendor Action

Expected Result

Place a Delivery order

Authenticated user inputs address within covered delivery area on restaurant locator in App, builds a cart and navigates to checkout.

Authenticated user clicks on “Continue” on the checkout page, and confirms selecting any payment method by clicking “Place Secure Order”.

The Partner has received all relevant information to the order previously via the from pricing webhook: service mode (DELIVERY) , order number, etc.

All order information can also be fetched from the GET Order endpoint, at any time.

fireOrderInSeconds: null indicates the order should be held in the POS until the order is released.

→ Order is registered in the POS.

→ Order does not appear in the KDS (not fired into the kitchen).

Fire a Delivery order into the kitchen

Delivery fulfillment provider requests to move the order to kitchen based on the driver’s geolocation or driver’s ETA to the restaurant.

Partner is subscribed to the ORDER_FIRE webhook, which triggers a request to fire an order into the kitchen.

Partner fires the order through a POST call to the Fire Order endpoint.

Info
Firing is expected to happen when the driver is at a distance / time from the restaurant equal or lower to the preparation time (prep time). The POS vendor is not required to compute any logic, as RBI is responsible for informing the POS vendor when to fire orders.

→ Order appears in the KDS (is fired into the kitchen).

→ KDS identifies the service mode.

→ DSS ticket printed according to the service mode.

→ Receipt printed with Order Number from RBI.

RBI’s order number is expected to substitute the POS order number.
RBI’s order number is configurable, allowing numerical interval restriction and / or utilization of an alphanumerical prefix.

Note
Drivers rely exclusively on this number to identify the order they are supposed to pick up at the restaurant.

Order Events (WIP)

Action

Tests

Vendor Action

Expected Result

Expand

title	CREATED

Pre-Conditions:
- User logged in
- Restaurant Selected
Steps:
- Navigate to menu
- Add an Item in the cart
- Place order (Checkout).
AC:
- Partner API should receive the order with partner status as CREATED.

Expand

title	PRICED

Pre-Conditions:
- User logged in
- Restaurant Selected
Steps:
- Navigate to menu
- Add an Item in the cart
- Place order (Checkout).
AC:
- The order needs to have total and tax applied
- Partner API should receive the order with partner status as PRICED.

Expand

title	COMMITED

Pre-Conditions:
- User logged in
- Restaurant Selected
Steps:
- Navigate to menu
- Add an Item in the cart
- Place order (Checkout).
- Click to Continue
- Choose the payment method
- Fill the necessary informations
- Click to pay
- Wait the
AC:
- The partner should receive the order payload
- Partner API should receive the order with partner status as COMMITED

Expand

title	PREPARING

Steps:
- Partner sends an event to update order status
AC:
- Partner API should receive the order with partner status as PREPARING

Expand

title	PREPARED

Steps:
- Partner sends an event to update order status
AC:
- Partner API should receive the order with partner status as PREPARED

Expand

title	ERROR

The error can happen between all described stages and to cover it properly we need to describe some scenarios:
- Error on Pricing → I.e.: The price isn’t configured for the Item and store chosen.
- Error on Payment → I.e.: The information provided for payment is incorrect.
- Error on Commit → I.e.: Error by sending information to the partner end-point
- Error on Update → I.e.: Error on payload sent by partner when changing the status to PREPARED
- Error on Refund → I.e.: Error when trying to refund an order.

...

Menu Availability Validation

Object

Available

section

If any section options are available

combo

If combo.plu exists in restaurant pos data for the selected store &&

main item is available &&

All the combo slot are available

combo slot

At least Minimum Amount item under combo slot options is available

item

If item.pluexists in restaurant pos data for the selected store &&

If, for any item option that has inject default selection flag set to true, at least one item option modifieris available under the item option.

Note

Warning:

second condition is not currently supported by FE
if the plu type is set as Empty, the item is treated as unavailable

item option

If any item option modifier are available for the item option

Example: If all item option modifiers are unavailable for a specific item option, i.e. lettuce, the entire item option is not displayed on the FE

item option modifier

Ifmodifier multiplier.plu exists in the pos data for the selected store or the plu type is Ignore, and themodifier.plu is in the store pos data

Note

Warning:

Empty PLU type is treated as unavailable. If an Item Option modifier was configured to Empty type, the item would appear as unavailable. If that item was the only item in the combo slot, the combo slot and combo would then appear as unavailable.

picker

if any picker options are available

picker aspect value

if any picker options that have thepicker aspect value mapped are available

Offer Availability Validation

Pass all the Rules validation set in Mechanics-Rules, the important rules can be Service Mode, Valid Time Span, Authentication Required and so on, the full list can be found in Rulesets for Offers, Rewards and Promotions.
Ensure the benefit set in Mechanics-Benefits is available, the availability validation follows the same logic in the /wiki/spaces/~834441867/pages/4822433853 section. Because the benefit can be item, combo and picker, so the important is to check accordingly.

Versions Compared

Old Version 4

New Version Current

Key

Store Availability

Store Menu Pricing & Availability

🏪 Restaurant Management

🍔 Menu Management

Availability

Order Creation

Service Modes

Alternative Flows

Order ID

Tender ID

Order Modes

Order Events

Pricing

💰 Checkout

Order Creation

Order firing for in-restaurant service modes

Payment methods for in-restaurant orders

Delivery orders

Order Events (WIP)

Menu Availability Validation

Offer Availability Validation

Page Comparison

Versions Compared

Old Version 4

New Version Current

Key

Store Availability

Store Menu Pricing & Availability

🏪 Restaurant Management

🍔 Menu Management

Availability

Order Creation

Service Modes

Alternative Flows

Order ID

Tender ID

Order Modes

Order Events

Pricing

💰 Checkout

Order Creation

Order firing for in-restaurant service modes

Payment methods for in-restaurant orders

Delivery orders

Order Events (WIP)

Menu Availability Validation

Offer Availability Validation