Rhythm 2.0 Specifications

Appearance

ATS-COM-FUL-016Organize warehouses and stock locations: Capability Test Specification

Markdown

ATS-COM-FUL-016

Organize warehouses and stock locations: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-COM-FUL-016

Design

Executed by
TST-COM-FUL-007, TST-COM-FUL-057, TST-COM-FUL-059, TST-COM-FUL-060

KindAcceptance test setProduct areaCommerceModuleFulfillment, Shipping and InventoryRevision2

Read atservices-commerce c8b66a98react-console baf6dae3

Organize warehouses and stock locations: 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-016-01ATS-COM-FUL-016-01
BR-CAP-COM-FUL-016-02ATS-COM-FUL-016-01
BR-CAP-COM-FUL-016-03ATS-COM-FUL-016-02, ATS-COM-FUL-016-09
BR-CAP-COM-FUL-016-04ATS-COM-FUL-016-03
BR-CAP-COM-FUL-016-05ATS-COM-FUL-016-04, ATS-COM-FUL-016-07
BR-CAP-COM-FUL-016-06ATS-COM-FUL-016-02, ATS-COM-FUL-016-09
BR-CAP-COM-FUL-016-07ATS-COM-FUL-016-05, ATS-COM-FUL-016-06, ATS-COM-FUL-016-08

The interaction cases exercise keep stock movements and transfers accountable; allocate stock and explain what buyers can obtain; configure shipping coverage and collection options. 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 covered
  • Transition gap: FND-COM-FUL-071
  • Validation covered
  • Permission covered
  • Edge gap: FND-COM-FUL-071
  • Failure gap: FND-COM-FUL-071
  • Boundary gap: FND-COM-FUL-071
  • Concurrency covered
  • Invariant gap: FND-COM-FUL-071
  • Interaction covered

Test Scenarios

9 scenarios proving CAP-COM-FUL-016; 6 bound to an existing test.

