Rhythm 2.0 Specifications

Appearance

ATS-COM-FUL-014Record goods leaving with a carrier or collector: Capability Test Specification

Markdown

ATS-COM-FUL-014

Record goods leaving with a carrier or collector: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-COM-FUL-014

Design

Executed by
TST-COM-FUL-074, TST-COM-FUL-075, TST-COM-FUL-078

KindAcceptance test setProduct areaCommerceModuleFulfillment, Shipping and InventoryRevision2

Read atservices-commerce c8b66a98react-console baf6dae3

Record goods leaving with a carrier or collector: 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-014-01ATS-COM-FUL-014-01, ATS-COM-FUL-014-06, ATS-COM-FUL-014-07, ATS-COM-FUL-014-08
BR-CAP-COM-FUL-014-02ATS-COM-FUL-014-02
BR-CAP-COM-FUL-014-03ATS-COM-FUL-014-02
BR-CAP-COM-FUL-014-04ATS-COM-FUL-014-03
BR-CAP-COM-FUL-014-05ATS-COM-FUL-014-03
BR-CAP-COM-FUL-014-06ATS-COM-FUL-014-04, ATS-COM-FUL-014-09
BR-CAP-COM-FUL-014-07ATS-COM-FUL-014-05
BR-CAP-COM-FUL-014-08ATS-COM-FUL-014-05
BR-CAP-COM-FUL-014-09ATS-COM-FUL-014-05

The interaction cases exercise allocate stock and explain what buyers can obtain. 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 gap: FND-COM-FUL-069
  • Transition gap: FND-COM-FUL-069
  • Validation gap: FND-COM-FUL-069
  • Permission covered
  • Edge gap: FND-COM-FUL-069
  • Failure covered
  • Boundary gap: FND-COM-FUL-069
  • Concurrency covered
  • Invariant covered
  • Interaction covered

Test Scenarios

9 scenarios proving CAP-COM-FUL-014; 9 bound to an existing test.

