# Inventory receiving and internal transfer

Phase 3B.3 extends the inventory ledger with company-numbered documents. It does
not introduce procurement, costing, or supplier accounting.

## Receipt lifecycle

`create_goods_receipt` creates DRAFT evidence. `update_goods_receipt` and
`set_goods_receipt_lines` edit only drafts, with revision preconditions. Draft
identifier text does not create serialized units or lock serialization policy.
`post_goods_receipt` atomically registers or reuses eligible registered units,
posts each line to the immutable ledger, and transitions to POSTED.
`cancel_goods_receipt` requires a reason and accepts only DRAFT. Posted receipts
cannot be edited, cancelled, or deleted. A failed posting rolls back all units,
ledger entries, and document changes.

## Transfer lifecycle

`create_stock_transfer`, `update_stock_transfer`, and `set_stock_transfer_lines`
manage DRAFT documents. Draft unit selections do not reserve stock.
`dispatch_stock_transfer` moves every line from source to a dedicated managed
TRANSIT location and records DISPATCHED. `receive_stock_transfer` moves every
line from transit to destination and records RECEIVED. Thus company stock is
conserved and dispatched stock is unavailable at both physical endpoints.
Serialized units explicitly enter IN_TRANSIT until receipt.
`cancel_stock_transfer` accepts only DRAFT and requires a reason. There is no
partial dispatch, partial receipt, or post-dispatch cancellation in this phase.
Managed transit locations cannot be manually edited, deactivated, or used by
ordinary stock movement APIs. Dispatched transfers prevent endpoint deactivation.
Quarantine/defective stock cannot be transferred into usable inventory.

## Authorization, locking, and history

Existing scope authorization checks receive_stock at the receipt destination,
and transfer_stock at both transfer endpoints. Cross-company documents are
rejected. Company-wide numbering uses a transactional per-company/kind sequence.
Commands lock actor, company, assignment and role dependencies, part categories,
parts, physical locations, document, stock positions, and serialized units.
Dependencies use shared locks; mutable documents and stock positions use update
locks. Parts share the locking discipline of the frozen part update service, so
first posting cannot race serialization-policy changes. The managed transit
location is locked after physical endpoints: no supported writer acquires it
exclusively or independently of its transfer. UUID ordering applies within each
lock class. Fresh document revisions and active line sets are revalidated.

Database constraints/triggers enforce company ownership, immutable identities,
terminal document history, line-to-ledger coherence, and serialized transit
state. Ordinary model saves/deletes are blocked. Ledger rows remain immutable.
Changing operational master availability never erases posted history; restoring
availability may be necessary to complete a pending transfer.

## Admin and queries

Admin creates/edits drafts through domain services. Posting, dispatch, receipt,
and cancellation require signed actor/document/action/revision confirmation.
Historical records are readonly, with no delete or arbitrary status controls.
All mutation forms retain Django CSRF protection. Query helpers filter scope in
SQL and prefetch line evidence; representative document detail retrieval takes
four queries independent of line count.

## Verification

The combined inventory suite passed 131 tests in one PostgreSQL run (95.491s),
including 31 real concurrency tests. The 58 Phase 3B.3 additions cover document
lifecycle, company isolation, serialization, rollback, readonly history, signed
Admin actions, CSRF, query counts, numbering races, competing transfers,
deactivation, duplicate posting/receiving, and policy-change/posting races.
The prior Phase 3B.2 checkpoint also passed all 97 frozen parts tests unchanged.


## Phase 6C operational workspace

Scoped receiving/transfer lists, evidence and confirmation forms delegate to the
existing create/set-lines/cancel/post and dispatch/receive services. Drafts remain
non-authoritative stock. Both transfer endpoints require scope. Serialized rules,
locks, revisions and per-line movement keys remain unchanged; no new transfer
state, supplier or procurement domain is introduced.

Actor/operation/document/revision-bound tokens expire after one hour. Posting
replay cannot create extra stock. Draft creation has no domain command key and may
create separate unposted drafts on repeated explicit creation. The operational
editor supports up to 100 lines, with one spare blank row per review. Larger edits
remain in guarded Admin. See [Operational UI](OPERATIONAL_UI.md#phase-6c-parts-and-inventory-operational-workspace)
for scope, responsive behavior, limits and focused regression evidence.