Versions Compared

Key

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

Contents

Table of Contents
minLevel1
maxLevel4
outlinefalse
stylenone
typelist
printabletrue

...

Table of Contents
minLevel5
maxLevel6
outlinefalse
typeflat
separatorpipe
printabletrue

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.

image-20240815-141535.pngImage Modified

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

image-20240815-141749.pngImage Modified

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.

image-20240815-142116.pngImage Modified

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

image-20240815-141749.pngImage Modified

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

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

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.

→ Combo disappears from App Menu section.

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

Make a modifier multiplier available for a certain store

Authenticated 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(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.

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

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

Make a modifier multiplier unavailable for a certain store

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

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

→ Modifier Multiplier disappears from App Menu section.

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

Make a Systemwide Offer available for a certain store

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

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

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

Make a Systemwide Offer unavailable for a certain store

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

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

Make a

systemwide offer available

premium comboslot item available as part of a combo:

→ Make

a request with availability : true for the respective PLU(s) to Partner’s API using the Update Store Menu PLUs endpointEnsure an incentive has been correctly defined:

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

image-20240216-202316-20240318-185006.pngImage Added

→ Tweak the Launch Darkly flag https://

rbictg

app.

atlassian

launchdarkly.

net

com/

wiki/spaces/COG/pages/4041670827/Systemwide+Offers#Incentives

intl-platform/staging-plk/features/enable-premium-combo-slots/targeting to serve Composite PLU for the given PosVendor.

→ 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

Make a systemwide offer unavailable

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-20240318-184606.pngImage Added

Make a premium comboslot item unavailable:

→ Same as ‘Making an item unavailable’.

Make a reward available:

→ Make a request with availability :

false

true 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
  • 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

same

availability

value

values in the API response

→ Confirm that the systemwide

offer(s) no longer

offers appear on the

Whitelabel App’s menu section

whitelabel application.

  • 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-20240216-202316-20240318-185006.pngImage 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-20240318-184606.pngImage 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 Creation

Service Modes

Alternative Flows

Order ID

Tender ID

Order Modes

Order Events

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

→ Make a request with price and availability : true 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 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 an item unavailable:

→ Make a request with 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 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 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

→ 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

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-20240216-202316-20240318-185006.pngImage 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-20240318-184606.pngImage 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",

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 Creation

Action

Tests

Expected Vendor Behavior

Expected Result

Order Number

Action

Tests

Expected Vendor Behavior

Expected Result

Place a Dine In order

As per above.

Partner collects the order number (number) from the GET Order endpoint and injects in the POS.

Order is injected in the POS.

Receipt printed with Order Number from

 

Service Modes

Action

Tests

Expected Vendor Behavior

Expected Result

Alternative Flows

Payment Methods

Action

Tests

Expected Vendor Behavior

Expected Result

Place a Cash or any other Unpaid in-restaurant order

As per above.

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 injected in KDS (Kitchen Display System), i.e. it is not sent to the kitchen.

→ Order is injected in KDS after user performs the payment.

Place an online payment (paid) in-restaurant order

As per above.

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 in KDS.

In-Restaurant Service Modes

Action

Tests

Expected Vendor Behavior

Expected Result

Place a Dine In order

As per above.

Partner collects the service mode (serviceMode) from the GET Order endpoint (EAT_IN) and injects in the POS.

→ Order is injected in the POS.

→ KDS identifies the service mode.

→ DSS ticket printed according to the service mode.

 

Place a Table Service order

As per above.

Partner collects the service mode (serviceMode) from the GET Order endpoint (TABLE_SERVICE) and injects in the POS.

→ Order is injected 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.

 

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

Delivery Service Mode

Action

Tests

Expected Vendor Behavior

Expected Result

Order Injection: Delivery orders

Delivery

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

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

Expand
titleGeneric 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 Events

Panel
panelIconIdatlassian-question_mark
panelIcon:question_mark:
panelIconText:question_mark:
bgColor#E6FCFF

Potentially unclear points for integrator:

  • Curbside pickup extra details








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": {
          "posType": "pos",
 ...
       "storeId": "number" },
        "terminalorder": [
"number",         "operator   {
                "referenceId": "numberreferenceId",
                "transactionIdname": "numbername",
    }
}
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
{            "productId": "productId",
                "serviceModeincentiveId": "serviceModeincentiveId",
    "channel": "channel",     "loyaltyId": "LoyaltyId",     "transactionIdloyaltyEngineId": "transactionIdloyaltyEngineId",
      "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
serverSystem Jira
serverId255417eb-03fa-3e2f-a6ba-05d325fec50d
keyIREQ-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
titleGeneric 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
titleGeneric 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.
         "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
serverSystem Jira
serverId255417eb-03fa-3e2f-a6ba-05d325fec50d
keyIREQ-1709
?

  •  

  •  

  •  

  •  

  •  

  •  

  •  

  •  



Order Injection: Time to Kitchen

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

  1. Place Order in Whitelabel App

→ Order should be triggered to POS with fireOrderInSeconds=null

  1. 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
titleCREATED
  • 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
titlePRICED
  • 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
titleCOMMITED
  • 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
titlePREPARING
  • Steps:

    • Partner sends an event to update order status

  • AC:

    • Partner API should receive the order with partner status as PREPARING

Expand
titlePREPARED
  • Steps:

    • Partner sends an event to update order status

  • AC:

    • Partner API should receive the order with partner status as PREPARED

Expand
titleERROR
  • 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.

...

Menu Availability Validation

...