Многие пользователи и разработчики 1С сталкиваются с ситуацией, когда существующая синхронизация данных работает в формате КД3 (Универсальный формат обмена EnterpriseData), но по разным причинам возникает необходимость или желание переключиться на формат КД2 (Правила конвертации данных 2.0). Причины могут быть разными: от появления предупреждений в КД3, с которыми нет времени разбираться, до привычки и лучшего понимания старого формата. Давайте подробно рассмотрим, возможно ли такое изменение в типовых конфигурациях, с какими сложностями мы столкнемся, и как правильно действовать в подобной ситуации.
Наш читатель столкнулся именно с такой проблемой: большая часть синхронизаций настроена на КД2, но одна из них (предположительно, для связки УНФ - БП) по недосмотру или в целях изучения была настроена на КД3. Теперь она выдает предупреждения, а времени на изучение новой технологии нет. Возникает вопрос: можно ли поменять КД3 на КД2 "из конфигурации", особенно если обе конфигурации типовые или близки к типовым и содержат нужные планы обмена?
Переход на КД3 (EnterpriseData) в продуктах 1С стал стандартной практикой, но для многих пользователей, привыкших к КД2, это может вызывать затруднения. Новый формат требует переосмысления логики обмена, изучения новых правил, что не всегда возможно в условиях ограниченного времени или при отсутствии специфических знаний. Если текущий обмен в КД3 начинает выдавать ошибки или предупреждения, естественным желанием является "откатиться" на более знакомый и, казалось бы, простой КД2.
Для того чтобы понять, почему не получается просто "переключить" формат синхронизации, необходимо уяснить принципиальные различия в архитектуре этих механизмов.
Мы рассмотрим каждый из форматов подробнее:
Формат КД2 основан на использовании внешних файлов правил конвертации, обычно с расширением .xml. Эти файлы содержат подробные инструкции о том, как объекты одной конфигурации должны преобразовываться в объекты другой. Конфигурация, выполняющая обмен, "понимает", как конвертировать данные, только если ей загрузить эти специфические правила. Правила могут храниться в регистрах сведений или справочниках правил обмена внутри конфигурации. Главная особенность КД2 – это жесткая привязка правил к конкретным конфигурациям и их структурам. Изменение структуры хотя бы одной из конфигураций требует обновления или создания новых правил обмена.
КД3 – это современный стандарт обмена, разработанный фирмой "1С". Его ключевое отличие заключается в передаче данных в нейтральном универсальном формате (XML-схема). В этом случае конфигурации не знают напрямую о внутренней структуре друг друга, а общаются через общий "словарь" универсального формата. Данные выгружаются из одной конфигурации в универсальный формат, а затем загружаются из универсального формата в другую конфигурацию. В типовых решениях этот формат жестко прописан в модулях обмена, и его логика глубоко интегрирована в код. Преимущества КД3 включают: независимость от конкретных конфигураций, унификация обменов, потенциально более легкая поддержка при обновлениях конфигураций, так как изменения в структуре одной конфы не всегда требуют немедленного изменения правил у другой.
Когда мы запускаем "Мастер синхронизации" в современных типовых конфигурациях, алгоритм автоматически определяет наиболее подходящие правила обмена для конкретной пары конфигураций. И здесь мы сталкиваемся с основной проблемой:
Мы выясним причины:
Фирма "1С" активно переводит свои продукты на универсальный формат обмена EnterpriseData (КД3). Это стратегическое решение, направленное на стандартизацию и упрощение поддержки обменов между различными конфигурациями. В результате такой эволюции поддержка КД2 для многих сценариев (например, Управление торговлей — Бухгалтерия Предприятия, Управление нашей фирмой — Бухгалтерия Предприятия) была либо программно ограничена, либо полностью удалена из "Мастера синхронизации" в новых версиях. Об этом упоминается в обсуждении: "как-то у меня в памяти УТ-БП запало, что в один момент вырубили через КД2 и преобразовали в обмен через универсальный формат" (сообщение 7).
Даже если мы попытаемся создать узел обмена вручную, как это предлагалось в сообщении 13 ("Открыть старый план обмена и создать там узел вручную"), программный код (обработчики событий, модули менеджера обмена) в типовой конфигурации ожидает, что обмен будет идти именно через EnterpriseData. Если код видит, что настройка подразумевает работу с универсальным форматом, он будет генерировать XML-файл именно этого стандарта, полностью игнорируя наши попытки "подсунуть" логику КД2. Автор подтверждает это, говоря: "Кажется, я что-то делаю не так. "Старый план обмена" у меня в универсальном формате, т.е. КД3. Или похоже добавляю не туда, т.к. в файл обмена все равно записывается в универсальном формате" (сообщение 14).
Это означает, что "просто удалить настройку и создать её заново как КД2 в современной типовой связке, скорее всего, не получится — «Мастер» не предложит такой опции, а ручное создание узла приведет к ошибкам записи, так как логика обмена в модулях жестко завязана на универсальный формат."
Для работы с КД2 вам нужны актуальные файлы правил (.xml), которые подходят под текущие релизы обеих конфигураций. В современных типовых конфигурациях такие файлы производителем (фирмой 1С) часто просто не поставляются. Вам придется либо писать их самостоятельно в "Конвертации данных 2.0", либо искать их в старых версиях конфигураций. Однако использование старых правил с новыми релизами чревато потерей данных, некорректным обменом и массой ошибок при каждом обновлении.
В ходе обсуждения возникла интересная ремарка: "Ну почему нельзя в типовых? УНФ - БП и ЗУП - БП оба варианта поддерживают" (сообщение 6). Это утверждение вносит некоторую неоднозначность, ведь автор работает именно со связкой УНФ - БП. Однако, несмотря на эту потенциальную поддержку, читатель все равно сталкивается с тем, что:
Мы делаем следующий вывод: хотя на уровне концепции или в более ранних версиях для связки УНФ - БП могла быть заявлена поддержка КД2, на практике в современных релизах и через типовые механизмы (такие как "Мастер синхронизации" или стандартные модули обмена) система жестко ориентирована на КД3. Возможно, поддержка КД2 сохранена только для старых, ранее настроенных обменов, или требует специфических действий, не предусмотренных типовым интерфейсом пользователя и сильно отличающихся от привычного создания узла.
Переход с КД3 на КД2 — это не просто смена "галочки" в настройках, это смена всей технологии передачи данных. При попытке "отката" мы неизбежно столкнемся с серьезными проблемами:
Как мы уже выяснили, производитель может просто не поставлять актуальные файлы правил .xml для КД2, подходящие под текущие релизы конфигураций. Их самостоятельное создание или адаптация — трудоемкий процесс, требующий глубоких знаний "Конвертации данных 2.0" и структур обеих конфигураций.
Узлы плана обмена для КД3 и КД2 в типовых конфигурациях часто представляют собой разные объекты метаданных. Нельзя просто "переключить" существующий узел из режима КД3 в режим КД2, так как они используют разные внутренние механизмы и логику.
Механизмы сопоставления объектов (регистрация изменений) в КД3 и КД2 работают по-разному. При попытке "заставить" старый узел работать в другом формате или создать новый узел в КД2 параллельно существующему КД3, мы неизбежно столкнемся с конфликтами идентификаторов (GUID объектов), что приведет к дублированию данных или некорректному обмену. Это может сильно повредить целостности данных в обеих базах.
Если текущая настройка КД3 выдает ошибки или предупреждения, наиболее правильным и безопасным решением считается не попытка "отката" на старый формат (который в современных типовых может быть программно вырезан или затруднен), а решение проблем в рамках текущего формата. Мы рассмотрим несколько шагов:
Это критически важный первый шаг перед любыми экспериментами или изменениями. Всегда создавайте полные резервные копии обеих информационных баз, участвующих в обмене. Это позволит нам вернуться к исходному состоянию в случае непредвиденных проблем (сообщение 10).
В большинстве случаев ошибки в КД3 связаны с тем, что в одной из конфигураций не заполнены обязательные реквизиты, необходимые для универсального формата. Например, при выгрузке контрагента может потребоваться заполненный ИНН, КПП или вид деятельности, которые в исходной базе были необязательными, но стали таковыми для универсального формата. Мы рекомендуем:
Если требуется изменить логику обмена или скорректировать правила выгрузки/загрузки данных в рамках КД3, это делается не через "Мастер", а через корректировку правил конвертации для КД3. Для этого используется специализированный интерфейс "Конвертации данных 3.0" (или его аналоги в конфигурации, например, через стандартные обработки). Этот процесс требует специфических навыков работы с КД3, понимания структуры универсального формата и умения настраивать соответствия объектов и свойств в рамках этой методологии.
Если стандартные механизмы типовых конфигураций не справляются с уникальными требованиями бизнеса, и модифицировать типовой обмен КД3 крайне сложно или невозможно, можно рассмотреть вариант создания отдельного плана обмена со своими правилами и узлами. Этот путь требует серьезного вмешательства в конфигуратор, разработки собственных правил (возможно, на базе КД2, если они есть и адаптированы, или написания обработок на встроенном языке), которые будут работать параллельно с типовыми. Это решение является наиболее сложным и трудоемким, требует глубоких знаний платформы 1С и конфигуратора, а также дополнительных усилий по поддержке при обновлениях.
В рамках этого подхода, можно попробовать создать узел обмена вручную, как предлагалось в сообщении 13, но с учетом, что это будет совершенно новый, нетиповой обмен, требующий тщательной проработки и тестирования.
Подытоживая наш анализ, мы можем сделать следующий вывод:
В современных типовых связках конфигураций 1С (таких как УНФ - БП), скорее всего, нет прямой и простой возможности "переключить" существующий обмен с КД3 на КД2 через пользовательский интерфейс или стандартные настройки. "Мастер синхронизации" не предложит такой опции, а ручное создание узла, как показал опыт нашего читателя, может привести к тому, что система все равно будет использовать универсальный формат из-за жесткой логики, прописанной в модулях типовых конфигураций.
Наиболее рекомендуемый и безопасный путь — это решать возникающие проблемы в рамках текущего формата КД3. Мы должны тщательно анализировать ошибки, при необходимости корректировать правила обмена КД3 и использовать инструменты, предназначенные для работы с этим форматом.
Попытка "отката" на КД2 в типовой конфигурации — это фактически создание нового, нетипового механизма обмена, что крайне трудозатратно, сложно в поддержке и чревато потерей данных. Мы должны быть готовы к значительному объему работ и высокому риску, выбирая этот путь.