При работе с системой 1С:Управление торговлей (релиз 11.4.2.139 и аналогичные) пользователи часто сталкиваются с неприятной ситуацией: при повторной загрузке одного и того же файла выписки из системы «Клиент-банк» программа не «узнает» ранее созданные документы и создает их дубли. Это приводит к задвоению оборотов по банку, неверному сальдо и необходимости ручной очистки базы данных.
В этой статье мы подробно разберем, почему стандартная обработка ведет себя подобным образом, проанализируем программный код, отвечающий за поиск документов, и рассмотрим варианты решения проблемы — от административных настроек до внесения исправлений в конфигурацию.
Для начала проанализируем ситуацию и выясним, почему система не видит уже загруженные документы. Основная логика сопоставления данных из файла с данными в базе 1С заложена в алгоритмах поиска по ключевым полям. Основными причинами сбоя являются:
00:00:00 или текущее время загрузки. Если при повторном поиске система использует строгие границы периода (например, начало и конец дня), а время документа из-за часовых поясов сервера или специфики кода оказывается за пределами выборки, документ не будет найден..txt является устаревшим и не содержит уникального GUID операции, который присваивается банком. Система вынуждена полагаться на реквизиты, которые могут быть изменены пользователем вручную.Рассмотрим подробнее программную часть. За сопоставление загружаемых данных с документами в информационной базе отвечает обработка КлиентБанк. Нам необходимо изучить модуль менеджера этой обработки, а именно процедуру ЗаполнитьСсылкиНаДокументы(ДокументыКЗагрузке, ТаблицаДокументов, БанковскийСчет).
В этой процедуре происходит сопоставление таблицы ДокументыКЗагрузке (сформированной из файла) и ТаблицаДокументов (выборка из базы данных). Проанализируем типичную логику поиска в проблемных релизах:
// Фрагмент типичного алгоритма поиска
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ПоступлениеБезналичныхДенежныхСредств.Ссылка КАК Ссылка,
| ПоступлениеБезналичныхДенежныхСредств.Номер КАК Номер,
| ПоступлениеБезналичныхДенежныхСредств.Дата КАК Дата
|ИЗ
| Документ.ПоступлениеБезналичныхДенежныхСредств КАК ПоступлениеБезналичныхДенежныхСредств
|ГДЕ
| ПоступлениеБезналичныхДенежныхСредств.БанковскийСчет = &БанковскийСчет
| И ПоступлениеБезналичныхДенежныхСредств.Дата МЕЖДУ &НачалоПериода И &КонецПериода";
Если в данном запросе или в последующем цикле обхода таблицы не учитывается нормализация номера через функцию ПрефиксацияОбъектовКлиентСервер.НомерНаПечать, то поиск по номеру будет работать некорректно. Также важно проверить, не игнорирует ли поиск непроведенные документы или документы, помеченные на удаление.
Прежде чем приступать к программированию, рассмотрим наиболее современный и штатный способ решения проблемы — использование DirectBank. Это технология прямого обмена с банком без выгрузки промежуточных файлов.
Преимущества DirectBank:
Для настройки перейдите в карточку банковского счета, на закладку «Настройки обмена» и проверьте возможность подключения прямого обмена с вашим банком.
Если переход на DirectBank невозможен, проанализируем, как можно доработать процедуру ЗаполнитьСсылкиНаДокументы. Нам нужно гарантировать, что поиск документа будет «прощать» различия в лидирующих нулях и незначительные отклонения во времени.
Шаг 1. Нормализация номеров. Добавим функцию, которая удаляет префиксы и лидирующие нули перед сравнением. Рассмотрим пример кода:
Функция ПолучитьЧистыйНомер(Знач Номер) Экспорт
// Удаляем префиксы и лидирующие нули
Пока Лев(Номер, 1) = "0" Цикл
Номер = Сред(Номер, 2);
КонецЦикла;
Возврат Номер;
КонецФункции
Шаг 2. Расширение интервала поиска. Если банк в разных выписках указывает разную дату (например, дата операции и дата проведения по счету могут отличаться на день), следует расширить границы поиска в запросе:
ГраницаНачала = НачалоДня(Объект.Дата) - 86400; // Минус один день
ГраницаКонца = КонецДня(Объект.Дата) + 86400; // Плюс один день
Запрос.УстановитьПараметр("НачалоПериода", ГраницаНачала);
Запрос.УстановитьПараметр("КонецПериода", ГраницаКонца);
Шаг 3. Добавление проверки на проведенность. Иногда полезно проверять наличие документа в базе без привязки к его статусу. Если документ уже создан, но еще не проведен, система должна его найти и подставить ссылку, а не создавать новый. Убедитесь, что в условиях ГДЕ запроса нет жесткой фильтрации Проведен = ИСТИНА, если ваша бизнес-логика допускает наличие черновиков.
Иногда проблема кроется в несоответствии версий формата обмена. В настройках обмена с банком можно выбрать версию формата (например, 1.02 или 1.03). Выясним, как это влияет на результат:
В разных версиях формата поля могут называться иначе или передаваться с разной точностью. Попробуйте сменить версию формата в настройках банковского счета и выполнить тестовую загрузку на копии базы. В некоторых случаях это корректирует алгоритм чтения номеров документов «из коробки».
Подводя итог нашему анализу, можно выделить следующие рекомендации для борьбы с дублями в УТ 11.4:
ЗаполнитьСсылкиНаДокументы. Основное внимание уделите сопоставлению номеров без учета нулей и расширению временного диапазона поиска документов в информационной базе.Таким образом, мы выяснили, что проблема дублирования в 11.4.2.139 чаще всего носит программный характер и связана с несовершенством алгоритмов сопоставления. Использование предложенных методов позволит вам добиться корректной работы системы и избежать рутинной работы по удалению лишних документов.