При активном использовании типовых решений 1С многие специалисты сталкиваются с ситуацией, когда после очередного обновления одной из баз (чаще всего Бухгалтерии предприятия) привычный механизм синхронизации данных перестает функционировать. Одной из наиболее острых проблем последнего времени стал переход на формат обмена EnterpriseData 1.10. Рассмотрим ситуацию, когда при обмене между Управление торговлей 11.4 и Бухгалтерия предприятия 3.0 данные из УТ успешно отправляются, но в БП отображается 0 принятых объектов.
Разберем техническую сторону конфликта. Проблема кроется в несоответствии поддерживаемых версий универсального формата EnterpriseData. В новых релизах Бухгалтерии предприятия (начиная с 3.0.98 и выше) разработчики внедрили поддержку формата версии 1.10 и сделали ее приоритетной. В то же время, более старые релизы Управления торговлей 11.4 (например, 11.4.13.243) "не знают" о существовании версии 1.10, так как в их метаданных максимальная версия ограничена 1.9.
Проанализируем процесс: при инициализации сеанса обмена конфигурации пытаются договориться о максимально возможной версии формата, которую поддерживают обе стороны. Из-за ошибки в логике определения версий, Бухгалтерия предприятия может пытаться использовать версию 1.10, ожидая от Управления торговлей данные в этом формате. Поскольку УТ не может корректно сформировать пакет по правилам версии 1.10, или возникают ошибки при десериализации данных в БП из-за отсутствия необходимых XDTO-пакетов, обмен фактически блокируется, и количество загруженных объектов остается нулевым.
Самый быстрый и правильный способ решения проблемы для тех, кто использует типовые конфигурации — это установка официального исправления от фирмы 1С. Для конфигурации Управление торговлей 11.4 был выпущен специальный патч (исправление) под номером EF_00_00385576.
Выясним, как правильно применить это решение:
Управление торговлей под правами администратора.EF_00_00385576.Данный патч корректирует логику в общих модулях, принудительно ограничивая выбор версии формата EnterpriseData. После его установки система автоматически откатится к использованию стабильной версии 1.8 или 1.9, которая поддерживается обеими конфигурациями.
Если по каким-то причинам установка патча невозможна (например, конфигурация сильно доработана и автоматическое обновление патчей отключено), проблему можно решить путем внесения изменений в программный код через расширение или непосредственно в основной конфигурации. Посмотрим, какой объект требует внимания.
Основная логика обмена по универсальному формату сосредоточена в менеджере обмена. Нам необходимо скорректировать список доступных версий в общем модуле МенеджерОбменаЧерезУниверсальныйФормат. Рассмотрим пример того, как это можно реализовать.
Найдем функцию, отвечающую за определение версий формата (обычно это ВерсииФормата или аналогичная в зависимости от конкретного релиза). Нам нужно убедиться, что версия 1.10 не предлагается системе в качестве доступной. Примерный алгоритм правки кода:
// В общем модуле МенеджерОбменаЧерезУниверсальныйФормат
Функция ПолучитьДопустимыеВерсииФормата() Экспорт
ДопустимыеВерсии = Новый Массив;
ДопустимыеВерсии.Добавить("1.5");
ДопустимыеВерсии.Добавить("1.6");
ДопустимыеВерсии.Добавить("1.7");
ДопустимыеВерсии.Добавить("1.8");
ДопустимыеВерсии.Добавить("1.9");
// ВНИМАНИЕ: Если здесь присутствует версия "1.10", её нужно исключить
// ДопустимыеВерсии.Добавить("1.10");
Возврат ДопустимыеВерсии;
КонецФункции
После внесения правок в код Управления торговлей, при следующем запуске синхронизации, базы должны успешно согласовать версию 1.9 (или 1.8), и данные начнут поступать в Бухгалтерию предприятия.
Иногда даже после установки патча или правки кода обмен продолжает выдавать ошибку, так как в настройках узла обмена уже "запомнилась" неудачная попытка использования версии 1.10. Проанализируем, как сбросить эти настройки.
Рассмотрим последовательность действий:
1.8.В некоторых случаях может потребоваться очистка записей в регистре сведений Безопасное хранилище данных (или аналогичных системных регистрах, где хранятся параметры подключения), чтобы параметры сессии обмена обновились полностью.
Нужно понимать, почему версия 1.10 вообще появилась. Основная цель её внедрения — поддержка новых требований законодательства, в частности прослеживаемости товаров и расширенной работы с маркировкой (Честный Знак). Версия формата 1.10 содержит дополнительные реквизиты в табличных частях документов, которые необходимы для корректной передачи номеров ГТД, регистрационных номеров партий товаров (РНПТ) и кодов маркировки.
Важный момент: если вы принудительно откатываете обмен на версию 1.8, обязательно проконтролируйте заполнение данных по прослеживаемым товарам в Бухгалтерии предприятия. Возможно, часть специфических реквизитов придется дозаполнять вручную или проверять их наличие в приходных документах, так как старый формат может их "не пробрасывать".
Выясним влияние версии платформы на стабильность обмена. При использовании современных версий EnterpriseData (особенно 1.10 и выше) крайне желательно использовать актуальную версию технологической платформы 1С:Предприятие 8.3. Разработчики рекомендуют версию не ниже 8.3.17.1851 или 8.3.18.1289. Это связано с тем, что механизмы работы с XDTO и XML постоянно оптимизируются, и на старых версиях платформы могут возникать ошибки переполнения памяти или некорректной обработки пространства имен при чтении больших пакетов данных.
Рассмотренные выше методы (патчи и правки кода) являются временными мерами, позволяющими оперативно восстановить работоспособность бизнеса. Однако стратегически правильным решением будет планирование перехода на актуальные версии конфигураций. В ветке Управление торговлей 11.5 поддержка формата EnterpriseData 1.10 реализована штатно, и подобные конфликты версий там отсутствуют.
Подведем итог: если вы столкнулись с "нулевым" приемом объектов в Бухгалтерии, в первую очередь проверьте наличие патча EF_00_00385576 для вашей версии Торговли. Это решит проблему в 90% случаев без необходимости глубокого погружения в программный код.