01 Warehouse identities and priorities remain stablevalidationapinegativetest
Proves
BR-CAP-COM-FUL-016-01 BR-CAP-COM-FUL-016-02
Preconditions
Two warehouses have priorities and a third has none.
Steps
Attempt duplicate identity and negative priority, then list warehouses.
Expected
Invalid creation fails and the list orders priorities before unset values.
Data
Fixtures for warehouse identities and priorities remain stable.
Bound to
services-commerce:modules/inventory/tests/integration/services/persistence/inventory-configuration.integration.spec.js#writes the warehouse under the id its name suggests, with its address, at version 1, and reads it back the same
services-commerce:modules/inventory/tests/integration/services/persistence/inventory-configuration.integration.spec.js#lists the warehouses in allocation order (priority first, none last), the active ones alone on request, and by search
services-commerce:modules/inventory/tests/integration/db/inventory-tables.table.integration.spec.js#refuses an id that is not a configuration id, by warehouses_id_configuration_id_check, and a negative priority by warehouses_fulfillment_priority_check
Source
services-commerce:modules/inventory/tests/integration/services/persistence/inventory-configuration.integration.spec.js#writes the warehouse under the id its name suggests, with its address, at version 1, and reads it back the same
02 In-use places resist deletion and stale replacementconcurrencyapinegativetest
Proves
BR-CAP-COM-FUL-016-03 BR-CAP-COM-FUL-016-06
Preconditions
A warehouse owns a location containing stock.
Steps
Try stale replacement and dependent deletions, then remove dependencies and delete.
Expected
Stale and in-use actions fail; dependency-free deletion succeeds.
Data
Fixtures for in-use places resist deletion and stale replacement.
Bound to
services-commerce:modules/inventory/tests/e2e/inventory.e2e.spec.js#reads the warehouse made with the shelf, lists it, replaces it at the version read (a stale one 409) and refuses its delete while locations belong to it (409)
services-commerce:modules/inventory/tests/integration/services/persistence/inventory-configuration.integration.spec.js#replaces the warehouse at its version (a stale one 409; another tenant’s 404)
services-commerce:modules/inventory/tests/integration/services/persistence/inventory-configuration.integration.spec.js#refuses deleting a warehouse its locations belong to (409) and a location an item is held at (409); deletes them once free, 404 after
services-commerce:modules/inventory/tests/integration/db/inventory-tables.table.integration.spec.js#refuses deleting a warehouse its locations and items still name (RESTRICT), by one of its warehouse keys
Source
services-commerce:modules/inventory/tests/e2e/inventory.e2e.spec.js#reads the warehouse made with the shelf, lists it, replaces it at the version read (a stale one 409) and refuses its delete while locations belong to it (409)
03 Location validation preserves its warehouse and codevalidationapinegativetest
Proves
BR-CAP-COM-FUL-016-04
Preconditions
A warehouse and location fixtures exist.
Steps
Try duplicate code, unknown kind, foreign ownership and moving an existing location.
Expected
Invalid changes fail and an omitted kind defaults to bin.
Data
Fixtures for location validation preserves its warehouse and code.
Bound to
services-commerce:modules/inventory/tests/integration/services/persistence/inventory-configuration.integration.spec.js#writes the location in its warehouse with the kind given (bin by default), at version 1
services-commerce:modules/inventory/tests/integration/services/persistence/inventory-configuration.integration.spec.js#refuses a code twice in one warehouse (400), a warehouse the tenant has not (400), and a kind outside the six (400)
services-commerce:modules/inventory/tests/integration/services/persistence/inventory-configuration.integration.spec.js#replaces the location at its version, keeps it in its warehouse (409 to move it), and refuses a stale version
services-commerce:modules/inventory/tests/e2e/inventory.e2e.spec.js#creates a location (a code twice in one warehouse 400), lists the bins in pick order, replaces one (its warehouse stays, 409), and deletes a free one (404 after)
Source
services-commerce:modules/inventory/tests/integration/services/persistence/inventory-configuration.integration.spec.js#writes the location in its warehouse with the kind given (bin by default), at version 1
04 Sellable-location selection follows warehouse and pick orderruleapitest
Proves
BR-CAP-COM-FUL-016-05
Preconditions
Two warehouses contain bins and restricted locations.
Steps
Read the sellable allocation locations.
Expected
Eligible bins appear in warehouse and pick-priority order, excluding quarantine and returns.
Data
Fixtures for sellable-location selection follows warehouse and pick order.
Bound to
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
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
05 Inventory configuration access remains scopedpermissionapinegativetest
Proves
BR-CAP-COM-FUL-016-07
Preconditions
Reader, denied and absent identities and a second workspace are available.
Steps
Try scoped reads and writes for each.
Expected
Readers can inspect only; denied or absent access fails and foreign records are unavailable.
Data
Fixtures for inventory configuration access remains scoped.
Bound to
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#refuses a principal denied the application 403 app_not_permitted, no context 401, and answers 404 in tenant B for tenant A’s warehouse
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
06 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
07 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
08 Imported opening stock participates in the normal ledgerinteractionapitest
Proves
BR-CAP-COM-FUL-020-12 BR-CAP-COM-FUL-017-03
Preconditions
An implementation workspace has a migrated warehouse, location and product source identity.
Steps
Import twelve units with two damaged, read back the source key and inspect live balances and movements.
Expected
The item has ten available units, backed by count and damage entries; an inactive destination refuses a new item.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Bound to
services-commerce:modules/data-operations/tests/integration/services/operations/inventory-import.integration.spec.js#opens the mug’s item through the ledger: a count correction of twelve and a damage of two, so the trigger holds ten available
services-commerce:modules/data-operations/tests/integration/services/operations/inventory-import.integration.spec.js#opens the cap’s item under the product’s own SKU at the default location, with no movement for a count of nought
services-commerce:modules/data-operations/tests/integration/services/operations/inventory-import.integration.spec.js#refuses the same key loaded again as that item’s invalid value, moving nothing
services-commerce:modules/data-operations/tests/integration/services/operations/inventory-import.integration.spec.js#refuses an item at an inactive location as that item’s refusal, as the implicit creation would
Source
services-commerce:modules/data-operations/tests/integration/services/operations/inventory-import.integration.spec.js#opens the mug’s item through the ledger: a count correction of twelve and a damage of two, so the trigger holds ten available,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#lets a reader list and read everything, and refuses it every write 403 permission_missing
09 A configured collection place prevents its removalinteractionapiproposed
Proves
BR-CAP-COM-FUL-016-03 BR-CAP-COM-FUL-010-05
Preconditions
An active warehouse is referenced by a pickup strategy.
Steps
Attempt to delete the warehouse, remove the strategy and retry deletion after clearing other dependencies.
Expected
The first deletion fails; dependency-free deletion succeeds.
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#reads the warehouse made with the shelf, lists it, replaces it at the version read (a stale one 409) and refuses its delete while locations belong to it (409),services-commerce:modules/shipping/tests/integration/services/persistence/shipping-configuration.integration.spec.js#holds the rules before the row: bands in ascending order with the open one last, a carrier naming its account, no bands on a flat one

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