Document Posting

Document Posting

MCP routing

• Preferred path: use MCP unica tools unica.view {}, unica.view on the object node, unica.apply, unica.search, unica.check, and unica.run.
• Runtime идёт через unica.run: вызов без op отдаёт словарь операций и контракт каждой — argsSchema, execution, previewRequired, ifRevRequiredOnApply. Контракт вызова бери оттуда, а не из этого текста; выбирай только операцию с implemented: true и не выдумывай аргументов записи с argsSchema: null; превью исполнением не является. Не обходи контракт прямым runner-ом.
• Use unica.docs with source: "development-standard" for the standards about posting: 450, 477, 603, 661, 663, 664, and diagnostics АПК:105, АПК:123, АПК:226, АПК:227. These are standards, not evidence of runtime behavior; confirm the wording before citing one.
• Use unica.view on the role node when posting runs in privileged mode or depends on rights or RLS on the target registers.
• Do not call internal analyzer, runtime, standards, or package adapters directly. They are hidden behind MCP unica.

References

• Read ../../references/platform/document-posting.md for the posting model, real-time versus regular branches, register choice, lock shape, and stop rules.
• Read ../../references/platform/transactions-locks.md for the transaction shape, managed lock modes, and what makes the balance read responsible; this skill adds only the ordering specific to posting.
• Read ../../references/platform/db-performance.md when posting is slow, contends on locks, or produces deadlocks.

Core model

Posting answers four separate questions, and mixing them is the usual defect:

• Whether the document posts at all: most documents do (Posting = Allow). An unposted document is a draft. Lifecycle stages are statuses on a posted document, never a reason to disable posting (std603).
• What is recorded: the register set declared in the document's RegisterRecords and written through Движения.<Регистр>.
• When it may be recorded: the platform picks the branch by comparing the document date with the session date, and ОбработкаПроведения reads it as РежимПроведения = РежимПроведенияДокумента.Оперативный. The mode is one input to deciding which checks run, not the whole rule.
• What must be locked: only the balances that can actually go negative. The write itself takes the lock — Движения.<Регистр>.БлокироватьДляИзменения = Истина — and the control query runs after that write, not before (std661).

By default the handler writes nothing itself: the platform writes the record sets implicitly when it returns, and an explicit Записать() inside the handler is АПК:105 (std450). Balance control is the sanctioned exception, and it has a prescribed order.

Workflow

1. Name the accounting subjects the document affects before touching code. Each subject is a register, not a column on an existing one.
2. Inspect the document with unica.view on the object node: declared registers, Posting, RealTimePosting, RegisterRecordsDeletion, RegisterRecordsWritingOnPost, and privileged-mode flags. Inspect every target register the same way for dimensions, resources, and periodicity.
3. Read the current handlers with unica.view on the module node (its Method branch lists the methods) before reading full modules; find the shared procedures posting calls with unica.search (a call graph is not on the v0.13 surface).
4. Decide the branch split: what the real-time branch checks, what the regular branch skips, and what both always write.
5. Decide which balances need control at all. Skip control where it cannot fail: a receipt document only increases balances, and re-posting cannot write off more than the first posting already did.
6. Fix the write order for the std661 shape: uncontrolled registers early with БлокироватьДляИзменения = Ложь in a stable register order, controlled registers last with БлокироватьДляИзменения = Истина, negative-balance queries after that write. Keep the same order in every handler that shares those registers.
7. Change metadata with unica.apply and module code with unica.apply, one verifiable step at a time.
8. Verify statically with unica.check on the module node (test runs are outside the v0.13 surface), and require separate evidence for posting, unposting, and runtime behavior with a realistic tabular section.

Design rules

• A balance register dimension must be meaningful for both receipt and expense. A value present only on receipts belongs to a turnover register or a record attribute.
• Parallelism follows the dimension set, because balances for one dimension combination live in one resource. Reach for totals separation only when the dimension set cannot give the needed granularity, and remember it buys nothing for control queries that still sit early in the transaction (std664).
• No logic or report over register data may reach a recorder field through a dot: implicit joins, and in a distributed infobase the recorder may not exist on the node (std477, АПК:123).
• Availability checks are a business decision, not a branch rule. The real-time mode is the usual place for them; a check in the regular branch must be justified against backdated entry and initial data load.
• Read row-level referential data with one query; take document-level data from the object. Dotted access to a reference attribute inside a row loop is one database read per row.
• Control balances after writing the controlled registers, at the end of the transaction — not in ПередЗаписью of the record set module, where the developer does not control the platform's write order and the lock is held while every other register is written.
• An explicit ДЛЯ ИЗМЕНЕНИЯ lock is normally unnecessary in the control step: the write already locked what the control query reads.
• Lock order, lock modes, and the transaction shape around all of this are owned by transactions-locks; apply them here rather than restating them.

Review checklist

• Every register written in code is declared in the document metadata.
• The handler does not call Записать() except for the balance-control shape (std450, АПК:105).
• Controlled registers are written last and their negative-balance query runs after that write.
• Uncontrolled registers are written in a stable order with БлокироватьДляИзменения = Ложь.
• Totals separation is on for the accumulation and accounting registers being written.
• PostInPrivilegedMode and UnpostInPrivilegedMode are set on a posting document (АПК:226, АПК:227).
• Unposting removes exactly the movements posting created, whether the platform or the deletion handler does it.
• The real-time branch is reachable and the regular branch is correct on its own.
• Refusal sets Отказ and reports the failing rows, not only a generic message.
• Re-posting an already posted document is idempotent for the resulting movements.
• The transactions-locks checklist has been applied to the handler as a whole.

Stop rules

• Do not turn posting off to model a draft or a lifecycle stage. Use statuses on a posted document (std603).
• Do not write record sets explicitly inside the handler unless the handler needs that data afterwards.
• Do not change Posting, RealTimePosting, RegisterRecordsDeletion, or the declared register list without checking movements already recorded by existing documents.
• Do not claim a posting performance win without a before/after measurement on comparable data.

Contract gaps

If public MCP unica cannot inspect the document, its registers, movements, or the runtime evidence needed for the task, report a Unica MCP contract gap with the missing operation.