v0.3.0

BREAKING: все 55 инструментов переименованы с плоского snake_case
(get_debtors) на трёхсегментный dot-notation <read|write>.<категория>.<имя>
(read.analytics.get_debtors). Причина — критерий Naming в оценке качества
листинга Smithery: плоский список инструментов без иерархии получает 0 баллов
(«Tool and trigger names should form a navigable tree via dot-notation … Flat
lists and over-nested paths both reduce the score»). Алиасов на старые имена
нет — сервер опубликован на Smithery только сегодня, внешних пользователей
листинга ещё нет, лучший момент для чистого переименования. Категории:
system/schema/counterparty/document/analytics/organization (чтение),
counterparty/entity/catalog/document/sales/purchase/warehouse/
money (запись) — полная таблица соответствий в
README «Инструменты». Заодно упростилась
annotationsFor() в src/mcp/server.ts: вместо regex-подбора по префиксу имени
теперь просто name.startsWith("read.")/"write.".

Добавлено

• outputSchema у всех 55 инструментов — MCP-клиенты теперь могут типизировать
  ответы (structuredContent), не только парсить текстовый JSON. Ещё один
  критерий quality score Smithery: «Tools should declare an outputSchema so
  callers can type-check responses». Схемы — в новом src/schemas/output.ts;
  большинство write-инструментов сводится к 4 переиспользуемым формам
  (createResultSchema/patchResultSchema/mark_for_deletion/post_document —
  почти все create_*/update_* идут через общие хелперы createOrPreview()/
  patchOrPreview() в write.ts), у read-инструментов — своя схема на каждый.
  src/tools/_shared.ts: ok(data) теперь кладёт structuredContent централизованно
  для всех инструментов разом. src/types/domain.ts: Counterparty/DocumentSummary
  выводятся из Zod-схем (z.infer) вместо дублирования вручную — один источник
  правды; заодно убраны 4 неиспользуемых нигде типа (BalanceRow/DebtRow/
  SalesSummary/CashflowSummary), не совпадавших с реальной формой ответа.
  Важная находка при разработке: outputSchema не может быть z.union([...])
  или голым z.record() на верхнем уровне — MCP SDK падает с Cannot read properties of undefined (reading '_zod') (протокол требует type:"object"
  на верхнем уровне, а обе формы конвертируются иначе). Все схемы поэтому —
  плоский z.object({...}).passthrough() с необязательными полями (разные
  ветки dry-run/confirmed — просто разные подмножества одних и тех же полей).
  Проверено вживую на реальной базе: все 55 инструментов (21 чтение реальными
  вызовами, 34 записи через confirm:false dry-run — ничего не пишет) прошли
  без единой ошибки валидации structuredContent.

Исправлено

• Пять параметров без описания (limit в search_documents/
  get_customer_history/get_supplier_history; entitySet/ref/line в
  add_document_line/remove_document_line) — найдено проверкой Smithery
  quality score («Parameter descriptions»). Манифест Smithery (manifest.json)
  также получил title/annotations по каждому инструменту — раньше терялись
  при выгрузке (закрывает критерии Naming/Annotations).

v0.2.0

Крупный релиз записи: 12 новых инструментов создания документов (возвраты,
складские операции, деньги, счета-фактуры, акт услуг). Все проверены боевым
POST-тестом (create → read → mark) на реальной базе — 1С приняла маппинг полей
и виды операций. Регламентные операции по-прежнему только читаются.

Исправлено

• Текст ошибки 1С больше не теряется. Ответ OData v3 кладёт ошибку в ключ
  odata.error (с точкой), а извлекатель читал error — из-за чего осмысленное
  сообщение 1С (напр. «Не удалось записать: Счет-фактура выданный!») подменялось
  голым «Ошибка сервера 1С (500)». Теперь поддержаны оба формата (v3 и v2/v4).
  Выявлено боевым POST-тестом новых документов.

Добавлено

• Акт об оказании услуг (фаза 4): create_services_act создаёт
  «Акт об оказании производственных услуг» — услуги с учётом доходов/расходов по
  номенклатурной группе (в отличие от create_act, который делает обычную реализацию
  услуг). Номенклатурная группа (субконто счёта доходов 90.01) — обязательный параметр,
  не угадывается. Счета строки (90.01/90.02/90.03, расчёты 62.01) резолвятся как у
  реализации. Проводки Дт 62 Кт 90.01 (НДС 90.03). НЕпроведённым; dry-run/confirm.
  «Поступление услуг» отдельного инструмента не требует — покрыто create_purchase.
  (Итого — 55 инструментов: 21 чтение + 34 записи.)
