Skip to main content
Glama
1c-odata-mcp

1c-odata-mcp

by foxnaim

Создать платёжное поручение (исходящее) контрагенту

write.money.create_payout_order

Creates an unposted outgoing payment order to a counterparty with an explicit number, defaulting to a dry-run preview before confirmed creation.

Instructions

Создаёт документ «Платёжное поручение» — исходящую выплату контрагенту (напр. оплата по агентскому договору / услугам, зеркало платёжки, уже ушедшей в банк). Документ ВСЕГДА создаётся НЕПРОВЕДЁННЫМ (Posted=false) — эта операция намеренно не проводит документ, проведение делайте отдельно через post_document, если вообще нужно. Номер (number) — задаётся явно вызывающим (обычно чтобы совпасть с номером уже отправленной банковской платёжки), не генерируется автоматически. По умолчанию dry-run (confirm=false); создание — при confirm=true. Счёт организации и валюта — резолвятся автоматически, если не заданы.

Input Schema

NameRequiredDescriptionDefault
dateNoДата документа YYYY-MM-DD (по умолчанию сегодня)
amountYesСумма документа
numberYesНомер документа — задайте явно (напр. чтобы совпасть с номером банковской платёжки). 1С автонумерует новые документы только если Number не передан вовсе — но здесь он обязателен.
commentNoКомментарий к документу
confirmNofalse (по умолчанию) — только предпросмотр (dry-run), запись НЕ выполняется. true — выполнить создание. Сначала всегда показывайте dry-run и получайте согласие пользователя; при подтверждении передавайте operationId из результата предпросмотра и те же аргументы. После таймаута повторяйте подтверждение с тем же id, не создавая новый предпросмотр.
vatRateNoСтавка НДСБезНДС
databaseNoИмя базы 1С из list_databases. Без указания — база по умолчанию.
payerInnNoИНН плательщика (по умолчанию — ИНН организации)
priorityNoОчередность платежа (ОчередностьПлатежа)
payerTextNoТекст плательщика (по умолчанию — имя организации)
contractRefNoRef_Key договора с контрагентом (ДоговорКонтрагента_Key)
currencyRefNoRef_Key валюты документа; без указания — рубль (643)
operationIdNoUUID из предпросмотра. Передайте его при confirm=true, чтобы повтор не создал дубликат.
purposeTextYesНазначение платежа (НазначениеПлатежа)
organizationNoОрганизация (юрлицо) для фильтра: часть названия, ИНН или Ref_Key из list_organizations. Без указания — все организации базы.
recipientInnNoИНН получателя
recipientKppNoКПП получателя
operationKindNoВид операции (ВидОперации), напр. ОплатаПоставщикуОплатаПоставщику
recipientTextYesТекст получателя — как печатается в платёжке (ТекстПолучателя)
orgBankAccountNoБанковский счёт организации — печатается в документе как реквизиты для оплаты. Название/номер счёта (напр. «Сбербанк» или «40802…») либо Ref_Key. Без указания берётся ОСНОВНОЙ счёт организации.
responsibleRefNoRef_Key ответственного (Ответственный_Key)
cashflowItemRefNoRef_Key статьи движения денежных средств (СтатьяДвиженияДенежныхСредств_Key)
counterpartyRefYesRef_Key контрагента-получателя (из find_counterparty)
counterpartyAccountRefNoRef_Key банковского счёта контрагента (СчетКонтрагента_Key)

Output Schema

NameRequiredDescriptionDefault
refNo
codeNo
noteNo
notesNo
dryRunNo
createdNo
payloadNo
databaseNo
replayedNo
entitySetNo
willCreateNo
descriptionNo
operationIdNo
writableBaseNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.12.0

TDQS

A3.8/5.0
Behavior4/5

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

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description adds real behavioral context: the document is ALWAYS created unposted (Posted=false), number is never auto-generated and must be supplied, and org account/currency are resolved automatically. That materially changes how an agent should behave. It stops short of covering idempotency/duplicate risk or the preview result shape, but the schema covers those.

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?

Five sentences, front-loaded with the purpose and then the critical behavioral caveats (unposted, explicit number, dry-run default). Some content overlaps the schema, but nothing is filler and the ordering is sensible.

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?

For a 24-parameter, high-blast-radius creation tool with full annotations, 100% schema coverage, and an output schema, the description covers exactly the non-obvious parts: non-posting behavior, mandatory manual numbering, dry-run default, and automatic account/currency resolution. An agent has what it needs to call this safely.

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% and the schema already documents confirm, operationId, number, and the auto-resolution defaults in detail, so the description's parameter notes largely restate structured data. It adds no syntax, format, or validation meaning beyond what the schema supplies — baseline 3 applies.

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 states a specific verb and resource — creating a "Платёжное поручение" outbound payment document to a counterparty — and clarifies the intended scenario (mirroring a payment order already sent to the bank, agency/service payments). It does not, however, distinguish this tool from close siblings such as write.money.create_bank_writeoff or write.money.create_payment, so an agent cannot pick among them from this text alone.

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

Usage Guidelines3/5

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

It names post_document as the alternative for posting, which is genuinely useful routing guidance, and specifies the dry-run/confirm protocol. But the most consequential choice — this tool versus the other money-creation siblings (create_payment, create_bank_writeoff, create_cash_payment) — is never addressed, leaving selection ambiguous.

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

Deploy Server

Other Tools