Skip to content

CAP-COM-FUL-015Process returned goods through inspection and disposition

Markdown

CAP-COM-FUL-015

Process returned goods through inspection and disposition

Markdown
  • DocumentDraft
  • Product intentProposed
  • ImplementationPartially observed

KindCapabilityProduct areaCommerceModuleFulfillment, Shipping and InventoryRevision1

Read atservices-commerce c8b66a98

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Outcomes
Staff disposition determines which returned goods become sellable.Return financial work follows its configured physical milestones.
Surfaces
api

Controls

28 controls apply, from the corpus control catalogue.

TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-AZ-006 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-TEN-004 TC-CRY-001 TC-DAT-001 TC-DAT-002 TC-DAT-003 TC-DAT-004 TC-LOG-001 TC-LOG-002 TC-LOG-003 TC-LOG-004 TC-LOG-005 TC-PI-001 TC-PI-002 TC-PI-003 TC-PI-005 TC-VEN-001 TC-VEN-002 TC-VEN-003 TC-PRV-001 TC-PRV-002

Permissions

KeyChecked atScope
commerce.return-receipts.readapitenant
commerce.return-receipts.createapitenant
commerce.return-receipts.updateapitenant

Business Rules

11 rules, 10 to be proved before approval. A rule's product intent is derived from its origin: 0 confirmed by a product decision, the rest inheriting this capability's proposed.

IdRuleKindEnforced atProvenance
01must prove
Proposed
Receipt against a return authorization is idempotent under its receipt key, with retries returning the recorded receipt without stock movement.
no proof recorded yet
invariantservice, databasetest
02must prove
Proposed
Receiving rejects quantities above each line's remaining authorization and rejects additional receipts on completed returns.
no proof recorded yet
validationservicetest
services-commerce:modules/shipping/tests/integration/services/returns/return-receiving.integration.spec.js#refuses more than the line has left authorized (receipt_exceeds_authorized), writing no receipt
03must prove
Proposed
Receiving advances the return to partially received or received without stock movement, requesting money on receipt only when the policy allows it and every authorized unit has arrived.
no proof recorded yet
policyservicetest
services-commerce:modules/shipping/tests/integration/services/returns/return-receiving.integration.spec.js#records the first receipt numbered against the RMA at the warehouse, the two units counted with the outbound shipment line, the document partially received with its RMA, nothing on the shelf and no money yet
04must prove
Proposed
Inspection records one of five conditions and any discrepancy for each received line, marks the receipt inspected once all lines are inspected and advances the return to inspecting.
no proof recorded yet
lifecycleservice, databasetest
services-commerce:modules/shipping/tests/integration/services/returns/return-receiving.integration.spec.js#records the inspection on the line and moves the receipt to inspected and the document to inspecting
05must prove
Proposed
Restocking records a return-restock movement at the requested location, otherwise the original shipping location or first sellable warehouse location, and restores original layer cost.
no proof recorded yet
calculationservicetest
services-commerce:modules/shipping/tests/integration/services/returns/return-receiving.integration.spec.js#restocks the two units at the bin they shipped from: the return_restock movement naming the disposition, on hand up two, the two reliefs reversed at 1500 with the restore_cogs fact of 3000
06must prove
Proposed
Quarantine records restock followed by quarantine movement without available stock or restored cost, while scrap and return-to-customer dispositions leave stock and cost of goods sold unchanged.
no proof recorded yet
calculationservicetest
services-commerce:modules/shipping/tests/integration/services/returns/return-receiving.integration.spec.js#quarantines the damaged unit: return_restock then quarantine_in at the quarantine shelf, no cost restored, and the document completes with every unit back on the line
07must prove
Proposed
Disposition rejects quantities above received units, unsupported replacements and choices prohibited by the return policy.
no proof recorded yet
validationservice, databasetest
services-commerce:modules/shipping/tests/integration/services/returns/return-receiving.integration.spec.js#refuses a disposition beyond what the line received, a replacement, and a disposition the policy does not allow; nothing dispositioned
08must prove
Proposed
A fully dispositioned receipt permits return completion, with credit memo and refund processing after the disposition commit.
no proof recorded yet
lifecycleservicetest
services-commerce:modules/shipping/tests/e2e/post-purchase-shipping.e2e.spec.js#dispositions one unit restocked and one scrapped in one transaction: the shelf up one, the receipt dispositioned, the document completed with the memo and the refund for the two (B15, B11)
09must prove
Proposed
An issued return label creates a one-parcel packed shipment toward the warehouse using the outbound account, otherwise an active carrier or manual carrier, and withdrawal before receipt cancels and pulls it.
no proof recorded yet
lifecycleservicetest
services-commerce:modules/shipping/tests/integration/services/returns/return-receiving.integration.spec.js#makes the return_label shipment of the three shipped units, packed in one parcel, addressed to the warehouse, labelled through UPS from the customer’s address
10
Proposed
Return receipts retain unique numbers and idempotency keys and cannot be deleted.
invariantdatabasetest
services-commerce:modules/shipping/tests/integration/db/return-receiving-tables.table.integration.spec.js#refuses a second receipt under the same number and under the same idempotency key, by return_receipts_number_uq and return_receipts_idempotency_key_uq
11must prove
Proposed
Receipt creation, inspection and disposition require their return-receipt permissions and reject readers and portal callers.
no proof recorded yet
permissionapiobserved

Scenarios

IdGivenWhenThenProvenance
01Two shirts have an authorized return and a manual incoming-label arrangement.Receive and inspect both, then restock one and scrap the other.One unit returns to stock and disposition completes the receipt and return financial work.test
services-commerce:modules/shipping/tests/e2e/post-purchase-shipping.e2e.spec.js#dispositions one unit restocked and one scrapped in one transaction: the shelf up one, the receipt dispositioned, the document completed with the memo and the refund for the two (B15, B11)

Edge Cases

IdGivenWhenThenProvenance
02The return is withdrawn before receipt.Complete withdrawal.Incoming shipment work is cancelled and its parcel is pulled.test
services-commerce:modules/shipping/tests/integration/services/returns/return-receiving.integration.spec.js#cancels the return label shipment (packed at the counter, no label bought yet) and pulls its parcel when the return is withdrawn

The Markdown files under specs/ in rhythmsoftware/rhythm-v2-docs are the canonical source of truth. This reader is a generated, read-only projection of them.