IDE + MCPПереразнесение платежей

Проверка одной квитанции на 7 350 ₽ выявила и исправила 4 платежа на 36 550 ₽, разнесённых не на того ИП

3 июня 2026 · «Бухгалтерия предприятия 3.0», ИП Лебедева Ольга Викторовна (бухгалтерское обслуживание селлеров маркетплейсов) · AI Agent for 1C

Коротко

Клиент прислал скриншот банковской квитанции на 7 350 ₽ и спросил, учтён ли этот платёж. Проверка показала, что платёж в базе есть, но отнесён не на того контрагента: деньги были за услуги одного ИП, а закрыли долг другого. Дальше выяснилось, что таких ошибочно разнесённых платежей не один, а четыре — на 36 550 ₽, плюс все оплаты с личной карты (67 900 ₽) висели одной общей суммой. Расчёты по трём контрагентам пересобрали полностью, и клиент получил две понятные таблицы-сверки с указанием, какой счёт чем оплачен.

Что требовалось

Бухгалтерское агентство ведёт в одной базе несколько ИП, в том числе двух родных сестёр: у одной абонентское обслуживание (~3 500 ₽/мес), у другой квартальный тариф (7 350 ₽/квартал). Одна из сестёр оплачивала со своей личной карты и за свой ИП, и за ИП сестры. Из-за этого платежи разносились вразнобой — то на свой ИП, то на чужой, то на карточку физлица, и задолженность по клиентам перестала сходиться, хотя по факту всё было оплачено.

Формальный запрос был простым: «проверьте, есть ли в учёте платёж на 7 350 ₽ от 07.07.2025 по счёту №74 и учтён ли он». За этим стоял более широкий вопрос — правильно ли вообще разнесены оплаты обеих сестёр.

Как помог агент

Агент нашёл указанный платёж в базе и установил, что он действительно проведён, но отнесён на ИП плательщицы, тогда как счёт №74 — это квартальный счёт её сестры. То есть оплата за сестру закрыла собственный долг плательщицы.

Чтобы понять, разовая это ошибка или системная, агент сверил все платежи по этому ИП с номерами счетов из назначения и нашёл четыре платежа на 36 550 ₽, которые на самом деле относились к сестре. Дополнительно выяснилось, что все оплаты с личной карты (67 900 ₽) учитывались общей суммой и тоже требовали корректного распределения между двумя ИП.

Затем агент:

сверил по каждому ИП начисления (реализации, акты) с поступившими оплатами и отделил реальный входящий долг от ошибок разнесения;
нашёл и пометил на удаление дубли актов (одна услуга была проведена дважды);
переразнёс четыре платежа на правильного контрагента;
отменил четыре прежних временных взаимозачёта и сформировал вместо них четыре корректных — каждый закрывает задолженность нужного ИП соответствующим авансом;
перепровёл расчёты строго по датам, чтобы оплаты закрывались в правильной хронологии;
сформировал клиенту две таблицы-сверки в Excel.

Вся работа выполнена прямо в рабочей базе, без программиста и без установки дополнительных обработок.

Результат

Услуги одной сестры (80 650 ₽) сведены полностью — долг 0.
Оплаты с личной карты (67 900 ₽) корректно распределены между двумя ИП (29 400 ₽ и 38 500 ₽), задолженность физлица сведена к 0.
У второй сестры остался реальный долг 3 500 ₽ — один неоплаченный месяц плюс остаток на начало периода. Этот реальный долг важно было не «замазать» зачётами, и агент его сохранил.
Четыре платежа на 36 550 ₽ переразнесены на правильного контрагента, четыре прежних зачёта заменены корректными.

Клиент получил две Excel-сверки (по каждому ИП): по каждому счёту видно дату, сумму, дату оплаты, источник (карта ИП или личная карта) и статус, неоплаченный счёт выделен. Это готовый материал, который бухгалтер передаёт клиенту.

для специалистов — запросы, инструменты, ход работы

1. Контекст

Агентство ведёт несколько ИП-клиентов в одной базе БП 3.0. Двое из них — родные сёстры:

Сафина Алина Ринатовна ИП — клиент с абонентским обслуживанием (~3 500 ₽/мес);
Сафина Карина Ринатовна ИП — клиент с квартальным тарифом (7 350 ₽/квартал).

