Проблема
В 1С:Управление нашей фирмой 3.0 есть стандартный справочник:
Соответствия назначений платежа и реквизитов платежа
Он позволяет определить реквизиты банковской операции по фразе, содержащейся в назначении платежа.
Например, можно создать правило:
Фраза для поиска:
Перечисление средств на счета согласно реестру
Вид операции расхода со счета:
Прочий расход
Статья ДДС:
Оплата труда
Корреспонденция:
Расчеты с персоналом по оплате труда
В банковской выписке при этом приходит назначение:
Перечисление средств на счета согласно реестру № 0000165z_0001119368
от 01102026 согласно Договору № ЗП-2025-1072/ПЗП18135
Фраза содержится в назначении полностью.
Логично ожидать, что при загрузке выписки УНФ применит созданное пользователем правило и сохранит указанные в нем реквизиты.
Однако на практике можно получить другой результат.
Например, в соответствии указано:
Вид операции = Прочий расход
а в обработке «Обмен с банком» после распознавания отображается:
Вид операции = Поставщику
Первое подозрение в такой ситуации обычно падает на поиск по назначению платежа.
Возникает ощущение, что справочник соответствий либо не используется, либо фраза по какой-то причине не находится.
Но причина находится дальше по типовой логике.
Соответствие действительно находится
Основная логика загрузки банковской выписки находится в общем модуле:
ЗагрузкаВыпискиПоБанковскомуСчету
При обработке строки выписки УНФ вызывает механизм получения данных из справочника соответствий.
Поиск фразы выполняется по назначению платежа.
Упрощенно условие выглядит следующим образом:
Если СтрНайти(
ВРег(СтрокаДокумента.НазначениеПлатежа),
ВРег(Выборка.Фраза)) > 0 Тогда
// Соответствие найдено.
КонецЕсли;
То есть соответствие действительно обнаруживается.
На этом этапе типовая конфигурация получает структуру с реквизитами найденного правила и использует ее при заполнении строки банковской выписки.
Проблема заключается в том, что распознавание на этом не заканчивается.
Откуда появляется другое значение
После обработки соответствия УНФ продолжает определять реквизиты банковского документа.
В частности, программа пытается найти платежное поручение.
Если платежное поручение найдено, его данные также участвуют в определении реквизитов загружаемого документа.
Например, соответствие определило:
Прочий расход
но найденное платежное поручение имеет операцию оплаты.
В результате позднее типовая логика может установить:
Поставщику
То есть справочник соответствий отработал правильно, но его результат был изменен следующим этапом распознавания.
Если подходящего платежного поручения нет, может использоваться анализ истории заполнения.
УНФ анализирует ранее обработанные операции по контрагенту и на основании прошлых данных пытается определить подходящие реквизиты.
Сам по себе этот механизм полезен.
Если организация постоянно оплачивает одному поставщику одни и те же услуги, программа может автоматически определить вид операции и другие значения без дополнительной настройки.
Но при наличии явно созданного пользователем правила получается спорная последовательность приоритетов.
Пользователь явно говорит программе:
Если назначение содержит конкретную фразу,
использовать конкретные реквизиты.
После чего автоматический механизм может решить:
По истории обычно было иначе,
поэтому поставим другое значение.
Для данной задачи такая логика неудобна.
Какой приоритет требуется
Нужен следующий принцип:
Если реквизит явно заполнен в найденном соответствии,
он должен иметь приоритет.
Если реквизит в соответствии не заполнен,
УНФ должна продолжить определять его штатными механизмами.
Это важный момент.
Не нужно полностью отключать:
поиск платежного поручения;
анализ истории;
заполнение договора;
автоматическое определение остальных данных.
Нужно только не позволять автоматике заменить те значения, которые пользователь уже явно задал в справочнике соответствий.
Например, если в соответствии заполнено:
Вид операции
Статья ДДС
Корреспонденция
именно эти значения должны сохраниться.
Но если:
Проект
не указан, программа по-прежнему может определить его типовым алгоритмом.
Таким образом расширение не заменяет стандартное распознавание, а только вводит понятный приоритет.
Почему не стоит заимствовать основную процедуру
Первый вариант решения был очевидным: изменить основную процедуру распознавания строки банковской выписки и добавить проверки непосредственно туда.
Такой вариант работает, но имеет существенный недостаток.
Процедура большая и содержит значительный объем типовой логики.
Если полностью переносить ее в расширение через:
&ИзменениеИКонтроль
то расширение становится значительно чувствительнее к обновлениям конфигурации.
При обновлении УНФ потребуется проверять:
не изменилась ли типовая процедура;
не добавились ли новые параметры;
не изменилась ли последовательность заполнения;
не появились ли дополнительные условия;
не требуется ли перенос новых изменений в расширение.
Для задачи, которая фактически сводится к изменению приоритета нескольких реквизитов, это слишком тяжелое решение.
Поэтому основную процедуру вообще не будем копировать.
Вместо этого используем три небольших перехвата в конкретных точках типового алгоритма.
Первый перехват: найденное платежное поручение
Первое место, которое требуется контролировать:
ОпределитьПлатежноеПоручение
Здесь удобно использовать:
&Вместо
но не заменять типовой алгоритм собственной реализацией.
Сначала вызываем:
ПродолжитьВызов()
То есть штатная функция УНФ полностью выполняется.
Она ищет платежное поручение и возвращает стандартный результат.
После этого проверяем найденное соответствие.
Если в нем явно заполнен вид операции, запрещаем платежному поручению заменить это значение.
Код:
&Вместо("ОпределитьПлатежноеПоручение")
Функция РПП_ОпределитьПлатежноеПоручение(СтрокаДокумента)
Результат = ПродолжитьВызов(СтрокаДокумента);
СтруктураСоответствия = РПП_ПолучитьДанныеИзСоответствия(СтрокаДокумента);
Если СтруктураСоответствия = Неопределено Тогда
Возврат Результат;
КонецЕсли;
Если СтрокаДокумента.Исходящий Тогда
Если ЗначениеЗаполнено(
СтруктураСоответствия.ВидОперацииРасходаСоСчета) Тогда
Результат.ВидОперацииПП = Неопределено;
КонецЕсли;
Иначе
Если ЗначениеЗаполнено(
СтруктураСоответствия.ВидОперацииПоступленияНаСчет) Тогда
Результат.ВидОперацииПП = Неопределено;
КонецЕсли;
КонецЕсли;
Возврат Результат;
КонецФункции
Здесь важно, что само платежное поручение не отменяется.
Мы не мешаем УНФ его найти.
Не сбрасываем документ.
Не отключаем дальнейшую стандартную обработку.
Не запрещаем использовать другие полезные данные из ПП.
Если соответствие не найдено, возвращается исходный типовой результат вообще без изменений.
Если соответствие найдено, но нужный вид операции в нем не заполнен, также ничего не меняется.
Вмешательство происходит только в одном случае:
Пользователь явно указал вид операции в соответствии.
Второй перехват: анализ истории
Следующая точка находится в процедуре:
ВыполнитьАнализИсторииНаСервере
Здесь используется другой подход:
&После
Сначала типовая процедура полностью выполняется.
История может определить необходимые данные.
Но после ее выполнения мы еще раз проверяем явное соответствие.
Если вид операции в нем заполнен, возвращаем значение из соответствия.
&После("ВыполнитьАнализИсторииНаСервере")
Процедура РПП_ВыполнитьАнализИсторииНаСервере(
ДанныеСтроки,
Объект,
ДоговорВЗаказеСчете,
ПараметрыВыделенияКолонок)
СтруктураСоответствия =
РПП_ПолучитьДанныеИзСоответствия(ДанныеСтроки);
Если СтруктураСоответствия = Неопределено Тогда
Возврат;
КонецЕсли;
Если ДанныеСтроки.Исходящий Тогда
Если ЗначениеЗаполнено(
СтруктураСоответствия.ВидОперацииРасходаСоСчета) Тогда
ДанныеСтроки.ВидОперации =
СтруктураСоответствия.ВидОперацииРасходаСоСчета;
КонецЕсли;
Иначе
Если ЗначениеЗаполнено(
СтруктураСоответствия.ВидОперацииПоступленияНаСчет) Тогда
ДанныеСтроки.ВидОперации =
СтруктураСоответствия.ВидОперацииПоступленияНаСчет;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
История при этом не отключается.
Это принципиально.
Она может продолжить использоваться для определения других данных.
Мы лишь не позволяем ей окончательно заменить явно указанный пользователем вид операции.
Третий перехват: остальные реквизиты соответствия
После проверки только вида операции выяснился следующий нюанс.
Если пользователь создает явное соответствие, логично ожидать приоритета не только для операции, но и для остальных заполненных в нем реквизитов.
В справочнике могут быть указаны:
Статья ДДС
Корреспонденция
Проект
Подразделение
Эквайринговый терминал
Поэтому нужен дополнительный финальный контроль.
Для этого удобно использовать типовую процедуру:
ЗаполнитьПодразделение
и расширить ее через:
&После
К этому моменту штатное заполнение реквизитов уже выполнено.
После стандартного вызова достаточно вернуть из соответствия только те значения, которые пользователь действительно указал.
&После("ЗаполнитьПодразделение")
Процедура РПП_ЗаполнитьПодразделение(
СтрокаДокумента,
Документ,
СтруктураЗначенийИзСоответствия)
Если НЕ СтруктураЗначенийИзСоответствия.СоответствиеНайдено Тогда
Возврат;
КонецЕсли;
Если ЗначениеЗаполнено(
СтруктураЗначенийИзСоответствия.СтатьяДДС) Тогда
СтрокаДокумента.СтатьяДДС =
СтруктураЗначенийИзСоответствия.СтатьяДДС;
КонецЕсли;
Если ЗначениеЗаполнено(
СтруктураЗначенийИзСоответствия.Корреспонденция) Тогда
СтрокаДокумента.Корреспонденция =
СтруктураЗначенийИзСоответствия.Корреспонденция;
КонецЕсли;
Если ЗначениеЗаполнено(
СтруктураЗначенийИзСоответствия.Проект) Тогда
СтрокаДокумента.Проект =
СтруктураЗначенийИзСоответствия.Проект;
КонецЕсли;
Если ЗначениеЗаполнено(
СтруктураЗначенийИзСоответствия.Подразделение) Тогда
СтрокаДокумента.Подразделение =
СтруктураЗначенийИзСоответствия.Подразделение;
КонецЕсли;
Если ЗначениеЗаполнено(
СтруктураЗначенийИзСоответствия.ЭквайринговыйТерминал) Тогда
СтрокаДокумента.ЭквайринговыйТерминал =
СтруктураЗначенийИзСоответствия.ЭквайринговыйТерминал;
КонецЕсли;
КонецПроцедуры
Здесь особенно важно условие:
ЗначениеЗаполнено()
Мы не переносим пустые значения из соответствия.
Например, если подразделение в правиле не указано, расширение не устанавливает пустое подразделение поверх результата типовой конфигурации.
Если проект не указан, проект остается таким, каким его определила УНФ.
Если статья ДДС указана явно, именно она становится итоговой.
Таким образом правило работает не как полная замена автоматического заполнения, а как набор явных приоритетов.
Получение данных соответствия
Чтобы не дублировать поиск соответствия в нескольких местах, используется одна небольшая вспомогательная функция:
Функция РПП_ПолучитьДанныеИзСоответствия(СтрокаДокумента)
СтруктураСоответствия =
ПолучитьДанныеИзСоответствияНазначенияПлатежа(
СтрокаДокумента,
ЕстьЗаписиВСправочникеСоответствий());
Если НЕ СтруктураСоответствия.СоответствиеНайдено Тогда
Возврат Неопределено;
КонецЕсли;
Возврат СтруктураСоответствия;
КонецФункции
Здесь используется штатная функция УНФ.
То есть собственный механизм поиска фразы создавать не требуется.
Мы используем уже найденное типовой конфигурацией соответствие и меняем только дальнейший приоритет его данных.
Полный код расширения
В результате весь модуль расширения остается небольшим:
&Вместо("ОпределитьПлатежноеПоручение")
Функция РПП_ОпределитьПлатежноеПоручение(СтрокаДокумента)
Результат = ПродолжитьВызов(СтрокаДокумента);
СтруктураСоответствия = РПП_ПолучитьДанныеИзСоответствия(СтрокаДокумента);
Если СтруктураСоответствия = Неопределено Тогда
Возврат Результат;
КонецЕсли;
Если СтрокаДокумента.Исходящий Тогда
Если ЗначениеЗаполнено(СтруктураСоответствия.ВидОперацииРасходаСоСчета) Тогда
Результат.ВидОперацииПП = Неопределено;
КонецЕсли;
Иначе
Если ЗначениеЗаполнено(СтруктураСоответствия.ВидОперацииПоступленияНаСчет) Тогда
Результат.ВидОперацииПП = Неопределено;
КонецЕсли;
КонецЕсли;
Возврат Результат;
КонецФункции
&После("ВыполнитьАнализИсторииНаСервере")
Процедура РПП_ВыполнитьАнализИсторииНаСервере(
ДанныеСтроки,
Объект,
ДоговорВЗаказеСчете,
ПараметрыВыделенияКолонок)
СтруктураСоответствия = РПП_ПолучитьДанныеИзСоответствия(ДанныеСтроки);
Если СтруктураСоответствия = Неопределено Тогда
Возврат;
КонецЕсли;
Если ДанныеСтроки.Исходящий Тогда
Если ЗначениеЗаполнено(СтруктураСоответствия.ВидОперацииРасходаСоСчета) Тогда
ДанныеСтроки.ВидОперации =
СтруктураСоответствия.ВидОперацииРасходаСоСчета;
КонецЕсли;
Иначе
Если ЗначениеЗаполнено(СтруктураСоответствия.ВидОперацииПоступленияНаСчет) Тогда
ДанныеСтроки.ВидОперации =
СтруктураСоответствия.ВидОперацииПоступленияНаСчет;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
&После("ЗаполнитьПодразделение")
Процедура РПП_ЗаполнитьПодразделение(
СтрокаДокумента,
Документ,
СтруктураЗначенийИзСоответствия)
Если НЕ СтруктураЗначенийИзСоответствия.СоответствиеНайдено Тогда
Возврат;
КонецЕсли;
Если ЗначениеЗаполнено(СтруктураЗначенийИзСоответствия.СтатьяДДС) Тогда
СтрокаДокумента.СтатьяДДС =
СтруктураЗначенийИзСоответствия.СтатьяДДС;
КонецЕсли;
Если ЗначениеЗаполнено(СтруктураЗначенийИзСоответствия.Корреспонденция) Тогда
СтрокаДокумента.Корреспонденция =
СтруктураЗначенийИзСоответствия.Корреспонденция;
КонецЕсли;
Если ЗначениеЗаполнено(СтруктураЗначенийИзСоответствия.Проект) Тогда
СтрокаДокумента.Проект =
СтруктураЗначенийИзСоответствия.Проект;
КонецЕсли;
Если ЗначениеЗаполнено(СтруктураЗначенийИзСоответствия.Подразделение) Тогда
СтрокаДокумента.Подразделение =
СтруктураЗначенийИзСоответствия.Подразделение;
КонецЕсли;
Если ЗначениеЗаполнено(СтруктураЗначенийИзСоответствия.ЭквайринговыйТерминал) Тогда
СтрокаДокумента.ЭквайринговыйТерминал =
СтруктураЗначенийИзСоответствия.ЭквайринговыйТерминал;
КонецЕсли;
КонецПроцедуры
Функция РПП_ПолучитьДанныеИзСоответствия(СтрокаДокумента)
СтруктураСоответствия =
ПолучитьДанныеИзСоответствияНазначенияПлатежа(
СтрокаДокумента,
ЕстьЗаписиВСправочникеСоответствий());
Если НЕ СтруктураСоответствия.СоответствиеНайдено Тогда
Возврат Неопределено;
КонецЕсли;
Возврат СтруктураСоответствия;
КонецФункции
Что получилось
Основная процедура распознавания банковской строки в расширение не переносится вообще.
Нет:
&ИзменениеИКонтроль
для большой типовой процедуры.
Нет ее копии.
Нет собственного алгоритма поиска соответствий.
Расширение использует стандартные механизмы УНФ и вмешивается только в конкретные точки, где требуется сохранить приоритет пользовательской настройки.
Итоговый алгоритм можно описать так:
Назначение платежа
Найдено явное соответствие
Заполненные в нем реквизиты получают приоритет
Платежное поручение и история продолжают работать
Незаполненные реквизиты определяются типовым механизмом
Таким образом пользователь может определить в правиле только то, что действительно необходимо зафиксировать.
Например:
Вид операции = Прочий расход
Статья ДДС = Оплата труда
Корреспонденция = Расчеты с персоналом по оплате труда
Проект = не заполнен
Подразделение = не заполнено
В таком случае первые три значения будут защищены от последующего автоматического распознавания.
Проект и подразделение УНФ сможет определить самостоятельно.
Как проверить
Проверка выполняется непосредственно в обработке:
Обмен с банком
Не обязательно создавать банковские документы.
Для тестирования можно временно установить в соответствии хорошо заметные значения.
Например:
другой вид операции;
другую статью ДДС;
тестовый проект;
тестовое подразделение.
После этого повторно выполнить:
Обновить из выписки
Уже в таблице обработки должны отображаться реквизиты из найденного соответствия.
Отдельно следует учитывать направление движения.
Для исходящего платежа используется:
ВидОперацииРасходаСоСчета
для входящего:
ВидОперацииПоступленияНаСчет
Поэтому изменение вида операции поступления никак не повлияет на строку со списанием денежных средств.
Итог
Проблема заключается не в поиске фразы назначения платежа.
УНФ корректно находит созданное пользователем соответствие.
Но дальнейшая типовая логика продолжает распознавание банковской операции и может изменить уже определенные значения на основании платежного поручения или истории.
Если справочник соответствий используется именно как инструмент явной настройки, логичнее установить следующий принцип:
явно заполнено пользователем в соответствии
имеет приоритет
не заполнено в соответствии
определяется стандартной автоматикой УНФ
Для реализации этого поведения не требуется копировать основную процедуру загрузки банковской выписки.
Достаточно трех небольших перехватов:
ОпределитьПлатежноеПоручение
ВыполнитьАнализИсторииНаСервере
ЗаполнитьПодразделение
Первый не позволяет платежному поручению заменить явно заданный вид операции.
Второй возвращает явный вид операции после анализа истории.
Третий финально сохраняет остальные заполненные реквизиты соответствия:
Статья ДДС
Корреспонденция
Проект
Подразделение
Эквайринговый терминал
При этом пустые поля соответствия ничего не очищают и не мешают штатному автоматическому заполнению.
В результате получается небольшое и достаточно устойчивое к обновлениям расширение, которое не дублирует большую типовую процедуру, а только меняет приоритет уже существующих механизмов УНФ.
Вступайте в нашу телеграмм-группу Инфостарт