← На главную

При работе с обменом данными между различными информационными системами, такими как 1С:Бухгалтерия и "Мой Склад", часто возникает необходимость тонкой настройки правил сопоставления объектов. Одной из распространенных задач является изменение полей поиска для организаций в универсальном формате обмена (EnterpriseData). Давайте рассмотрим, как мы можем добиться этого без прямого вмешательства в типовой код, а также как решить сопутствующие проблемы, связанные с некорректным сопоставлением по глобальным уникальным идентификаторам (GUID).

Настройка полей поиска организации в правилах обмена через "Конвертацию данных 3" (КД3)

Универсальный формат обмена, или EnterpriseData, тесно интегрирован с конфигурацией "1С:Конвертация данных 3" (КД3). Именно КД3 является основным инструментом для разработки, модификации и тонкой настройки правил обмена данными. Если мы хотим изменить, по каким полям система будет искать организацию при загрузке данных, то наши шаги будут следующими:

1. Загрузка структуры и правил: Мы загружаем в КД3 структуру формата EnterpriseData, а также структуры конфигураций-источника и приемника. Далее импортируем существующие правила обмена или синхронизации данных.
2. Работа с ПКО (Правило Конвертации Объектов): Находим соответствующее ПКО для справочника "Организации". В типовом коде это может выглядеть так, как было упомянуто в сообщении на форуме:
Скопировать код

// Пример из модуля МенеджерОбменаЧерезУниверсальныйФормат13::
// Процедура ДобавитьПКО_Справочник_Организации_Получение(ПравилаКонвертации)
//    ...
//    ПравилоКонвертации.ПоляПоиска.Добавить("ИНН,КПП");
//    ПравилоКонвертации.ПоляПоиска.Добавить("НаименованиеПолное");
//    ПравилоКонвертации.ПоляПоиска.Добавить("Наименование");
// КонецПроцедуры
// В КД3 эти настройки задаются через графический интерфейс,
// минуя прямое редактирование кода.

Мы обращаемся к свойствам этого ПКО. Обычно на закладке "Поиск объектов в приемнике" или в общих свойствах ПКО мы можем вручную указать реквизиты, по которым система должна производить поиск. Например, для точного сопоставления по данным ФНС, мы можем указать "ИНН" и "КПП".

• Исключение нежелательных полей: Крайне важно снять флажки с тех полей, которые могут привести к ошибочному сопоставлению. Если наименования организаций могут отличаться (как в случае с "косметическим" переименованием в одной из систем), то мы обязательно снимаем флажки с полей "Наименование" и "НаименованиеПолное". Оставляем только те поля, которые однозначно идентифицируют организацию, такие как "ИНН" и "КПП".

Таким образом, КД3 позволяет нам гибко настраивать поля поиска без необходимости изменять исходный код конфигурации, что является предпочтительным подходом при работе с типовыми решениями.

Использование расширений конфигурации

В тех случаях, когда конфигурация находится на поддержке, и мы хотим внести изменения в логику обмена, но не можем или не хотим использовать КД3 (например, если речь идет о тонкой модификации поведения на этапе загрузки или при специфичных условиях), наиболее предпочтительным способом является создание расширения конфигурации.

Хотя прямое изменение XDTO-пакетов через расширения может быть ограничено или затруднено, мы можем использовать обработчики событий. Расширения позволяют переопределить поведение модулей или объектов, реагируя на определенные события. Например, мы можем найти правило конвертации свойств организации и внести изменения в логику его работы через расширение. Это может быть реализовано путем подписки на события перед записью объекта или при его поиске в приемнике, позволяя нам скорректировать набор полей поиска или даже логику сопоставления.

Создание расширения – это "безопасный" способ доработки, так как он не затрагивает основную конфигурацию и позволяет обновлять ее без потери наших изменений. Этот подход особенно актуален для облачных версий 1С:Предприятия (1С:Фреш), где прямое изменение конфигурации или даже некоторые настройки через интерфейс могут быть ограничены.

Решение проблем сопоставления организаций по GUID и наименованию

Даже при правильной настройке полей поиска в КД3, мы можем столкнуться с ситуацией, когда организации сопоставляются некорректно. Основной причиной этого является механизм сопоставления по уникальному идентификатору (GUID).