Плюс в базе есть карточка-физлицо «САФИНА АЛИНА РИНАТОВНА» (без ИНН) — на неё загружались платежи с личной карты Алины. Фактически одна женщина оплачивает со своей карты и свой ИП, и ИП сестры. В учёте это привело к смешению расчётов: платежи относились то на ИП, то на физлицо, то на чужого контрагента.

Это распространённая ситуация в сервисной бухгалтерии: физлицо оплачивает за несколько ИП, разнесение платежей нарушается, и дебиторская задолженность по клиентам перестаёт сходиться — притом что суммарно всё оплачено.

2. Обращение заказчика

«Алина сообщает, что нашла платёж, прошу проверить — есть ли он и учтён ли?» — и скриншот квитанции Т-Банка: 07.07.2025, 7 350 ₽, получатель ИП Лебедева Н. В., назначение «Оплата по счёту № 74 от 02.07.2025».

Запрос на проверку одного платежа. За ним стоит вопрос о корректности разнесения платежей обеих сестёр, что является уже массовой задачей.

3. Исследование

3.1 Платёж есть, но отнесён не туда

Поиск по всей базе одним запросом (по фрагменту назначения и по сумме за период):

ВЫБРАТЬ Дата, Номер, Контрагент.Наименование, СуммаДокумента, НазначениеПлатежа
ИЗ Документ.ПоступлениеНаРасчетныйСчет
ГДЕ НазначениеПлатежа ПОДОБНО "%74 ОТ 02.07.2025%"
   ИЛИ (Дата МЕЖДУ &Нач И &Кон И СуммаДокумента = 7350)

Документ	Контрагент в базе	Назначение
Поступление №98 от 07.07.2025, 7 350 ₽	Сафина Алина Ринатовна ИП ❗	«счёт № 74 от 02.07.2025»

Счёт №74 — это квартальный счёт Карины (её тариф 7 350). А платёж проведён на ИП Алины. То есть Алина оплатила за сестру, но платёж закрыл её собственный ИП, а не ИП Карины.

3.2 Оценка масштаба: единичный случай или системная ошибка

Выгружены все 28 платежей по ИП Алины с назначениями, номера счетов из назначения сверены со справочником счетов обоих ИП. Установлено, что четыре платежа на ИП Алины фактически относятся к Карине (это видно по номеру счёта, а у двух прямо в назначении указано «Оплата за Сафину Карину Ринатовну ИНН 504112880345»):

Платёж	Сумма	Назначение (счёт)	Чей счёт
№27 от 16.04.2024	7 350	счёт №23	Карины
№28 от 16.04.2024	14 500	счёт №22 (закрытие года)	Карины
№40 от 04.07.2024	7 350	счёт №39	Карины
№98 от 07.07.2025	7 350	счёт №74	Карины
	36 550

Кроме того, вся личная карта физлица (13 платежей, 67 900 ₽) числилась общей суммой авансом на карточке-физлице: 4 платежа (29 400) — за Карину, 9 (38 500) — за собственный ИП Алины.

3.3 Сведение расчётов и выявление расхождения

Ключевая проверка — сравнение начислений и оплат по каждому ИП по документам, а не по «развёрнутому» сальдо счёта 62:

ВЫБРАТЬ "Реализации" КАК Вид, СУММА(СуммаДокумента) ИЗ Документ.РеализацияТоваровУслуг
ГДЕ Контрагент = &К И ПометкаУдаления = ЛОЖЬ
ОБЪЕДИНИТЬ ВСЕ
ВЫБРАТЬ "Оплаты", СУММА(СуммаДокумента) ИЗ Документ.ПоступлениеНаРасчетныйСчет
ГДЕ Контрагент = &К И ПометкаУдаления = ЛОЖЬ

Карина: услуги 80 650. После переразнесения её оплаты = свои 14 700 + перенесённая разноска 36 550 + личная карта 29 400 = ровно 80 650. Полностью оплачена.
Алина: услуги 144 190, свои оплаты 107 440. По документам нетто-долг = 36 750, а в ГЛ — 42 000.

Технический момент. Расхождение «документный нетто 36 750 ≠ ГЛ нетто 42 000» = 5 250. Первоначально предполагался артефакт перепроведения, но после полной чистки сальдо расхождение осталось — следовательно, это реальный входящий остаток (задолженность до периода загруженных документов). Этот момент важно было выявить: иначе зачёты привели бы к фиктивной переплате у Алины вместо корректного долга.

3.4 Причина некорректного разнесения и выявленные дубли

