Link a Goods Return Request to Its Original Delivery

1. Define the linked records before discussing a collection

Start with the completed outbound delivery as the anchor. Keep its original job reference, delivered-item references, completion evidence and recorded outcome visible. A later message asking for goods to be returned does not alter those facts. It creates a new customer return request linked to the delivery.

Separate six questions that often become one vague status: Was a request made? What quantities and units were requested? Has a named owner authorised a reverse-movement decision? Has a separate return movement been proposed? Did anyone actually take custody of goods? Has the intended receiving party acknowledged receipt? Each answer can be unknown without making the other answers false.

Record the customer’s stated reason as an unverified claim. A request may say that an item is unwanted, incorrect, damaged or surplus; this guide does not treat that statement as proof of condition, defect, fault, liability, refund entitlement or acceptance by the fleet. Preserve the wording or a concise attributed summary, identify its source, and leave the decision boundary explicit.

Source: BossFlow Fleet workflow scope

2. Follow a concrete desk-side decision sequence

First, locate the original delivery using stable references rather than a customer name alone. Confirm the delivery is the intended record and copy only the item references needed for the request. Do not reopen the completed delivery merely to make it look connected to later work.

Second, create a return-request record. Give it its own reference and link it to the original job. Enter the requester, request time if known, item reference, requested quantity, unit basis, stated reason, and any unresolved condition. “Unknown” is more useful than a guessed quantity or unit.

Third, ask the designated decision owner to record an explicit outcome: pending review, not authorised, authorised subject to stated conditions, or another clearly defined internal outcome. An authorisation decision should identify what it covers and what remains unresolved. It is not, by itself, an instruction to allocate a vehicle, driver or collection time.

Fourth, only after a distinct movement decision is available, create a separate proposed return-movement reference. Link it to the request and original delivery. Keep its proposed status separate from actual collection. Assignment, acceptance and movement progress remain their own operational facts.

Fifth, when a collection is reported, record custody evidence against the return movement without rewriting the request into completion. Then record any receiving-party acknowledgement separately. If either is missing, say so plainly and keep the relevant question open.

3. Suggested internal return-request worksheet

The following is an original suggested internal worksheet, not a carrier requirement, universal industry standard, Malaysia service rule or legal obligation. It is deliberately small so that dispatch, operations and receiving teams can see which decision has actually been made.

Suggested fields are: return-request reference; original delivery/job reference; original delivered-item reference; requested quantity and unit basis; request source and time if known; stated reason marked “unverified claim”; review owner; decision and decision time; separate return-movement reference; proposed collection status; custody evidence reference; receiving-party acknowledgement; and unresolved conditions with a named next owner.

Use linked references rather than copying the original delivery evidence into every later record. This preserves the history: an outbound delivery can remain completed while its linked request is pending, a proposed return movement is unassigned, or returned-goods custody has not yet been evidenced. A request record should describe what is known now, not predict the eventual commercial or operational result.

1. Five-item check before proposing a collection:
2. The original delivery and item references identify the intended completed delivery.
3. Each requested quantity has an explicit unit basis, or is marked unknown.
4. The stated reason is labelled as an unverified claim, not a finding.
5. A named owner has recorded whether reverse movement is authorised or still pending.
6. A separate return-movement reference exists before any collection is treated as proposed.

4. Use the evidence currently available

This table is suggested internal practice. It helps the team select a modest next record action from evidence already visible; it does not determine transport, commercial or legal outcomes.

5. Fictional example / 虚构示例

Fictional example only: Northbank Components completed delivery job OUT-418 for Orchard Workshop. The delivery record lists item reference CW-17, described internally as control housings, and shows the outbound delivery as completed. Later, a requester from Orchard Workshop asks that two units of CW-17 be collected. The request says the units were “not needed.” That phrase is entered as the requester’s unverified claim.

A dispatcher creates request RET-026 and links it to OUT-418 and CW-17. The requested quantity is recorded as two units; no assumption is made about condition, packaging, custody, credit, refund or responsibility. The request is sent to the named internal review owner. At this point, RET-026 is a request, not an approved vehicle movement.

The owner records “pending review” because a condition remains unresolved. No return-movement reference is created as an authorised collection instruction. Later, if an explicit movement decision is made, a separate reference such as RM-026 could be created and linked. If goods are then reported collected, custody evidence would be recorded against RM-026; a later acknowledgement by the intended receiving party would remain a separate event. The original OUT-418 remains completed throughout.

6. Close only the question that has evidence

Close the request review when its decision is recorded, even if no reverse movement will follow. Close the proposed movement only on the basis of its own operational evidence. Close the custody question only when the record identifies what was taken into custody, in what quantity and unit, and the supporting evidence available. Close receiving acknowledgement only when that acknowledgement is recorded or an internal outcome explicitly says it remains unresolved.

Avoid converting a missing acknowledgement into a negative conclusion. “No acknowledgement recorded” describes the record state; it does not establish that goods were not received. Similarly, a custody entry alone does not establish the original delivery was wrong, that a return was accepted for any commercial purpose, or that any party has accepted liability.

The supplied BossFlow Fleet material distinguishes assignment from acceptance and completion from settlement, and describes keeping vehicle, driver and job connected. Its carrier-specific examples are not used here as a rule for this workflow. This guide’s worksheet and decision sequence are original suggested internal practices for a linked goods-return request.

7. Narrow differentiation and illustrative image

This is a fleet operations guide for one narrow change in record state after delivery: linking a request to collect previously delivered goods without erasing the outbound delivery evidence. It is not a consumer transport booking page, a refund workflow, a failed-pickup record, a cancelled freight-job process, returnable pallet accounting, a delivery-proof discrepancy process, or a generic CRM/internal-system guide.

Reuse the existing AI conceptual fleet illustration and label it: “Illustrative AI concept: fleet yard; not an actual customer fleet.” The image may provide context for dispatch work but does not depict the fictional example, confirm a collection, or evidence returned-goods custody.

Source note for renderer: the supplied GOV.UK page supports the limited idea that a user need can be expressed through an actor, a need and a goal, with observable acceptance criteria. It is not a freight operating standard. All field names, separations and decisions in this guide are proposed internal practice.

Source: GOV.UK: writing user stories