--- id: ATS-COM-FUL-014 scope: CAP-COM-FUL-014 product_area: commerce module: fulfillment revision: 2 status: proposed approved_by: null approved_at: null source_sha: services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b react-console: baf6dae382d6f41dce976c7f848667ccc37e076f scenarios: - id: ATS-COM-FUL-014-01 title: Departure changes stock and delivery records atomically level: api 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. negative: false data_needs: 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 - TST-COM-FUL-078 provenance: test 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 category: invariant - id: ATS-COM-FUL-014-02 title: Unauthorized or repeated departure cannot move stock level: api 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. negative: true data_needs: 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 - TST-COM-FUL-078 provenance: test 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 category: failure - id: ATS-COM-FUL-014-03 title: Cancellation fencing resolves contention with departure level: api 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. negative: true data_needs: 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:), 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/integration/services/fulfillment/shipping-flow.integration.spec.js#answers the plan must_return for the unit: shipped, by the row - >- 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) - TST-COM-FUL-078 - TST-COM-FUL-074 provenance: test 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:), nothing refused category: concurrency - id: ATS-COM-FUL-014-04 title: Retained units use a new shipment after fenced cancellation level: api 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. negative: false data_needs: 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) - >- services-commerce:modules/shipping/tests/e2e/post-purchase-shipping.e2e.spec.js#carries the two kept units on a new shipment (0..1) - TST-COM-FUL-078 - TST-COM-FUL-074 provenance: test 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 category: interaction - id: ATS-COM-FUL-014-05 title: Collection requires collector and authorized staff level: api 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. negative: true data_needs: 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/integration/services/fulfillment/shipping-flow.integration.spec.js#refuses the handover of a carrier’s shipment operation_not_supported - >- 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 - TST-COM-FUL-078 - TST-COM-FUL-075 provenance: test 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 category: permission - id: ATS-COM-FUL-014-06 title: Warehouse departure supplies the physical application outcome category: interaction level: api proves: - BR-CAP-COM-FUL-004-04 - BR-CAP-COM-FUL-014-01 - BR-CAP-COM-FUL-018-05 exercises: - CAP-COM-FUL-004 - CAP-COM-FUL-014 - CAP-COM-FUL-018 relies_on: - ATS-COM-FUL-004-03 - ATS-COM-FUL-014-01 - ATS-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. negative: false data_needs: >- 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 - TST-COM-FUL-078 provenance: test 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 - id: ATS-COM-FUL-014-07 title: Packing permits label purchase and manifestation before departure category: interaction level: api 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 exercises: - CAP-COM-FUL-012 - CAP-COM-FUL-013 - CAP-COM-FUL-014 relies_on: - ATS-COM-FUL-012-04 - ATS-COM-FUL-013-01 - ATS-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. negative: false data_needs: >- 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::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 - TST-COM-FUL-078 provenance: test 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::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 - id: ATS-COM-FUL-014-08 title: Replenishment creates the second dispatch wave category: interaction level: api 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 exercises: - CAP-COM-FUL-012 - CAP-COM-FUL-017 - CAP-COM-FUL-018 - CAP-COM-FUL-014 relies_on: - ATS-COM-FUL-012-02 - ATS-COM-FUL-017-04 - ATS-COM-FUL-018-02 - ATS-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. negative: false data_needs: >- 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 - TST-COM-FUL-075 provenance: test 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 - id: ATS-COM-FUL-014-09 title: >- Cancellation fencing releases selected allocations while retained units ship later category: interaction level: api proves: - BR-CAP-COM-FUL-012-08 - BR-CAP-COM-FUL-014-06 - BR-CAP-COM-FUL-018-07 exercises: - CAP-COM-FUL-012 - CAP-COM-FUL-014 - CAP-COM-FUL-018 relies_on: - ATS-COM-FUL-012-06 - ATS-COM-FUL-014-04 - ATS-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. negative: false data_needs: >- 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#carries the two kept units on a new shipment (0..1) - >- 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 - TST-COM-FUL-074 provenance: test 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: [] evidence: - repository: services-commerce tests: - >- 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 - >- 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 - >- 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:), 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/integration/services/fulfillment/shipping-flow.integration.spec.js#answers the plan must_return for the unit: shipped, by the row - >- 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) - >- 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) - >- services-commerce:modules/shipping/tests/e2e/post-purchase-shipping.e2e.spec.js#carries the two kept units on a new shipment (0..1) - >- 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/integration/services/fulfillment/shipping-flow.integration.spec.js#refuses the handover of a carrier’s shipment operation_not_supported - >- 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 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 coverage_notes: rule: >- No scenario specifically isolates this dimension; the coverage finding retains the missing proof. transition: >- No scenario specifically isolates this dimension; the coverage finding retains the missing proof. validation: >- No scenario specifically isolates this dimension; the coverage finding retains the missing proof. edge: >- No scenario specifically isolates this dimension; the coverage finding retains the missing proof. boundary: >- No scenario specifically isolates this dimension; the coverage finding retains the missing proof. transition_audit: - model: STATE-COM-FUL-005 from: open to: released source: >- services-commerce:modules/shipping/services/fulfillment/shipment-creation.ts:releaseShipment coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-005 from: released to: picking source: >- services-commerce:modules/shipping/services/fulfillment/picking.ts:createPickListForWarehouse coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-005 from: picking to: picked source: >- services-commerce:modules/shipping/services/fulfillment/picking.ts:recordPickOnList coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-005 from: picked to: packing source: >- services-commerce:modules/shipping/services/fulfillment/packing.ts:packShipment coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-005 from: picked to: packed source: >- services-commerce:modules/shipping/services/fulfillment/packing.ts:packShipment coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-005 from: packing to: packed source: >- services-commerce:modules/shipping/services/fulfillment/packing.ts:packShipment coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-005 from: packed to: labelled source: >- services-commerce:modules/shipping/services/fulfillment/labels.ts:purchaseLabelForPackage coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-005 from: labelled to: packed source: >- services-commerce:modules/shipping/services/fulfillment/labels.ts:voidLabelOfPackage coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-005 from: labelled to: manifested source: >- services-commerce:modules/shipping/services/fulfillment/handoff.ts:manifestShipment coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-005 from: manifested to: handed_to_carrier 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 coverage: covered scenarios: - ATS-COM-FUL-004-12 - ATS-COM-FUL-012-10 - ATS-COM-FUL-013-10 - ATS-COM-FUL-014-01 - ATS-COM-FUL-014-06 - ATS-COM-FUL-014-07 - ATS-COM-FUL-018-08 - model: STATE-COM-FUL-005 from: packed to: collected source: 'services-commerce:docs/migrations/shipping/README.md#D-P8S-14' coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-005 from: handed_to_carrier to: delivered source: >- services-commerce:modules/shipping/services/fulfillment/labels.ts:trackPackage coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-005 from: handed_to_carrier to: exception source: >- services-commerce:modules/shipping/services/fulfillment/labels.ts:trackPackage coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-005 from: handed_to_carrier to: returned_to_sender source: >- services-commerce:modules/shipping/services/fulfillment/labels.ts:trackPackage coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-005 from: open to: cancelled source: >- services-commerce:modules/shipping/services/fulfillment/shipment-creation.ts:cancelShipment coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-005 from: manifested to: cancelled source: >- services-commerce:modules/shipping/services/fulfillment/cancellation-fence.ts:cancelFencedShipmentLines coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-005 from: allocated to: released_to_warehouse source: >- services-commerce:modules/shipping/services/fulfillment/shipment-creation.ts:releaseShipment coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-005 from: released_to_warehouse to: picking source: >- services-commerce:modules/shipping/services/fulfillment/picking.ts:createPickListForWarehouse coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-005 from: picking to: picked source: >- services-commerce:modules/shipping/services/fulfillment/picking.ts:recordPickOnList coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-005 from: picking to: short source: >- services-commerce:modules/shipping/services/fulfillment/picking.ts:recordPickOnList coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-005 from: picking to: released_to_warehouse source: >- services-commerce:modules/shipping/services/fulfillment/picking.ts:cancelPickList coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-005 from: allocated to: cancellation_pending source: >- services-commerce:modules/shipping/services/persistence/shipments.ts:fenceLinesForCancellation coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-005 from: released_to_warehouse to: cancellation_pending source: >- services-commerce:modules/shipping/services/persistence/shipments.ts:fenceLinesForCancellation coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-005 from: picking to: cancellation_pending source: >- services-commerce:modules/shipping/services/persistence/shipments.ts:fenceLinesForCancellation coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-005 from: picked to: cancellation_pending source: >- services-commerce:modules/shipping/services/persistence/shipments.ts:fenceLinesForCancellation coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-005 from: packing to: cancellation_pending source: >- services-commerce:modules/shipping/services/persistence/shipments.ts:fenceLinesForCancellation coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-005 from: packed to: cancellation_pending source: >- services-commerce:modules/shipping/services/persistence/shipments.ts:fenceLinesForCancellation coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-005 from: labelled to: cancellation_pending source: >- services-commerce:modules/shipping/services/persistence/shipments.ts:fenceLinesForCancellation coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-005 from: manifested to: cancellation_pending source: >- services-commerce:modules/shipping/services/persistence/shipments.ts:fenceLinesForCancellation coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-005 from: short to: cancellation_pending source: >- services-commerce:modules/shipping/services/persistence/shipments.ts:fenceLinesForCancellation coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-005 from: cancellation_pending to: cancelled source: >- services-commerce:modules/shipping/services/persistence/shipments.ts:cancelFencedLines coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-006 from: packed to: packed source: >- services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#buys the first label through UPS under package::1 (the intent then the outcome), the tracking number and the cost on the label, the package labelled coverage: covered scenarios: - ATS-COM-FUL-012-10 - ATS-COM-FUL-013-01 - ATS-COM-FUL-013-10 - ATS-COM-FUL-014-07 - model: STATE-COM-FUL-006 from: packed to: labelled source: >- services-commerce:modules/shipping/services/fulfillment/labels.ts:recordPurchaseOutcome,resolveLabelPurchase coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-006 from: packed to: packed source: >- services-commerce:modules/shipping/services/fulfillment/labels.ts:purchaseLabelForPackage coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-006 from: labelled to: packed source: >- services-commerce:modules/shipping/services/fulfillment/labels.ts:voidLabelOfPackage coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-006 from: labelled to: voided source: >- services-commerce:modules/shipping/services/fulfillment/labels.ts:voidLabelsOfShipment coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-006 from: labelled to: manifested source: >- services-commerce:modules/shipping/services/fulfillment/handoff.ts:manifestShipment coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-006 from: manifested to: handed_to_carrier source: >- services-commerce:modules/shipping/services/fulfillment/handoff.ts:handoffShipment coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-006 from: handed_to_carrier to: in_transit source: >- services-commerce:modules/shipping/services/fulfillment/labels.ts:trackPackage coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-006 from: in_transit to: delivered source: >- services-commerce:modules/shipping/services/fulfillment/labels.ts:trackPackage coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-006 from: in_transit to: exception source: >- services-commerce:modules/shipping/services/fulfillment/labels.ts:trackPackage coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-006 from: in_transit to: returned_to_sender source: >- services-commerce:modules/shipping/services/fulfillment/labels.ts:trackPackage coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-006 from: packed to: collected source: >- services-commerce:modules/shipping/services/fulfillment/handoff.ts:handoverShipment coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-006 from: packed to: voided source: >- services-commerce:modules/shipping/services/fulfillment/cancellation-fence.ts:cancelFencedShipmentLines coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-006 from: requested to: purchased source: >- services-commerce:modules/shipping/services/persistence/carrier-labels.ts:recordLabelOutcome coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-006 from: requested to: failed source: >- services-commerce:modules/shipping/services/persistence/carrier-labels.ts:recordLabelOutcome coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-006 from: purchased to: voided source: >- services-commerce:modules/shipping/services/persistence/carrier-labels.ts:recordLabelVoid coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-006 from: purchased to: void_failed source: >- services-commerce:modules/shipping/services/persistence/carrier-labels.ts:recordLabelVoid coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-006 from: void_failed to: voided source: >- services-commerce:modules/shipping/services/persistence/carrier-labels.ts:recordLabelVoid coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-006 from: void_failed to: void_failed source: >- services-commerce:modules/shipping/services/persistence/carrier-labels.ts:recordLabelVoid coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-009 from: held to: committed source: >- services-commerce:modules/inventory/db/inventory-allocations.table.ts (commerce_commit_claims) coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-009 from: held to: released source: >- services-commerce:modules/inventory/services/persistence/inventory-allocations.ts:expireHolds coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-009 from: committed to: picked source: >- services-commerce:modules/inventory/services/persistence/inventory-allocations.ts:pickUnitsOfLine coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-009 from: backordered to: committed source: >- services-commerce:modules/inventory/services/persistence/inventory-allocations.ts:fillBackorders coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-009 from: picked to: shipped source: >- services-commerce:modules/inventory/services/persistence/inventory-allocations.ts:shipUnits coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-009 from: committed to: released source: >- services-commerce:modules/inventory/services/persistence/inventory-allocations.ts:releaseFencedUnitsOfLine coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-009 from: picked to: released source: >- services-commerce:docs/migrations/inventory/README.md (D-P7-24 amendment of D-P8I-13) coverage: 'gap: FND-COM-FUL-069' scenarios: [] - model: STATE-COM-FUL-009 from: backordered to: released source: >- services-commerce:modules/inventory/db/inventory-allocations.table.ts (commerce_release_claims) coverage: 'gap: FND-COM-FUL-069' scenarios: [] permission_audit: - key: commerce.shipments.handoff where_checked: api coverage: 'gap: FND-COM-FUL-069' note: >- Per-key positive and negative coverage is not separately mapped; permission scenarios retain the observed aggregate tests. - key: commerce.shipments.handover where_checked: api coverage: 'gap: FND-COM-FUL-069' note: >- Per-key positive and negative coverage is not separately mapped; permission scenarios retain the observed aggregate tests. related_audit: - capability: CAP-COM-FUL-018 scenarios: - ATS-COM-FUL-014-06 - ATS-COM-FUL-014-08 - ATS-COM-FUL-014-09 invariant_audit: - invariant: INV-DOM-COM-FUL-001-01 scenarios: - ATS-COM-FUL-004-07 coverage: covered provenance: observed source: >- services-commerce:modules/fulfillment/db/obligations.table.ts:obligations_subject_uq - invariant: INV-DOM-COM-FUL-001-02 scenarios: - ATS-COM-FUL-004-07 coverage: covered provenance: observed source: >- services-commerce:modules/fulfillment/services/persistence/obligations.ts:OBLIGATION_TRANSITIONS; db/migrations/20261018004016_obligation_register.sql:refuse_obligation_regression - invariant: INV-DOM-COM-FUL-001-03 scenarios: - ATS-COM-FUL-004-07 coverage: covered provenance: observed source: >- services-commerce:modules/fulfillment/db/obligations.table.ts:obligations_authorization_state_check - invariant: INV-DOM-COM-FUL-001-04 scenarios: - ATS-COM-FUL-004-03 coverage: covered provenance: observed source: >- services-commerce:modules/fulfillment/db/obligations.table.ts:obligations_quantity_check - invariant: INV-DOM-COM-FUL-001-05 scenarios: - ATS-COM-FUL-002-08 coverage: covered provenance: observed source: >- services-commerce:modules/fulfillment/services/persistence/obligations.ts:openGate - invariant: INV-DOM-COM-FUL-001-06 scenarios: - ATS-COM-FUL-004-02 coverage: covered provenance: observed source: >- services-commerce:modules/fulfillment/services/persistence/obligations.ts:recordObligationOutcome - invariant: INV-DOM-COM-FUL-001-07 scenarios: - ATS-COM-FUL-005-02 coverage: covered provenance: observed source: >- services-commerce:modules/fulfillment/db/obligation-attempts.table.ts; modules/fulfillment/db/intervention-logs.table.ts (UPDATE, DELETE and TRUNCATE revoked) - invariant: INV-DOM-COM-FUL-001-08 scenarios: - ATS-COM-FUL-005-02 coverage: covered provenance: observed source: >- services-commerce:modules/fulfillment/services/register/obligation-interventions.ts - invariant: INV-DOM-COM-FUL-001-09 scenarios: - ATS-COM-FUL-005-03 coverage: covered provenance: test source: >- services-commerce:docs/migrations/obligation-register/README.md#D-P4-16 (obligation-register.e2e five simultaneous approvals) - invariant: INV-DOM-COM-FUL-001-10 scenarios: - ATS-COM-FUL-006-03 coverage: covered provenance: observed source: >- services-commerce:modules/fulfillment/db/enforcements.table.ts:enforcements_cause_uq - invariant: INV-DOM-COM-FUL-001-11 scenarios: - ATS-COM-FUL-002-07 coverage: covered provenance: observed source: >- services-commerce:modules/fulfillment/services/facts/financial-facts-handler.ts - invariant: INV-DOM-COM-FUL-001-12 scenarios: [] coverage: 'gap: FND-COM-FUL-069' provenance: observed source: >- services-commerce:modules/fulfillment/db/obligations.table.ts (composite RESTRICT keys) - invariant: INV-DOM-COM-FUL-004-01 scenarios: [] coverage: 'gap: FND-COM-FUL-069' provenance: observed source: >- services-commerce:modules/shipping/db/shipments.table.ts; packages.table.ts; pick-lists.table.ts; return-receipts.table.ts - invariant: INV-DOM-COM-FUL-004-02 scenarios: [] coverage: 'gap: FND-COM-FUL-069' provenance: observed source: 'services-commerce:modules/shipping/db/shipment-lines.table.ts' - invariant: INV-DOM-COM-FUL-004-03 scenarios: - ATS-COM-FUL-014-01 coverage: covered provenance: test 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 - invariant: INV-DOM-COM-FUL-004-04 scenarios: - ATS-COM-FUL-014-02 coverage: covered provenance: observed source: >- services-commerce:modules/shipping/services/fulfillment/handoff.ts:obligationsOfUnits - invariant: INV-DOM-COM-FUL-004-05 scenarios: - ATS-COM-FUL-014-03 coverage: covered provenance: observed source: >- services-commerce:modules/shipping/services/persistence/shipments.ts:fenceLinesForCancellation,handoffLinesOfShipment - invariant: INV-DOM-COM-FUL-004-06 scenarios: - ATS-COM-FUL-013-02 coverage: covered provenance: documented source: 'services-commerce:docs/migrations/shipping/README.md#D-P8S-08' - invariant: INV-DOM-COM-FUL-004-07 scenarios: [] coverage: 'gap: FND-COM-FUL-069' provenance: observed source: >- services-commerce:modules/shipping/db/shipments.table.ts:shipments_pickup_check - invariant: INV-DOM-COM-FUL-004-08 scenarios: - ATS-COM-FUL-012-07 coverage: covered provenance: observed source: >- services-commerce:modules/shipping/db/shipment-events.table.ts (UPDATE, DELETE and TRUNCATE revoked) - invariant: INV-DOM-COM-FUL-004-09 scenarios: [] coverage: 'gap: FND-COM-FUL-069' provenance: observed source: >- services-commerce:modules/shipping/db/return-receipts.table.ts; return-receipt-lines.table.ts:return_receipt_lines_quantities_check - invariant: INV-DOM-COM-FUL-004-10 scenarios: - ATS-COM-FUL-010-04 coverage: covered provenance: observed source: >- services-commerce:modules/shipping/services/persistence/carrier-accounts.ts - invariant: INV-DOM-COM-FUL-004-11 scenarios: - ATS-COM-FUL-010-02 - ATS-COM-FUL-010-03 - ATS-COM-FUL-010-04 coverage: covered provenance: observed source: >- services-commerce:modules/shipping/db/shipping-strategies.table.ts; modules/shipping/db/shipments.table.ts; modules/shipping/db/carrier-labels.table.ts - invariant: INV-DOM-COM-FUL-004-12 scenarios: - ATS-COM-FUL-010-03 coverage: covered provenance: observed source: >- services-commerce:modules/shipping/services/persistence/shipping-strategies.ts:validateStrategyInput - invariant: INV-DOM-COM-FUL-005-01 scenarios: - ATS-COM-FUL-017-02 coverage: covered provenance: observed source: >- services-commerce:modules/inventory/db/inventory-items.table.ts (column grants, apply_inventory_movement, apply_inventory_allocation) - invariant: INV-DOM-COM-FUL-005-02 scenarios: - ATS-COM-FUL-017-02 coverage: covered provenance: observed source: >- services-commerce:modules/inventory/db/inventory-items.table.ts:inventory_items_balances_check - invariant: INV-DOM-COM-FUL-005-03 scenarios: - ATS-COM-FUL-017-01 - ATS-COM-FUL-017-02 coverage: covered provenance: observed source: >- services-commerce:modules/inventory/db/inventory-movements.table.ts:inventory_movements_quantity_sign_check - invariant: INV-DOM-COM-FUL-005-04 scenarios: - ATS-COM-FUL-017-03 coverage: covered provenance: documented source: 'services-commerce:docs/migrations/inventory/README.md#D-P8I-22' - invariant: INV-DOM-COM-FUL-005-05 scenarios: - ATS-COM-FUL-018-05 coverage: covered provenance: observed source: 'services-commerce:modules/inventory/db/inventory-allocations.table.ts' - invariant: INV-DOM-COM-FUL-005-06 scenarios: - ATS-COM-FUL-018-03 coverage: covered provenance: documented source: 'services-commerce:docs/migrations/inventory/README.md#D-P8I-21' - invariant: INV-DOM-COM-FUL-005-07 scenarios: - ATS-COM-FUL-014-01 coverage: covered provenance: observed source: >- services-commerce:modules/inventory/services/persistence/inventory-allocations.ts:shipUnits - invariant: INV-DOM-COM-FUL-005-08 scenarios: - ATS-COM-FUL-017-05 coverage: covered provenance: observed source: 'services-commerce:modules/inventory/services/stock/transfer-stock.ts' - invariant: INV-DOM-COM-FUL-005-09 scenarios: - ATS-COM-FUL-017-04 coverage: covered provenance: observed source: 'services-commerce:modules/inventory/services/stock/staff-movements.ts' - invariant: INV-DOM-COM-FUL-005-10 scenarios: - ATS-COM-FUL-019-01 coverage: covered provenance: observed source: >- services-commerce:modules/inventory/services/persistence/inventory-counts.ts:completeCount - invariant: INV-DOM-COM-FUL-005-11 scenarios: - ATS-COM-FUL-019-02 coverage: covered provenance: observed source: >- services-commerce:modules/inventory/db/inventory-exceptions.table.ts:inventory_exceptions_open_uidx - invariant: INV-DOM-COM-FUL-005-12 scenarios: - ATS-COM-FUL-016-06 - ATS-COM-FUL-017-09 - ATS-COM-FUL-018-12 coverage: covered provenance: observed source: >- services-commerce:modules/inventory/services/persistence/warehouses.ts; inventory-locations.ts --- # 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. | Rule | Scenarios | |---|---| | `BR-CAP-COM-FUL-014-01` | `ATS-COM-FUL-014-01`, `ATS-COM-FUL-014-06`, `ATS-COM-FUL-014-07`, `ATS-COM-FUL-014-08` | | `BR-CAP-COM-FUL-014-02` | `ATS-COM-FUL-014-02` | | `BR-CAP-COM-FUL-014-03` | `ATS-COM-FUL-014-02` | | `BR-CAP-COM-FUL-014-04` | `ATS-COM-FUL-014-03` | | `BR-CAP-COM-FUL-014-05` | `ATS-COM-FUL-014-03` | | `BR-CAP-COM-FUL-014-06` | `ATS-COM-FUL-014-04`, `ATS-COM-FUL-014-09` | | `BR-CAP-COM-FUL-014-07` | `ATS-COM-FUL-014-05` | | `BR-CAP-COM-FUL-014-08` | `ATS-COM-FUL-014-05` | | `BR-CAP-COM-FUL-014-09` | `ATS-COM-FUL-014-05` | ## Interactions With Related Capabilities 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.