Как мы построили решение

Архитектура проекта была понятна с самого начала.

Клиент создавал платежные поручения непосредственно в интернет-банке и пока не планировал переносить эту работу в 1С. Значит, сначала нужно было обеспечить регулярное получение банковских документов, а уже потом научить систему правильно их обрабатывать.

Для загрузки мы решили использовать DirectBank.

Конфигурация 1С:УНФ была актуальной и поддерживала эту технологию. Альфа-Банк тоже поддерживал прямой обмен через свой сервис AlfaLink, поэтому писать отдельную интеграцию не потребовалось.

Если бы DirectBank использовать не получилось, пришлось бы подключаться к API банка: разрабатывать обмен, настраивать авторизацию, разбирать ответы, учитывать ошибки и изменения со стороны банка. Для 300–400 операций в месяц такая работа была бы слишком дорогой для клиента.

После подключения документы начали автоматически поступать в УНФ несколько раз в течение рабочего дня. Исчезли файлы, ручная загрузка и действия, связанные с самим переносом данных.

Но DirectBank отвечал только за доставку документов. Основная задача начиналась после того, как платеж уже появился в 1С.

Что именно требовалось автоматизировать

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

Для каждого документа система должна была понять:

• какой вид операции выбрать;
• какую статью ДДС заполнить;
• к какому договору или заказу относится платеж;
• нужно ли закрыть задолженность или требуется отразить аванс;
• провести документ автоматически с верной аналитикой.

Человек выполняет эту работу привычно. Он читает назначение платежа, видит знакомые формулировки, учитывает контрагента и сумму, проверяет взаиморасчеты. Большая часть этих решений нигде подробно не записана.

Вот здесь и началась основная работа проекта.

Первые правила дали около 40%

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

После первой реализации автоматически стали корректно обрабатываться примерно 40% платежей.

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

Мы добавили следующую группу правил. Охват поднялся выше 60%.

Правила помогли разобраться со статьями ДДС

Когда мы начали формализовать сценарии, появились вопросы, на которые не всегда удавалось ответить сразу.

Почему две похожие операции разносились по разным статьям?

Нужна ли эта детализация именно для движения денежных средств?

Часть справочника ДДС пришлось переосмыслить. Где-то не было четкого понимания значения статьи, где-то существовала излишняя детализация, которая была нужна для бюджета доходов и расходов, но почти ничего не давала в рамках движения денег.

Это нормальная история. Пока учет ведет человек, отдельные противоречия могут годами оставаться незаметными: сотрудник знает, как поступить, и каждый раз принимает решение вручную. Как только мы пытаемся описать эту логику формально, все пограничные места сразу становятся видны.

В результате проект начал решать две задачи одновременно: автоматизировать разноску и приводить правила учета к понятному виду.

Анализ истории за год поднял охват выше 90%

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

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

После этой работы охват автоматической обработки вырос сразу выше 90%.

Попутно обнаружились ошибки в разнесении документов прошлых периодов. Несколько десятков документов были разнесены не совсем корректно: выбрана другая статья или оплата была связана с неподходящим основанием.

Дальше началась работа с исключениями и детальной разноской оплат

После очередной итерации потенциальный охват обработки платежных документов на основе правил превысил 97%.

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

Кроме того, оставалась и детализация поступающих оплат по заказам.

Все это можно было продолжать описывать кодом.

Для каждого случая — новое условие, дополнительная проверка. Но чем реже встречается операция, тем хуже экономика такой разработки. Программист тратит часы на правило, которое может сработать один раз за год или вообще больше не понадобиться.

Как мы использовали ИИ

Для подключения искусственного интеллекта мы использовали нашу подсистему ИИ-Коннектор. Она позволяет обращаться к Яндекс GPT или шлюзу RouterAI непосредственно из 1С:Предприятие.

Основную массу платежей продолжили обрабатывать обычные правила. Они понятны, легко проверяются и хорошо работают на повторяющихся операциях.

ИИ подключается только тогда, когда:

• надо разнести оплату от покупателя по документам;
• правила не дали результата.

У одного клиента может быть несколько договоров и заказов, при этом взаиморасчеты ведутся по документам. Нужно понять, какую задолженность закрывает платеж, остается ли часть суммы авансом и с каким основанием связать документ.

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

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

Какие данные передаются модели

Запросы к ИИ нужны для сравнительно небольшой доли операций, поэтому стоимость обработки остается низкой.

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

Без контекста 1С эти данные почти ничего не говорят о деятельности компании. Состав передаваемой информации при этом можно ограничивать в зависимости от требований клиента.

Кроме детализации оплат от покупателя по документам ИИ в этом проекте помог закрыть редкие и неоднозначные случаи. При желании систему можно использовать и без него: просто доля автоматической обработки будет ниже, а больше операций потребуется обработать руками или реализовывать частные сценарии кодом.

Даже в таком варианте эффект остается значимым. Стандартные правила после анализа истории (без учета детализации по заказам) покрывали более 90% операций.

Результат: выше 99%

Когда мы настраивали ИИ удалось получить еще одну закономерность для исходящих платежей. После реализации правила для ее обработки необработанными оставались около 40 платежных документов из примерно 4 600. Это меньше одного процента от общего количества платежных документов.

Часть редких операций мы сознательно оставили для ручной обработки. Если отдельный платеж встретился один раз за год, писать для него специальную логику нет особого смысла. Проще открыть документ и обработать его вручную.

Теперь выписка загружается автоматически, документы разбираются и проводятся, а на конец дня система проверяет, сошелся ли банк.

Если какая-то операция осталась без обработки, она не теряется. Ответственные сотрудники получают информацию о возникшем исключении и могут сразу разобраться с конкретным документом.

Что изменилось для компании

Раньше сотрудник ежедневно обрабатывал всю выписку. Теперь он контролирует результат и работает только с редкими исключениями.

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

Ошибки, связанные с человеческим фактором и ручным выбором аналитики, исчезли. А правила учета теперь закреплены внутри системы — их можно проверить, дополнить и передать любому сотруднику.

Что показал этот проект

Здесь не было одного инструмента, который решил все.

DirectBank обеспечил регулярную загрузку документов в 1С. Коннектор для подключения к ИИ дал возможность работать с искусственным интеллектом прямо из 1С. Модуль обработки банковских операций и стандартные правила закрыли подавляющее большинство платежных документов. Искусственный интеллект помог справиться с разбором назначения платежа и редкими случаями, для которых писать отдельный код было бы долго и дорого.

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

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

И вот это уже правильное распределение работы.