Суть ошибки в том, что в алгоритме «ВыгрузитьСведенияФизическогоЛица» некорректно указаны условия отбора (аж три раза…). Вместо GUID объекта <Источник.Ссылка> в процедуру отбора в качестве параметра передаётся абстрактнейшее <Источник>.
Правила обмена, используемые по умолчанию, встроены в план обмена в виде набора шаблонов. Убедимся, что в исследуемых нами релизах ошибка присутствует:
Для исправления ситуации необходимо выгрузить правила в соответствующие xml файлы (с помощью буфера обмена), исправить ошибки, загрузить изменённые файлы правил при настройке синхронизации.
Комплект правил плана обмена ОбменЗарплата3Бухгалтерия3 состоит из следующих правил:
| Тип правила | Файл |
|---|---|
| Регистрации | RegistrationRules.xml |
| Обмена | ExchangeRules.xml |
| Обмена корреспондента | CorrespondentExchangeRules.xml |
При настройке синхронизации есть возможность загрузить каждые правила из отдельного xml файла, либо в виде архива, содержащего эти файлы. В связи с тем, что необходимо корректировать два из трёх файлов, логичнее подготовить архив.
Для работы с правилами регистрации и правилами обмена формата 2 существует специальная конфигурация «Конвертация данных 2.1». В случае разработки собственных правил или доработки существующих, настоятельно рекомендуется использовать для этого данную конфигурацию. В нашем случае имеет место банальное исправление ошибки, поэтому мы считаем, что корректно будет просто внести изменения любым текстовым редактором, не изменяя при этом Идентификатор правил. Пример того, как это сделано xml редактором FirstObject XML Editor:
Для подготовки архива создадим папку (например, с именем RulesPersData), создадим в ней файлы RegistrationRules.xml, ExchangeRules.xml, CorrespondentExchangeRules.xml путём копирования содержимого соответствующих шаблонов. Откорректируем созданные файлы и упакуем их в архив. При настройке синхронизации, данный архив будет использован в качестве источника для загрузки правил обмена.
Правила обмена, встроенные в конфигурацию, время от времени редактируются разработчиками. При обновлении конфигурации рекомендуется проверять, отличаются ли правила обмена в новом релизе от тех, которые были нами откорректированы. В случае наличия изменений и наличия данной ошибки, рекомендуется загрузить новые правила, предварительно исправив ошибку. Если же ошибка наконец-то будет исправлена разработчиками, необходимо в настройке синхронизации указать, что будут использоваться встроенные правила обмена.
Если не составит труда, то накатайте письмо в 1С.
Странно. Сколько пользуемся обменом БП-ЗУП никогда не замечали никаких ошибок.
Дайте, пожалуйста, описание: что именно некорректно передаётся? Может быть мы просто не замечаем?
Все там корректно. Источник и есть ссылка.
Если открыть любой ссылочный элемент метаданных , то видим там .Ссылка — то есть в самом источнике (который является уже ссылкой ) всегда есть ссылка на саму себя и выглядит Источник.Ссылка.
То же ошибки не замечал + Источник и несет в себе GUID объекта метаданных
Первоначальное состояние
Зарплата считалась в ЗУП 2.5, данные о физических лицах (в том числе, об их документах) заполнялись в ней. В БП 3.0 данные о физических лицах передавались по ссылке, с документами обмена (через обработку выгрузки данных в бухгалтерскую программу). В процессе перехода на ЗУП 3.1 данные были перенесены в данную конфигурацию, после чего встала задача настройки синхронизации между базами через план обмена.
Используемые при настройке версии конфигураций:
• БП 3.0.58.20
• ЗУП 3.1.5.129
При использовании встроенных правил обмена
Было замечено, что при редактировании информации о физическом лице, либо при добавлении нового физического лица в любой из конфигураций, данные изменения не отражаются в базе-корреспонденте. Как выяснилось, во встроенных правилах регистрации объектов, для справочника Физические лица установлен режим выгрузки РежимВыгрузкиПриНеобходимости, который позволяет выгружать данные о физическом лице только по ссылке. Нас такая ситуация совершенно не устраивает, ставилась задача полной синхронности данных о физических лицах в обоих базах.
Кроме этого, была замечена странность, приводящая к ошибке: если изменить информацию о физическом лице, хранящуюся в регистрах сведений, то эти изменения регистрируются к обмену. К примеру, если изменить данные документа Паспорт гражданина РФ у какого-либо физического лица, то после синхронизации в базе-приёмнике у данного физического лица пропадает запись о документе Паспорт гражданина РФ. Это происходит в том случае, когда нет соответствия объектов (отсутствует запись в регистре сведений Соответствие объектов информационных баз, относящаяся к данному физическому лицу).
Вторая странность: если соответствие объектов установлено (оно устанавливается автоматически, при выгрузке объекта по ссылке), то любые изменения данных таких физических лиц начинают регистрироваться к обмену, как в случае режима РежимВыгрузкиПерсональныеДанные.
Прошу прощения за задержку с ответом.
Если изменить в правилах выгрузки для физического лица режим на РежимВыгрузкиПерсональныеДанные, то любые изменения информации о физических лицах регистрируются к обмену. Однако, в этом случае записи регистров сведений, связанных с физическими лицами, начали исчезать в совершенно различных ситуациях. Анализ правил обмена выявил следующее:
При выгрузке записи справочника Физические лица, соответствующее ПКО (правило конвертации объекта) содержит обработчик события После выгрузки в файл следующего содержания:
Смысл данного алгоритма в том, чтобы сразу за выгрузкой XML узла записи о физическом лице выгрузить все записи регистров сведений ФИОФизическихЛиц, ГражданствоФизическихЛиц, ДокументыФизическихЛиц, связанных с выгружаемой записью о физическом лице.
Проанализировав состав отправленного сообщения, мы обнаружили, что сразу после объекта Физическое лицо созданы три набора записей регистра, однако, они не содержат, собственно, строк набора записей. Это говорит о том, что отборы записей в алгоритме ВыгрузитьСведенияФизическогоЛица возвращают пустой набор. Это приводит к тому, что в корреспондирующей базе записи вышеперечисленных регистров сведений, связанных с данным физическим лицом, замещается пустыми наборами, или проще говоря, удаляются. После замены в алгоритме Источник на Источник.Ссылка записи регистров начали выгружаться корректно.
Примеры сообщений при выгрузке .
Прошу прощения за задержку с ответом.
Ответ в
Спасибо, помогло
Ваша статья больше столку сбивает
Может она кому то и поможет, но объясните пожалуйста зачем добавлять ссылку к источнику?
Источник и есть ссылка на объект, как насчет информации по обработчикам?
«Источник — Произвольный — выгружаемый объект источник (ссылка или произвольные данные)»
Выгружая объект источник: СправочникСсылка.ФизическиеЛица у вас никак не может получится произвольный объект, в котором один из реквизитов ссылка (это хоть как то бы оправдало сие действие по созданию правил)
Вообщем, перед всеми этими манипуляциями с правилами надо было бы убедится, а во всех ли базах, с которыми идет обмен, были эти самые паспортные данные для физ лиц.
Ведь если хотя бы в одной базе не было ПД, то при отправке из этой базы в другую, где ПД есть, они все будут затерты и в итоге у нас везде пусто, зато физ лица ездят исправно
Если все пусто, никуда не деться уже и заносить придется заново, что я думаю и сделал автор статьи, после того как «исправил» правила обмена, и логично предположить, что все, что он исправил встало к обмену и уехало в другие базы и следовательно больше не пропадало
Спасибо, помогло.
(9)
Не обязательно ссылка! В данном случае это СправочникОбъект.ФизическиеЛица, поэтому и в набор данных ничего не выгружается