Returns and exchanges at the LS Central POS: a workflow that keeps inventory right

Store operations · 7 min read

A return is two events wearing one coat: money goes back to the customer, and an item comes back into the store. Most POS mistakes happen because the cashier handles the first event carefully and the second one casually — the refund posts, but the wrong item, the wrong quantity, or a damaged unit lands back in sellable stock, and the inventory record drifts a little further from the shelf. LS Central gives you three distinct return routes, and they are not interchangeable. This guide compares them, gives a step-by-step workflow for each of the common cases, and ends with the short check that keeps the stock record honest.

One honesty note before the steps: button labels and menu layouts vary by implementation, and some behaviour below is tied to specific commands and terminal settings. Where a step depends on a setting, the setting is named — check it on your own terminal card rather than assuming it matches a neighbouring store's.

Pick the return route before you scan anything

Two commands support the refund route: REFUND_MARK_LINE marks a line for refund, and REFUND_MARK_ALL marks all lines for refund. And the negative-quantity route has a hard edge worth knowing before you promise a customer anything: if item return is not allowed in a sale, the application will not allow negative-quantity scanning exceeding the quantity of the item already in the transaction. In other words, without the setting, NEG_QTY can offset an item in the current basket, but it cannot turn the sale into a return.

The decision that comes first: what shape is this return?

The receipt-based return, step by step

1. Scan the receipt. When a receipt is scanned for a refund or exchange, the POS sends a request to a web service to retrieve the original transaction from Head Office. The original receipt is a strong starting point: it carries the receipt and transaction number, the sold item lines with description, quantity, and sales price, and the terminal ID.
2. Handle the archived-original case calmly. If the original transaction has been externally archived, it must first be imported back into Head Office and restored; only once it is restored can the web service return the original transaction details to the POS. That is a back-office step, not a cashier workaround — escalate it rather than keying a manual return that pretends to be receipt-based.
3. Mark only what is actually coming back. Use REFUND_MARK_LINE for the individual lines being returned, or REFUND_MARK_ALL when the whole transaction is coming back. Match each marked line to a physical item on the counter — not to what the customer says is in the bag.
4. Check linked items. On selecting an item to return that has linked items, the linked items should also be selected automatically — LS Central's 26.1 hotfix notes describe exactly this fix for receipt-scanned returns, so treat it as version-specific behaviour to verify on your build, and check the journal for the linked lines either way. A returned main item whose linked item stays "sold" is a quiet inventory error.
5. Confirm quantities and prices against the original lines. The return should mirror the original sale's quantities and prices, not today's shelf price. If a line's price differs from the original transaction, stop and find out why before posting.
6. Post the transaction and settle the refund. Post the completed return the same way you post a sale, and settle the amount back to the customer through the tender your store's setup prescribes for refunds. Keep the return receipt with the day's paperwork — the end-of-day check below uses it.

What success looks like: the posted return's lines, quantities, and prices match the original transaction for exactly the items physically on the counter, linked items are accounted for, and the customer leaves with a refund that matches the receipt in your hand.

Running an exchange without breaking the stock record

An exchange is a return and a sale that share a customer. Whether they can share a transaction depends on one setting: Return in Transaction, a toggle on the POS Terminal Card. LS Central documents it from both directions — terminals can be set to allow returns in a transaction, and a fiscal setup example sets the toggle off precisely so terminals cannot sell and return in the same transaction. Find out which way your terminal is set before the customer is standing in front of you.

Shape A — one transaction (Return in Transaction allowed).

1. Start the sale, and bring the returned item in with NEG_QTY so it sits in the transaction as a negative quantity.
2. Add the replacement item as a normal positive line.
3. Read the basket before tendering: one negative line for the item coming back, one positive line for the item going out, nothing else. Settle only the net difference — a refund if the replacement is cheaper, a payment if it is dearer, per your store's tender rules.

Shape B — two transactions (Return in Transaction not allowed).

1. Run the return first as its own refund transaction with REFUND, remembering that every line in that transaction posts as a refund — so the replacement item does not belong anywhere near it.
2. Post the refund transaction and settle the refund.
3. Ring the replacement as a separate, ordinary sale and take payment for it.

Shape B takes a minute longer, and it is the correct shape on terminals where the setting is off. Forcing Shape A there is how exchanges end up half-keyed: the negative line cannot exceed the quantity already in the transaction, the cashier improvises, and the stock record ends up describing a transaction that never quite happened.

After posting: the inventory check

The transaction posting is not the end of the return. Run this check while the item is still on the counter:

1. Physical first. The item on the counter is the item on the return — same item, same variant, same quantity. If what came back is not what the lines say, correct the return before the customer leaves, not at the stock count.
2. Condition decides the destination. Sellable-as-is goes back to the shelf. Anything damaged, opened in a way your policy does not accept for resale, or missing parts stays off the shelf and follows the damaged-goods process — the stock record should never claim a unit is available that a customer would reject.
3. Linked items are back too. If the returned item had linked items on the original sale, confirm those units are physically back and present on the return lines. Count them; do not assume the automatic selection matched the bag.
4. The replacement left once. On an exchange, confirm the replacement item appears exactly once as a sold line. A duplicated replacement line takes two units out of stock for one item walking out the door.
5. File the paperwork together. Original receipt reference, return receipt, and any damaged-goods note in one place. The end-of-day check is only possible if the day's returns can be counted.

What success looks like: the shelf, the stock record, and the paperwork all tell the same story — this unit came back, in this condition, against this original sale, and this unit went out in its place.

The end-of-day cross-check

The X report includes the number of refunds and the total amount for refunds, alongside the number of transactions and items sold — and the Z report carries the same information. Before the close (see our end-of-day routine), compare the report's refund count and total against the return receipts kept during the day. A mismatch means a return was posted without paperwork, paperwork exists for a return that never posted, or an exchange was shaped in a way that posted the return leg twice. All three are findable on the day they happen and painful a month later at the stock count, which is the whole argument for checking daily.

FAQ

What is the difference between REFUND and NEG_QTY? REFUND starts a dedicated Refund transaction in which all lines are posted as refunds. NEG_QTY makes a scanned item a negative quantity inside the current transaction, and it can be used for item returns only if the terminal allows Return in Transaction; otherwise negative scanning cannot exceed the quantity of the item already in the transaction.

Can you sell and return in the same transaction? Only if the terminal is set that way. Return in Transaction is a toggle on the POS Terminal Card, and some setups deliberately turn it off so terminals cannot sell and return in the same transaction — in that case, run the refund and the new sale as two transactions.

What happens when a receipt is scanned for a refund or exchange? The POS requests the original transaction from Head Office through a web service. If that transaction has been externally archived, it has to be imported back and restored first; once restored, the web service can return the original details to the POS.

How do refunds show up at the end of the day? The X report lists the number of refunds and the total amount for refunds. Compare those two figures against the day's return receipts before closing — it is the fastest way to catch a mis-posted return while it can still be fixed.