При использовании стандартных механизмов синхронизации между конфигурациями 1С:Управление торговлей 11 (УТ 11) и 1С:Бухгалтерия предприятия 3.0 (БП 3.0) специалисты часто сталкиваются с ситуацией, когда при первичной или очередной выгрузке в базу-приемник «прилетают» дубли контрагентов с одинаковым ИНН, а документы загружаются без складов, организаций или договоров. Проанализируем, как устроен типовой механизм обмена, выясним причины сбоев и разберем по шагам правильный порядок настройки синхронизации.
В современных конфигурациях 1С обмен между УТ 11 и БП 3.0 выполняется не через классические правила обмена (XML-файлы из Конвертации данных 2.1), а с использованием формата EnterpriseData (ED). Логика этого формата строится на обработке правил, созданных в Конвертации данных 3.0 (КД3), которые программно внедрены в общие модули типовых конфигураций (например, модуль МенеджерОбменаЧерезУниверсальныйФормат).
Ключевое отличие формата EnterpriseData заключается в том, что конфигурации обмениваются данными не напрямую по структуре друг друга, а через единую универсальную XDTO-схему. Каждая база отвечает за трансляцию своих данных в формат ED при выгрузке и из формата ED в собственные справочники и документы при загрузке.
Выясним, почему стандартный обмен «из коробки» создает дубли и не заполняет поля:
ИНН + КПП. Если в одной из баз у контрагента не заполнен или отличается КПП (например, указан КПП филиала вместо головной организации), механизм создаст дубликат.Партнеры (управленческий учет) и Контрагенты (регламентированный учет). Если включено независимое ведение партнеров и контрагентов, а в Бухгалтерии используется только справочник Контрагенты, возникает рассинхронизация при переносе связей.Счета учета номенклатуры, Счета учета расчетов с контрагентами). Если эти регистры в БП 3.0 не заполнены, документы загрузятся незаполненными или непроведенными.Рассмотри пошаговый порядок действий, который предотвращает появление дублей и потерю реквизитов:
ИНН и Наименованию, для номенклатуры — по Артикулу и Наименованию).Соответствия объектов информационных баз. После этого при последующих автоматических обменах система будет точно знать, какому элементу УТ 11 соответствует элемент в БП 3.0.Если дубли уже создались в базе-приемнике, проанализируем порядок их устранения:
Поиск и удаление дублей в БП 3.0.Соответствия объектов информационных баз и проверим записи для оставшегося правильного объекта.Регистрация изменений для обмена данными.Если типовых алгоритмов сопоставления недостаточно (например, требуется искать контрагентов строго по ИНН без учета КПП или переносить специфические реквизиты), не требуется снимать конфигурацию с поддержки. В современных релизах доработка правил EnterpriseData выполняется через расширения конфигурации (.cfe) путем переопределения обработчиков в модуле МенеджерОбменаЧерезУниверсальныйФормат или с помощью подключения внешних правил обмена, подготовленных в Конвертации данных 3.0.
При передаче огромных объемов данных через XML-файлы типовые механизмы обработки текста могут приводить к перерасходу оперативной памяти на сервере. Посмотрим на пример оптимизации программного кода при чтении и записи временных файлов обмена на сервере с использованием двоичных данных вместо полной загрузки длинных строк в память:
&НаСервере
Процедура ПрочитатьЗаписатьТекстОптимизированно(Знач Прочитать, АдресХранилища, ИмяФайла)
Если Прочитать Тогда
// Вместо ПрочитатьТекст() помещаем файл в хранилище как ДвоичныеДанные
Двоичные = Новый ДвоичныеДанные(ИмяФайла);
АдресХранилища = ПоместитьВоВременноеХранилище(Двоичные);
Иначе
// Извлекаем двоичные данные из хранилища и записываем прямо в файл
Двоичные = ПолучитьИзВременногоХранилища(АдресХранилища);
Если Двоичные <> Неопределено Тогда
Двоичные.Записать(ИмяФайла);
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Использование ДвоичныеДанные предотвращает загрузку гигабайтных XML-строк в память серверного процесса 1С, что существенно ускоряет работу обмена и снижает риск падения службы rphost по превышению лимита памяти.