При организации двустороннего обмена данными между конфигурациями 1С (например, между «Управление производственным предприятием» и «Управление торговлей 10.3» или «Розницей») технические специалисты часто сталкиваются с неприятной ситуацией. В процессе обмена номера документов в одной из баз начинают самопроизвольно меняться, а при обратной выгрузке эти же документы загружаются повторно, создавая дубликаты. В результате учетная система засоряется «мусорными» записями с разными номерами, но абсолютно одинаковым содержанием.
В этой статье мы подробно разберем, почему возникает эта классическая проблема, изучим ее внутренние механизмы и пошагово исправим правила обмена в конфигурации «Конвертация данных 2» (КД 2), а также скорректируем поведение планов обмена на стороне платформ 1С.
Когда документ переносится из базы-источника в базу-приемник, его номер может измениться. Рассмотрим основные факторы, которые к этому приводят:
Номер отключена передача значения. В таком случае система игнорирует исходный номер и генерирует новый по порядку в соответствии с текущей нумерацией базы-приемника.УстановитьНовыйНомер() или принудительная очистка поля номера, то при записи объект обязательно получит новый номер.Само по себе изменение номера в розничной или торговой базе — это лишь половина проблемы. Настоящая беда начинается, когда этот измененный документ отправляется обратно в центральную базу (УПП) и создает там дубликат. Проанализируем, почему так происходит:
1. Поиск объекта по «Полям поиска» вместо GUID (УИД)
Если в настройках ПКО выключен поиск по уникальному идентификатору (GUID), система сопоставляет объекты по ключевым полям поиска. Обычно для документов это связка Дата + Номер (иногда + Организация). Схема сбоя выглядит следующим образом:
0000-0001.УТ-00005.УТ-00005 за указанную дату.0000-0001, поиск не дает результатов. Система считает этот документ абсолютно новым и создает дубликат с номером УТ-00005. В базе УПП появляются два одинаковых документа.2. Эффект «эха» и принудительная регистрация изменений
Даже если в правилах обмена прописано, что из подчиненного узла (магазина) должны выгружаться только «Заказы поставщикам», документы поступления все равно могут возвращаться обратно. Это происходит из-за записи объектов при загрузке без блокировки регистрации. На уровне платформы запись должна сопровождаться установкой признака ОбменДанными.Загрузка = Истина. Если в конфигурации-приемнике созданы некорректные подписки на события, они могут проигнорировать этот флаг и зарегистрировать загруженный документ на отправку обратно в источник.
3. Избыточная выгрузка связанных объектов по ссылке
В «Конвертации данных 2» правила конвертации свойств по умолчанию выгружают объект полностью, если он указан в качестве реквизита другого выгружаемого объекта (например, документ «Поступление» указан как документ-основание в «Заказе поставщику»). Если для этого свойства не настроен специальный режим, то вместе с разрешенным «Заказом» в файл обмена запишется и все «Поступление», которое затем применится в базе-источнике.
Для ликвидации проблемы изменения номеров и задвоения документов нам потребуется скорректировать правила конвертации в программе «Конвертация данных 2» и проверить некоторые подписки на события в конфигураторе.
Это самый надежный способ предотвратить дублирование информации, независимо от того, как меняются номера документов в различных базах.
ПоступлениеТоваровУслуг).Теперь, даже если номер документа в магазине изменится до неузнаваемости, при обратной выгрузке 1С сопоставит его по скрытому уникальному GUID и просто обновит существующий документ в УПП вместо создания нового.
Проанализируем, как передается сам номер документа, чтобы исключить его нежелательное изменение:
Номер.Чтобы документы, загруженные из центрального офиса, не регистрировались автоматически на обратную выгрузку в розничной базе, необходимо проверить программный код подписок на события. Откройте конфигуратор базы-приемника и найдите общие подписки, отвечающие за регистрацию изменений на узлах планов обмена (например, при записи документов). В начале процедур-обработчиков обязательно должно присутствовать следующее условие:
Если Источник.ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
Этот простой фрагмент кода гарантирует, что если документ записывается в процессе импорта данных (когда платформа автоматически устанавливает свойство Загрузка = Истина), никакие механизмы регистрации изменений для обмена затрагиваться не будут.
Выясним причину, по которой документ «Поступление» выгружается вместе с «Заказом поставщику», несмотря на запреты. Для этого ограничим выгрузку связанных объектов:
ЗаказПоставщику.ДокументОснование или аналогичный), который ссылается на документ ПоступлениеТоваровУслуг.При такой настройке система передаст в файле обмена только уникальный идентификатор и базовые реквизиты ссылки на Поступление, но не будет полностью выгружать весь документ со всеми его табличными частями и движениями, предотвращая его несанкционированное создание или обновление в базе-приемнике.
После сохранения и загрузки новых правил обмена в рабочие базы необходимо вручную навести порядок в текущих очередях отправки:
ДокументСсылка.ПоступлениеТоваровУслуг.Подведем итоги. Мы проанализировали сложную архитектурную проблему двустороннего обмена 1С, выявили уязвимые места в правилах сопоставления документов и пошагово исправили их. Настройка поиска по GUID в связке с ограничением выгрузки по ссылкам и контролем регистрации изменений позволит вам навсегда забыть о дублировании документов и хаосе в нумерации ваших баз данных.