1c-odata-mcp

Overview Schema Source Related Servers Discussions Admin

Создать акт (реализация услуг)

write.sales.create_act

Creates an unposted 1C sales act (invoice) for services with service lines and printable content, using dry-run preview before confirmation.

Instructions

Создаёт «Реализация (акт, накладная)» с табличной частью УСЛУГИ (без склада/остатков). Документ НЕПРОВЕДЁННЫЙ; проводки при проведении Дт 62 Кт 90.01 (без 41; счёт расчётов — по настройке договора, источник виден в предпросмотре). ВАЖНО для услуг: задавайте content в строке — это «Содержание», текст, который печатается в акте и УПД (номер приложения, номер договора, период оказания). 1С его не заполнит. Счета доходов/расходов при необходимости задаются явно (напр. 90.01.2 / 90.02.2). dry-run/confirm. Контрагент — покупатель; позиции — услуги-номенклатура.

Input Schema

Name	Required	Description
`date`	No	Дата YYYY-MM-DD (по умолчанию сегодня)
`lines`	Yes	Позиции-услуги
`confirm`	No	false (по умолчанию) — только предпросмотр (dry-run), запись НЕ выполняется. true — выполнить создание. Сначала всегда показывайте dry-run и получайте согласие пользователя; при подтверждении передавайте operationId из результата предпросмотра и те же аргументы. После таймаута повторяйте подтверждение с тем же id, не создавая новый предпросмотр.
`database`	No	Имя базы 1С из list_databases. Без указания — база по умолчанию.
`contractRef`	No	Ref_Key договора
`operationId`	No	UUID из предпросмотра. Передайте его при confirm=true, чтобы повтор не создал дубликат.
`organization`	No	Организация (юрлицо) для фильтра: часть названия, ИНН или Ref_Key из list_organizations. Без указания — все организации базы.
`incomeAccount`	No	Счёт доходов для ВСЕХ строк (напр. «90.01.2»); счёт в строке важнее
`operationKind`	No	Вид операции (ВидОперации). Обычно НЕ задавайте: по умолчанию «Услуги» или значение из настройки базы (ODATA_ACCOUNTING_CONFIG, operationKinds.salesAct). Нужен, только если в конфигурации другое значение — не угадывайте.
`expenseAccount`	No	Счёт расходов для ВСЕХ строк (напр. «90.02.2»); счёт в строке важнее
`orgBankAccount`	No	Банковский счёт организации — печатается в документе как реквизиты для оплаты. Название/номер счёта (напр. «Сбербанк» или «40802…») либо Ref_Key. Без указания берётся ОСНОВНОЙ счёт организации.
`sumIncludesVat`	No	Сумма включает НДС
`counterpartyRef`	Yes	Ref_Key покупателя

Output Schema

Name	Required	Description	Default
`ref`	No
`code`	No
`note`	No
`notes`	No
`dryRun`	No
`created`	No
`payload`	No
`database`	No
`replayed`	No
`entitySet`	No
`willCreate`	No
`description`	No
`operationId`	No
`writableBase`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.12.0Nov 7, 2026

TDQS

A4.1/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, the description discloses that the document is created unposted, what postings it will produce when posted, how settlement accounts are derived, and that the content field is critical because 1C will not fill it. It also explains the preview/confirm workflow and avoids contradiction with openWorldHint or destructiveHint=false.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and is appropriately sized for a 13-parameter write tool. It is dense and semicolon-heavy, but every sentence conveys operational information without obvious filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema and full input-schema descriptions, the definition covers the key behavioral context an agent needs: unposted status, posting behavior, content importance, account override notes, and the dry-run/confirm safety workflow. No critical gap remains for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already carries most parameter meaning. The description reinforces critical fields such as content, income/expense accounts, and buyer semantics, and adds a note about contract settlement settings being visible in preview, but most parameter detail is duplication of the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and document type: creates «Реализация (акт, накладная)» with a services table and explicitly excludes warehouse/stock handling. That distinguishes it from warehouse-oriented siblings, but it does not explicitly differentiate from the closely named sibling write.sales.create_services_act.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides clear context for when this tool applies: services act, no warehouse, buyer counterparty, service nomenclature lines, and dry-run/confirm workflow. It does not name alternative tools or spell out when-not-to-use cases, so guidance is strong but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server