Processing a Return

Returns in wallmarkets work best when they stay attached to the delivery they came from.

That is the core idea behind the current workflow. Instead of creating a disconnected note about product coming back, you create a return record tied to the original shipment, with the exact products, quantities, prices, and date.

That makes follow-up work much easier later.

The cleanest way to start a return

You have two practical entry points:

• open Returns and click New Return
• open a delivery detail page and click Create Return

The second option is usually better because it keeps you anchored to the original record from the start.

When you create a return from a delivery, wallmarkets can prefill the returned products so you are adjusting a real shipment instead of rebuilding it from memory.

What the return form captures

A return record in the current product is built around these pieces:

• original delivery
• return date
• returned products
• returned quantities
• unit prices

That is enough to preserve the financial and operational shape of the return even without extra storytelling around it.

The checks wallmarkets performs

The return workflow has important guardrails.

wallmarkets checks that:

• the selected delivery belongs to the current business
• the return date is not before the original delivery date
• the return date is not in the future
• quantities are greater than zero
• prices are greater than zero
• returned quantities do not exceed what was delivered minus what was already returned

That last rule matters a lot. It prevents teams from accidentally creating more returned quantity than the original shipment could possibly support.

Why the original delivery matters

The original delivery is doing more work than just identifying the supermarket.

It also gives the return workflow:

• the product list you can return against
• the maximum quantities available
• the branch context
• the reference point you will use later in reporting

This is why good delivery hygiene pays off twice. A clean delivery record makes the return workflow cleaner too.

What happens after the return is created

Once saved, the return appears in the returns list and gets its own detail page.

From there you can:

• review the returned products and totals
• download a PDF
• print a copy
• jump back to the original delivery

The original delivery page also shows linked returns, so the relationship works in both directions.

When to create the return

Create the return as close as possible to the actual event.

Waiting until later usually creates two problems:

• quantities get fuzzy
• the person entering the record starts guessing which delivery it belonged to

If the team can create the return while the delivery is still fresh in memory, the data is usually cleaner.

Common mistakes

Starting from the wrong delivery

The return may still save, but it will point reporting and reconciliation in the wrong direction.

Returning a product quantity from memory

If the system says the quantity exceeds what was delivered, that is usually a sign to stop and verify, not a signal to force the record through.

Treating returns as an afterthought

Returns are part of the delivery history. Logging them properly is what keeps the history trustworthy.

A good operating habit

If you discover a problem on a delivery, open that delivery first and create the return from there.

That one step reduces mislinked returns, quantity errors, and confusion during later review.

Related guides

• Tracking returns against deliveries
• Return analytics
• Tracking deliveries