Skip to content

CAP-COM-ORD-018Receive inventory and retain its cost

Markdown

CAP-COM-ORD-018

Receive inventory and retain its cost

Markdown
  • DocumentDraft
  • Product intentProposed
  • ImplementationObserved

KindCapabilityProduct areaCommerceModuleCustomer purchases, purchased benefits and vendor stockRevision1

Read atservices-commerce c8b66a98react-console baf6dae3

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Outcomes
Layer values explain the cost assigned to stock on hand.Accounting can consume distinct inventory and cost facts with one posting acknowledgement.
Surfaces
apijob
Intent sources
services-commerce:docs/migrations/purchasing/README.md#D-P8P-15. A costing method per business unit: FIFO, the default, or LIFO

Controls

31 controls apply, from the corpus control catalogue.

TC-IAM-006 TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-AZ-005 TC-AZ-006 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-CRY-001 TC-CRY-004 TC-DAT-001 TC-DAT-002 TC-DAT-003 TC-LOG-001 TC-LOG-002 TC-LOG-003 TC-LOG-004 TC-LOG-005 TC-AVL-004 TC-MON-001 TC-MON-002 TC-MON-004 TC-PI-001 TC-PI-002 TC-PI-003 TC-PI-004 TC-PI-005 TC-PRV-001 TC-PRV-002

Permissions

KeyChecked atScope
commerce.purchasing.createapitenant
commerce.purchasing.readapitenant
commerce.inventory-costing.readapitenant
commerce.inventory-costing.updateapitenant
commerce.inventory-costing.createapitenant
commerce.inventory-costing.deleteapitenant
commerce.inventory-costing.bulkapitenant

Business Rules

15 rules, 15 to be proved before approval. A rule's product intent is derived from its origin: 0 confirmed by a product decision, the rest inheriting this capability's proposed.

IdRuleKindEnforced atProvenance
01must prove
Proposed
Receipts replay by their business key without duplicate movements, and corrections use later movements rather than editing the receipt fact.
no proof recorded yet
invariantservice, databasetest
services-commerce:modules/purchasing/tests/integration/services/receiving/purchasing-flow.integration.spec.js#answers the retried receipt as found under its key, writing nothing twice
02must prove
Proposed
Receipt quantities cannot exceed an open purchase line or enter an already received order, and a cost difference requires an explanation before any write.
no proof recorded yet
validationservicetest
services-commerce:modules/purchasing/tests/integration/services/receiving/purchasing-flow.integration.spec.js#refuses a receipt beyond what the line has open (over_receipt) and a receipt against a received order, writing nothing
03must prove
Proposed
Receiving commits stock movements, landed-cost layers and capitalization facts together, then satisfies waiting backorders in age order within that transaction.
no proof recorded yet
invariantservice, databasetest
services-commerce:modules/purchasing/tests/integration/services/receiving/purchasing-flow.integration.spec.js#writes, in the receipt’s transaction, the receipt movement naming the line, the layer of 60 @ 1000 and the capitalize_receipt fact of 60000
04must prove
Proposed
Quantity or value allocation divides landed cost to whole minor units with the final line taking the remainder, and each layer’s unit cost includes its allocated share.
no proof recorded yet
calculationservicetest
services-commerce:modules/purchasing/tests/unit/cost/cost-rules.spec.js#shares by quantity to the minor unit, the last line taking the rounding remainder
05must prove
Proposed
Stock relief uses the business unit’s current FIFO or LIFO method, defaulting to FIFO, while later method changes leave earlier cost records intact.
origin: services-commerce:docs/migrations/purchasing/README.md#D-P8P-15. A costing method per business unit: FIFO, the default, or LIFO
no proof recorded yet
calculationservicetest
services-commerce:modules/purchasing/tests/integration/services/receiving/purchasing-flow.integration.spec.js#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
06must prove
Proposed
Unconfigured business units read default costing settings, and replacement requires the read version, an allowed method and agreement with the requested business unit.
origin: services-commerce:docs/migrations/purchasing/README.md#D-P8P-15. A costing method per business unit: FIFO, the default, or LIFO
no proof recorded yet
validationapi, servicetest
services-commerce:modules/purchasing/tests/e2e/purchasing.e2e.spec.js#writes LIFO at version 0, replaces it with the record read sent back, and refuses the stale version 409
07must prove
Proposed
Stock without sufficient layer coverage receives zero-cost relief with an uncosted exception.
no proof recorded yet
policyservicetest
services-commerce:modules/purchasing/tests/integration/services/receiving/purchasing-flow.integration.spec.js#relieves units no layer covers at cost zero under no layer and raises uncosted_relief, so the books say so
08must prove
Proposed
Returned units reverse their original relief using its recorded cost and original layer position.
no proof recorded yet
calculationservicetest
services-commerce:modules/purchasing/tests/integration/services/receiving/purchasing-flow.integration.spec.js#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
09must prove
Proposed
Cost correction consumes the original layer’s remaining units into a new correction layer and records the value difference as a cost adjustment.
no proof recorded yet
calculationservicetest
services-commerce:modules/purchasing/tests/integration/services/receiving/purchasing-flow.integration.spec.js#moves the unconsumed remainder to a layer at the corrected cost, leaves the original consumed, and writes the cost_adjustment of the difference
10must prove
Proposed
Valuation sums the remaining layer values beside on-hand quantity and reports reconciliation, business unit and costing method.
no proof recorded yet
calculationservicetest
services-commerce:modules/purchasing/tests/e2e/purchasing.e2e.spec.js#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
11must prove
Proposed
Posting intake lists unposted inventory facts by date and accepts one Accounting reference, replaying the same reference and rejecting a conflicting one.
no proof recorded yet
invariantservice, databasetest
services-commerce:modules/purchasing/tests/integration/services/receiving/purchasing-flow.integration.spec.js#lists the unposted facts by date, stamps them posted once under Accounting’s reference, and refuses another reference on a posted fact
12must prove
Proposed
Receipt, shipment, restore and stock-adjustment facts identify their inventory, clearing, cost-of-goods and adjustment account purposes for Accounting.
no proof recorded yet
calculationservicetest
services-commerce:modules/purchasing/tests/unit/cost/cost-rules.spec.js#debits inventory and credits GRNI for a receipt, debits COGS and credits inventory for a handoff, the reverse for a restore
13must prove
Proposed
Reconciliation reports stock-to-layer mismatches and shipment or transfer movements missing relief, leaving correction to a separate action.
no proof recorded yet
policyserviceobserved
14must prove
Proposed
Transfers preserve covered cost in weighted destination layers with exact rounding, produce no posting fact and retain any uncovered quantity without a destination cost layer.
no proof recorded yet
calculationserviceobserved
15must prove
Proposed
Count or staff stock gains use the latest receipt cost, while losses and scrap relieve layers by the business unit method and write the corresponding posting fact.
no proof recorded yet
calculationserviceobserved

Scenarios

IdGivenWhenThenProvenance
01Existing backorders require sweatshirts that are not yet available.A supplier delivery is recorded for the waiting stock.Receipt fills the waiting commitments and subsequent shipping draws their cost from the received layers.unknown

The Markdown files under specs/ in rhythmsoftware/rhythm-v2-docs are the canonical source of truth. This reader is a generated, read-only projection of them.