Рассмотрим распространенный вопрос, который возникает при работе с конвертацией данных в 1С:Предприятии, особенно при переходе от ручной выгрузки к автоматизированному обмену через планы обмена. Возникает закономерный вопрос: будут ли правила конвертации, разработанные для ручной выгрузки с помощью Конвертации Данных 2.1 (КД 2.1), работать при загрузке их в собственный план обмена, например, между базами ЗУП 3?
Разберем эту ситуацию по шагам, учитывая нюансы работы КД 2.1 и современные реалии конфигурации ЗУП 3.1.
Прежде всего, давайте выясним, может ли процесс выгрузки/загрузки данных по КД 2.1 функционировать одинаково, независимо от того, как вы его запускаете – вручную через универсальную обработку или автоматически через план обмена. По своей сути, механизму Конвертации Данных 2.1 действительно безразлично, каким способом его вызвали. Правила конвертации, разработанные в КД 2.1, вполне могут успешно использоваться в планах обмена, включая обмен между идентичными базами ЗУП 3.
Ключевым инструментом для реализации обмена по правилам КД 2.1 является типовая обработка Универсальный обмен данными в формате XML (часто известная как V8Exchan.epf или V8Exchan83.epf). Она используется как для ручной выгрузки, так и в качестве основы для программного запуска обмена через планы обмена.
Объекты конфигурации ПланОбмена играют важную роль в этом процессе. Они не только реализуют механизмы обмена данными, но и хранят информацию об узлах, участвующих в обмене, а также определяют состав данных, подлежащих передаче. Более того, параметры, которые вы можете задать в реквизитах или табличных частях плана обмена, могут быть переданы в структуру Параметры правил КД 2.1 и доступны в обработчиках. Это открывает возможности для тонкой настройки логики обмена в зависимости от специфических настроек конкретного плана обмена.
При обсуждении обмена данными с ЗУП 3, важно учитывать, что конфигурация ЗУП 3.1 изначально ориентирована на использование формата EnterpriseData (ED) и механизма Конвертации Данных 3.0 (КД 3.0) для синхронизации данных.
EnterpriseData (XDTO-формат): Этот формат обеспечивает более гибкую работу с данными. Его ключевое преимущество в том, что он не привязан напрямую к метаданным конфигурации-источника и конфигурации-приемника. Это значительно упрощает сопровождение обменов при внесении изменений в конфигурации, поскольку позволяет избежать многих конфликтов, которые могли бы возникнуть при прямом обмене по метаданным.
КД 3.0: В отличие от КД 2.0, которая поддерживает только XML-формат, КД 3.0 позволяет редактировать правила обмена как для XML, так и для XDTO-формата. КД 3.0 рекомендуется для обменов между типовыми решениями, которые не подвергаются значительным доработкам. Для нетиповых конфигураций, постоянно изменяющихся обменов или разовых переносов данных может быть предпочтительнее КД 2.0 из-за ее, возможно, более привычного функционала для части разработчиков.
Несмотря на этот вектор развития, в ЗУП 3.1 присутствуют планы обмена, которые продолжают использовать правила КД 2.0. Яркий пример — план обмена ОбменЗарплата3Бухгалтерия3, который по умолчанию использует правила, разработанные в КД 2.0. Это означает, что вы имеете выбор: использовать формат EnterpriseData с КД 3.0 (через план СинхронизацияДанныхЧерезУниверсальныйФормат) или, при желании, обратиться к классическим правилам КД 2.0 для определенных задач. Также, переносы данных из более ранних конфигураций, таких как УПП 1.3 или КА 1.1, в ЗУП 3.1 часто используют именно правила КД 2.1.
Важный момент, который необходимо учитывать, если вы решите "принудительно" использовать КД 2.0 в ЗУП 3, – это потенциальные сложности с Библиотекой стандартных подсистем (БСП). Попытка "залить" старую БСП в ЗУП 3 для поддержки КД 2.0 – это трудоемкий и "геморройный" процесс. Старая БСП будет конфликтовать с новой, уже встроенной в ЗУП 3, из-за значительных изменений в развитии платформы и архитектуре конфигураций. Такой прямой подход нецелесообразен и может привести к нестабильности системы. Если же вам необходимо использовать КД 2.0 в ЗУП 3, это чаще реализуется через уже существующие планы обмена, использующие КД 2.0, либо путем разработки собственных обменов на базе КД 2.0, но без попыток внедрения устаревшей БСП.
Теперь обратимся к одной из наиболее частых проблем, возникающих при обмене данными через план обмена на КД 2.1: "ссылочные объекты не все выгружает далеко".
Эта проблема является известной и часто возникает, если объекты настроены на режим ВыгружатьПриНеобходимости, встречаются по ссылкам, но их поиск или регистрация настроены некорректно. Чтобы гарантировать корректную выгрузку, необходимо следовать следующим принципам:
Регистрация объектов для обмена: Объекты, которые должны быть выгружены, должны быть либо зарегистрированы для обмена в соответствующем узле плана обмена, либо принудительно выгружены кодом. Режим выгрузки ВыгружатьВсегда для объекта в правилах регистрации гарантирует, что он будет зарегистрирован для отправки, независимо от параметра Отказ в обработчике ПередОбработкой.
Порядок выгрузки свойств: Для корректной выгрузки ссылочных объектов критически важен порядок выгрузки свойств. Например, если Договор контрагента подчинен Контрагенту, то свойство Контрагент должно выгружаться раньше свойства Договор контрагента. Это позволяет избежать ошибок, связанных с отсутствием базового объекта при попытке создать или связать подчиненный.
Настройки Правил Конвертации Объектов (ПКО) в КД 2.1:
Признак Не запоминать выгруженные объекты: Этот признак устанавливается для ПКО тех объектов, которые выгружаются по ссылке, например, из табличной части документа. Его использование помогает избежать повторной выгрузки уже переданных объектов, но важно понимать его влияние на общий механизм отслеживания выгруженных данных.
Признак Не выгружать объекты свойств источника по ссылкам: Этот признак, примененный к ПКО документа, содержащего табличную часть, может быть использован для тонкой настройки. Его цель – предотвратить неконтролируемую выгрузку ссылочных объектов из свойств источника, когда их выгрузка должна быть явно определена другими правилами или происходить по прямой регистрации. Это скорее мера по предотвращению избыточных или ошибочных выгрузок, чем средство для обеспечения выгрузки отсутствующих объектов.
Принудительная выгрузка кодом: В случаях, когда автоматическая регистрация или настройки правил не обеспечивают полную выгрузку, вы можете принудительно выгружать объекты с помощью кода. Это делается в обработчиках событий правил конвертации. Например, можно использовать методы, которые добавляют объект в список на выгрузку, даже если он не был автоматически зарегистрирован для обмена.
Для обеспечения надежной работы обмена данными, особенно в условиях ЗУП 3, рекомендуем тщательно тестировать разработанные правила конвертации и отслеживать состав выгружаемых объектов. Используйте стандартные средства отладки и просмотра журнала регистрации обмена для выявления и исправления проблем с ссылочными объектами.
Таким образом, правила конвертации данных 2.1 могут быть успешно использованы в собственных планах обмена ЗУП 3, но с учетом определенных нюансов. Необходимо внимательно отнестись к вопросу регистрации ссылочных объектов и порядку их выгрузки. Хотя ЗУП 3 ориентирован на КД 3.0 и EnterpriseData, функциональность КД 2.1 остается доступной для определенных задач и планов обмена. Выбирайте подход, который наиболее соответствует вашим требованиям и возможностям поддержки.