High Level
“Error communicating with POS”
Why: One of our POS integration functions failed while communicating with POS.
Handling: Next steps should depend entirely on the “Function” and “Error” fields. See below for more details.
“No order confirmation received from POS”
Why: This POS never “called back” to tell us whether an order was processed or not, and after a while (“POS Timeout Minutes” from CMS, to be exact) we gave up.
Handling: The customer has already been SMS’d to tell them that there’s a problem, and the order will appear in Live Orders in VenMan.
Usually, this will mean there is a connectivity issue, so contacting the venue should be next.
"Tag assigned to an invalid location"
Why: The user has tapped onto a QR/NFC beacon, but either the Location or the specific Section has been deleted.
Handling: Escalate to L2.
"Order rejected by POS"
Why: This POS has “called back” to tell us that they couldn’t process the order.
Handling: The “Reason” property generally comes straight from POS so should help you plan the next steps.
Reasons are POS specific and can range from connectivity issues to bad or misconfigured SKUs, or POS/me&u configuration issues causing the order not to balance.
Sometimes the reason is vague (eg. doesn’t specify the problem SKU): use the Supportal link + CMS to cross-check product and modifiers.
"Order failed option validation"
Why: This POS has “called back” to tell us that they couldn’t process the order, meaning submitting the order and not paying for the order on the payment/order summary screen.
Handling: The “Item” and “Item SKU” fields indicate the problem item. If relevant, the “Option” and “Option SKU” fields indicate the specific modifier on that item that is an issue.
When present, the “Error” property will help to understand the problem, and in some cases may come from POS. Common messages include:
“Modifier not allowed on product” - This POS does not allow orders that include modifiers on products if they are not already linked on the POS end, and such a link was not found.
“Modifier SKU not found” - The modifier option SKU was not found in the POS
If there is no “Error” property, assume that the error is “No such SKU exists” - referring to the Option (if specified) or Product.
"Order failed option validation - price conflict"
Why: This POS does not support overriding its product and/or modifier prices, and our price does not match theirs.
Handling: Update the offending price and publish.
If the “Rejected?” field is “no” then the order was not blocked, and the user is free to pay and complete the order. In this scenario, the order will not balance in POS.
Specific “Functions”
For “Error communicating with POS” errors, the “Function” field indicates what me&u was trying to do when the error occurred.
OrderValidate
When: Occurs when the user clicks “Go to checkout”
What: We validate what we can about the order and venue’s POS configuration. If supported, we also validate the product/modifier SKUs.
Handling: If only a one-off and the “Error” indicates some kind of transient / connection error, there is no action. The customer will be given the opportunity to retry again.
OrderCreateQueue-{POS}
When: Occurs after the user has paid and “completed” the ordering process.What: This is where we submit the order to POS. Some POS will accept/reject it on the spot, but for others, we might need to be “called back” to find out whether it’s been successful.
Handling: If only a one-off and the “Error” indicates some kind of transient / connection error, there is no action. The customer will be given the opportunity to retry again.
PollOrderStatus
When: We have to periodically ask the POS whether the order has been processed yet.
Handling: If it’s a one-off, it can be ignored as the system will poll again in a few seconds. If it’s been consistently erroring for > 30 seconds, raise to L2
{POS}-{Event} (eg. “Doshii-OrderUpdated”)
When: POS has contacted us to tell us something (Order has been updated, Product has been deleted) etc
Handling: Raise to L2
Specific “Exception” Errors
{POS}ErrorException (eg. “KountaErrorException”)
When: The POS has returned an error response. Most of the time, the “Error” field will make sense to the POS vendor.
If the error contains “<html>” then the POS returned a webpage error instead of a structured one, and the text represents a summarised view of that page.
Handling: Specific to each POS, so follow the “POS Type” field link to Helpjuice. Raise to L2 if unknown.
HttpRequestException / IOException
When: Either a general connectivity error or the POS did not respond in a way we could handle (usually an error but without specific information)
Handling:
“Response status code does not indicate success: 123 (XYZ).” - Follow “POS Type” link to Helpjuice to see if there are any known scenarios that cause the specific error. Any 5xx (500-599) errors mean that something went wrong on their end - 404 can occasionally also indicate the same. Raise to L2 if more than a blip.
InvalidOperationException / FormatException / ArgumentException
When: These are usually me&u complaining about the data order the order or POS config (for example “SKUless modifiers not supported when no Default SKU configured”)
Handling:
Follow “POS Type” link to Helpjuice to see if there is any documentation on the specific error message. Otherwise, raise to L2 if the error message is not helpful (“Nullable object must have value”)
NullReferenceException
When: This is an error on the me&u side, though usually caused by the POS not returning data that we are relying on.
Handling:
Raise to L2, they might be able to help understand and resolve. A potential touching point on the weekly Bugs meeting.
Order Statuses
The list of response reasons includes:
Rejected: Submit operation was successful, but the POS rejected the order.
Orphaned: Submit operation timed out
Failed to submit: Submit operation failed
Of these, any orders with responses of Orphaned or failed to submit have a status of Unconfirmed.
Clarifying the statuses
We defined Unconfirmed orders as any order that requires an operation from the front-of-house staff to remedy an issue, such as a refund, manual data entry, or a conversation with a customer.
We defined Confirmed orders as any order that requires no intervention
As such, Rejected orders should be considered unconfirmed.