--- id: TST-COM-ORD-155 title: Purchasing and costing kind: api-lifecycle product_area: commerce module: orders revision: 1 status: draft source_sha: services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b repository: services-commerce files: - modules/purchasing/tests/e2e/purchasing.e2e.spec.js implements: - ATS-COM-ORD-011-05 - ATS-COM-ORD-017-01 - ATS-COM-ORD-017-02 - ATS-COM-ORD-017-03 - ATS-COM-ORD-017-04 - ATS-COM-ORD-017-06 - ATS-COM-ORD-018-01 - ATS-COM-ORD-018-06 - ATS-COM-ORD-018-09 - ATS-COM-ORD-018-10 - ATS-COM-ORD-018-11 environment: local implementation_state: implemented latest_result: not-run latest_run_at: null latest_run_ref: null conformance: not-verified estimated_minutes: 2 isolation: The suite creates its own test workspace records and removes them using the fixture cleanup. evidence: - provenance: test source: 'services-commerce:modules/purchasing/tests/e2e/purchasing.e2e.spec.js' test_cases: - >- creates the vendor with its e-mail address lowercased, reads and lists it, replaces it at the version read (a stale one 409) - >- refuses a supplier address whose country is not an ISO 3166-1 code (ZZ), on a create and on a replacement, 400 naming address.country - >- lets a reader list and read, refuses the reader every write 403 permission_missing, a denied principal 403 app_not_permitted, no context 401, and another tenant 404 - 'reads a business unit with no settings at the defaults: FIFO at version 0, not configured' - >- writes LIFO at version 0, replaces it with the record read sent back, and refuses the stale version 409 - 'refuses a method that is neither FIFO nor LIFO 400, and a body naming another business unit 400' - >- shows the products’ business unit and its method beside the valuation’s totals: faa, FIFO, not configured - >- lets a reader read the settings, refuses the reader the write 403 permission_missing, a denied principal 403 app_not_permitted, no context 401 - 'keeps tenant A’s setting from tenant B: B reads the same business unit at its own defaults' - >- replaces the draft at the version read with the record exactly as it was read, read-only line columns included, and answers the same lines one version on - still refuses a line that states a column no purchase order line has (the schema stays strict) - places the order with three units committed and two backordered - drafts the order numbered with its line and issues it - >- records the first receipt (10 at the order line’s cost), fills the two backorders in its transaction, and the order is partially received - >- records the second receipt at 1200 with its reason and 50 of landed cost per unit, and the order is received - >- values the shirt L item at Σ the layers (3 at zero from the movement route, 10 × 1000, 10 × 1250 = 22500), reconciled with 23 on hand - >- answers the retried first receipt as the same receipt, lists the receipts by order and reads one with its lines - >- refuses a receipt against the received order 409, a receipt line with no quantity 400, and the vendor’s delete 409 - >- lists the facts unposted (the two receipts’), stamps them posted under Accounting’s reference, and lists none unposted after - >- corrects the second layer’s cost to 1100: the remainder on a correction layer, the original consumed, a cost_adjustment of 10 × 150, the valuation reconciled - >- closes a second order with unreceived quantity: the remainder cancelled, and cancels part of a line on another scenario_coverage: - scenario: ATS-COM-ORD-011-05 test_cases: - >- lets a reader list and read, refuses the reader every write 403 permission_missing, a denied principal 403 app_not_permitted, no context 401, and another tenant 404 scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. - scenario: ATS-COM-ORD-017-01 test_cases: - >- creates the vendor with its e-mail address lowercased, reads and lists it, replaces it at the version read (a stale one 409) - >- refuses a supplier address whose country is not an ISO 3166-1 code (ZZ), on a create and on a replacement, 400 naming address.country scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. - scenario: ATS-COM-ORD-017-02 test_cases: - >- refuses a receipt against the received order 409, a receipt line with no quantity 400, and the vendor’s delete 409 scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. - scenario: ATS-COM-ORD-017-03 test_cases: - >- replaces the draft at the version read with the record exactly as it was read, read-only line columns included, and answers the same lines one version on - still refuses a line that states a column no purchase order line has (the schema stays strict) - drafts the order numbered with its line and issues it scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. - scenario: ATS-COM-ORD-017-04 test_cases: - >- closes a second order with unreceived quantity: the remainder cancelled, and cancels part of a line on another scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. - scenario: ATS-COM-ORD-017-06 test_cases: - >- lets a reader list and read, refuses the reader every write 403 permission_missing, a denied principal 403 app_not_permitted, no context 401, and another tenant 404 scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. - scenario: ATS-COM-ORD-018-01 test_cases: - >- answers the retried first receipt as the same receipt, lists the receipts by order and reads one with its lines scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. - scenario: ATS-COM-ORD-018-06 test_cases: - 'reads a business unit with no settings at the defaults: FIFO at version 0, not configured' - >- writes LIFO at version 0, replaces it with the record read sent back, and refuses the stale version 409 - 'refuses a method that is neither FIFO nor LIFO 400, and a body naming another business unit 400' scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. - scenario: ATS-COM-ORD-018-09 test_cases: - >- corrects the second layer’s cost to 1100: the remainder on a correction layer, the original consumed, a cost_adjustment of 10 × 150, the valuation reconciled scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. - scenario: ATS-COM-ORD-018-10 test_cases: - >- values the shirt L item at Σ the layers (3 at zero from the movement route, 10 × 1000, 10 × 1250 = 22500), reconciled with 23 on hand - >- shows the products’ business unit and its method beside the valuation’s totals: faa, FIFO, not configured scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. - scenario: ATS-COM-ORD-018-11 test_cases: - >- lists the facts unposted (the two receipts’), stamps them posted under Accounting’s reference, and lists none unposted after scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. dependency_evidence: provenance: test source: 'services-commerce:modules/purchasing/tests/e2e/purchasing.e2e.spec.js' declared_by_test: >- the composed handler, the routes, the mappers, the receiving workflow, the cost rules, the placement with the Merchandise participant over the inventory tables, PostgreSQL. Doubled: the signing key pair and the other services' tables (the Accounting products are planted as the owner). --- # Purchasing and costing ## Verification Boundary The suite drives the composed local API dispatcher and its registered routes. ## What This Suite Proves The registered cases check purchasing and costing with their fixture records and assertions. Scenario bindings name only the examples those cases exercise. ## What It Does Not Prove A registered file supplies no run result or verified conformance by itself. Local fixtures do not establish deployed cross-service behavior or complete browser journeys. ## Real Dependencies and Test Doubles PostgreSQL and the exercised Commerce persistence or workflow code are real. Remote service records, clocks and transports follow the suite’s fixtures. ## Must Not Be Doubled The database constraints, role restrictions, locks and transactions exercised by this suite must use PostgreSQL.