1. Приоритет GUID: Система обмена 1С в первую очередь пытается найти объект по его уникальному идентификатору (GUID). Если GUIDы объектов в обменивающихся базах совпадают, сопоставление происходит именно по ним. Поля поиска, которые мы настроили в КД3, используются только как резервный механизм – если объект не был найден по GUID.
2. Проблема с "косметическим" переименованием и GUID: Рассмотрим ситуацию, описанную на форуме: в одной системе (например, "Мой Склад") организация была "косметически" переименована, а в 1С создана новая организация. Затем в 1С старую организацию переименовали, пытаясь соответствовать "Моему Складу". Однако, при обмене, данные продолжают загружаться на *старую* организацию в 1С, несмотря на ее переименование и очистку наименований. Почему? Потому что к этой старой организации в 1С уже был привязан GUID из "Моего Склада". Система видит этот GUID и игнорирует все изменения наименований или полей поиска, сопоставляя объекты по идентификатору.
3. Ключевой инструмент: Регистр сведений "Публичные идентификаторы синхронизируемых объектов": Для решения этой проблемы нам необходимо обратиться к регистру сведений Публичные идентификаторы синхронизируемых объектов. Этот регистр хранит информацию о соответствии объектов между базами, фактически устанавливая, какой GUID во внешней системе соответствует какому объекту в текущей базе 1С.

Как работать с регистром:

1. Доступ к регистру: Мы можем найти этот регистр через меню "Все функции" (или "Главное меню" - "Сервис" - "Все функции") или, если доступ есть, напрямую через интерфейс синхронизации данных.
2. Поиск некорректных записей: Мы ищем записи, которые относятся к проблемной организации. Это могут быть "битые" (фиктивные) ссылки или некорректные идентификаторы, которые привязывают внешний GUID к неправильному объекту в нашей базе.
3. Удаление некорректных записей: Если мы обнаруживаем запись, связывающую GUID из "Моего Склада" (или любой другой внешней системы) с неправильной организацией в 1С, мы удаляем эту запись. Это "отвязывает" внешний GUID от объекта в нашей базе.

После удаления записи из регистра Публичные идентификаторы синхронизируемых объектов, при следующем обмене система не сможет найти объект по GUID и будет вынуждена использовать резервный механизм – поиск по настроенным нами полям. Если мы правильно настроили поиск по "ИНН" и "КПП" в КД3, то сопоставление произойдет корректно, даже если наименования различаются.

• Поля поиска как резервный механизм: Еще раз подчеркнем, что корректная настройка полей поиска (например, только ИНН и КПП) становится критически важной именно для случаев, когда объект не найден по GUID. Это позволяет сопоставить организации, даже если их наименования в разных системах отличаются.
• Ручное сопоставление: В особо сложных случаях, когда автоматическое сопоставление не дает результата, мы всегда можем прибегнуть к ручному сопоставлению объектов. В интерфейсе синхронизации данных обычно предусмотрены специальные обработки, позволяющие выбрать объект-источник и объект-приемник, а также указать поля, по которым будет выполняться поиск для ручного сопоставления.
• Удаление дублирующей организации: Иногда может потребоваться удалить некорректно созданную или дублирующую организацию, к которой по ошибке привязался GUID из внешней системы. Однако мы должны быть крайне осторожны с таким шагом, поскольку удаление может повлечь за собой другие проблемы, например, наличие непроведенных документов, выписанных на удаленную организацию. В таких случаях потребуется дополнительная очистка данных и перепроведение документов.

Решения для "Fresh" (облачных) версий 1С

Для пользователей облачных версий 1С:Предприятия ("Fresh") существуют определенные ограничения:

1. Ограничения на удаление: В "Fresh"-версиях прямое удаление элементов справочников может быть ограничено или невозможно через стандартный интерфейс.
2. Расширения как основной инструмент: Для доработок и изменений правил обмена, включая настройку полей поиска или решение проблем сопоставления, мы должны использовать расширения конфигурации. Это единственный поддерживаемый способ внесения изменений в логику системы в облачной среде.
3. Атрибут ОбменДанными.Загрузка: Для предотвращения конфликтов и ошибок при обмене данными в расширениях мы можем использовать атрибут ОбменДанными.Загрузка в обработчиках модулей объектов. Этот атрибут позволяет временно отключать некоторые проверки при записи объекта в режиме обмена, что может быть полезно при загрузке данных, которые иначе вызвали бы ошибки валидации.

В заключение, эффективное управление обменом данных с организациями в 1С требует комплексного подхода. Мы начинаем с точной настройки полей поиска в "Конвертации данных 3", далее внимательно отслеживаем и корректируем сопоставление по GUID с помощью регистра Публичные идентификаторы синхронизируемых объектов, и при необходимости применяем расширения конфигурации для специфических доработок, особенно в "Fresh"-среде. Такой подход позволяет нам добиться надежного и корректного обмена данными, избегая типовых ошибок и конфликтов.