• Счета-фактуры (фаза 3), создание: create_issued_invoice (счёт-фактура
  выданный, вид «НаРеализацию») и create_received_invoice (полученный, вид
  «НаПоступление»). Создаются НА ОСНОВАНИИ реализации / поступления: организация,
  контрагент, договор, сумма и НДС наследуются от документа-основания, связь пишется
  в шапку (ДокументОснование + _Type) и в ТЧ «ДокументыОснования». Для полученного
  дату входящего счёта-фактуры продавца указывают вручную (её нет в поступлении).
  Основание можно переопределить (baseDocumentEntity) — напр. отчёт комитенту.
  Создаются НЕпроведёнными; dry-run/confirm.
• Денежные документы (фаза 2), создание: create_bank_writeoff (списание с
  расчётного счёта), create_cash_receipt (ПКО), create_cash_payment (РКО).
  Вид операции — обязательный параметр (бизнес-классификация, не угадывается:
  ОплатаПоставщику / ПеречислениеНалога / ПрочийПриход / ВыдачаПодотчетномуЛицу и
  т.п.). Контрагент полиморфный (Контрагент + _Type). Для оплаты поставщику/от
  покупателя с договором заполняется «Расшифровка платежа» (сч. 60/62,
  СпособПогашения=Автоматически); для налогов/ЗП/взносов — шапка без расшифровки.
  Создаются НЕпроведёнными; dry-run/confirm.
• Товарные складские документы (фаза 1), создание + построчное редактирование:
  create_return_from_customer (возврат от покупателя), create_return_to_supplier
  (возврат поставщику), create_transfer (перемещение между складами),
  create_surplus (оприходование), create_writeoff (списание), create_inventory
  (инвентаризация, не проводится). Счета учёта берутся из регистра/плана счетов
  (как у поступления/реализации); возвраты переиспользуют логику продажи/закупки.
  update_document_lines/add_document_line/remove_document_line теперь знают
  эти типы. Создаются НЕпроведёнными; dry-run/confirm. Чтение — как и прежде через
  search_documents/get_document.
• create_payout_order — создаёт «Платёжное поручение» (исходящая выплата контрагенту), всегда
  НЕПРОВЕДЁННЫМ. Номер задаётся явно вызывающим (для зеркалирования уже отправленной банковской
  платёжки тем же номером) — не автонумеруется, в отличие от прочих create_*. Счёт организации
  и валюта (рубль, код 643) резолвятся автоматически, если не заданы явно. dry-run/confirm, как у
  остальных инструментов записи.

v0.1.11

Исправлено

• publish.yml: пин npm@11 вместо npm@latest — свежий мажор npm@12.0.0
  (вышел 2026-07-08) ломает provenance при самообновлении на раннере
  (Cannot find module 'sigstore') и сорвал публикацию версии 0.1.10.
  Версия 0.1.10 пропущена (git-тег остался, в npm и GitHub Releases не
  публиковалась) — как ранее 0.1.7; все её изменения включены в этот релиз.

Добавлено

• get_organization_card — полные реквизиты организации из настроек 1С: ИНН/КПП/
  ОГРН, полное/сокращённое наименование, дата регистрации, ОКВЭД, налоговый орган,
  контактная информация (юр./факт./почтовый адрес, телефон, email — виды расшифровываются
  по имени, не по коду), основной банковский счёт (банк по БИК, валюта), а также
  директор и главный бухгалтер. Для ИП директор — сам предприниматель (из карточки
  организации); для юрлиц — из периодического регистра «Ответственные лица
  организаций» (структура полей определяется динамически по $metadata, т.к. может
  отличаться между конфигурациями; если регистр не опубликован — вежливая заметка
  вместо ошибки). Работает по названию организации или автоматически, если она одна.
