---
id: TST-COM-FUL-058
title: Merchandise placement
kind: api-lifecycle
product_area: commerce
module: fulfillment
revision: 1
status: draft
source_sha:
  services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
repository: services-commerce
files:
  - modules/inventory/tests/e2e/merchandise-placement.e2e.spec.js
implements:
  - ATS-COM-FUL-017-04
  - ATS-COM-FUL-018-03
  - ATS-COM-FUL-018-04
  - FAS-COM-FUL-04-05
environment: local
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 5
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/e2e/merchandise-placement.e2e.spec.js
    test_titles:
      - 'advises every cart ok: the last cap is limited with none left, nothing is held just in time'
      - >-
        lets exactly one placement win and refuses the nine others 409 claim_conflict naming the
        item, the SKU and insufficient_stock
      - >-
        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)
      - >-
        placed nothing for the losers (their checkouts open, the refusal on their trail) and left
        the shelf with the winner’s unit allocated and nothing available
      - >-
        advised the two as a backorder of one, and placed them: one unit committed, one backordered,
        the SKU showing backorder to the next buyer
      - >-
        dispatched the two unit obligations once the order was accepted and paid, and the
        participant picked the committed unit and left the backordered one waiting, both obligations
        in progress
      - >-
        fills the backordered unit in the receipt’s transaction: committed, counted against
        allocated, four left to sell, both obligations still in progress
      - >-
        has the badge delivered before the cancellation, so the cancellation meets a delivered line
        (premise)
      - >-
        cancels the whole order: the merchandise participant has no unit to fence and does not
        refuse
      - delivers the participant’s cancel and completes the cancellation
      - >-
        holds the two caps for the item under hold:<item> (the units held with the product’s
        expiry), and the shelf shows one left
      - 'extends the hold within the window and refuses one past it, 409 hold_not_extendable'
      - >-
        converts the held units to committed on the line at placement, and the void releases them
        (reason void), the stock back
    scenario_anchors:
      - >-
        services-commerce:modules/inventory/tests/e2e/merchandise-placement.e2e.spec.js#fills the
        backordered unit in the receipt’s transaction: committed, counted against allocated, four
        left to sell, both obligations still in progress
      - >-
        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/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/e2e/merchandise-placement.e2e.spec.js'
---

# Merchandise placement

## Verification Boundary

This suite calls the composed local HTTP handler over the prepared database. It checks merchandise placement through request contracts and the enforcing security boundary.

## 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

Local handler execution does not establish deployed routing, queue delivery or browser behavior. It also supplies no latest result until a qualification run records one.

## Real Dependencies and Test Doubles

The database and imported Commerce persistence services are real. Fixtures create the records owned by this run. Signed local security contexts and the composed handler exercise the request boundary. Financial facts are supplied by a local fixture provider. Queue publication uses the suite’s recording or scripted publisher. Accounting command responses use the suite’s fixture port. Time-sensitive cases use a controlled clock where the source fixture supplies one.

## Must Not Be Doubled

Keep the composed handler, permission enforcement, request validation and database writes real when claiming this local API coverage. Scripted financial, queue or carrier outcomes must remain visibly separate from deployed integration evidence.