---
id: TST-COM-FUL-060
title: Inventory configuration
kind: integration
product_area: commerce
module: fulfillment
revision: 1
status: draft
source_sha:
  services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
repository: services-commerce
files:
  - >-
    modules/inventory/tests/integration/services/persistence/inventory-configuration.integration.spec.js
implements:
  - ATS-COM-FUL-016-01
  - ATS-COM-FUL-016-02
  - ATS-COM-FUL-016-03
  - ATS-COM-FUL-016-04
environment: local
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 3
isolation: >-
  Run-created workspace identifiers and fixture records in the prepared test database; concurrency
  cases own their extra connections.
evidence:
  - repository: services-commerce
    path: >-
      modules/inventory/tests/integration/services/persistence/inventory-configuration.integration.spec.js
    test_titles:
      - >-
        writes the warehouse under the id its name suggests, with its address, at version 1, and
        reads it back the same
      - refuses a second warehouse under one id (400) and a negative priority (400)
      - >-
        lists the warehouses in allocation order (priority first, none last), the active ones alone
        on request, and by search
      - replaces the warehouse at its version (a stale one 409; another tenant’s 404)
      - 'writes the location in its warehouse with the kind given (bin by default), at version 1'
      - >-
        refuses a code twice in one warehouse (400), a warehouse the tenant has not (400), and a
        kind outside the six (400)
      - 'lists the locations in pick order within each warehouse, by warehouse and by kind'
      - >-
        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
      - >-
        replaces the location at its version, keeps it in its warehouse (409 to move it), and
        refuses a stale version
      - >-
        refuses deleting a warehouse its locations belong to (409) and a location an item is held at
        (409); deletes them once free, 404 after
      - never shows another tenant’s locations
    scenario_anchors:
      - >-
        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#refuses
        a second warehouse under one id (400) and a negative priority (400)
      - >-
        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/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/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/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
---

# Inventory configuration

## Verification Boundary

This suite checks inventory configuration against the prepared PostgreSQL database. Its entry points are the persistence and service functions used by the tests.

## What This Suite Proves

The bound scenarios identify the assertions this suite contributes. Source anchors retain the exact test cases; where a capability scenario has several contributing suites, a single binding does not imply that every branch runs here.

## What It Does Not Prove

Direct service and persistence calls do not establish the full HTTP permission contract, deployed scheduling or browser behavior. No execution result is claimed by this register.

## Real Dependencies and Test Doubles

The database and imported Commerce persistence services are real. Fixtures create the records owned by this run. Time-sensitive cases use a controlled clock where the source fixture supplies one.

## Must Not Be Doubled

Keep the database constraints, row visibility and persistence writes real when claiming this integration coverage. A canned repository response cannot replace the boundary being checked.