{"title":"Open orders reference","slug":"pos-open-orders-reference","url":"https://support.storeconnect.com/articles/pos-open-orders-reference","url_markdown":"https://support.storeconnect.com/articles/pos-open-orders-reference.md","subtitle":null,"summary":"How a POS open order (a bar tab or table order) is represented in Salesforce, what the submit step does to items and fulfillments, and which store variables and package version the feature depends on.","type":"Developer_Documentation","video_url":"","keywords":"open order, open orders, open a tab, bar tab, table order, POS_Order_Type, OPEN, s_c__Memo__c, Cancelled_At, submit, idempotent upsert, sc_id, fulfillment, pos.open_orders.enabled, pos.memo.label, POS data model, hospitality","last_modified":"2026-10-25T22:50:31+0000","body_markdown":"An open order is an order that stays editable while a customer keeps adding to it, then is paid at the end of the visit. Hospitality businesses describe it as a tab or a table order. This topic covers how one is stored and what each stage does to the records, for anyone building an integration, a report, or a custom POS layout around the feature.\n\nFor the operator procedure, see [Start an open order](pos-open-orders). For enabling the feature, see [Configure open orders](configure-pos-open-orders).\n\n## Requirements\n\n| Requirement | Value |\n|---|---|\n| Package version | 21.3.0 or later (21.2.0 adds `s_c__Memo__c`, 21.3.0 adds the order item cancellation fields) |\n| Store variable | `pos.open_orders.enabled` set to `true` |\n| Optional store variable | `pos.memo.label` to rename the memo label shown to staff |\n\n## How an open order is stored\n\nAn open order is an ordinary Order record with two things that distinguish it: a type stamp and a live link to a cart.\n\n| Record | Field | Meaning |\n|---|---|---|\n| [Order](order-object-reference) | `s_c__POS_Order_Type__c` | Set to `OPEN` while the order is open. The same field carries other POS order types, such as `Layby`. |\n| [Order](order-object-reference) | `s_c__Memo__c` | The staff-facing identifier, Text(80), for example a table number or a customer name. |\n| [Cart](cart-object-reference) | `s_c__Order_Id__c` | Links the working cart to the open order. Resuming an order finds its cart through this lookup. |\n| [Order Item](orderitem-object-reference) | `s_c__Cancelled_At__c` | When a submitted line was canceled. |\n| [Order Item](orderitem-object-reference) | `s_c__Cancelled_By_User_Id__c` | The user who canceled it. |\n\nThe cart is the working surface and the order is the committed record. Items exist on the cart as soon as staff add them, and reach the order only when they are submitted. Query `s_c__POS_Order_Type__c = 'OPEN'` to list the orders currently running in a venue.\n\nAn open order is created as a shell: no payments, no fulfillments, and no finalization. It is not put through the checkout pipeline until it is paid.\n\n## What submit does\n\nSubmitting sends the whole cart to the linked order, not a narrow patch of the changes. That matters when building anything that reads the result.\n\n- **Idempotent by line.** The server upserts each line by its `sc_id`, so resubmitting an unchanged order changes nothing.\n- **Repricing.** Every line is repriced on submit, because a customer change can move prices across the whole order. Once a payment has been recorded against the order, repricing is skipped so a settled total cannot drift away from what was paid.\n- **Quantity splitting.** A line with a quantity above 1 is split into individual single-unit lines on both the cart and the order, so each unit is tracked, prepared, and canceled independently. A unit discount carries across unchanged and a line-level transaction discount is distributed across the split lines, leaving the total unchanged.\n- **Fulfillment fan-out.** Each submit creates fulfillments only for lines that route to a fulfillment station and do not have one yet, grouped by fulfillment type, stock location, and fulfillment station. Lines with no station get their fulfillments at checkout, so in a store without station routing a submit creates no fulfillments. Successive submits therefore produce separate fulfillments, which is what makes each round its own kitchen ticket. Lines with a `delivery` fulfillment type are left for the checkout shipping flow.\n- **Cancellation.** A line submitted with a quantity of 0 is stamped canceled on the server. Restoring the quantity clears the stamp.\n- **Commit only.** Submitting does not clear the cart. The POS cart's **Submit** button pairs the submit with `cart:new` to free the register.\n\n## Lifecycle actions\n\nThe actions below drive the feature and can be placed on POS action items or called from custom JavaScript through [scAction](pos-sc-action). Parameters for each are documented in the [POS actions reference](pos-actions-reference).\n\n| Stage | Action |\n|---|---|\n| Create against a fresh cart | `cart:new:open_order` |\n| Convert the active cart | `cart:update:open_order` |\n| Edit the memo in place | `open_order:update` |\n| Commit the cart to the order | `open_order:submit` |\n| Resume for another round | `order:resume` |\n| Cancel a single submitted line | `cart:item:cancel` |\n| Cancel the order | `order:cancel` |\n\n## Taking payment\n\nAn open order is paid by resuming its cart and checking out, not by an order-level payment. Calling `checkout:start` with the `order_sc_id` of an open order is declined with `This order is still open. Resume it to take payment.` Resume it with `order:resume` and start checkout from the resulting cart instead.\n\n## Offline behavior\n\nCreating, updating, submitting, and canceling all work offline. Each change is queued through the unsaved-changes engine on the device and syncs when the register reconnects.\n\nResuming is the exception. An order the register does not already hold locally has to be fetched, so `order:resume` fails while offline with `Can't continue this order while offline.`\n\nCross-register contention only warns. When a second register resumes an order's cart that another register already has open, the cart shows a banner, `This cart is currently open on another register (\u003cregister name\u003e).`, but editing and submitting are not blocked, so the last submit wins. A workflow that expects exclusive access needs to enforce that itself."}