При разборе реализаций обеих сестёр выявлены дубли актов (одна услуга проведена дважды — например, у Карины квартальный акт за 1 кв 2026 числился и 04.04, и 04.05). Их пометили на удаление до сведения расчётов, чтобы не учитывать оплату по задвоенным услугам. Признак дубля — одинаковый период/сумма при двойном проведении в течение месяца.

4. Решения

Стратегия: вернуть каждому ИП его собственные оплаты, а взаимозачёты пересобрать с нуля — прежние были временными решениями поверх некорректного разнесения.

4.1 Снять старые взаимозачёты

4 ранее созданные «Корректировки долга» (зачёты по некорректной картине расчётов) распровели и пометили на удаление — batch_1c UNPOST + DELETE_MARK. Расчёты вернулись в исходное состояние, от которого можно собрать корректную картину.

4.2 Переразнести 4 платежа на Карину — правка РасшифровкиПлатежа

Переразнесение платежа на другого контрагента — это не только смена шапки. Поступление хранит расчёты в табличной части РасшифровкаПлатежа (договор, способ погашения, счета учёта). Изменяем и шапку (Контрагент, ДоговорКонтрагента), и строку расшифровки:

{
  "action": "UPDATE", "post": true,
  "ref": {"metadata_type": "Документ.ПоступлениеНаРасчетныйСчет", "uuid": "<платёж>"},
  "data": {
    "Контрагент":        {"metadata_type": "Справочник.Контрагенты", "uuid": "<Карина>"},
    "ДоговорКонтрагента": {"metadata_type": "Справочник.ДоговорыКонтрагентов", "uuid": "<Карина/Квартальный>"},
    "РасшифровкаПлатежа": [{
      "ДоговорКонтрагента": {"metadata_type": "Справочник.ДоговорыКонтрагентов", "uuid": "<Карина/Квартальный>"},
      "СуммаПлатежа": 7350, "СуммаВзаиморасчетов": 7350,
      "СпособПогашенияЗадолженности": {"metadata_type": "Перечисление.СпособыПогашенияЗадолженности", "uuid": "ref-no-props:Автоматически"},
      "СчетУчетаРасчетовСКонтрагентом": {"metadata_type": "ПланСчетов.Хозрасчетный", "uuid": "<62.01>"},
      "СчетУчетаРасчетовПоАвансам":     {"metadata_type": "ПланСчетов.Хозрасчетный", "uuid": "<62.02>"}
    }]
  }
}

Перед правкой — metadata_1c по Документ.ПоступлениеНаРасчетныйСчет, чтобы точно определить состав РасшифровкаПлатежа и сохранить способ погашения / статью ДДС.

4.3 Дубль-реализации: ПометкаУдаления не снимается через UPDATE — применён object-метод

При откате ошибочно помеченного на удаление документа выявлено: batch_1c UPDATE с data: {"ПометкаУдаления": false} возвращает UPDATED, однако флаг не снимает (стандартный реквизит не записывается как обычное поле).

Технический момент. Снять или установить пометку удаления необходимо методом объекта УстановитьПометкуУдаления() — это случай, когда корректным инструментом является invoke_1c (вызов экспортного/объектного метода), а не batch_1c:
invoke_1c → kind: object_method, method: "УстановитьПометкуУдаления", args: [false]
После этого документ корректно проводится. Разграничение ответственности инструментов: запись данных выполняется batch_1c, а вызов поведения объекта — invoke_1c.

4.4 Собрать правильные зачёты

После переразнесения проанализировали исходные остатки 62 по договорам и сформировали корректные «Корректировки долга» (вид «Зачёт задолженности») — каждая закрывает дебиторскую задолженность нужного контрагента соответствующим авансом:

Карина: свой аванс (14 700) + аванс физлица Алины (29 400) → долг Карины. Итог 0.
Алина: свой аванс на «не тот договор» (35 000) + личная карта (38 500) → её долг по основному договору.

Проводка зачёта: Дт 62.02 — Кт 62.01. Документы одиночные, проводятся без ошибок.

4.5 Перепроведение: параллельный режим привёл к блокировкам — выполнено поштучно

После удаления зачётов и переразнесения автозачёт авансов на 62 счёте «развернулся» (появились отрицательные авансы −43 980 и т. п.). Устраняется строго хронологическим перепроведением.

