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

На копии двух предоставленных баз была отлажена процедура идентификации договоров из текста назначения платежа в документе «Поступление на расчетный счет».

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

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

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

Алгоритм на данном этапе работает следующим образом:

1. Поиск ключевых слов. Программа находит слова «договор» и «счёт» с учётом возможных сокращений.
2. Выделение дат и похожих на номера фрагментов. Из текста извлекаются даты и «словоподобные» элементы, которые могут быть номерами.
3. Обработка дат. Найденные даты в текстовом формате программа пытается преобразовать в тип «Дата».
4. Связка ключевых слов, дат и номеров. Алгоритм подбирает номера, расположенные рядом с ключевыми словами и датами.
5. Сопоставление с базой. Полученные варианты (номер и дата) сравниваются со справочником договоров данного контрагента.
6. Точное совпадение. Если договор найден однозначно (по номеру и дате), присваивается статус 1.
7. Нечёткое совпадение. При отсутствии точного совпадения выполняется сравнение по методу Джаро–Винклера. В этом случае устанавливается статус 1.9.
8. Поиск по счёту. Если в тексте найден номер счёта, программа ищет документ «Счёт на оплату покупателю» и берёт из него ссылку на договор (статус 1.0001).
9. Частичное совпадение. Если найден номер, хотя бы частично совпадающий с существующим, устанавливается статус >1.
10. Отсутствие результата. Если ни один из методов не дал результата, присваивается статус –1.

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

В форме документа добавлено поле-ссылка «Идентифицировать договор» с кратким результатом распознавания (статус и способ).

Если статус распознавания 1 или 1.1, ссылка отображается зеленым цветом. Если статус -1, то красным цветом, в других случаях - синим (подсказка пользователю, что нужно проверить корректность выбора договора).

Если пользователь подкорректирует назначение платежа, заметив ошибку или препятствие для идентификации номера и даты, и нажмет на ссылку «Идентифицировать договор», программа еще раз попытается идентифицировать и отобразит новый результат-статус.

Были проанализированы назначения платежей из 16184 документов поступления на расчетный счет (база №1) и 16700 (база №2), в первой базе не удалось распознать из назначений платежа 529 договоров (~4%), во второй - 790 (~5%). Таким образом, эффективность распознавания составила более 95%.

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