--- id: ATS-COM-FUL-015 scope: CAP-COM-FUL-015 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-015-01 title: Receiving respects authorization and receipt identity level: api 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. negative: true data_needs: Fixtures for receiving respects authorization and receipt identity. bound_to: - >- services-commerce:modules/shipping/tests/integration/services/returns/return-receiving.integration.spec.js#answers the retried receipt as the one recorded, moving nothing - >- 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 - TST-COM-FUL-082 - TST-COM-FUL-074 provenance: test source: >- services-commerce:modules/shipping/tests/integration/services/returns/return-receiving.integration.spec.js#answers the retried receipt as the one recorded, moving nothing category: invariant - id: ATS-COM-FUL-015-02 title: Arrival waits for policy before financial execution level: api 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. negative: false data_needs: 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 - TST-COM-FUL-082 provenance: test 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 category: transition - id: ATS-COM-FUL-015-03 title: Inspection accepts only supported conditions level: api 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. negative: true data_needs: 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 - TST-COM-FUL-082 - TST-COM-FUL-076 provenance: test 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 category: validation - id: ATS-COM-FUL-015-04 title: Disposition separates sellable restoration from other treatment level: api 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. negative: false data_needs: >- 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) - TST-COM-FUL-082 - TST-COM-FUL-074 provenance: test 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 category: rule - id: ATS-COM-FUL-015-05 title: Disposition cannot exceed receipt or policy level: api 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. negative: true data_needs: 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) - TST-COM-FUL-082 - TST-COM-FUL-079 provenance: test 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 category: boundary - id: ATS-COM-FUL-015-06 title: Return-label work follows issuance and withdrawal level: api 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. negative: false data_needs: 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) - TST-COM-FUL-082 - TST-COM-FUL-074 provenance: test 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 category: interaction - id: ATS-COM-FUL-015-07 title: Receiving routes reject read-only and portal callers level: api 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. negative: true data_needs: 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 - TST-COM-FUL-074 provenance: test 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 category: permission - id: ATS-COM-FUL-015-08 title: Physical return disposition permits the requested money work category: interaction level: api proves: - BR-CAP-COM-FUL-007-06 - BR-CAP-COM-FUL-015-08 exercises: - CAP-COM-FUL-007 - CAP-COM-FUL-015 relies_on: - ATS-COM-FUL-007-04 - ATS-COM-FUL-015-04 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. negative: false data_needs: >- An isolated workspace with the products, records, authority and quantities described in the preconditions. bound_to: [] provenance: proposed 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 - id: ATS-COM-FUL-015-09 title: Returned stock becomes available through the movement ledger category: interaction level: api proves: - BR-CAP-COM-FUL-015-05 - BR-CAP-COM-FUL-017-03 - BR-CAP-COM-FUL-018-06 exercises: - CAP-COM-FUL-015 - CAP-COM-FUL-017 - CAP-COM-FUL-018 relies_on: - ATS-COM-FUL-015-04 - ATS-COM-FUL-017-02 - ATS-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. negative: false data_needs: >- An isolated workspace with the products, records, authority and quantities described in the preconditions. bound_to: [] provenance: proposed 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 - id: ATS-COM-FUL-015-10 title: Return-label preparation uses the outbound carrier choice category: interaction level: api proves: - BR-CAP-COM-FUL-015-09 - BR-CAP-COM-FUL-013-01 exercises: - CAP-COM-FUL-015 - CAP-COM-FUL-013 relies_on: - ATS-COM-FUL-015-06 - ATS-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. negative: false data_needs: >- An isolated workspace with the products, records, authority and quantities described in the preconditions. bound_to: [] provenance: proposed 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::1 (the intent then the outcome), the tracking number and the cost on the label, the package labelled evidence: - repository: services-commerce tests: - >- services-commerce:modules/shipping/tests/integration/services/returns/return-receiving.integration.spec.js#answers the retried receipt as the one recorded, moving nothing - >- 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 - >- 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 - >- 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 - >- 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) - >- 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) - >- 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) - >- 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 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 coverage_notes: edge: >- No scenario specifically isolates this dimension; the coverage finding retains the missing proof. failure: >- No scenario specifically isolates this dimension; the coverage finding retains the missing proof. concurrency: >- No scenario specifically isolates this dimension; the coverage finding retains the missing proof. transition_audit: - model: STATE-COM-FUL-008 from: received to: inspected source: >- services-commerce:modules/shipping/services/returns/return-receiving.ts:inspectReturnReceipt coverage: 'gap: FND-COM-FUL-070' scenarios: [] - model: STATE-COM-FUL-008 from: received to: dispositioned source: >- services-commerce:modules/shipping/services/returns/return-receiving.ts:dispositionReturnReceipt coverage: 'gap: FND-COM-FUL-070' scenarios: [] - model: STATE-COM-FUL-008 from: inspected to: dispositioned 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 coverage: covered scenarios: - ATS-COM-FUL-015-04 permission_audit: - key: commerce.return-receipts.read where_checked: api coverage: 'gap: FND-COM-FUL-070' note: >- Per-key positive and negative coverage is not separately mapped; permission scenarios retain the observed aggregate tests. - key: commerce.return-receipts.create where_checked: api coverage: 'gap: FND-COM-FUL-070' note: >- Per-key positive and negative coverage is not separately mapped; permission scenarios retain the observed aggregate tests. - key: commerce.return-receipts.update where_checked: api coverage: 'gap: FND-COM-FUL-070' note: >- Per-key positive and negative coverage is not separately mapped; permission scenarios retain the observed aggregate tests. related_audit: - capability: CAP-COM-FUL-007 scenarios: - ATS-COM-FUL-015-08 - capability: CAP-COM-FUL-017 scenarios: - ATS-COM-FUL-015-09 invariant_audit: - invariant: INV-DOM-COM-FUL-004-01 scenarios: [] coverage: 'gap: FND-COM-FUL-070' 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-070' 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-070' 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-070' 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 --- # 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. | Rule | Scenarios | |---|---| | `BR-CAP-COM-FUL-015-01` | `ATS-COM-FUL-015-01` | | `BR-CAP-COM-FUL-015-02` | `ATS-COM-FUL-015-01` | | `BR-CAP-COM-FUL-015-03` | `ATS-COM-FUL-015-02` | | `BR-CAP-COM-FUL-015-04` | `ATS-COM-FUL-015-03` | | `BR-CAP-COM-FUL-015-05` | `ATS-COM-FUL-015-04`, `ATS-COM-FUL-015-08`, `ATS-COM-FUL-015-09` | | `BR-CAP-COM-FUL-015-06` | `ATS-COM-FUL-015-04`, `ATS-COM-FUL-015-08`, `ATS-COM-FUL-015-09` | | `BR-CAP-COM-FUL-015-07` | `ATS-COM-FUL-015-05` | | `BR-CAP-COM-FUL-015-08` | `ATS-COM-FUL-015-04`, `ATS-COM-FUL-015-08`, `ATS-COM-FUL-015-09` | | `BR-CAP-COM-FUL-015-09` | `ATS-COM-FUL-015-06`, `ATS-COM-FUL-015-10` | | `BR-CAP-COM-FUL-015-11` | `ATS-COM-FUL-015-07` | ## Interactions With Related Capabilities 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.