Технический момент — об ограничении и обходе. batch_1c исполняет пакет параллельно (mode: parallel, threads_used: 20). При перепроведении документов одного контрагента 20 потоков конкурируют за один и тот же регистр расчётов → Неустранимый конфликт блокировок, и порядок дат не соблюдается (а для FIFO-зачёта порядок критичен). Решение: перепроводить по одному документу в строгом порядке дат — единичный batch_1c на документ блокировок не вызывает (mode: sync), и каждый акт видит корректно проведённых предшественников. ~37 реализаций Алины перепроведены поштучно — артефакт устранён с −43 980 до 0 без единого конфликта.

Остаточное расхождение −3 045 выявлено точечно (запрос остатков 62.02 в разрезе документа-расчёта) и устранено перепроведением одного конкретного поступления.

4.6 Устойчивость к обрыву связи

Дважды в ходе операции коннектор к базе отвечал -32602 на любой запрос. Каждый проведённый документ уже зафиксирован в своей транзакции, поэтому потерь нет: после восстановления связи перепроведение продолжено с того документа, на котором произошёл обрыв. Длительная массовая правка переносит обрыв связи без отката.

4.7 Выгрузка результата клиенту

По итогам сформированы две Excel-сверки «оплаты по счетам» (по каждому ИП): дата счёта, сумма, дата оплаты, источник (карта ИП / личная карта), статус. Платежи с личной карты выделены, неоплаченный счёт — красным. Сформированы через Excel COM (PowerShell), сохранены в папку загрузок пользователя.

5. Инструменты

5.1 Использовали в этом кейсе

Инструмент	Что делали
`query_1c`	Поиск платежа по всей базе, сверка «номер счёта в назначении → чей счёт», начисления vs оплаты по каждому ИП, остатки 62 по контрагенту/договору/документу-расчёта, контрольные верификации после каждого шага
`metadata_1c`	Состав `Документ.ПоступлениеНаРасчетныйСчет` (табличная часть `РасшифровкаПлатежа`) и `Документ.КорректировкаДолга` перед массовой правкой и созданием зачётов
`batch_1c`	UPDATE 4 поступлений (переразнесение на Карину) + UNPOST/DELETE_MARK старых зачётов и дублей + CREATE 4 новых «Корректировок долга» + POST ~37 документов по одному при перепроведении
`invoke_1c`	`object_method` `УстановитьПометкуУдаления(Ложь)` — снять флаг, который не снимается через UPDATE

Локально, в связке с MCP:

PowerShell + Excel COM — формирование двух Excel-сверок для клиента в папку загрузок.

5.2 Что осталось за рамками — но есть в арсенале

Инструмент / компонент	Что даёт	Когда пригодился бы в похожей задаче
`run_task` / `task_status`	Длительные асинхронные задачи с поллингом	Хронологическое перепроведение сотен документов как фоновая задача — вместо поштучных вызовов вручную
`get_skill` / `skill_report`	Поиск и сохранение переиспользуемого скилла	Скилл «переразнести платежи физлица между ИП и пересобрать зачёты» применялся бы шаблонно и накапливался бы как актив
`invalidate_knowledge`	Сброс семантического кэша знаний агента	После создания/удаления договоров и контрагентов — чтобы агент перечитал актуальную карту расчётов
`get_run_history`	История операций агента в базе	Аудит «кто и когда переразнёс эти платежи»; отчёт клиенту
`web_search`	Поиск в интернете под токеном клиента	Если бы поведение типового зачёта по виду договора было неочевидно — для сверки с ИТС

Компонент продукта	Что даёт	Когда применим
`ai_ПанельАгента` (нативная BSL-панель)	Бухгалтер взаимодействует с агентом внутри 1С	Ольга запускает «проверь платёж / своди расчёты сестёр» непосредственно в своей программе, прикладывает скриншот квитанции — без переписки с разработчиком
Skill Server	Каталог переиспользуемых скиллов	«Разнесение оплат физлица за несколько ИП», «откат и пересборка взаимозачётов», «сверка оплат по источнику карты» — накапливаются как актив
Identity Server	Multi-tenant с per-client scope	Сервисная компания ведёт десятки ИП с одного контура, у каждого — изоляция прав на свою базу
Audit-trail runtime	Все вызовы инструментов — в журнал	На каждую правку поступления и каждый зачёт остаётся запись с привязкой к токену — это можно предоставить клиенту в спорной ситуации с расчётами

6. Результаты

