/document-posting

name: document-posting
description: "Проведение документов 1С. Используй когда нужно спроектировать или починить движения документа, выбрать состав регистров, разделить оперативное и неоперативное проведение, поставить контроль остатков, управляемые блокировки, отмену проведения и перепроведение."

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`, `dryRunRequired`. Контракт вызова бери оттуда, а не из этого текста; при `implemented: true` используй опубликованную `argsSchema`; при `support.state: limited` разрешено только подмножество `support.supportedArgs`. При `support.state: unavailable` остановись; не выдумывай аргументов при `argsSchema: null`. Для плановой операции сначала проверь результат `dryRun: true`, затем исполняй запрос с `dryRun: false`. Preview не фиксирует входы между вызовами. Не обходи контракт прямым 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.view` at `<method>.Callee` (callers at `<method>.Caller`). 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 l