01 Departure changes stock and delivery records atomicallyinvariantapitest
Proves
BR-CAP-COM-FUL-014-01 INV-DOM-COM-FUL-004-03 INV-DOM-COM-FUL-005-07
Preconditions
Three units belong to a manifested shipment.
Steps
Confirm carrier handoff.
Expected
All units ship, one minus-three stock movement is retained, obligations complete, cost facts are emitted and order quantities update.
Data
Fixtures for departure changes stock and delivery records atomically.
Bound to
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#hands off: the line handed to the carrier with its whole quantity shipped, the units shipped in the ledger, one shipment movement of minus three on the item, three fewer on hand
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#completes every unit’s obligation through the register (the allocation as the record), and emits one deferred cost relief fact per item
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#writes the shipped quantity on the order line, the order’s shipping_summary complete, and the order’s history
Source
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#hands off: the line handed to the carrier with its whole quantity shipped, the units shipped in the ledger, one shipment movement of minus three on the item, three fewer on hand
02 Unauthorized or repeated departure cannot move stockfailureapinegativetest
Proves
BR-CAP-COM-FUL-014-02 BR-CAP-COM-FUL-014-03 INV-DOM-COM-FUL-004-04
Preconditions
One shipment lacks obligation authorization and another already left.
Steps
Attempt handoff on both.
Expected
Both fail without movement and their refusals are recorded.
Data
Fixtures for unauthorized or repeated departure cannot move stock.
Bound to
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#refuses units_not_authorized, naming the obligation still pending, and moves nothing: the unit committed, nothing shipped, the shipment still manifested
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#raises the handoff_refused finding and writes the refusal on the shipment’s history
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#refuses a second handoff of the same shipment (not manifested any more) and records the refusal
Source
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#refuses units_not_authorized, naming the obligation still pending, and moves nothing: the unit committed, nothing shipped, the shipment still manifested
03 Cancellation fencing resolves contention with departureconcurrencyapinegativetest
Proves
BR-CAP-COM-FUL-014-04 BR-CAP-COM-FUL-014-05 INV-DOM-COM-FUL-004-05
Preconditions
A manifested shipment contains a unit selected for cancellation.
Steps
Fence before handoff and separately race cancellation against departure.
Expected
The fence blocks shipment; the race has one successful action and departed goods require return.
Data
Fixtures for cancellation fencing resolves contention with departure.
Bound to
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#fences the whole range the unit is in (cancellation_pending under cancellation:<id>), nothing refused
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#refuses the handoff shipment_cancelled_pull_package, naming the fenced line, and moves nothing
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#lets the handoff commit, and the cancellation that waited finds the line already handed off: refused, nothing fenced
services-commerce:modules/shipping/tests/e2e/post-purchase-shipping.e2e.spec.js#refuses the cancellation of the shipped shirts: rejected, must_return with shipment_handed_off (B9)
Source
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#fences the whole range the unit is in (cancellation_pending under cancellation:<id>), nothing refused
04 Retained units use a new shipment after fenced cancellationinteractionapitest
Proves
BR-CAP-COM-FUL-014-06
Preconditions
A three-unit line is fenced for cancellation of one unit.
Steps
Apply cancellation and create shipment work for the retained quantity.
Expected
The old line and parcel are pulled with label voiding, and the two retained units ship separately.
Data
Fixtures for retained units use a new shipment after fenced cancellation.
Bound to
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#cancels the fenced line at the cancel step: the units unstamped (still the order’s, picked), the label voided and the package pulled, the shipment cancelled
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#leaves the order’s units free for a new shipment: a second shipment carries both again
services-commerce:modules/shipping/tests/e2e/post-purchase-shipping.e2e.spec.js#fences and cancels the shipment line, pulls the package and voids the counter label, and refuses the handoff asked after (409)
Source
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#cancels the fenced line at the cancel step: the units unstamped (still the order’s, picked), the label voided and the package pulled, the shipment cancelled
05 Collection requires collector and authorized staffpermissionapinegativetest
Proves
BR-CAP-COM-FUL-014-07 BR-CAP-COM-FUL-014-08 BR-CAP-COM-FUL-014-09
Preconditions
A packed pickup, a carrier shipment and a fenced pickup exist.
Steps
Try reader handover, missing collector, valid handover, repetition and incompatible fixtures.
Expected
Only valid first collection succeeds with its stock, delivery and cost effects.
Data
Fixtures for collection requires collector and authorized staff.
Bound to
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#hands it over: the lines, the package and the shipment collected with who collected it, the whole quantity shipped
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#moves the stock as the handoff does: the units shipped, one shipment movement of minus two (reason handover), two fewer on hand
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#completes the obligations through the register, emits the cost relief fact and writes the order’s shipped quantities
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#refuses a second handover (not packed any more) and the cancellation of a collected shipment
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#refuses the handover of a pick-up whose line the cancellation fenced, shipment_cancelled_pull_package, and moves nothing
services-commerce:modules/shipping/tests/e2e/shipping.e2e.spec.js#refuses the handover to a reader 403 permission_missing, and one naming nobody who collected 400
Source
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#hands it over: the lines, the package and the shipment collected with who collected it, the whole quantity shipped
06 Warehouse departure supplies the physical application outcomeinteractionapitest
Proves
BR-CAP-COM-FUL-004-04 BR-CAP-COM-FUL-014-01 BR-CAP-COM-FUL-018-05
Preconditions
Three picked units have current delivery authorization and a manifested shipment.
Steps
Hand the shipment to its carrier, then inspect allocation units and delivery detail.
Expected
The three units are shipped and their obligations are completed with the allocation references.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Bound to
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#hands off: the line handed to the carrier with its whole quantity shipped, the units shipped in the ledger, one shipment movement of minus three on the item, three fewer on hand
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#completes every unit’s obligation through the register (the allocation as the record), and emits one deferred cost relief fact per item
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#writes the shipped quantity on the order line, the order’s shipping_summary complete, and the order’s history
Source
services-commerce:modules/fulfillment/tests/integration/services/persistence/obligation-register.integration.spec.js#records partial completion as in progress with the units, then completes when the rest arrive,services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#hands off: the line handed to the carrier with its whole quantity shipped, the units shipped in the ledger, one shipment movement of minus three on the item, three fewer on hand,services-commerce:modules/inventory/tests/integration/db/inventory-tables.table.integration.spec.js#counts a held row against held, a committed one against allocated and a released one against nothing, through the trigger
07 Packing permits label purchase and manifestation before departureinteractionapitest
Proves
BR-CAP-COM-FUL-012-04 BR-CAP-COM-FUL-012-06 BR-CAP-COM-FUL-012-07 BR-CAP-COM-FUL-013-01 BR-CAP-COM-FUL-014-01
Preconditions
An authorized merchandise order has released warehouse work.
Steps
Pick, pack, purchase labels for every parcel, manifest and hand off.
Expected
Parcel preparation reaches labelled and manifested states before the shipment leaves; departure completes its units.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Bound to
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#releases the shipment to the floor and lists its line for picking at the bin the ledger names, the shipment picking
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#records the pick: the list line picked, the shipment line picked with its quantity, the shipment picked
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#packs the three units into two parcels, the second weighed from nothing (the shirt has no weight), the line packed, the shipment packed with two packages
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
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#records the refused purchase failed (carrier_unavailable), not in flight, so the next purchase buys on attempt 2
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#answers a purchase the platform refused before anything ran 503 carrier_unavailable with the reason, sent once
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#hands off: the line handed to the carrier with its whole quantity shipped, the units shipped in the ledger, one shipment movement of minus three on the item, three fewer on hand
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#completes every unit’s obligation through the register (the allocation as the record), and emits one deferred cost relief fact per item
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#writes the shipped quantity on the order line, the order’s shipping_summary complete, and the order’s history
Source
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#releases the shipment to the floor and lists its line for picking at the bin the ledger names, the shipment picking,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,services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#hands off: the line handed to the carrier with its whole quantity shipped, the units shipped in the ledger, one shipment movement of minus three on the item, three fewer on hand
08 Replenishment creates the second dispatch waveinteractionapitest
Proves
BR-CAP-COM-FUL-012-02 BR-CAP-COM-FUL-017-07 BR-CAP-COM-FUL-018-02 BR-CAP-COM-FUL-014-01
Preconditions
A five-shirt order has three available units and two backorders.
Steps
Ship the first wave, receive two more shirts and create and ship the next wave.
Expected
The second wave contains only the two replenished units; all five obligations complete.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Bound to
services-commerce:modules/shipping/tests/e2e/shipping.e2e.spec.js#makes the first wave of the three picked units (0..2), charged what the order paid, and walks it to the handoff
services-commerce:modules/shipping/tests/e2e/shipping.e2e.spec.js#fills the two backorders at the receipt, and the second wave picks the filled units at its creation (3..4) and ships them
services-commerce:modules/shipping/tests/e2e/shipping.e2e.spec.js#completes the order’s shipping: every unit shipped, every obligation completed, the shelf down five, the cost facts emitted per wave
Source
services-commerce:modules/shipping/tests/e2e/shipping.e2e.spec.js#makes the first wave of the three picked units (0..2), charged what the order paid, and walks it to the handoff,services-commerce:modules/inventory/tests/integration/services/stock/staff-movements.integration.spec.js#converts both backordered units to committed in the receipt’s transaction, oldest order first, leaving one to sell,services-commerce:modules/inventory/tests/integration/services/stock/merchandise-claims.integration.spec.js#is refused insufficient_stock with nothing written when the product prohibits backorders (the last cap),services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#hands off: the line handed to the carrier with its whole quantity shipped, the units shipped in the ledger, one shipment movement of minus three on the item, three fewer on hand
09 Cancellation fencing releases selected allocations while retained units ship laterinteractionapitest
Proves
BR-CAP-COM-FUL-012-08 BR-CAP-COM-FUL-014-06 BR-CAP-COM-FUL-018-07
Preconditions
Three picked shirts share a labelled shipment and cancellation selects the final unit.
Steps
Commit cancellation, deliver its instruction and create a new shipment for the retained units.
Expected
The selected unit releases, the old parcel is pulled, and two retained picked units use new shipment work.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Bound to
services-commerce:modules/shipping/tests/e2e/post-purchase-shipping.e2e.spec.js#fences and cancels the shipment line, pulls the package and voids the counter label, and refuses the handoff asked after (409)
services-commerce:modules/shipping/tests/e2e/post-purchase-shipping.e2e.spec.js#delivers the cancel to the Merchandise participant: unit 2 released, the kept units unfenced and picked, the document completed, the memo and the refund after the domain
Source
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#refuses a second handover (not packed any more) and the cancellation of a collected shipment,services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#cancels the fenced line at the cancel step: the units unstamped (still the order’s, picked), the label voided and the package pulled, the shipment cancelled,services-commerce:modules/inventory/tests/integration/services/stock/merchandise-claims.integration.spec.js#releases a line’s committed units on a void, giving the stock back; a release naming nothing live answers released: []

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