Page Comparison

Contents

...

Contents

Table of Contents

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

...

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.

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

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

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 premium item (within a comboslot) available as part of a combo

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

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 appears inside the Combo with the desired premium price.

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

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

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

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

Make a Reward available for a certain store

Authenticated user selects ordering for the corresponding store and navigates to the rewards 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.

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

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

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

Make a Reward unavailable for a certain store

Authenticated user selects ordering for the corresponding store and navigates to the rewards 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.

→ Reward button for Mobile redemption is grayed out.

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

Order Creation

Action	Tests	Expected Vendor Behavior	Expected Result

In-Restaurant Service Modes

Action	Tests	Expected Vendor Behavior	Expected Result

Order Injection: Time to Kitchen

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.

In-Restaurant Service Modes

Place a Dine In / Pickup / Drive-Thru

Action

Tests

Expected Vendor Behavior

Expected Result

Place a Dine In / Pickup / Drive-Thru order

Immediate order (Now)

As per above.

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

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

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

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

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
Guests rely exclusively on this number to identify their online orders.

Place a Table Service order

Immediate order (Now)

As per above.

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

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

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

→ 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 Order Number from RBI.→ ORB displays Order Number from RBIthe 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.

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
Guests Crew members rely exclusively on this on an easy identification of the table number to identify their online orderswhere this order should be taken to.

Place a Table Service Curbside order

Immediate order (Now)

As per above.

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

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

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

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

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

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
Crew members rely on an easy identification of the table car plate number to identify where this order should be taken to.

Place

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 pagea Dine In / Pickup / Drive-Thru order

Future order (Scheduled)

As per above.

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

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

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

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

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
Guests rely exclusively on this number to identify their online orders.

Place a Table Service order

Future order (Scheduled)

As per above.

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

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

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

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

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

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

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
Crew members rely on an easy identification of the table number to identify where this order should be taken to.

Place a Curbside order

Future order (Scheduled)

As per above.

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

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

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

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

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

→ 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, though at a less relevant place, since car plate should take precedence to the order number.

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
Crew members rely on an easy identification of the car plate number to identify where this order should be taken to.

Delivery Service Mode

Action	Expected Vendor Behavior	Expected Result
Place a Delivery order	Partner collects the service mode (`serviceMode`) from the GET Order endpoint (`DELIVERY`) and injects in the POS. `fireOrderInSeconds: null` indicates the order should not be fired to the kitchen, and instead be injected to the POS in suspended mode.	→ Order is injected in the POS. → Order does not appear in the KDS (not fired into the kitchen).
Fire a Deliver order into the kitchen	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. 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.


Cancel a Delivery order 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.

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.

Place a Table Service order

Place a Delivery In order

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

...

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

...

Versions Compared

Old Version 13

New Version 14

Key

Order Creation

In-Restaurant Service Modes

In-Restaurant Service Modes

Delivery Service Mode

Order Number

Menu Availability Validation