Как настроить автоматическое распознавание реквизитов при загрузке банковских выписок в 1С:УТ 11?

Программист 1С v8.3 (Управляемые формы) Управленческий учет IT и автоматизация бизнеса
← На главную

Проблема автоматизации загрузки банковских выписок в 1С:Управление торговлей 11 является одной из самых актуальных для бухгалтеров и финансовых специалистов. Часто возникает ситуация, когда после нажатия кнопки "Загрузить" система оставляет документы незаполненными: не определен контрагент, не выбрана хозяйственная операция или статья движения денежных средств (ДДС). Это приводит к необходимости ежедневного ручного разнесения сотен платежей, что сводит на нет смысл автоматизации обмена с банком.

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

Анализ штатного механизма распознавания платежей

Для начала проанализируем, как именно 1С пытается «угадать» реквизиты платежа. В конфигурации УТ 11 реализован многоступенчатый алгоритм поиска совпадений. Понимание этого процесса позволит нам правильно «обучать» систему.

  1. Идентификация по УИП: В первую очередь система ищет Уникальный Идентификатор Платежа. Если клиент указал его в назначении, и этот УИП ранее был сгенерирован в счете или заказе, программа однозначно определит объект расчетов и контрагента.
  2. Поиск по «образцу» (статистика): Если УИП отсутствует, включается механизм поиска аналогичных операций в прошлом. Система анализирует регистр сведений ПараметрыРаспознаванияПлатежей. Она ищет сочетание расчетного счета плательщика, получателя и ключевых слов в назначении платежа.
  3. Зеркальный поиск: Этот метод используется для выявления возвратов. Если система видит входящий платеж от контрагента, которому мы ранее платили ту же сумму (или наоборот), она автоматически предложит операцию «Возврат от поставщика» или «Возврат клиенту».
  4. Подбор по объектам расчетов: Программа пытается найти неоплаченные заказы или накладные по данному контрагенту, подходящие по сумме.

Проанализируем ситуацию, когда этот алгоритм дает сбой. Основная причина — отсутствие «истории» или изменение банковских реквизитов (например, у самого банка при списании комиссии). В таких случаях система просто не находит за что «зацепиться».

Особенности работы с услугами банка и эквайрингом

Рассмотрим подробнее наиболее проблемные участки: услуги банка и эквайринговые операции. Трудность с банковскими услугами заключается в том, что расчетный счет банка может меняться, а текст назначения платежа («Комиссия за расчетное обслуживание») остается статичным. Штатный механизм поиска по образцу часто привязывается именно к счету, поэтому при его изменении распознавание прекращается.

С эквайрингом ситуация еще сложнее. Сумма, поступающая на расчетный счет, обычно меньше суммы продажи на величину банковской комиссии. Рассмотрим пример: клиент оплатил 10 000 рублей, банк удержал 200 рублей комиссии и зачислил 9 800 рублей. Штатный поиск «копейка в копейку» не сработает.

Для решения проблемы с эквайрингом рекомендуется:

  1. Предварительно создавать документ ОтчетБанкаЭквайера.
  2. В форме загрузки выписки использовать кнопку «Подобрать», чтобы вручную сопоставить входящий платеж с отчетом и выделить комиссию. После этого система «запомнит» связь и в следующий раз вероятность автоматического сопоставления возрастет.

Технологическое решение: Доработка системы через кастомный регистр

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

Разберем структуру возможного регистра сведений НастройкиЗаполненияВыписки:

Измерения:

Ресурсы:

При загрузке выписки в модуле обработки необходимо добавить код, который будет производить поиск по этому регистру. Рассмотрим примерный алгоритм на языке 1С:


// Пример логики поиска по ключевым словам в назначении платежа
Функция ОпределитьРеквизитыПоНазначению(ТекстНазначения, ТекущийСчет) Экспорт
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |   Настройки.ВидОперации,
        |   Настройки.СтатьяДДС,
        |   Настройки.Контрагент
        |ИЗ
        |   РегистрСведений.НастройкиЗаполненияВыписки КАК Настройки
        |ГДЕ
        |   &Назначение ПОДОБНО ""%"" + Настройки.КлючевоеСлово + ""%""
        |   И Настройки.БанковскийСчет = &БанковскийСчет";
    
    Запрос.УстановитьПараметр("Назначение", ТекстНазначения);
    Запрос.УстановитьПараметр("БанковскийСчет", ТекущийСчет);
    
    Результат = Запрос.Выполнить();
    Если Не Результат.Пустой() Тогда
        Возврат Результат.Выбрать();
    КонецЕсли;
    
    Возврат Неопределено;
КонецФункции

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

Использование функционала «Правила заполнения реквизитов»

В более поздних версиях УТ 11.4 и 11.5 разработчики 1С услышали пользователей и добавили механизм «Правила заполнения реквизитов платежа». Выясним, как им воспользоваться:

Перейдем в раздел Казначейство — Настройки и справочники — Правила заполнения реквизитов. Здесь можно создать правило, указав, что если назначение платежа содержит текст «Оплата по договору лизинга», то система должна автоматически проставить вид операции «Оплата поставщику» и конкретную статью ДДС.

Важные шаги при настройке правил:

  1. Используйте максимально уникальные фразы из назначения платежа, чтобы избежать ложных срабатываний.
  2. Указывайте приоритет правил, если одно назначение может попасть под несколько условий.
  3. Проверяйте привязку к конкретной организации, если у вас ведется многофирменный учет.

Переход на DirectBank

Проанализируем еще один современный способ решения проблем с загрузкой — технологию DirectBank. В отличие от старого метода через текстовый файл kl_to_1c.txt, DirectBank работает через прямое API с сервером банка.

Почему это помогает в распознавании?

Рекомендации по «обучению» системы

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

  1. Очистка статистики: Если система начала подставлять неверные данные, это значит, что в регистре ПараметрыРаспознаванияПлатежей накопились ошибочные записи. Рекомендуется найти этот регистр через «Все функции» (Функции для технического специалиста) и удалить записи, содержащие неверные привязки.
  2. Ручное заполнение первого платежа: Когда вы загрузили новую выписку, максимально корректно заполните все реквизиты первого платежа от нового контрагента. Нажмите кнопку «Провести». Именно в этот момент система делает запись в регистр статистики.
  3. Работа с зарплатой: Для корректной идентификации зарплатных платежей всегда соблюдайте последовательность: Ведомость на выплату -> Выгрузка в банк -> Загрузка выписки. В этом случае система сопоставит платеж по внутреннему идентификатору ведомости.

Таким образом, мы выяснили, что хотя типовой функционал УТ 11.3 на первый взгляд кажется ограниченным по сравнению с предыдущими версиями, он обладает мощными механизмами адаптации. Сочетание правильной методики работы, настройки современных правил заполнения и, при необходимости, небольших доработок позволяет достичь 95-98% автоматического распознавания банковской выписки.

← На главную