document-posting git:20261104.563146fA

Immutable. This exact content never changes and is served at /api/v1/blob/d07bbd903cf52825.

---
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`. Контракт вызова бери оттуда, а не из этого текста;
используй опубликованную `argsSchema`; при `support.state: limited`
разрешено только подмножество `support.supportedArgs`. Недоступной операции
в словаре нет. Для плановой операции сначала проверь результат
`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.

## What A Query Can Observe

Use the actual document reference and distinguish these states in a standard
8.3.27 posting call. Form data is a separate representation; it is not proof of
the object or database value at the query point.

| Point | Form data | Document object | Database query in the same session | Write transaction |
| --- | --- | --- | --- | --- |
| Object `ПередЗаписью` | Separate representation | Pending values | State before this write | Active |
| Entry to `ОбработкаПроведения` | Separate representation | Values passed into posting | The document has already been written in this transaction | Active |
| A field is changed in memory inside `ОбработкаПроведения` | Separate representation | Can be newer than the last database write | Reads the saved state unless another write occurred | Still active |

Confirm the class/event and `РежимЗаписиДокумента.Проведение` through
`unica.docs` with `source: "platform-help"`, open the returned pages and check
`applicableVersion`. The posting-mode page establishes that document changes are
saved before posting in the same transaction. A statement about ordering or data
freshness without code, official help or runtime evidence is a hypothesis; label
it and propose a concrete comparison rather than explaining a mismatch as a
one-write delay.

A saved document is not a committed transaction or proof of visibility to another
session. A populated `Движения` set is also not proof that its records are already
in the database: inspect its write flags and the actual write point. Keep
transaction control and locks with [their owning reference](../../references/platform/transactions-locks.md).
Use [the diagnostic example](../../references/platform/object-events.md#diagnosing-a-document-query-mismatch)
to compare the form, object, query target and changes inside the handler.

## 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 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.