--- id: TST-COM-ORD-160 title: Purchasing and cost kind: integration product_area: commerce module: orders revision: 1 status: draft source_sha: services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b repository: services-commerce files: - modules/purchasing/tests/integration/services/receiving/purchasing-flow.integration.spec.js implements: - ATS-COM-ORD-017-04 - ATS-COM-ORD-018-01 - ATS-COM-ORD-018-02 - ATS-COM-ORD-018-03 - ATS-COM-ORD-018-05 - ATS-COM-ORD-018-07 - ATS-COM-ORD-018-08 - ATS-COM-ORD-018-09 - ATS-COM-ORD-018-11 - ATS-COM-ORD-018-13 - ATS-COM-ORD-018-15 - ATS-COM-ORD-018-16 - FAS-COM-ORD-07-01 - FAS-COM-ORD-07-02 - FAS-COM-ORD-07-03 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/integration/services/receiving/purchasing-flow.integration.spec.js test_cases: - >- records the first receipt numbered, against the order, with one line of 60 at the order line’s cost, and the order partially received - >- writes, in the receipt’s transaction, the receipt movement naming the line, the layer of 60 @ 1000 and the capitalize_receipt fact of 60000 - >- fills the two backorders at the first receipt, oldest first, converting them to committed; the shelf shows 58 available after - 'answers the retried receipt as found under its key, writing nothing twice' - >- receives the remaining 40 and the order is received with its instant; the two layers stand oldest first - >- refuses a receipt beyond what the line has open (over_receipt) and a receipt against a received order, writing nothing - >- closes an issued order after 90 of 100: cancelled_quantity 10, status closed; cancelling it instead is refused - >- refuses a receipt line whose cost differs from the order line’s without a reason, and takes one with a reason - >- relieves 60 @ 1000 from the first layer and 10 @ 1200 from the second: 72000 of COGS in two rows naming the layers and the movement - >- writes one relieve_cogs fact of 72000 (Dr cogs_expense / Cr inventory) for the shipment line, with the order - 'values the item after at 30 × 1200 = 36000, reconciled with the ledger’s on-hand of 30' - >- restores 5 returned units at the relieved cost and place: a restore row naming the relief it reverses, a layer at that cost dated with the original layer, a restore_cogs fact of 5 × that cost - >- makes a layer and a capitalize_receipt fact from a staff receipt with a cost, and a layer at the last receipt cost from one without - 'relieves a scrap FIFO with a write_off fact, and a negative adjustment with an adjustment_loss fact' - >- values a count gain at the last receipt cost (adjustment_gain) and relieves a count loss (adjustment_loss), each fact naming the count line - >- moves the unconsumed remainder to a layer at the corrected cost, leaves the original consumed, and writes the cost_adjustment of the difference - >- lists the unposted facts by date, stamps them posted once under Accounting’s reference, and refuses another reference on a posted fact - >- raises valuation_mismatch on stock no layer costs, relief_missing on a shipment movement no relief followed, and nothing on the reconciled items - >- relieves units no layer covers at cost zero under no layer and raises uncosted_relief, so the books say so - >- relieves under FIFO while the business unit has no setting: 4 @ 1000 from the older layer, recorded fifo - >- relieves a LIFO business unit’s 12 over two layers newer first: 10 @ 1200 from the newer, then 2 @ 1000 from the older, recorded lifo - >- rewrites nothing made before the switch: the FIFO relief rows read back unchanged, the receipt layers still record fifo - >- shows the business unit’s method beside the valuation’s totals: LIFO, configured, the 4 left of the older layer - >- restores the LIFO relief at its recorded costs and places: each relief reversed, the layers dated with the originals, a restore_cogs of 14000 scenario_coverage: - scenario: ATS-COM-ORD-017-04 test_cases: - >- closes an issued order after 90 of 100: cancelled_quantity 10, status closed; cancelling it instead is refused 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 receipt as found under its key, writing nothing twice' scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. - scenario: ATS-COM-ORD-018-02 test_cases: - >- refuses a receipt beyond what the line has open (over_receipt) and a receipt against a received order, writing nothing - >- refuses a receipt line whose cost differs from the order line’s without a reason, and takes one with a reason scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. - scenario: ATS-COM-ORD-018-03 test_cases: - >- writes, in the receipt’s transaction, the receipt movement naming the line, the layer of 60 @ 1000 and the capitalize_receipt fact of 60000 - >- fills the two backorders at the first receipt, oldest first, converting them to committed; the shelf shows 58 available after scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. - scenario: ATS-COM-ORD-018-05 test_cases: - >- relieves under FIFO while the business unit has no setting: 4 @ 1000 from the older layer, recorded fifo - >- relieves a LIFO business unit’s 12 over two layers newer first: 10 @ 1200 from the newer, then 2 @ 1000 from the older, recorded lifo - >- rewrites nothing made before the switch: the FIFO relief rows read back unchanged, the receipt layers still record fifo scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. - scenario: ATS-COM-ORD-018-07 test_cases: - >- relieves units no layer covers at cost zero under no layer and raises uncosted_relief, so the books say so scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. - scenario: ATS-COM-ORD-018-08 test_cases: - >- restores 5 returned units at the relieved cost and place: a restore row naming the relief it reverses, a layer at that cost dated with the original layer, a restore_cogs fact of 5 × that cost 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: - >- moves the unconsumed remainder to a layer at the corrected cost, leaves the original consumed, and writes the cost_adjustment of the difference 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 unposted facts by date, stamps them posted once under Accounting’s reference, and refuses another reference on a posted fact scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. - scenario: ATS-COM-ORD-018-13 test_cases: - >- fills the two backorders at the first receipt, oldest first, converting them to committed; the shelf shows 58 available after - 'values the item after at 30 × 1200 = 36000, reconciled with the ledger’s on-hand of 30' - >- lists the unposted facts by date, stamps them posted once under Accounting’s reference, and refuses another reference on a posted fact scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. - scenario: ATS-COM-ORD-018-15 test_cases: - 'relieves a scrap FIFO with a write_off fact, and a negative adjustment with an adjustment_loss fact' - >- values a count gain at the last receipt cost (adjustment_gain) and relieves a count loss (adjustment_loss), each fact naming the count line scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. - scenario: ATS-COM-ORD-018-16 test_cases: - >- raises valuation_mismatch on stock no layer costs, relief_missing on a shipment movement no relief followed, and nothing on the reconciled items scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. - scenario: FAS-COM-ORD-07-01 test_cases: - >- records the first receipt numbered, against the order, with one line of 60 at the order line’s cost, and the order partially received - >- writes, in the receipt’s transaction, the receipt movement naming the line, the layer of 60 @ 1000 and the capitalize_receipt fact of 60000 scope: >- The fixture chain asserts this outcome within the suite’s declared dependency boundary. - scenario: FAS-COM-ORD-07-02 test_cases: - >- closes an issued order after 90 of 100: cancelled_quantity 10, status closed; cancelling it instead is refused scope: >- The fixture chain asserts this outcome within the suite’s declared dependency boundary. - scenario: FAS-COM-ORD-07-03 test_cases: - >- answers the retried receipt as found under its key, writing nothing twice - >- receives the remaining 40 and the order is received with its instant; the two layers stand oldest first scope: >- The fixture chain asserts this outcome within the suite’s declared dependency boundary. dependency_evidence: provenance: test source: >- services-commerce:modules/purchasing/tests/integration/services/receiving/purchasing-flow.integration.spec.js declared_by_test: >- PostgreSQL, every persistence service, the receiving workflow, the cost rules, the claim function through the claimer grant, the inventory ledgers' triggers. Doubled: nothing (the Accounting products are planted as the owner). --- # Purchasing and cost ## Verification Boundary The suite exercises persistence or workflow operations against the local integration database. ## What This Suite Proves The registered cases check purchasing and cost 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.