• docs/CONNECTING.md: предупреждение и строка диагностики про версионные пути
  к node в конфиге Claude Desktop (node@22, node@24 и т.п.) — после
  brew upgrade такой путь перестаёт существовать, и Claude Desktop падает с
  «Failed to spawn process: No such file or directory» без объяснений в
  интерфейсе. Примеры конфига переведены на generic-путь /opt/homebrew/bin/node
  (Apple Silicon) / /usr/local/bin/node (Intel), который Homebrew сам
  переключает на актуальную версию.

v0.1.9

Исправлено

• Совместимость со строгими MCP-клиентами: под клиентом (когда stdin — pipe)
  логи пишутся в файл <tmpdir>/1c-odata-mcp/server.log, а stderr остаётся
  чистым — иначе клиенты, трактующие любой вывод в stderr как фатальную ошибку
  (Kilo Code, OpenCode и др.), падали. В терминале логи по-прежнему в stderr;
  принудительно вернуть в stderr — MCP_LOG_STDERR=1.

Добавлено

• Документация: явная поддержка любых MCP-клиентов (Claude, Cursor, VS Code +
  Continue/Cline, JetBrains) и локальных моделей (Ollama, LM Studio); блок про
  приватность данных (локальный процесс, с локальной моделью данные не покидают
  сеть); демо-визуал и FAQ в README; гайд по включению OData под разные типы 1С
  (docs/ODATA-SETUP.md); CODE_OF_CONDUCT.md.

Изменено

• Обновлены зависимости: fast-xml-parser 5.9.3, @types/node 26,
  actions/checkout v7, прочие dev-зависимости (Dependabot).
• Более ёмкое описание пакета в package.json (для кого / ~40 инструментов /
  npx / локальные модели / read-only по умолчанию).

v0.1.8

Исправлено

• Тихий недосчёт в агрегатах устранён системно. Аналитика занижала годовые
  итоги на «шумных» базах: выборки стояли под общим ODATA_MAX_ROWS=1000, и при

  1000 документов хвост периода молча отбрасывался (выплаты ИП за год — на ~3 млн
  ₽; затронуты и get_sales, get_cashflow, get_debtors, get_inventory).
  Введён единый безопасный путь агрегации (src/odata/aggregate.ts): высокий
  потолок ODATA_ANALYTICS_MAX_ROWS (200000), и вместо тихой обрезки — громкая
  ошибка при переполнении либо авто-чанкинг по месяцам (большой период
  досчитывается полностью по окнам). Также: get_debtors/get_inventory считали
  общий итог только по показанным top-N строкам — теперь по всем.

• Деньги в аналитике суммируются в целых копейках (без float-дрейфа на тысячах
  сумм).

Добавлено

• Поля from/to/asOf валидируются как дата YYYY-MM-DD (формат + диапазон
  месяца/дня) + проверка from ≤ to; раньше кривая дата уходила в OData как есть.
• В ответах аналитики — блок scan (documentsScanned / windows / elapsedMs):
  видно, что выборка полная и сколько просканировано.

Изменено

• Выборки по типам документов в get_payments_breakdown / get_cashflow идут
  параллельно (быстрее на больших периодах).

Удалено

• Неиспользуемый odataDateTime (латентный UTC-сдвиг даты).

v0.1.6

Добавлено

• get_deal_history — хронология всех движений по «сделке» (банковский код в
  назначении платежа, напр. CB…) или по договору (contractRef): приход, расход,
  итоги и сальдо. Закрывает вопросы вроде «покажи финрезультат по сделке»,
  «движения по договору №42».
• get_taxes_paid — сумма уплаченных налогов/взносов за период с разбивкой по
  статье ДДС (УСН / НДФЛ / страховые / ЕНП / 1% в ПФР), месяцу или получателю.
  Маркер — ВидОперации=«ПеречислениеНалога» (надёжный гейт в БП 3.0). Опц.
  параметр cashflowItem уточняет конкретный вид налога.
• get_sales_breakdown и get_purchases_breakdown — суммы продаж/закупок за
  период с разбивкой по контрагенту / месяцу / договору / итогу. Фильтры:
  конкретный контрагент, категория контрагента (ИП/ЮрЛицо/ФизЛицо/
  Нерезидент/Госорган), договор. Закрывает вопросы «топ покупателей за год»,
  «выручка по месяцам», «сколько закупили у ИП».
