Skip to content

ATS-COM-FUL-018Allocate stock and explain what buyers can obtain: Capability Test Specification

Markdown

ATS-COM-FUL-018

Allocate stock and explain what buyers can obtain: Capability Test Specification

Markdown
  • DocumentProposed

KindAcceptance test setProduct areaCommerceModuleFulfillment, Shipping and InventoryRevision2

Read atservices-commerce c8b66a98react-console baf6dae3

Coverage

  • Rule covered
  • Transition covered
  • Validation gap: FND-COM-FUL-073
  • Permission gap: FND-COM-FUL-073
  • Edge gap: FND-COM-FUL-073
  • Failure covered
  • Boundary gap: FND-COM-FUL-073
  • Concurrency covered
  • Invariant covered
  • Interaction covered

Test Scenarios

15 scenarios proving CAP-COM-FUL-018; 11 bound to an existing test.

01 Claims retain individual units and allocation orderruleapitest
Proves
BR-CAP-COM-FUL-018-01
Preconditions
Two sellable bins hold stock.
Steps
Claim two units for one line and repeat.
Expected
The first location supplies two numbered commitments and repetition creates no duplicates.
Data
Fixtures for claims retain individual units and allocation order.
Bound to
services-commerce:modules/inventory/tests/integration/services/stock/merchandise-claims.integration.spec.js#answers ok with one committed claim for the SKU and the quantity, under the claim ref the line is stamped with
services-commerce:modules/inventory/tests/integration/services/stock/merchandise-claims.integration.spec.js#writes one committed unit per unit on the first location in allocation order, unit 0 and 1, each stamped with the order and the line
services-commerce:modules/inventory/tests/integration/services/stock/merchandise-claims.integration.spec.js#answers the same claim again for the same line without writing twice (idempotent on the line)
Source
services-commerce:modules/inventory/tests/integration/services/stock/merchandise-claims.integration.spec.js#answers ok with one committed claim for the SKU and the quantity, under the claim ref the line is stamped with
02 Product policy decides shortage refusal or backorderfailureapinegativetest
Proves
BR-CAP-COM-FUL-018-02
Preconditions
Products differ on backorder permission and have too little stock.
Steps
Claim excess quantity and exercise an absent location item.
Expected
The strict product fails, the permissive product commits and backorders, and the missing item is created where needed.
Data
Fixtures for product policy decides shortage refusal or backorder.
Bound to
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/inventory/tests/integration/services/stock/merchandise-claims.integration.spec.js#commits what exists and backorders the rest when the product allows it (A12), the shortfall counting as backordered, never against available
services-commerce:modules/inventory/tests/integration/services/stock/merchandise-claims.integration.spec.js#backorders a SKU no item holds yet by making its item at the first sellable location, when the product allows it
Source
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)
03 Concurrent buyers cannot share the final stockconcurrencyapinegativetest
Proves
BR-CAP-COM-FUL-018-03 BR-CAP-COM-FUL-018-08 INV-DOM-COM-FUL-005-06
Preconditions
Ten carts compete for one unit and a shipment can consume it.
Steps
Race placements and separately race claim against shipment.
Expected
One placement wins, other carts conflict and a shipped unit is not claimed again.
Data
Fixtures for concurrent buyers cannot share the final stock.
Bound to
services-commerce:modules/inventory/tests/e2e/merchandise-placement.e2e.spec.js#lets exactly one placement win and refuses the nine others 409 claim_conflict naming the item, the SKU and insufficient_stock
services-commerce:modules/inventory/tests/e2e/merchandise-placement.e2e.spec.js#refuses a placement made after the last cap was gone with the same 409 claim_conflict and insufficient_stock, never a preparation refusal (D-P8I-21)
services-commerce:modules/inventory/tests/integration/services/stock/merchandise-claims.integration.spec.js#answers the second, once it gets the row, insufficient_stock, with nothing written for it
services-commerce:modules/inventory/tests/integration/services/stock/merchandise-claims.integration.spec.js#answers the claim, once it gets the row, insufficient_stock: the unit the shipment took is not claimed twice
Source
services-commerce:modules/inventory/tests/e2e/merchandise-placement.e2e.spec.js#lets exactly one placement win and refuses the nine others 409 claim_conflict naming the item, the SKU and insufficient_stock
04 Early holds retain extension and release limitstransitionapinegativetest
Proves
BR-CAP-COM-FUL-018-04 BR-CAP-COM-FUL-018-09
Preconditions
Checkout holds two limited-stock units.
Steps
Extend within the permitted window, exceed it, place and void.
Expected
The excessive extension fails, placement commits the units and void releases them.
Data
Fixtures for early holds retain extension and release limits.
Bound to
services-commerce:modules/inventory/tests/e2e/merchandise-placement.e2e.spec.js#holds the two caps for the item under hold:<item> (the units held with the product’s expiry), and the shelf shows one left
services-commerce:modules/inventory/tests/e2e/merchandise-placement.e2e.spec.js#extends the hold within the window and refuses one past it, 409 hold_not_extendable
services-commerce:modules/inventory/tests/e2e/merchandise-placement.e2e.spec.js#converts the held units to committed on the line at placement, and the void releases them (reason void), the stock back
services-commerce:modules/inventory/tests/integration/services/stock/merchandise-claims.integration.spec.js#converts the held unit to committed on the line, answering the hold’s ref as the claim
services-commerce:modules/inventory/tests/integration/services/stock/merchandise-claims.integration.spec.js#refuses a hold that is not held (converted already, or never made): hold_not_found
Source
services-commerce:modules/inventory/tests/e2e/merchandise-placement.e2e.spec.js#holds the two caps for the item under hold:<item> (the units held with the product’s expiry), and the shelf shows one left
05 Allocation constraints enforce one-unit state recordsinvariantapinegativetest
Proves
BR-CAP-COM-FUL-018-05 INV-DOM-COM-FUL-005-05
Preconditions
A stock item is available for direct ledger fixtures.
Steps
Try missing hold or commitment references, duplicate holds, multi-unit rows and item changes.
Expected
All invalid rows fail and valid state changes affect held or allocated balances.
Data
Fixtures for allocation constraints enforce one-unit state records.
Bound to
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
services-commerce:modules/inventory/tests/integration/db/inventory-tables.table.integration.spec.js#refuses a held row without a checkout item or an expiry, and a committed row without a line, by inventory_allocations_holder_check and inventory_allocations_held_until_check
services-commerce:modules/inventory/tests/integration/db/inventory-tables.table.integration.spec.js#refuses a second live hold of one checkout item and unit, by inventory_allocations_hold_unit_uidx, and a quantity other than one, by inventory_allocations_quantity_check
services-commerce:modules/inventory/tests/integration/db/inventory-tables.table.integration.spec.js#refuses a hold the stock cannot cover, by inventory_items_balances_check: available never falls below zero
services-commerce:modules/inventory/tests/integration/db/inventory-tables.table.integration.spec.js#refuses moving a row to another item, SQLSTATE RHC05 (the trigger), and a release reason outside the contract’s
Source
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
06 Availability uses consistent product statesruleapitest
Proves
BR-CAP-COM-FUL-018-06
Preconditions
Fixtures include limited stock, permitted backorders and untracked goods.
Steps
Read storefront availability for each requested quantity.
Expected
Results distinguish limited, unavailable and backorder states while untracked goods remain available without counts.
Data
Fixtures for availability uses consistent product states.
Bound to
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
services-commerce:modules/inventory/tests/integration/services/stock/staff-movements.integration.spec.js#answers the storefront’s words: limited with what is left, backorder with the shortfall for the shirt, unavailable for the cap, available for a product it does not track
Source
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
07 Void and cancellation release only their owned unitsinteractionapitest
Proves
BR-CAP-COM-FUL-018-07
Preconditions
Separate orders contain committed units and a partial cancellation.
Steps
Void one order and deliver the other's selected cancellation.
Expected
Void releases all its commitments and partial cancellation releases only its named unit.
Data
Fixtures for void and cancellation release only their owned units.
Bound to
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: []
services-commerce:modules/shipping/tests/e2e/post-purchase-shipping.e2e.spec.js#delivers the cancel to the Merchandise participant: unit 2 released, the kept units unfenced and picked, the document completed, the memo and the refund after the domain
Source
services-commerce:modules/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: []
08 Warehouse departure supplies the physical application outcomeinteractionapitest
Proves
BR-CAP-COM-FUL-004-04 BR-CAP-COM-FUL-014-01 BR-CAP-COM-FUL-018-05
Preconditions
Three picked units have current delivery authorization and a manifested shipment.
Steps
Hand the shipment to its carrier, then inspect allocation units and delivery detail.
Expected
The three units are shipped and their obligations are completed with the allocation references.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Bound to
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#hands off: the line handed to the carrier with its whole quantity shipped, the units shipped in the ledger, one shipment movement of minus three on the item, three fewer on hand
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#completes every unit’s obligation through the register (the allocation as the record), and emits one deferred cost relief fact per item
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#writes the shipped quantity on the order line, the order’s shipping_summary complete, and the order’s history
Source
services-commerce:modules/fulfillment/tests/integration/services/persistence/obligation-register.integration.spec.js#records partial completion as in progress with the units, then completes when the rest arrive,services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#hands off: the line handed to the carrier with its whole quantity shipped, the units shipped in the ledger, one shipment movement of minus three on the item, three fewer on hand,services-commerce:modules/inventory/tests/integration/db/inventory-tables.table.integration.spec.js#counts a held row against held, a committed one against allocated and a released one against nothing, through the trigger
09 Replenishment creates the second dispatch waveinteractionapitest
Proves
BR-CAP-COM-FUL-012-02 BR-CAP-COM-FUL-017-07 BR-CAP-COM-FUL-018-02 BR-CAP-COM-FUL-014-01
Preconditions
A five-shirt order has three available units and two backorders.
Steps
Ship the first wave, receive two more shirts and create and ship the next wave.
Expected
The second wave contains only the two replenished units; all five obligations complete.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Bound to
services-commerce:modules/shipping/tests/e2e/shipping.e2e.spec.js#makes the first wave of the three picked units (0..2), charged what the order paid, and walks it to the handoff
services-commerce:modules/shipping/tests/e2e/shipping.e2e.spec.js#fills the two backorders at the receipt, and the second wave picks the filled units at its creation (3..4) and ships them
services-commerce:modules/shipping/tests/e2e/shipping.e2e.spec.js#completes the order’s shipping: every unit shipped, every obligation completed, the shelf down five, the cost facts emitted per wave
Source
services-commerce:modules/shipping/tests/e2e/shipping.e2e.spec.js#makes the first wave of the three picked units (0..2), charged what the order paid, and walks it to the handoff,services-commerce:modules/inventory/tests/integration/services/stock/staff-movements.integration.spec.js#converts both backordered units to committed in the receipt’s transaction, oldest order first, leaving one to sell,services-commerce:modules/inventory/tests/integration/services/stock/merchandise-claims.integration.spec.js#is refused insufficient_stock with nothing written when the product prohibits backorders (the last cap),services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#hands off: the line handed to the carrier with its whole quantity shipped, the units shipped in the ledger, one shipment movement of minus three on the item, three fewer on hand
10 Cancellation fencing releases selected allocations while retained units ship laterinteractionapitest
Proves
BR-CAP-COM-FUL-012-08 BR-CAP-COM-FUL-014-06 BR-CAP-COM-FUL-018-07
Preconditions
Three picked shirts share a labelled shipment and cancellation selects the final unit.
Steps
Commit cancellation, deliver its instruction and create a new shipment for the retained units.
Expected
The selected unit releases, the old parcel is pulled, and two retained picked units use new shipment work.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Bound to
services-commerce:modules/shipping/tests/e2e/post-purchase-shipping.e2e.spec.js#fences and cancels the shipment line, pulls the package and voids the counter label, and refuses the handoff asked after (409)
services-commerce:modules/shipping/tests/e2e/post-purchase-shipping.e2e.spec.js#delivers the cancel to the Merchandise participant: unit 2 released, the kept units unfenced and picked, the document completed, the memo and the refund after the domain
Source
services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#refuses a second handover (not packed any more) and the cancellation of a collected shipment,services-commerce:modules/shipping/tests/integration/services/fulfillment/shipping-flow.integration.spec.js#cancels the fenced line at the cancel step: the units unstamped (still the order’s, picked), the label voided and the package pulled, the shipment cancelled,services-commerce:modules/inventory/tests/integration/services/stock/merchandise-claims.integration.spec.js#releases a line’s committed units on a void, giving the stock back; a release naming nothing live answers released: []
11 Returned stock becomes available through the movement ledgerinteractionapiproposed
Proves
BR-CAP-COM-FUL-015-05 BR-CAP-COM-FUL-017-03 BR-CAP-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.
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#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
12 An inactive warehouse refuses receipt and allocationinteractionapiproposed
Proves
BR-CAP-COM-FUL-018-01 INV-DOM-COM-FUL-005-12
Preconditions
The only sellable location belongs to an inactive warehouse.
Steps
Attempt a receipt and a placement claim, then repeat after authorized activation.
Expected
Inactive-place work is refused; active-place work is considered under its normal stock guards.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Source
services-commerce:modules/inventory/tests/e2e/inventory.e2e.spec.js#lets a reader list and read everything, and refuses it every write 403 permission_missing,services-commerce:modules/inventory/tests/e2e/inventory.e2e.spec.js#moves quarantined beside on_hand and a scrap off it; refuses what the shelf cannot bear (400 naming the rule), a wrong sign (400) and a type staff do not record (400),services-commerce:modules/inventory/tests/integration/services/stock/merchandise-claims.integration.spec.js#answers ok with one committed claim for the SKU and the quantity, under the claim ref the line is stamped with
13 Place ordering controls the units claimed from received stockinteractionapiproposed
Proves
BR-CAP-COM-FUL-016-05 BR-CAP-COM-FUL-017-01 BR-CAP-COM-FUL-018-01
Preconditions
Two active sellable bins have different pick priorities and receive the same SKU.
Steps
Receive stock in both and claim two units, then inspect their item and location references.
Expected
The claim uses the earlier sellable location before the later one.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Source
services-commerce:modules/inventory/tests/integration/services/persistence/inventory-configuration.integration.spec.js#answers the sellable locations across warehouses in allocation order: the main warehouse (priority 1) before the depot (2), bins by pick priority, quarantine and returns left out,services-commerce:modules/inventory/tests/e2e/inventory.e2e.spec.js#moves quarantined beside on_hand and a scrap off it; refuses what the shelf cannot bear (400 naming the rule), a wrong sign (400) and a type staff do not record (400),services-commerce:modules/inventory/tests/integration/services/stock/merchandise-claims.integration.spec.js#answers ok with one committed claim for the SKU and the quantity, under the claim ref the line is stamped with
14 A shelf count corrects the ledger and changes availabilityinteractionapiproposed
Proves
BR-CAP-COM-FUL-019-02 BR-CAP-COM-FUL-017-03 BR-CAP-COM-FUL-018-06
Preconditions
A sellable item holds ten units and a scoped count observes eight.
Steps
Complete the count, inspect its correction movement and read availability.
Expected
The count retains one correction and buyers see the corrected stock; repeated completion changes nothing.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Source
services-commerce:modules/inventory/tests/integration/services/stock/staff-movements.integration.spec.js#opens the count open with no lines, records the lines with what the shelf expected, and completes it with one correction for the variance,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
15 Nightly expiry gives held stock back to buyersinteractionapitest
Proves
BR-CAP-COM-FUL-019-04 BR-CAP-COM-FUL-018-04
Preconditions
An expired checkout hold consumes one unit of tracked sellable stock.
Steps
Run nightly reconciliation, inspect the expiry finding and read the allocation and availability.
Expected
The hold releases with an expiry reason and its unit becomes available.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Bound to
services-commerce:modules/inventory/tests/integration/services/reconciliation/nightly-inventory.integration.spec.js#counts what it did: the tenant, one hold expired, three items checked, one mismatch, one stale unit, one low-stock SKU of two with a point, and the cost pass: three items whose stock no layer costs (the fixture’s bare receipts), no handoff without a relief
services-commerce:modules/inventory/tests/integration/services/reconciliation/nightly-inventory.integration.spec.js#releases the expired hold (reason expiry) and raises expired_hold on it, giving the unit back
services-commerce:modules/inventory/tests/integration/services/reconciliation/nightly-inventory.integration.spec.js#raises balance_mismatch on the item knocked out of line, with what was kept and what the ledgers say, and corrects nothing
services-commerce:modules/inventory/tests/integration/services/reconciliation/nightly-inventory.integration.spec.js#raises low_stock on shirt L at its own reorder point with the product’s reorder quantity, and nothing on the cap above its point
services-commerce:modules/inventory/tests/integration/services/reconciliation/nightly-inventory.integration.spec.js#finds the same on a second run and adds an occurrence to each open finding rather than another row
Source
services-commerce:modules/inventory/tests/integration/services/reconciliation/nightly-inventory.integration.spec.js#counts what it did: the tenant, one hold expired, three items checked, one mismatch, one stale unit, one low-stock SKU of two with a point, and the cost pass: three items whose stock no layer costs (the fixture’s bare receipts), no handoff without a relief,services-commerce:modules/inventory/tests/e2e/merchandise-placement.e2e.spec.js#holds the two caps for the item under hold:<item> (the units held with the product’s expiry), and the shelf shows one left

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.