Rhythm 2.0 Specifications

Appearance

ATS-COM-FUL-015Process returned goods through inspection and disposition: Acceptance Test Set

Markdown

ATS-COM-FUL-015

Process returned goods through inspection and disposition: Acceptance Test Set

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-COM-FUL-015

KindAcceptance test setProduct areaCommerceModuleFulfillment, Shipping and InventoryRevision1

Read atservices-commerce c8b66a98

Test Scenarios

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

01 Receiving respects authorization and receipt identityapinegativetest
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 executionapitest
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 conditionsapinegativetest
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 treatmentapitest
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 policyapinegativetest
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 withdrawalapitest
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 callersapinegativetest
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

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