Rhythm 2.0 Specifications

Appearance

ATS-COM-FUL-015Process returned goods through inspection and disposition: Capability Test Specification

Markdown

ATS-COM-FUL-015

Process returned goods through inspection and disposition: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-COM-FUL-015

Design

Executed by
TST-COM-FUL-074, TST-COM-FUL-076, TST-COM-FUL-079, TST-COM-FUL-082

KindAcceptance test setProduct areaCommerceModuleFulfillment, Shipping and InventoryRevision2

Read atservices-commerce c8b66a98react-console baf6dae3

Process returned goods through inspection and disposition: Capability Test Specification ​

Coverage ​

The category map distinguishes available cases from missing proof. A covered category has a scenario; the lifecycle and permission audits retain gaps in exhaustive coverage. Proposed cases describe the intended verification and carry no execution result.

RuleScenarios
BR-CAP-COM-FUL-015-01ATS-COM-FUL-015-01
BR-CAP-COM-FUL-015-02ATS-COM-FUL-015-01
BR-CAP-COM-FUL-015-03ATS-COM-FUL-015-02
BR-CAP-COM-FUL-015-04ATS-COM-FUL-015-03
BR-CAP-COM-FUL-015-05ATS-COM-FUL-015-04, ATS-COM-FUL-015-08, ATS-COM-FUL-015-09
BR-CAP-COM-FUL-015-06ATS-COM-FUL-015-04, ATS-COM-FUL-015-08, ATS-COM-FUL-015-09
BR-CAP-COM-FUL-015-07ATS-COM-FUL-015-05
BR-CAP-COM-FUL-015-08ATS-COM-FUL-015-04, ATS-COM-FUL-015-08, ATS-COM-FUL-015-09
BR-CAP-COM-FUL-015-09ATS-COM-FUL-015-06, ATS-COM-FUL-015-10
BR-CAP-COM-FUL-015-11ATS-COM-FUL-015-07

The interaction cases exercise complete the financial work requested by a post-sale document; keep stock movements and transfers accountable. They vary the upstream record or outcome and inspect the resulting work across the capability boundary. Workflow crossings also include stock, financial or application records when the flow depends on them. Existing test bindings retain their source anchors so a reviewer can distinguish supporting assertions from a complete workflow run.

Coverage

  • Rule covered
  • Transition covered
  • Validation covered
  • Permission covered
  • Edge gap: FND-COM-FUL-070
  • Failure gap: FND-COM-FUL-070
  • Boundary covered
  • Concurrency gap: FND-COM-FUL-070
  • Invariant covered
  • Interaction covered

Test Scenarios

10 scenarios proving CAP-COM-FUL-015; 7 bound to an existing test.

01 Receiving respects authorization and receipt identityinvariantapinegativetest
Proves
BR-CAP-COM-FUL-015-01 BR-CAP-COM-FUL-015-02
Preconditions
A return permits three units.
Steps
Receive two, replay the receipt, exceed the remainder and receive against a completed return.
Expected
One receipt survives repetition and over-receipt or terminal receipt requests fail.
Data
Fixtures for receiving respects authorization and receipt identity.
Bound to
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
services-commerce:modules/shipping/tests/integration/services/returns/return-receiving.integration.spec.js#refuses a receipt against the completed return, 409 return_not_receivable
services-commerce:modules/shipping/tests/e2e/post-purchase-shipping.e2e.spec.js#records the receipt of both units against the RMA (the retry under the key answers it again): the document received, nothing on the shelf yet
Source
services-commerce:modules/shipping/tests/integration/services/returns/return-receiving.integration.spec.js#answers the retried receipt as the one recorded, moving nothing
02 Arrival waits for policy before financial executiontransitionapitest
Proves
BR-CAP-COM-FUL-015-03
Preconditions
A return's policy refunds on receipt.
Steps
Receive some goods, then all remaining goods.
Expected
Receipt adds no stock and requests money only after the required arrival is complete.
Data
Fixtures for arrival waits for policy before financial execution.
Bound to
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
services-commerce:modules/shipping/tests/integration/services/returns/return-receiving.integration.spec.js#takes the third unit damaged: the document received, the money on receipt for the three (nothing to move in this world) and financially settled
Source
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
03 Inspection accepts only supported conditionsvalidationapinegativetest
Proves
BR-CAP-COM-FUL-015-04
Preconditions
A receipt line awaits inspection.
Steps
Submit a supported condition and an unknown one.
Expected
The supported result advances inspection while the unknown condition is rejected.
Data
Fixtures for inspection accepts only supported conditions.
Bound to
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
services-commerce:modules/shipping/tests/integration/db/return-receiving-tables.table.integration.spec.js#refuses a condition outside the five and a second line under the same line number, by return_receipt_lines_condition_check and return_receipt_lines_number_uq
Source
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
04 Disposition separates sellable restoration from other treatmentruleapitest
Proves
BR-CAP-COM-FUL-015-05 BR-CAP-COM-FUL-015-06 BR-CAP-COM-FUL-015-08
Preconditions
Inspected quantities can be restocked, quarantined or scrapped.
Steps
Restock two units, quarantine one and scrap one.
Expected
Restock restores original location and cost, quarantine remains unsellable without cost restoration and scrap adds no stock before return completion.
Data
Fixtures for disposition separates sellable restoration from other treatment.
Bound to
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
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
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)
Source
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
05 Disposition cannot exceed receipt or policyboundaryapinegativetest
Proves
BR-CAP-COM-FUL-015-07
Preconditions
Two units have been received.
Steps
Attempt three-unit disposition, replacement and a policy-forbidden choice.
Expected
All three fail without recording disposition.
Data
Fixtures for disposition cannot exceed receipt or policy.
Bound to
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
services-commerce:modules/shipping/tests/integration/services/persistence/return-receipts.queries.integration.spec.js#holds a line’s dispositioned count to what it received (409 disposition_exceeds_received)
Source
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
06 Return-label work follows issuance and withdrawalinteractionapitest
Proves
BR-CAP-COM-FUL-015-09
Preconditions
Shipped units have a label-issuing return policy.
Steps
Authorize one return and withdraw another before receipt.
Expected
Issuance creates a packed incoming shipment and withdrawal cancels and pulls its parcel.
Data
Fixtures for return-label work follows issuance and withdrawal.
Bound to
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
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
services-commerce:modules/shipping/tests/e2e/post-purchase-shipping.e2e.spec.js#authorizes the return with an RMA carrying a return_label shipment packed at the counter: the two shipped units in one parcel, to the warehouse, the label the clerk’s (B14)
Source
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
07 Receiving routes reject read-only and portal callerspermissionapinegativetest
Proves
BR-CAP-COM-FUL-015-11
Preconditions
Reader and portal identities are available.
Steps
Call receipt, inspection and disposition routes.
Expected
Both identities are denied each mutation.
Data
Fixtures for receiving routes reject read-only and portal callers.
Bound to
services-commerce:modules/shipping/tests/e2e/post-purchase-shipping.e2e.spec.js#refuses a reader the receiving routes 403 permission_missing, and the member 403
Source
services-commerce:modules/shipping/tests/e2e/post-purchase-shipping.e2e.spec.js#refuses a reader the receiving routes 403 permission_missing, and the member 403
08 Physical return disposition permits the requested money workinteractionapiproposed
Proves
BR-CAP-COM-FUL-007-06 BR-CAP-COM-FUL-015-08
Preconditions
A return authorizes two shipped shirts and refunds after disposition.
Steps
Receive and inspect both shirts, restock them, then process the requested refund confirmation.
Expected
Stock restoration precedes financial completion; processor-pending money remains unfinished until confirmation.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Source
services-commerce:modules/fulfillment/tests/integration/services/adjustments/adjustment-worker.integration.spec.js#is held pending at the processor, never failed, however many times it is asked again, with no exception,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
09 Returned stock becomes available through the movement ledgerinteractionapiproposed
Proves
BR-CAP-COM-FUL-015-05 BR-CAP-COM-FUL-017-03 BR-CAP-COM-FUL-018-06
Preconditions
Two shipped shirts return under a restock-permitting authorization.
Steps
Receive and inspect them, restock to the original sellable location and read availability and movements.
Expected
The returned quantity has a restock entry and is available to buyers; receiving alone adds no stock.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Source
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,services-commerce:modules/inventory/tests/integration/db/inventory-tables.table.integration.spec.js#refuses the application role a balance: UPDATE on on_hand is 42501 (the column grant), while its settings are its to change,services-commerce:modules/inventory/tests/e2e/inventory.e2e.spec.js#answers the availability in the storefront’s words: limited with what is left, unavailable for more than the shelf has, backorder for the shirt, available for a product it does not track
10 Return-label preparation uses the outbound carrier choiceinteractionapiproposed
Proves
BR-CAP-COM-FUL-015-09 BR-CAP-COM-FUL-013-01
Preconditions
An issued return permits a label and identifies an outbound carrier account.
Steps
Prepare the incoming shipment and purchase its label, then withdraw an unreceived return.
Expected
The incoming parcel uses the selected account and warehouse destination; withdrawal pulls its parcel.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Source
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,services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#buys the first label through UPS under package:<id>:1 (the intent then the outcome), the tracking number and the cost on the label, the package labelled

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.

Rhythm Software