---
id: TST-COM-FUL-009
title: Order import
kind: integration
product_area: commerce
module: fulfillment
revision: 1
status: draft
source_sha:
  services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
repository: services-commerce
files:
  - modules/data-operations/tests/integration/services/operations/order-import.integration.spec.js
implements:
  - ATS-COM-FUL-020-08
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/data-operations/tests/integration/services/operations/order-import.integration.spec.js
    test_titles:
      - 'writes the order with its 1.0 number, accepted at its placement, billed, and marked migrated'
      - >-
        writes both lines in order, each migrated, with a legacy purchase of the rhythm1.legacy
        schema
      - >-
        creates one obligation per item line in its final state: completed and open for the
        fulfilled line, blocked for the other
      - >-
        leaves the invoice link pending on the order.migrated event rather than blocking the order
        (D-C-04)
      - 'refuses the same key loaded again as that item’s invalid value, writing nothing'
      - >-
        refuses an order naming an ordering profile the tenant does not have as its own invalid
        value, naming the constraint
      - makes the pending link under the idempotency key the first write would have used
      - re-points the line’s product and records the relink on the order’s history
      - >-
        reads the order back by its key in the shape the tool carried it, under the live columns and
        the links as they stand
    scenario_anchors:
      - >-
        services-commerce:modules/data-operations/tests/integration/services/operations/order-import.integration.spec.js#writes
        the order with its 1.0 number, accepted at its placement, billed, and marked migrated
      - >-
        services-commerce:modules/data-operations/tests/integration/services/operations/order-import.integration.spec.js#creates
        one obligation per item line in its final state: completed and open for the fulfilled line,
        blocked for the other
      - >-
        services-commerce:modules/data-operations/tests/integration/services/operations/order-import.integration.spec.js#leaves
        the invoice link pending on the order.migrated event rather than blocking the order (D-C-04)
      - >-
        services-commerce:modules/data-operations/tests/integration/services/operations/order-import.integration.spec.js#refuses
        the same key loaded again as that item’s invalid value, writing nothing
      - >-
        services-commerce:modules/data-operations/tests/integration/services/operations/order-import.integration.spec.js#makes
        the pending link under the idempotency key the first write would have used
---

# Order import

## Verification Boundary

This suite checks order import 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.

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