Rhythm 2.0 Specifications

Appearance

ATS-COM-FUL-013Purchase and follow carrier labels safely: Capability Test Specification

Markdown

ATS-COM-FUL-013

Purchase and follow carrier labels safely: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-COM-FUL-013

Design

Executed by
TST-COM-FUL-075, TST-COM-FUL-077, TST-COM-FUL-078, TST-COM-FUL-084

KindAcceptance test setProduct areaCommerceModuleFulfillment, Shipping and InventoryRevision2

Read atservices-commerce c8b66a98react-console baf6dae3

Purchase and follow carrier labels safely: 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-013-01ATS-COM-FUL-013-01, ATS-COM-FUL-013-10, ATS-COM-FUL-013-11
BR-CAP-COM-FUL-013-02ATS-COM-FUL-013-02
BR-CAP-COM-FUL-013-03ATS-COM-FUL-013-03
BR-CAP-COM-FUL-013-04ATS-COM-FUL-013-01, ATS-COM-FUL-013-10, ATS-COM-FUL-013-11
BR-CAP-COM-FUL-013-05ATS-COM-FUL-013-04
BR-CAP-COM-FUL-013-06ATS-COM-FUL-013-05, ATS-COM-FUL-013-09
BR-CAP-COM-FUL-013-07ATS-COM-FUL-013-05, ATS-COM-FUL-013-09
BR-CAP-COM-FUL-013-09ATS-COM-FUL-013-06
BR-CAP-COM-FUL-013-10ATS-COM-FUL-013-07
BR-CAP-COM-FUL-013-11ATS-COM-FUL-013-08

The interaction cases exercise record goods leaving with a carrier or collector; process returned goods through inspection and disposition. 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-068
  • Transition covered
  • Validation covered
  • Permission covered
  • Edge covered
  • Failure covered
  • Boundary gap: FND-COM-FUL-068
  • Concurrency gap: FND-COM-FUL-068
  • Invariant gap: FND-COM-FUL-068
  • Interaction covered

Test Scenarios

11 scenarios proving CAP-COM-FUL-013; 8 bound to an existing test.

01 Label attempts distinguish purchased and unavailable outcomestransitionapitest
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.
Data
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:<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/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
Source
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
02 Uncertain carrier purchases retain their original keyfailureapinegativetest
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.
Data
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:<id>: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
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:<id>:1, the package packed, the uncertainty on the history
03 Staff can record a carrier-confirmed in-flight purchasetransitionapiproposed
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.
Data
Fixtures for staff can record a carrier-confirmed in-flight purchase.
Source
services-commerce:modules/shipping/services/fulfillment/labels.ts:resolveLabelPurchase
04 Manual labels require clerk-supplied informationvalidationunitnegativetest
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.
Data
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
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
05 UPS invocation checks the connection and grantpermissionunitnegativetest
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.
Data
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_<code>)
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
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
06 Void retries retain distinct attempt outcomesfailureapitest
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.
Data
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:<label id>:2), each attempt’s intent on the history
services-commerce:modules/shipping/tests/unit/carriers/carrier-adapters.spec.js#names each void attempt by its label and its number (void:<label id>:<attempt>), a new key for each attempt
Source
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
07 Tracking completion can finish the shipmenttransitionapitest
Proves
BR-CAP-COM-FUL-013-10
Preconditions
A handed-over shipment contains UPS and manual parcels.
Steps
Request UPS history and enter the manual delivery result.
Expected
Both parcels become delivered and the shipment follows them.
Data
Fixtures for tracking completion can finish the shipment.
Bound to
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#tracks the UPS package to delivery from the platform’s history, records the counter package delivered by hand, and the shipment is delivered once both are
Source
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#tracks the UPS package to delivery from the platform’s history, records the counter package delivered by hand, and the shipment is delivered once both are
08 Pickup rejects carrier-only operationsedgeapinegativetest
Proves
BR-CAP-COM-FUL-013-11
Preconditions
A pickup shipment has been packed.
Steps
Try label purchase, label void, manifest and carrier handoff.
Expected
Every carrier-only action reports unsupported operation.
Data
Fixtures for pickup rejects carrier-only operations.
Bound to
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#refuses the carrier’s label purchase, void, manifest and handoff operation_not_supported
services-commerce:modules/shipping/tests/e2e/shipping.e2e.spec.js#makes a pickup shipment of the paid order, on no carrier, and refuses its label 409 operation_not_supported
Source
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#refuses the carrier’s label purchase, void, manifest and handoff operation_not_supported
09 The account selected by shipping configuration supplies label invocationinteractionapiproposed
Proves
BR-CAP-COM-FUL-010-07 BR-CAP-COM-FUL-013-06
Preconditions
A packed carrier shipment references a UPS account connected through the integration service.
Steps
Purchase a label with the invocation grant, then use an account without a valid connection or grant.
Expected
The connected purchase records a label; the invalid configuration makes no carrier request.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Source
services-commerce:modules/shipping/tests/integration/db/shipping-tables.table.integration.spec.js#refuses a carrier outside the six and a markup above 100 %, by carrier_accounts_carrier_check and carrier_accounts_markup_check,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
10 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
11 Return-label preparation uses the outbound carrier choiceinteractionapiproposed
Proves
BR-CAP-COM-FUL-015-09 BR-CAP-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.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
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:<id>:1 (the intent then the outcome), the tracking number and the cost on the label, the package labelled

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