Часто при работе со связкой конфигураций, например «1С:Управление торговлей 10» (УТ 10) и «1С:Бухгалтерия 3.0» (БП3), пользователи сталкиваются с неприятной ситуацией. Контрагенты и их договоры переносятся из УТ в БП3 посредством правил обмена. Однако при загрузке банковской выписки напрямую в БП3 (через файл Клиент-банка или DirectBank) система не подхватывает уже существующий перенесенный договор, а создает новый. В результате справочник обрастает дублями, единственное визуальное отличие которых — наименование. Давайте подробно разберем, по какому принципу программа ищет договоры, почему происходят задвоения и как мы можем решить эту проблему.
Многие ошибочно полагают, что система ищет договор исключительно по наименованию (например, «Основной договор») или только по галочке Использовать как основной. На самом деле алгоритм 1С использует куда более сложную и строгую многоступенчатую проверку. Рассмотрим по шагам, на что опирается программа при потоковой загрузке выписок.
Вид договора. В первую очередь 1С сопоставляет вид операции в строке загружаемой выписки и вид самого договора (С покупателем, С поставщиком, Прочее). Если из УТ 10 договор выгрузился с видом С покупателем, а платеж идентифицируется бухгалтерской программой так, что требует вид договора Прочее, система проигнорирует существующий элемент и автоматически создаст новый договор с нужным видом.Назначение платежа. Программа анализирует текстовое назначение платежа из банковского файла. Она ищет маркеры вроде «по дог. № ХХХ от ДД.ММ.ГГГГ». Если номер и дата найдены, система будет искать в базе договор с точным совпадением реквизитов Номер и Дата. Если при переносе из УТ 10 эти поля остались пустыми или заполнены с другими префиксами, 1С сочтет, что нужного договора нет.ИНН и КПП. Выясним причину дублирования контрагентов, которая тянет за собой дублирование договоров. Если клиент совершает оплату с КПП филиала, а в базе БП3 головной контрагент имеет другой КПП, система может посчитать плательщика новым обособленным подразделением. В результате создается новый контрагент и, естественно, новый договор для него.Использовать как основной. Вопреки ожиданиям, этот флаг в современных релизах БП3 используется в первую очередь для автоподстановки при ручном создании документов пользователем. В алгоритмах загрузки выписок он учитывается по остаточному принципу: только если система нашла несколько договоров, которые на 100% совпадают по виду, валюте и данным из назначения платежа.Теперь, когда мы понимаем логику работы загрузчика, проанализируем доступные варианты исправления ситуации.
Вариант 1. Настройка автосоздания элементов в обработке обмена с банком.
Самый простой пользовательский метод. Посмотрим на настройки формы «Обмен с банком». Там присутствуют системные опции, отвечающие за автоматическое создание недостающих элементов. Если мы отключим автосоздание новых контрагентов и договоров при загрузке, программа перестанет генерировать дубли. Ненайденное поле договора будет подсвечиваться красным цветом, и бухгалтер сможет выбрать правильный перенесенный договор вручную. При этом система часто выдает информационное сообщение, почему договор не подставился (например, несовпадение валюты или вида), что поможет выявить системную ошибку в учете.
Вариант 2. Загрузка выписок в базу-источник (УТ 10).
С точки зрения архитектуры обмена данными, хорошей практикой является ввод всех первичных оперативных документов в управленческой базе. Загружайте банковские выписки непосредственно в УТ 10. Там они корректно привяжутся к нужным заказам и договорам (так как поиск будет идти в родной среде), а затем готовые и проведенные документы поступления на расчетный счет и списания перенесутся в БП3 вместе с правильной аналитикой.
Вариант 3. Доработка логики поиска с помощью расширения.
Если процесс обмена выстроен так, что выписки должны грузиться именно в БП3, мы можем переопределить стандартный алгоритм поиска с помощью механизма расширений. Например, чтобы решить проблему с разными КПП одного клиента, можно написать код, который при загрузке будет искать контрагента только по ИНН, игнорируя КПП, или сопоставлять его с головным контрагентом.
Пример логики, которую можно реализовать в расширении для вмешательства в обработку загрузки (псевдокод):
&Вместо("НайтиИлиСоздатьДоговорКонтрагента")
Функция МодифицированныйПоискДоговора(Контрагент, Организация, ВидДоговора, ДанныеВыписки)
// Выполняем поиск по нашим правилам (например, игнорируя строгий вид или КПП)
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ ПЕРВЫЕ 1
| ДоговорыКонтрагентов.Ссылка КАК Договор
|ИЗ
| Справочник.ДоговорыКонтрагентов КАК ДоговорыКонтрагентов
|ГДЕ
| ДоговорыКонтрагентов.Владелец = &Контрагент
| И ДоговорыКонтрагентов.Организация = &Организация";
Запрос.УстановитьПараметр("Контрагент", Контрагент);
Запрос.УстановитьПараметр("Организация", Организация);
Результат = Запрос.Выполнить();
Если Не Результат.Пустой() Тогда
Выборка = Результат.Выбрать();
Выборка.Следующий();
Возврат Выборка.Договор;
КонецЕсли;
// Если ничего не найдено - вызываем стандартный метод автосоздания
Возврат ПродолжитьВызов(Контрагент, Организация, ВидДоговора, ДанныеВыписки);
КонецФункции
Вариант 4. Корректировка правил обмена.
Проанализируем выгрузку из УТ 10. Если в УТ договоры ведутся без номеров и дат (просто «Основной договор»), а в назначениях платежа от клиентов всегда приходят номера счетов или спецификаций, то БП3 никогда не найдет совпадений. Необходимо навести порядок в справочниках УТ 10: заполнить поля Номер и Дата договора, а также убедиться, что реквизит Вид договора корректно транслируется через правила конвертации в БП3.
Применяя описанные подходы комплексно, вы сможете избавиться от дублирования нормативно-справочной информации и сделать процесс разнесения банковской выписки прозрачным и контролируемым.