• В get_payments_breakdown добавлены: counterpartyKind (категория), cashflowItem
  (статья ДДС по коду/имени/Ref — серверный фильтр), groupBy:"cashflowItem".
  Закрывает вопросы «сколько заплатили ИП за год», «приход/расход по статьям ДДС».
• Параметр asOf в get_debtors и get_inventory — сальдо/остатки на конец
  указанной даты (для аудита, исторических отчётов). Под капотом — параметр
  Period виртуальной таблицы Balance (path-параметр у регистра, не $filter).

Добавлено

• get_payments_breakdown — высокоуровневая разбивка проведённых
  банковских/кассовых документов за период с фильтрами по направлению
  (приход/расход/оба), контрагенту (Ref_Key), подстроке в назначении платежа,
  виду операции, и разбивкой по виду операции / месяцу / контрагенту / итогу.
  Отвечает на вопросы вроде «сколько процентов по депозиту от <банка> за год»,
  «сколько заплатили такому-то поставщику», «приход по месяцам».
  Контрагент в банковских документах хранится полиморфно — фильтр по нему
  применяется в коннекторе (быстро); назначение/период/орг — на сервере 1С.

Исправлено

• search_documents: фильтр counterpartyRef для документов с полиморфным
  полем Контрагент (банковские: ПоступлениеНаРасчетныйСчет/СписаниеСРасчетногоСчета
  и т.п.) больше не валит OData ошибкой 400/500: коннектор автодетектит тип поля
  (Контрагент_Key → сервер, Контрагент → клиент) и фильтрует на своей стороне,
  возвращая пометку counterpartyFilter.

v0.1.5

Процесс обработки входящего счёта поставщика «под ключ» (на реальном кейсе проверено вживую): проверить поставщика → завести карточку (банк/директор/договор) → создать номенклатуру в папке → зарегистрировать счёт.

Добавлено

• create_supplier_invoice — регистрация входящего «Счёта на оплату поставщика» (основание под оплату, в т.ч. предоплату до поставки): без проводок и счетов учёта, единая ТЧ «Товары» под товары и услуги (поле content/Содержание), реквизиты входящего счёта (incomingNumber/incomingDate).
• create_folder и move_to_folder — папки/группы иерархических справочников (по умолчанию Контрагенты), вложенность по имени или Ref_Key.
• create_nomenclature — артикул, размещение в папке (folder) и признак услуги (isService).
• create_contract — руководитель/подписант контрагента (headName, headPosition).

Изменено

• create_contract: вид договора (kind) теперь обязателен — коннектор не угадывает покупатель/поставщик; номер по умолчанию «б/н», дата — сегодня.

Исправлено

• Даты документов больше не уезжают на день назад в поясах с плюсовым смещением (MSK +3): форматирование через локальное время вместо UTC (Edm.DateTime в 1С — «настенная» дата без зоны). Добавлен регресс-тест.

npm: npm i 1c-odata-mcp@0.1.5 · опубликовано через Trusted Publishing (OIDC, provenance).

v0.1.4

Изменено

• Обновлены зависимости: pino 10, TypeScript 6, @types/node 25, fast-xml-parser 5 (разбор $metadata проверен на живой базе).

Исправлено

• Версия MCP-сервера берётся из package.json (раньше была захардкожена 0.1.0).

npm: npm i 1c-odata-mcp@0.1.4

v0.1.3

Качество и инфраструктура:

• Юнит-тесты (Vitest) на ключевую логику, включая регресс кодирования +/%20.
• CI на GitHub Actions; публикация в npm по тегу через Trusted Publishing (OIDC, без токена; provenance автоматически).
• Аннотации инструментов MCP (readOnlyHint/destructiveHint) + instructions сервера.
• ESLint + Prettier; CONTRIBUTING/SECURITY, Dependabot, шаблоны issue; CHANGELOG.

Документация: README — про проект и ограничения; docs/CONNECTING — установка/настройка; SEO (badges, keywords, topics).

v0.1.2

«Богатая» карточка контрагента:

• телефон, email, адрес (табличная часть «Контактная информация») и ОГРН (если в базе настроен доп.реквизит) в create_counterparty / update_counterparty;
• create_bank_account — расчётный счёт контрагента (банк по БИК), опция «основной»;
• create_contact_person — контактное лицо (директор и т.п.), опция «основное».