Метрика	Значение
Контрагентов в разборе	3 (2 ИП + 1 физлицо-плательщик)
Платежей физлица разнесено корректно (личная карта)	13 на 67 900 ₽ (29 400 Карине / 38 500 Алине)
Платежей переразнесено с чужого ИП на свой	4 на 36 550 ₽
Услуги Карины сведены	80 650 → долг 0
Долг Алины после сведения	3 500 ₽ (реальный: 1 неоплаченный месяц + входящий остаток)
Прежних зачётов снято	4
Новых корректных зачётов создано	4
Документов перепроведено (поштучно, по датам)	~37
Конфликтов блокировок при поштучном перепроведении	0 (в параллельном режиме блокировки возникали)
Артефакт развёрнутого сальдо	−43 980 → 0
Обрывов связи пройдено без потери прогресса	2
Excel-сверок выдано клиенту	2 (по каждому ИП, с источником оплаты)
EPF загружено в боевую базу	0
Обращений к Конфигуратору	0

7. Что это даёт пользователю MCP `ai-agent-1c`

Проверка одного платежа → выявление системной ошибки. Вопрос об учёте платежа на 7 350 привёл к выявлению 36 550 ₽, разнесённых некорректно. query_1c по назначению платежа находит нужный документ за один запрос; далее связка «реализации vs оплаты по контрагенту» раскрывает полную картину расчётов.
Массовое переразнесение расчётов без внешних обработок. Перепривязка платежей к другому контрагенту, отмена и пересборка взаимозачётов, перепроведение расчётов — задача, традиционно требующая EPF, доступа администратора к боевой базе и Конфигуратора. Выполнена связкой query_1c → batch_1c → invoke_1c непосредственно из диалога: запрос → подтверждение человеком → правка → верификация.
Корректная работа с границами инструмента. В случае, когда batch_1c столкнулся с блокировками параллельного режима, выполнен переход на поштучное проведение с корректным результатом. В случае, когда UPDATE не снимает системный флаг, применён объектный метод через invoke_1c. Агент находит рабочий обход и проверяет результат запросом после каждого шага.
Результат, понятный клиенту. Не отчёт о сведении сальдо, а две Excel-таблицы: какой счёт, когда и с какой карты оплачен, какая сумма осталась к оплате. Это материал, который бухгалтер передаёт клиенту.

Особое значение имеют пункты 2 и 3: разовая массовая пересборка расчётов с контрагентами — частая трудоёмкая работа сервисной бухгалтерии, которая выполняется из чата, с верификацией на каждом шаге и устойчивостью к обрывам связи.

Приложения

A. Файлы кейса

Файл	Назначение
`Downloads/Сафина_Карина_сверка_оплат.xlsx`	Сверка оплат Карины: 10 счетов, все закрыты, источник по каждому
`Downloads/Сафина_Алина_сверка_оплат.xlsx`	Сверка оплат Алины: 33 счёта, источник + неоплаченный №50 (3 500)
`~/.claude/projects/.../memory/project_safina_two_cards.md`	Память агента: схема «сёстры оплачивают с двух карт, требуется периодическое переразнесение/зачёт»

B. Карта проблемы

   Алина платит со своей карты И с карты ИП — за свой ИП И за ИП сестры Карины
                                  │
                                  ▼
        Платежи сели вразнобой: 4 «карининых» — на ИП Алины (36 550),
        вся личная карта (67 900) — общей кучей на физлице
                                  │
                                  ▼
        Дебиторка по клиентам не сходится, хотя суммарно всё оплачено
                                  │
   ┌──────────────────────────────┼──────────────────────────────┐
   │                              │                              │
Переразноска платежей      Пересборка зачётов            Перепроведение
(batch_1c UPDATE           (снять 4 старых,              (поштучно по датам —
 РасшифровкаПлатежа)        создать 4 корректных)         параллель = блокировки)
   │                              │                              │
   ├─ 4 платежа → Карине          ├─ Карина: 0                   ├─ артефакт −43 980 → 0
   ├─ личная карта split          ├─ Физлицо: 0                  ├─ 0 конфликтов
   │   29 400 / 38 500            └─ Алина: реальный 3 500     └─ пережили 2 обрыва связи
   └─ ПометкаУдаления через                                          
       invoke_1c (object_method)                                     
                                  │
                                  ▼
                  2 Excel-сверки клиенту «счёт → дата → с какой карты»

← Все кейсы