IDE + MCPАнализ расчётов
Разобрали развёрнутое сальдо на счёте 62 у ИП и свели расчёты с клиентом до нуля
Коротко
У клиента-ИП на абонентском обслуживании по одному договору одновременно числились и долг, и аванс на счёте 62: дебет 28 400 при кредите 22 500. Руководитель попросила разобраться, откуда взялся такой остаток, и проверить, нет ли задвоения документов. Агент сверил между собой реализации, счета и оплаты, нашёл причину расхождения и помог свести расчёты с клиентом в ноль. По итогу: начислено 68 800 равно оплачено 68 800, остаток нулевой.
Что требовалось
После ранее проведённой корректировки на счёте 62 по одному договору одновременно повисли долг и аванс — так называемое развёрнутое сальдо (дебет 28 400 и кредит 22 500). Ситуацию осложняло то, что клиент платил суммами, не совпадающими с суммами счетов, делал опечатки в назначении платежа, а один счёт оказался указан сразу в двух платежах. Нужно было понять природу остатка, убедиться в отсутствии задвоенных документов и привести расчёты в порядок.
Изначально агент посмотрел только реализации и сделал предварительный вывод о недоплате за апрель. Руководитель с этим не согласилась: по её данным спорные 5 900 — это недоплата за февраль, и проверять нужно не только реализации, а сопоставление реализаций, счетов и оплат вместе.
Как помог агент
Агент принял замечание и перестроил проверку: разложил рядом три потока документов — реализации, счета и оплаты — и сопоставил их по месяцам, привязывая каждую оплату к своему счёту по тексту назначения платежа («Оплата по счёту № …»).
Такая сверка показала: задвоенных документов нет — шесть реализаций соответствуют шести счетам, и помесячно всё сходится. Спорные 5 900 — это действительно недоплата за февраль: платёж пришёл на 5 900 вместо 11 800 по февральскому тарифу. Один и тот же номер счёта в двух платежах оказался не дублем в базе, а опечаткой клиента в назначении — на учёт это не повлияло.
Агент также установил причину самого развёрнутого сальдо: оплата за «закрытие года» пришла на день позже акта, аванса на тот момент не было, поэтому акт повис как долг, а пришедшая позже сумма закрыла более ранние периоды. Чтобы это устранить, агент аккуратно перепровёл документы договора строго по датам — и долг с авансом свернулись в чистый долг 5 900.
После этого выяснилась и причина самой недоплаты: договор был заключён в середине февраля, поэтому первый месяц неполный. Руководитель уменьшила реализацию февраля до половинного тарифа, и расчёты сошлись в ноль. Важно, что пока вывод оставался спорным, агент ничего в базе не менял — только смотрел данные, а правки начались уже после согласования.
Результат
- Задвоенных документов не обнаружено: шесть реализаций соответствуют шести счетам, помесячно всё сходится.
- Установлена настоящая причина долга — недоплата за февраль (а не за апрель), замечание руководителя подтвердилось.
- Развёрнутое сальдо (дебет 28 400 при кредите 22 500) свёрнуто перепроведением документов по датам.
- После применения половинного тарифа первого месяца расчёты с клиентом сведены в ноль: начислено 68 800 равно оплачено 68 800, остаток 0.
Вся работа выполнена прямо в рабочей базе — без программиста и без установки дополнительных обработок.
1. Контекст
Клиент - ИП на абонентском обслуживании, договор № 20260210 от 09.02.2026. За февраль-май: консультация, четыре месяца основного тарифа и «закрытие года». Шесть реализаций, шесть счетов, шесть оплат.
Проблема: после ранее проведённой корректировки данных на счёте 62 образовалось развёрнутое сальдо - долг и аванс одновременно на одном договоре. Требовалось установить природу остатка и свести расчёты.
Симптомы:
- 62.01 Дт 28 400 при 62.02 Кт 22 500 (нетто 5 900);
- платежи поступали суммами, не совпадающими с суммами счетов, и с опечатками в назначении;
- один счёт фигурировал в назначении сразу двух платежей.
2. Обращение заказчика
«Я не согласна, смотрю платежи: 5 900 - это оплата за февраль. Почему ты смотришь только реализации? Нужно смотреть дубли в сопоставлении реализаций и счетов, и затем оплат.»
Это - ключевой момент кейса. Первый вывод агента («недоплата апреля 5 900») арифметически давал ту же сумму, но неверно указывал период и причину. Поправка специалиста задала корректную методику анализа.
3. Исследование
3.1 Три потока рядом
Запрашиваем реализации, счета и оплаты - последние обязательно с назначением платежа, поскольку именно там указан номер счёта.
ВЫБРАТЬ Номер, Дата, СуммаДокумента, НазначениеПлатежа, Проведен
ИЗ Документ.ПоступлениеНаРасчетныйСчет
ГДЕ Контрагент = &К
УПОРЯДОЧИТЬ ПО Дата
Сопоставление по месяцам (привязка оплаты к счёту - по тексту «Оплата по счёту № N»):
| Период / услуга | Реализация | Счёт | Оплата (назначение) | Итог |
|---|---|---|---|---|
| Февраль, консультация | 5 000 | № 33 (5 000) | № 038 - 5 000 «по сч. 33» | закрыто |
| Февраль, тариф | 11 800 | № 39 (11 800) | № 034 - 5 900 «по сч. 39» | недоплата |
| Март, тариф | 11 800 | № 81 (11 800) | № 116 - 11 800 / № 077 - 11 800 | закрыто |
| Закрытие года | 22 500 | № 137 (22 500) | № 067 - 22 500 «по сч. 137» | закрыто |
| Апрель, тариф | 11 800 | № 122 (11 800) | (зачёт по FIFO) | закрыто |
| Май, тариф | 11 800 | № 162 (11 800) | № 157 - 11 800 «по сч. 162» | закрыто |
3.2 Что показала триада (а не одни реализации)
- Дублей нет. Шесть реализаций = шесть счетов = 74 700, помесячно все позиции уникальны и обоснованы.
- Долг 5 900 относится к февралю. Платёж № 034 от 10.02 поступил на 5 900 вместо 11 800 по февральскому тарифу (счёт № 39). Это и есть «5 900 за февраль», на которые указывала руководитель.
- Счёт № 39 фигурирует в двух платежах (№ 034 на 5 900 и № 116 на 11 800) - это не дубль счёта в базе, а опечатка клиента в назначении: платёж № 116 фактически закрывает следующий период. На учёт это не влияет, суммы счетов и реализаций совпадают.
Технический момент - привязка по назначению платежа. Анализа одних реализаций недостаточно: задвоение или недоплату можно выявить только на пересечении трёх потоков. Текст «Оплата по счёту № N» связывает поступление с конкретным счётом и периодом даже при несовпадении сумм.
3.3 Откуда развёрнутое сальдо
Оплата «закрытия года» (22 500) поступила 05.04 - на день позже самой реализации (03.04). Зачёт у реализации выполняется против более раннего аванса; аванса на тот момент не было, поэтому акт был отражён как долг, а поступившая позже сумма по FIFO закрыла другие, более ранние долги. Результат - долг и аванс одновременно. Устраняется перепроведением по датам.
4. Решения
4.1 Сворачивание развёрнутого сальдо
Распровести все 12 документов договора одним пакетом, затем провести по одному строго по хронологии.
[
{"action":"UNPOST","type":"Документ.РеализацияТоваровУслуг","ref":{"...":"175"}},
{"action":"UNPOST","type":"Документ.ПоступлениеНаРасчетныйСчет","ref":{"...":"038"}},
"… все 12 документов договора …"
]
Затем - 12 отдельных вызовов POST в порядке дат (акты и оплаты в хронологической последовательности). После этого развёрнутое сальдо свернулось в чистый долг 5 900 на 62.01, аванс 22 500 был устранён.
Технический момент - UNPOST пакетом, POST по одному. Распроведение допустимо выполнять одним пакетом, а проведение - поштучно: единичный вызов выполняется в режиме sync и не приводит к конфликту блокировок параллельного режима. Это обеспечивает корректный хронологический порядок FIFO-зачёта.
4.2 Поправка человека закрыла долг
Проверка подтвердила: долг 5 900 - это недоплата февральского тарифа. Причина частичной оплаты: договор заключён 09.02, февраль является неполным месяцем. Руководитель уменьшила реализацию февраля с 11 800 до 5 900 (половинный тариф первого месяца).
-- контроль после правки
ВЫБРАТЬ Счет.Код, СуммаОстатокДт, СуммаОстатокКт
ИЗ РегистрБухгалтерии.Хозрасчетный.Остатки(, , , Субконто1 = &К)
ГДЕ Счет.Код В ("62.01","62.02")
-- результат: пусто, долг 0
Начислено стало 68 800 = оплачено 68 800. Долг 0.
5. Инструменты
5.1 Использовали в этом кейсе
| Инструмент | Что делали |
|---|---|
query_1c |
Три потока документов, остаток 62.01+62.02, контроль после каждого шага |
batch_1c |
UNPOST 12 документов одним пакетом, POST по одному по датам |
5.2 Что осталось за рамками - но есть в арсенале
| Инструмент / компонент | Что даёт | Когда пригодился бы |
|---|---|---|
batch_1c UPDATE |
Правка суммы реализации | Если бы половинный тариф правил агент, а не человек |
Skill Server (get_skill) |
Переиспользуемый скилл «разбор 62 триадой» | Тот же разбор для следующего клиента в один вызов |
| Audit-trail runtime | Журнал вызовов | Подтверждение того, что изменений данных по спорному выводу не вносилось до согласования |
6. Результаты
| Метрика | Значение |
|---|---|
| Дубли | не найдены (6 = 6, помесячно сходится) |
| Природа долга | недоплата февраля, не апреля (поправка принята) |
| Развёрнутое сальдо 28 400 / 22 500 | свёрнуто перепроведением по датам |
| Итог после половинного тарифа | начислено 68 800 = оплачено 68 800, долг 0 |
| EPF в боевую базу / визитов в Конфигуратор | 0 / 0 |
7. Что это даёт пользователю MCP ai-agent-1c
- Принимает поправку и пересобирает методику. Первый вывод агента был ошибочным; после замечания специалиста агент перестроил анализ в триаду, а не оставил исходный вывод без изменений.
- Сопоставляет по смыслу, а не по сумме. Назначение платежа «по счёту № N» связывает оплату с периодом даже при несовпадающих суммах и опечатках клиента.
- Не изменяет данные по спорному выводу. Пока вывод оспаривался, изменений в базу не вносилось - выполнялось только чтение; запись началась после подтверждения.
Приложения
A. Объекты кейса
| Объект | Что с ним сделали |
|---|---|
| 12 документов договора № 20260210 | Распроведены пакетом и проведены по одному по датам |
| Платёж № 034 (5 900) | Идентифицирован как недоплата февраля |
| Реализация февраля (11 800 → 5 900) | Уменьшена руководителем до половинного тарифа |
| Остаток 62.01/62.02 | Сведён в ноль |
B. Карта проблемы
62.01 Дт 28 400 + 62.02 Кт 22 500 (нетто долг 5 900)
│
▼
первый вывод «недоплата апреля» ── поправка человека: «5 900 за февраль»
│
▼
триада реализация ↔ счёт ↔ оплата по «Оплата по счёту № N»
│
▼
дублей нет; долг = недоплата февральского тарифа (5 900)
│
▼
перепроведение по датам → чистый долг 5 900
│
▼
половинный тариф первого месяца (договор с 09.02) → долг 0 ✅