--- id: ATS-COM-FUL-013 scope: CAP-COM-FUL-013 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-013-01 title: Label attempts distinguish purchased and unavailable outcomes level: api proves: - BR-CAP-COM-FUL-013-01 - BR-CAP-COM-FUL-013-04 preconditions: A packed UPS parcel and a denied integration binding exist. steps: Purchase a label through each binding. expected: >- Successful work stores tracking and cost; denied work stores failure and a later purchase uses attempt two. negative: false data_needs: >- Fixtures for label attempts distinguish purchased and unavailable outcomes. bound_to: - >- 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/db/shipping-tables.table.integration.spec.js#writes a label intent once under its key (premise), refuses the same key twice, by carrier_labels_idempotency_key_uq, and holds a purchased label to its tracking number and instant, by carrier_labels_purchased_check - TST-COM-FUL-078 - TST-COM-FUL-077 provenance: test 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 category: transition - id: ATS-COM-FUL-013-02 title: Uncertain carrier purchases retain their original key level: api proves: - BR-CAP-COM-FUL-013-02 - INV-DOM-COM-FUL-004-06 preconditions: UPS accepted a purchase but its response was lost. steps: Repeat the purchase while its result remains uncertain. expected: >- Recovery queries and resends the original key, reports in-flight uncertainty and records the found label without another purchase. negative: true data_needs: Fixtures for uncertain carrier purchases retain their original key. bound_to: - >- services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#leaves an unknown purchase in flight: the label requested under package::1, the package packed, the uncertainty on the history - >- services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#asks the carrier by the key before buying again, then the same purchase under the same key, and refuses label_purchase_in_flight while neither settles it, buying under no new key - >- services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#settles the purchase in flight by the lookup: the label the carrier holds recorded on attempt 1, the package labelled, never bought twice - >- services-commerce:modules/shipping/tests/e2e/shipping.e2e.spec.js#answers an unknown purchase 200 with the label still requested, and the next purchase 409 label_purchase_in_flight while the carrier cannot say - >- services-commerce:modules/shipping/tests/unit/carriers/carrier-adapters.spec.js#answers an unknown purchase as uncertain with the execution, never bought again - TST-COM-FUL-078 - TST-COM-FUL-075 - TST-COM-FUL-084 provenance: test source: >- services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#leaves an unknown purchase in flight: the label requested under package::1, the package packed, the uncertainty on the history category: failure - id: ATS-COM-FUL-013-03 title: Staff can record a carrier-confirmed in-flight purchase level: api proves: - BR-CAP-COM-FUL-013-03 preconditions: A manual-carrier label attempt remains in flight. steps: Resolve the attempt with the carrier-visible result. expected: The attempt becomes purchased and its parcel becomes labelled. negative: false data_needs: Fixtures for staff can record a carrier-confirmed in-flight purchase. bound_to: [] provenance: proposed source: >- services-commerce:modules/shipping/services/fulfillment/labels.ts:resolveLabelPurchase category: transition - id: ATS-COM-FUL-013-04 title: Manual labels require clerk-supplied information level: unit proves: - BR-CAP-COM-FUL-013-05 preconditions: A manual carrier account is configured. steps: >- Try valid details, absent details and fractional cost, then rating, void and tracking. expected: >- Valid details are accepted, invalid purchases fail, rating supplies no option and void succeeds without automatic tracking. negative: true data_needs: Fixtures for manual labels require clerk-supplied information. bound_to: - >- services-commerce:modules/shipping/tests/unit/carriers/carrier-adapters.spec.js#answers the clerk’s details as the purchased label, under the request’s key - >- services-commerce:modules/shipping/tests/unit/carriers/carrier-adapters.spec.js#fails a purchase with no details, not retryable, and one with a cost that is not a whole non-negative number - >- services-commerce:modules/shipping/tests/unit/carriers/carrier-adapters.spec.js#rates nothing, with the warning that says so - >- services-commerce:modules/shipping/tests/unit/carriers/carrier-adapters.spec.js#voids every label and tracks nothing - TST-COM-FUL-084 provenance: test source: >- services-commerce:modules/shipping/tests/unit/carriers/carrier-adapters.spec.js#answers the clerk’s details as the purchased label, under the request’s key category: validation - id: ATS-COM-FUL-013-05 title: UPS invocation checks the connection and grant level: unit proves: - BR-CAP-COM-FUL-013-06 - BR-CAP-COM-FUL-013-07 preconditions: UPS fixtures include missing connections and invocation authority. steps: Exercise granted and ungranted calls and each response class. expected: >- Only the connected authorized request is sent and each failure retains its mapped classification. negative: true data_needs: Fixtures for uPS invocation checks the connection and grant. bound_to: - >- services-commerce:modules/shipping/tests/unit/carriers/carrier-adapters.spec.js#buys a label through shipping.label.purchase@1 under the label’s key, the shipment as the subject - >- services-commerce:modules/shipping/tests/unit/carriers/carrier-adapters.spec.js#refuses an account with no connection as 503 carrier_unavailable, sending nothing - >- services-commerce:modules/shipping/tests/unit/carriers/carrier-adapters.spec.js#refuses every call 503 carrier_unavailable in a function without the integrations_invoke grant, sending nothing - >- services-commerce:modules/shipping/tests/unit/carriers/carrier-adapters.spec.js#answers a timeout and a rate limit as failed and retryable - >- services-commerce:modules/shipping/tests/unit/carriers/carrier-adapters.spec.js#answers an invalid request as failed and not retryable, the contract’s code as it is (never ups_) - >- services-commerce:modules/shipping/tests/unit/carriers/carrier-adapters.spec.js#answers a purchase the gateway gave no answer to (IntegrationInvokeFailed) as uncertain, so it stays in flight - >- services-commerce:modules/shipping/tests/unit/carriers/carrier-adapters.spec.js#refuses a purchase on a disconnected connection (IntegrationInvokeRefused) as 503 carrier_unavailable, not in flight - TST-COM-FUL-084 provenance: test source: >- services-commerce:modules/shipping/tests/unit/carriers/carrier-adapters.spec.js#buys a label through shipping.label.purchase@1 under the label’s key, the shipment as the subject category: permission - id: ATS-COM-FUL-013-06 title: Void retries retain distinct attempt outcomes level: api proves: - BR-CAP-COM-FUL-013-09 preconditions: Purchased labels receive refused and uncertain void responses. steps: Void both labels and retry the uncertain result. expected: >- Refusal retains label cost and a finding, and uncertain recovery uses another void key before returning the parcel to packing. negative: false data_needs: Fixtures for void retries retain distinct attempt outcomes. bound_to: - >- services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#keeps a void the carrier refused (refused.void_window_closed): the label void_failed with its cost, the void_failed finding - >- services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#voids the second label through the platform: the label voided, the package back to packed - >- services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#voids again under the next attempt’s key (void: