Suspended transactions in LS Central: parking, recalling, and cleaning up parked sales

Store operations · 7 min read

A customer gets halfway through a basket, then remembers the wallet is in the car, or heads back to the shelves for three more things. Suspending the sale is the right tool for that moment: the transaction goes on hold, the queue keeps moving, and the sale can be finished when the customer returns. The problems start later — parked sales nobody can find, parked sales nobody remembers parking, and a suspended list that quietly grows for weeks. This guide covers the mechanics LS Central actually documents, then the two things the documentation leaves to you: a naming discipline that makes parked sales findable, and a cleanup routine that keeps the list at zero.

What a suspended transaction actually is

Suspend is used to put a sale on hold and retrieve it later to finish it. While it is suspended, the sale is simply on hold in the LS Central system — it is not a finished sale, and it is not a second copy of the sale sitting somewhere else. When the Suspend button is pressed on the POS, the transaction and its related lines are sent to the specified remote database. That detail matters for everything that follows:

• Recall is a move, not a copy. When a cashier asks for the list of suspended transactions, only the headers come back from the remote database. Selecting one requests the whole transaction from the server — and if that succeeds, the transaction is deleted from the remote database. From that moment it lives only on the POS that recalled it, where it can be finalized or suspended again.
• There is a local fallback. If the POS cannot suspend the transaction to the remote database, it suspends the transaction locally instead. A locally suspended sale does not behave like a remote one at recall time — see the failure cases below.
• The POS command does double duty. The SUSPEND POS command suspends an active transaction, or retrieves a suspended transaction if no transaction is active. It can be assigned to a key on the fixed keyboard or as a menu key in the Sales menu.

Three states a parked sale can be in

Most recall confusion is really a state confusion: a cashier looks for a sale in the shared list when it was only ever parked locally, or looks for it after a colleague already recalled it onto another terminal.

Park a sale so it can be found again

1. Suspend at the natural break point. On a conventional POS, click the Suspend button and select Yes. On the Mobile POS, a sale can be suspended at any time: on the Payment screen, tap Suspend Transaction; on the PLU screen, open the hamburger menu in the top left of the header bar (or slide the left edge to the right) and tap Suspend transaction.
2. Enter an identifier that a stranger could search. After tapping Suspend Transaction on the Mobile POS, you are asked to enter an identifier so the transaction can be found later when it is retrieved. Treat that prompt as the whole ballgame: use the customer's name plus one basket detail, in whatever format your store has agreed. An identifier like a first name alone will collide by lunchtime.
3. Tell the customer what happens next. The sale is on hold, it can be picked up at any terminal if it suspended remotely, and the identifier is what the next cashier will search for. If the customer will not be back today, do not park the sale and hope — use the decision framework below instead.
4. Serve the next customer. That is the point of the feature: suspending lets you serve other customers while still retrieving the suspended sale when the customer returns.

What success looks like: the suspended list contains the new entry, the identifier is searchable and unambiguous, and any cashier — not just the one who parked it — could find this sale in under a minute.

Recall it on the same or a different POS

A suspended sale can be retrieved through web services on the same POS or on a different one, and it does not matter which kind of POS retrieves it — a conventional POS or a Mobile POS. On the Mobile POS:

1. Go to the Home screen and tap Functions – Recall transaction.
2. On the Suspended transactions screen, search for the identifier entered when the sale was suspended.
3. Select the transaction. The full transaction is requested from the server; the list itself only carried the headers.
4. Check the lines against the customer's basket before tendering. A recalled sale is a sale that was interrupted — quantities and items deserve one look before money changes hands.
5. Finalize the sale, or suspend it again if the customer has to step away a second time. Remember that a successful recall removed it from the remote database: if you walk away without re-suspending, there is nothing left in the shared list.

When recall fails: the two documented cases

If a transaction cannot be retrieved from the remote database, the POS displays an error. LS Central's documentation gives exactly two reasons, and they need opposite responses:

The practical lesson: a failed recall is not automatically a lost sale. First work out which case you are in — starting with "which terminal parked this?" — before anyone rescans a full basket.

Suspend, finish, or void: a decision framework

For voiding itself, the documented commands are VOID, which voids the current transaction, and VOID_TR, which allows you to void a recent transaction.

The end-of-day cleanup routine

The X report is the control that makes cleanup possible: among its totals it shows the number of suspended transactions and the total amount for suspended transactions. If that number is not zero at close, there is work to do. The LS Central documentation checked for this guide does not describe a dedicated "delete parked sale" function, so the routine below clears stale sales through the documented recall and void commands rather than any database edit.

1. Run the X report before the close. Note the suspended transaction count and total. A count of zero ends the routine — record it and move on to the rest of the close (see our end-of-day routine).
2. Open the suspended list and work it oldest first. For each entry, decide from the identifier: is this customer plausibly still coming back today?
3. Recall what should be completed. Recall the transaction, check its lines, and finalize it if the customer has returned or is at another till.
4. Clear what was abandoned. Recall the stale transaction so it is the current transaction on the POS, then void it with VOID. Work one sale at a time — a recalled sale exists only on your terminal until you deal with it.
5. Chase local suspensions at their own terminal. If an entry cannot be recalled from your terminal, it may have been suspended locally. Check the terminal that parked it before writing the sale off.
6. Re-run the check. Confirm the suspended count has dropped to zero, or that every remaining entry has a named reason — a customer returning tomorrow with a manager's agreement, for example — written down for the morning.

What success looks like: at close, the X report's suspended count is zero or fully explained in writing, nothing on the list is older than today without a name attached, and the morning shift inherits no mystery baskets.

FAQ

Can a suspended sale be recalled on a different POS? Yes. A suspended sale can be retrieved through web services on the same POS or a different one, and the retrieving device can be a conventional POS or a Mobile POS. The exception is a sale that was suspended locally because the remote database could not be reached — that one is recalled at the terminal where it was last suspended.

Does recalling a sale copy it? No. Selecting a suspended transaction requests the whole transaction from the server, and on success it is deleted from the remote database. After recall, the transaction is only available on the POS that recalled it.

How do we know how many sales are parked? The X report includes the number of suspended transactions and their total amount, alongside figures such as the number of refunds and voided transactions. The Z report carries the same information as the X report.

A recall just errored. Is the sale gone? Not necessarily. The documented error has two causes: a remotely stored transaction that cannot be retrieved, which leaves rescanning the items as the option, and a transaction that was suspended locally, which must be recalled at the terminal that parked it. Identify which case you have before doing either.