Занятие № 03. Курс «1С:Конвертация данных 2.1 – Профессиональная настройка правил обмена и типовые сценарии переноса данных»
Синхронизация объектов
Изучите теорию модуля № 1:
- Глава 4. Синхронизация данных
Выполните практические задания:
Отчеты по домашним заданиям размещайте по ссылкам, указанным выше. Отчеты, опубликованные на этой странице, удаляются без предупреждения.
Ваши вопросы по материалам данного занятия задавайте в комментарии ниже.
Общие вопросы по курсу, не связанные с конкретным занятием, задавайте на странице: http://kursy-po-1c.ru/data-conv/all-hw/convdata-common-qa/
Общие вопросы по курсу, не связанные с конкретным занятием, задавайте на странице: http://kursy-po-1c.ru/data-conv/all-hw/convdata-common-qa/
К сожалению, у Вас недостаточно прав для дальнейшего просмотра.
Если Вы приобрели курс, но еще не активировали токен — пожалуйста, активируйте доступ по инструкциям, высланным на Ваш email после покупки.
Если Вы не залогинены на сайте — залогиньтесь, вернитесь на эту страницу и обновите ее.
Если Вы залогинены, у Вас активирован токен доступа, но Вы все равно видите эту запись — напишите нам на e-mail поддержки.
Комментарии / обсуждение (334):
Комментарии закрыты
Здравствуйте.
Не могу повторить за преподавателем действия по теме “Синхронизация по внешним данным”: происходит дублирование записей в приёмнике. Нашла ответ от 2016 г., где предлагается заменить СвойстваПоиска на ПараметрыОбъекта. Сопоставление происходит, но заменяется АртикулСобственный на АртикулПоставщика, хотя включено “Не замещать значение свойства у существующих объектов в приёмнике”.
КД 2.1.8.2 – проблема не решена?
Добрый день
У Вас флажок “Не замещать” стоит в ПКС для передачи свойства в параметр. А в том ПКС, где выгружается именно реквизит Артикул (первое ПКС), этого флажка нет. Попробуйте там поставить.
Скажите, в каких случаях при выгрузке в приемник переносится UID ?
интересуют ситуации:
– когда в приемнике элемент создан, то ему присваивается UID источника?
– когда в приемнике элемент найден, то у него заменяется UID на UID источника?
– отдельного поля UID в ПКС я не увидел, поэтому вопрос: зависит ли перенос UID от галочки в ПКО “Искать объект приемника по внутреннему идентификатору объекта источника” ?
– может быть еще условия упускаю?
1)УИД – это по сути своей ссылка. В базе данных ссылка записывается именно в виде УИД.
2) Если поиск идет по УИД и в приемнике объект не найден, то новый объект создается с таким же идентификатором, как в источнике
3) Если поиск по УИД отключен, то в приемник УИД из источника не перенесется.
4) Если поиск по УИД включен и стоит галка продолжить поиск по полям поиска и в приемнике мы находим соответствие не по УИД, а по полям поиска, то УИД заменен не будет. Ведь если мы заменим в базе идентификатор, то получим битую ссылку во всех объектах, которые ссылаются на этот объект
5) Отдельного поля УИД нет, потому что это ссылка (см. пункт 1)
Получается, что при синхронизации по УИД нам нужно быть уверенными, хоть и вероятность мала, но все же, что УИД в базах не пересекаются у разных элементов?
Есть какие-то готовые обработки, которые берут УИД из источника и ищут их в приемнике на предмет пересечения?
Вероятность, что у номенклатуры Колбаса в источнике и Капусты в приемнике будет одинаковый УИД стремится к нулю, потому что это по-сути GUID (глобальный уникальный индентификатор)
В моей практике подобных пересечений не было. Такое может произойти, например, если сделать копию базы и переименовать элемент справочника с Колбаса на Капуста. Тогда визульно это будут разные элементы с одним УИД.
Готовых “типовых” обработок нет, но можете написать самостоятельно. УИД = XMLСтрока(Ссылка) даст Вам строку УИД.
ЭлементСправочника.ПолучитьСсылку(Новый УникальныйИдентификатор(УИД)) вернет ссылку в приемнике с таким УИД, если есть
Добрый день, скажите, вот мы попытались найти элементы в приемнике сначала по УИД, потом по полям поиска и в случае, если не нашли, то можем ли мы пользователю открыть форму с таблицей, где перечислен список не найденных в приемнике элементов для того, чтобы пользователь принудительно поставил соответствие базы приемника и дальше продолжил загрузку? Как это реализуется?
Я рассматриваю задачу разовой выгрузки без изменения конфигураций (без добавления регистров сопоставления). То есть в моей задаче явно есть элементы, которые нужно сопоставить, но нет ни одного поля, по которым я могу автоматически это сделать, но пользователь готов вручную их сопоставить с помощью таблицы.
Добрый день
В обработке Универсальный обмен такого функционала нет. При загрузке через обмены, встроенные в новые конфигурации, такое окно выдается для проверки/изменения ручного сопоставления. Если Вы можете настроить типовой обмен, возможно, лучше им воспользоваться.
Если нет, возможны разные варианты. Например, можно выгрузить элементы вместе с идентификаторами из одной из баз, а во второй загрузить их, и набросать обработку, где для каждой строки такой таблицы пользователь выбрал бы ссылку из текущей базы. А результат сопоставления можно записать, например, в дополнительные реквизиты объектов, или просто в файл, который загрузить в событии перед загрузкой и сверяться по нему. Или в регистр Соответствие объектов информационных баз, он скорее всего есть в конфигурации
Потому что чтобы сделать такой механизм именно при загрузке, сначала надо прочитать файл, получить информацию, предложить пользователю форму сопоставления, а потом уже читать еще раз и загружать
Здравствуйте.
Вопрос по 1C-ConvData-Module1-Chapter04-Lesson07.
Не понятно про КлючВыгружаемыхДанных.
КлючВыгружаемыхДанных в файле с выгруженными данными можно увидеть?
КлючВыгружаемыхДанных = UUID?
КлючВыгружаемыхДанных = Ссылке?
В обработках, отвечающих за конвертацию, есть коллекция ВыгруженныеОбъекты. При выгрузке ссылочных данных в эту коллекцию помещается идентификатор выгруженого объекта. При стандартном поведении этот идентификатор – ссылка на этот объект. Если объект с такой ссылкой уже выгружался, то обработка пропускает такой объект и не выгружает его повторно.
Но иногда нам нужно выгрузить объект несколько раз, например, когда в источнике справочник независимый, а в приемнике – подчиненный. То есть мы по сути один элемент справочника в источнике выгружаем в несколько элементов в приемнике. В этом случае мы устанавливаем КлючВыгружаемыхДанных, который состоит из UUID элемента справочника и UUID владельца. Ключ для каждого такого элемента становится уникальным и данные выгружаются корректно. Есть подробная статья на эту тему https://infostart.ru/public/887008/, если вдруг остались непонятки
Здравствуйте! Подскажите по реализации. Нужно синхронизировать объекты по регистру сведений, который есть в конечной базе, в нем есть поля (КодИсточникНом, НаименованиеИсточникНом, КодКонечНом,НаименоКонеч, СсылкаНом,СсылкаХарак). В нем уже сделано сопоставление и заполнены ссылки. Задача состоит в том , что в исходной не было учета по хар-кам, а в конечной есть. Как в документах подставлять характеристику из регистра?
Допустим есть документ с ТЧ Товары с реквизитами Номенклатура и Характеристика. В ПКО Номенклатуры в полях поиска я делаю поиск по регистру по наименованию и коду. А как передать характеристику?
В ТЧ товары в ПКС Характеристика перед выгрузкой создать ИсходящиеДанные в которые передать ОбъектКоллекции.Номенклатура.Код и ОбъектКоллекции.Номенклатура.Наименование? И где потом получить характеристику по ним? или лучше как то сразу при получение номенклатуры сразу в какой -то параметр записывать характеристику?
Добрый день
Не совсем понял Вашу постановку задачи.
В исходной базе Номенклатура = Номенклатура + Характеристика в конечной или как?
Подскажите в каком уроке рассматривается синхронизация объектов по регистру сведений сопоставление объектов?
Добрый день
В обмене между типовыми решениями при включенном поиске по Уникальному идентификатору в ПКО сопоставление объектов автоматически происходит с использованием регистра сведений Соответствия объектов информационных баз. В курсе это сопоставление не рассматривается, оно внутреннее, повлиять на него типовыми средствами нельзя
интересовало именно написание своих правил с использованием этого регистра. Нашел что-то подобное в уроке синхронизация по внешним данным
Да, можно передавать уникальный идентификатор и тип данных источника через параметры объекта и искать объект запросом. Еще нужно при создании нового объекта после загрузки добавлять записи в этот регистр.
Добрый день!
Вопрос по ключу выгружаемых данных. Как можно описать универсальный ответ на вопрос – требуется создавать “КлючВыгружаемыхДанных” для текущего ПКО или нет?
Забегая в перед (ДЗ 1.4.2), дополнение к данном правилу, как я понял, если в ПКО нет источника, добавлять перед выгрузкой
Добрый день.
КлючВыгружаемыхДанных нужно определять, если в ПКО не указан объект источник, или если по этому правилу должны выгружаться нессылочные объекты – строки, структуры, строки таблиц значений. Тогда кэширование станадартными средствами не будет работать, или будет работать некорректно
Да, если ПКО настроено без источника, кэширование автоматически отключается, его нужно включить в обработчике
Спасибо!
Не замещать значение свойства №3
Добрый день!
Прочитал и просмотрел видео и по первой версии этого вопроса и ниже по второй. Но в голове до конца не уложилось, как обойти проблему. Можете пожалуйста написать решение данной проблемы на конкретном примере, допустим реквизите “Код” ПКО “Сотрудники” из ДЗ 1.3.1 / 1.3.2 ? Если после выполнения ДЗ в ПКС “Код” указать “Не замещать значение свойства у существующих объектов в приемнике” и в Конечной базе создать Сотрудника с ИНН из Источника, то при выгрузке произвольный “Код” данного сотрудника затирается. (КД 2.1.8.2, обновлений видимо уже не будет)
Спасибо!
Добрый день
Как написал тогда слушатель курса в вопросе, лучше всего установить свойство ОбъектНайден в значение Истина, и тогда все флажки “Не замещать значение свойства” будут работать в этом ПКО.
То есть если брать задание 1.3.1, нужно в ПКО Сотрудники в обработчике При загрузке написать
Если НЕ НужноБылоЗаписатьОбъект Тогда
ОбъектНайден = Истина;
КонецЕсли;
КонецЕсли;
Спасибо!
Здравствуйте. Для проверки синхронизации по уникальному идентификатору создал простейшее ПКО по переносу справочника “Должности” (ЗУП 3.1) в спр. “Должности организации” (УПП 1.3). В ПКС только поле “Наименование” с включенным флагом поиска. В ПКО включен поиск по уникальному идентификатору и поиск по полям. Больше в правилах ничего нет. Создал в ЗУП должность “Тест”. При переносе в УПП должность организации “Тест” появился.
Вопрос: с помощью обработки проверил их уникальные идентификаторы – они разные, почему?. Если в УПП переименовать “Тест” в “Тест1” и еще раз сделать перенос то тогда создается вторая должность “Тест”. При выгрузке с ЗУП и загрузке в УПП использую их встроенные обработки Универсальный обмен данными в формате XML, версии конфигураций актуальные.
Добрый день
Посмотрите в файл данных. Там, во-первых, в узле ПравилаОбмена найдите нужное правило, у него должно быть свойство СинхронизироватьПоИдентификатору, значение true.
Во-вторых, найдите узел Объект, в котором выгрузилась должность Тест. Там в узле Ссылка первый узел Свойство должен содержать Уникальный идентификатор.
Можно попробовать использовать внешнюю обарботку, которая входит в поставку КД 2, она всегда работала корректно
Подскажите, как исправить след. ситуацию:
1) Делаю перенос документа в котором переносится транспортное средство.
В ПКО Документа есть ПКС ТранспортноеСредство-Машина ПравилоКонвератции ТранспортноеСредствоСклад
2) В ПКО ТранспортноеСредствоСклад одно ПКС с флагом поиск по реквизиту ТС Значение = Источник; с ПКО ТранспортныеСредства
3) В ПКО ТранспортныеСредства тоже одно ПКС с флагом поиска по коду
Получается такая ситуация, что в базе конечной есть два склада, где задано ТС из источника. Но мне нужно взять такой склад, где его дата закрытия не заполнена (реквизит склада).
Нужно в ПКО ТранспортноеСредствоСклад в обработчике Поля поиска написать запрос, который бы выбирал склад, у которого ТранспортноеСредство такое, как в соответствии СвойстваПоиска[“СС_ТранспортноеСредство”], а дата закрытия не заполнена.
Ссылку на найденный склад нужно записать в параметр СсылкаНаОбъект
При выполнении дз 1.3.2 возникла проблема с синхронизацией сотрудников по ИНН, а затем по Наименованию.
в базе источнике реквизит называется “ИНН_Сотрудника”, а в приемнике “ИНН”
Сотрудники грузились только по сочетанию ИНН и Наименование, хотя я в закладке “поля поиска” добавил код:
СтрокаИменСвойствПоиска="ИНН_Сотрудника";
ИначеЕсли НомерВариантаПоиска=2 Тогда
СтрокаИменСвойствПоиска="Наименование";
КонецЕсли;
Потом выяснил, что нужно было вместо “ИНН_Сотрудника” указать “ИНН”.
Правильно ли я понял, что для синхронизации берутся названия реквизитов базы приемника?
Добрый день
При поиске объекта по полям при загрузке в базе-приемнике создается запрос. И СтрокаИменСвойствПоиска – это набор полей, на которые в этом запросе будут наложены условия в разделе ГДЕ. Поэтому, конечно, нужно, чтобы это были имена свойств именно из базы-приемника.
Здравствуйте.
Подскажите, пожалуйста, по какому уникальному идентификатору происходит поиск при переносе из регистра сведений в справочник?
Т.е. объект источник – это регистр сведений, объект приемник – это справочник (свойства у них например одинаковые).
В ПКО установлена галочка искать по внутреннему идентификатору.
Как будет происходить поиск, в этом случае, какой уникальный идентификатор используется (объект источник не ссылочный же в этом случае)?
Добрый день
В этом случае не будет выполняться поиск по Уникальному идентификатору. Только по полям поиска.
Добрый день. Подскажите пожалуйста с проблемой. У меня есть два ПКО СотрудникПредпирятия и СотрудникиВыгрузкаДолжностиДляДокументаПринят. Отличия этих правил в том что в одном не выгружается должность а во втором выгружается должность с помощью флага получить из входящих данных(для дом. Задания по приему на работу). Проблема заключается в том что при выгрузки первого справочника без должности он ругается на должность. В чем может быть проблема т.к. в ПВД указано правильно правило СотрудникиПредприятия? Заранее спасибо за ответ.
Ошибка при выгрузке данных: {ВнешняяОбработка.УниверсальныйОбменДаннымиXML.МодульОбъекта(1693)}: Ошибка получения свойства объекта из входящих данных
ПКО = СотрудникиВыгрузкаДолжностиДляДокументаПринят (Справочник: Сотрудники предприятия)
ПКС = 1 (–> ДолжностьСотрудника)
Объект = Уволенные (Сотрудники предприятия)
СвойствоПриемника = ДолжностьСотрудника (СправочникСсылка.ДолжностиСотрудников)
ОписаниеОшибки = Получение элемента по индексу для значения не определено
ПозицияМодуля = ВнешняяОбработка.УниверсальныйОбменДаннымиXML.МодульОбъекта(8282)
КодСообщения = 68
)
Добрый день.
Здесь по ссылке из элемента справочника Сотрудники выгружается Родитель – группа справочника (Уволенные). В ПКО СотрудникПредприятия в ПКС Родитель, видимо, не указано ПКО. Оно подбирается автоматически – то, которое для выгрузки должности.
Если для одного типа объектов создано два ПКО, нужно во всех ПКС обязательно указывать, какое использовать.
Здравствуйте! По работе возник практический вопрос по синхронизации данных. Есть УТ10.3 и БП3.0. Обмен через стандартный механизм обмена, но по своим правилам конвертации. Почему-то не переносятся справочники по ссылкам. Если изменить сами справочники, то они регистрируются для выгрузки и нормально переносятся, а если надо перенести по ссылке с документом, то не переезжают.
Проблема выяснилась, когда понадобилось в обмен подключить еще одну организацию, у которой в УТ уже были ранее созданы договора контрагентов. Документы переносятся, а договора нет, соответственно документы в БП не открываются, так как на месте договора битая ссылка.
И нигде не могу найти, может где-то галка должна стоять что надо переносить по ссылкам, а не только при изменениях справочников.
Подскажите куда рыть?
Добрый день!
Во всех регулярных обменах, встроенных в типовые, по умолчанию объекты свойств по ссылкам не выгружаются. Это логично, потому что если объект не изменен, выгружать его незачем, а если изменен, то он зарегистрируется и будет выгружен отдельно.
Чтобы по ссылке из свойства объект выгружался целиком, нужно в ПКС для этого свойства в обработчике Перед выгрузкой написать
ВыгружатьОбъект = Истина;
Огромное спасибо!!!
вопрос по видео:
1C-ConvData-Module1-Chapter04-Lesson08.ufm
интересный разбирается пример с программной синхронизацией номенклатуры через регистр сведений. А как быть с ранее задвоенной номенклатурой. То есть некий разработчик, который не изучал ваш курс по конвертации, перенес номенклатуру по уид из одной рабочей базы в другую и естественно получилось задвоение более 1000 позиций номенклатуры. Есть какой-то способ программно в конвертации отловить номенклатуру совпадающую по уид ее удалить (или хотя бы как-то поменять название ей, чтобы потом удалить через обработку задвоенных значений, а то там уид не виден) а в соответствие поставить по наименованию или артикулу как пользователи решат. Т.е. чтобы конвертация убрала задвоение – можно такой код написать, если можно то в каком обработчике? или есть какой-то другой алгоритм убрать задвоенность номенклатуры о котором я не догадываюсь и конвертация тут не поможет??
Добрый день!
То есть нужно удалить из базы-приемника ту номенклатуру, у которой УИД совпадает с номенклатурой из базы-источника? Создайте в тех же правилах, по которым переносилась номенклатура, еще одно ПКС – ПометкаУдаления, напишите в этом ПКС в событии Перед выгрузкой
Значение = Истина;
И все перенесенные элементы будут помечены на удаление. И если была перенесена только сама номенклатура, без других данных, которые могут на нее ссылаться, то можно ее удалить. Но если на нее есть ссылки, то нужно использовать обработку поиска и замены дублирующихся элементов, чтобы исправить такую ситуацию.
Ну да надо удалить ту что совпадает по УИД – это загруженная номенклатура. В базе ведется своя. Создать в тех же правилах проблематично – перенос написан руками через обработки выгрузкаxml загрузкаxml для документа. По ссылке загружается номенклатура там в коде видно создается элемент по уид, естественно не проверяется а есть номенклатура уже с таким названием или нет и вот получилось задвоение – номенклатура с одинаковым наименованием.
Хотя конечно отдельное правило пометить номенклатуру никто создать не мешает. Ссылки на нее есть – она в перенесенных документах. Придется видимо учиться пользоваться обработкой удаления задвоенных – она хоть ищет по удаленным – найдя можно отличить будет в ней где какой элемент?
Если сейчас Вы используете какой-то из обменов, встроенных в типовую конфигурацию, то отдельное правило для Номенклатуры создавать не нужно. Просто так называемые онлайн обмены синхронизируют объекты через регистр сведений, а у самих объектов в базе-приемнике может быть и не тот же идентификатор, что в базе-источнике.
Можно создать отдельное такое правило для Номенклатуры и произвести выгрузку-загрузку с помощью обработки Универсальный обмен данными XML. Или можно просто написать обработку, которая в одной базе получит список уникальных идентификаторов, а в другой пометит эти объекты на удаление.
Да, обработка поиска дублей ищет и помеченные на удаление, но в списке результатов поиска не видно, помечен объект на удаление, или нет. Она показывает, сколько в базе ссылок на каждый из объектов, и какие объекты на него ссылаются. Посмотрите эту обработку, а потом решите, нужно помечать лишние объекты на удаление, или нет.
Здравствуйте. По ходу прослушивания модуля возник вопрос
Есть ли смысл индексировать поля текстового типа?
Ведь в индексе будет содержаться та же строка, что и в самом объекте
Здравствуйте!
Если индексировать в объектах строковый реквизит, по которому планируется искать эти объекты, то поиск будет происходить быстрее, за счет упорядочивания индексов.
Но поиск работает и без индексирования.
Здравствуйте.
Все-таки вопросы по ключу выгружаемых данных.
В занятии преподаватель настраивал выдачу диагностических сообщений с ключом. Насколько я помню, в сообщении выдавалось три одинаковых набора ссылок (три пары данных):
Сообщить(КлючВыгружаемыхДанных);
Так мне и непонятно, чем три одинаковых ключа отличаются от выгрузки просто трех одинаковых ссылок без ключей. Почему в первом случае система кеширует данные (выгружая дубликаты, но не загружая их в базу приемник) а во втором случае выгружает вместо трех всего один объект, но трижды загружает его в базу приемник?
Здравствуйте!
Кэширование нужно для того, чтобы не выгружать объекты по нескольку раз. Например, один объект был уже выгружен полностью, но в том же сеансе выгрузки на него снова встретилась ссылка. Если кэширование отключено, этот объект снова будет выгружен полностью, при этом будет получен узел ссылки на этот объект и записан в свойство другого объекта, из которого на него встретилась ссылка.
Кэширование позволяет не выгружать объект повторно. Нужно только сохранять узлы ссылок на все выгруженные в этом сеансе объекты, и подставлять их, если опять встретилась ссылка на тот же самый объект. Узлы ссылок сохраняются со строковыми ключами. По умолчанию это значение функции ЗначениеВСтрокуВнутр() от ссылки на объект.
Таким образом, кэширование сокращает размер файла данных и время выгрузки и загрузки, т.е. сильно оптимизирует процесс. Но если один объект в базе-источнике должен быть загружен в приемник как несколько объектов, то нужно либо отключить кэширование, либо переопределить ключ. В этом случае ключ должен быть уникален для каждого итогового объекта, который уже будет загружен в конечную базу. В уроке это будет отдельный объект для каждого владельца, поэтому ключ должен быть уникален уже не для самого объекта, а для пары объект+владелец. Для каждого владельца в этом случае в файл данных выгружается отдельный объект, а узел ссылки на него запоминается с ключом Источник+Владелец.
С этим понятно. Обязательно ли определять ключ как ЗначениеВСтрокуВнутр(источник) или я могу его определить любым строковым значением, главное, чтобы значение (совокупность значений) было уникальным в рамках выгрузки?
Любую строку можно использовать как КлючВыгружаемыхДанных. Как ее получить – неважно, главное, чтобы она была уникальна для итогового объекта (объекта из конечной базы).
Здравствуйте!
При синхронизации данных в Конечной ИБ АртикулСобственный (9999999) замещается АртикуломПоставщика (8888888) для Дивана-кровати, чего быть не должно.
– В обработчике событий Поля поиска в ПКО Номенклатура прописан запрос:
Запрос.Текст =
"ВЫБРАТЬ
| Номенклатура.Ссылка
|ИЗ
| РегистрСведений.СоответствиеНоменклатуры КАК СоответствиеНоменклатуры
| ВНУТРЕННЕЕ СОЕДИНЕНИЕ Справочник.Номенклатура КАК Номенклатура
| ПО СоответствиеНоменклатуры.АртикулСобственный = Номенклатура.Артикул
|ГДЕ
| СоответствиеНоменклатуры.АртикулПоставщика = &АртикулПоставщика";
Запрос.УстановитьПараметр("АртикулПоставщика", СвойстваПоиска["Артикул"]);
РезультатЗапроса = Запрос.Выполнить();
Выборка = РезультатЗапроса.Выбрать();
Если Выборка.Следующий() Тогда
СсылкаНаОбъект = Выборка.Ссылка;
КонецЕсли;
– в Настройках ПКО Номенклатура ставим флаг Продолжить поиск по полям поиска
– Добавляем ПКС Артикул/Артикул (флаги Поиск объекта по при загрузке по свойству и Отключить обработку правил)
– в Конечной ИБ в регистре сведений СоответствиеНоменклатуры запись по артикулам создал (8888888/9999999)
Спасибо!
Извините за дублирование, мои посты перестали отображаться в 2-х браузерах.
Забыл приложить вложение.
Здравствуйте!
Скорее всего, объект находится по уникальному идентификатору. Попробуйте отключить поиск и УИД в ПКО, еще раз выгрузить и загрузить данные.
Нужно еще иначе передавать Артикул. В текущей версии обработки по отключенным ПКС не переносятся данные. Нужно создать ПКС с видом “Передавать данные в параметр”, указать имя параметра “Артикул”, и свойство-источник “Артикул”. Это ПКС нужно отметить флагом поиска. Тогда в обработчике ПоляПоиска значение артикула можно получить из соответствия ПараметрыОбъекта по ключу “Артикул”:
Запрос.УстановитьПараметр(“АртикулПоставщика”, ПараметрыОбъекта[“Артикул”]);
После сделанных изменений, при загрузке в Конечной ИБ выдает ошибку:
Ошибка при загрузке данных: {Обработка.УниверсальныйОбменДаннымиXML.МодульОбъекта(1629)}: Ошибка в обработчике события ПоследовательностьПолейПоиска
ИмяПКО =
ТипОбъекта = Номенклатура
Обработчик = Последовательность полей поиска
ОписаниеОшибки = Получение элемента по индексу для значения не определено
ПозицияМодуля = (13)
КодСообщения = 73
Ошибка в обработчике события ПоследовательностьПолейПоиска
ИмяПКО =
ТипОбъекта = Номенклатура
Обработчик = Последовательность полей поиска
ОписаниеОшибки = Получение элемента по индексу для значения не определено
ПозицияМодуля = (13)
КодСообщения = 73
Что делал:
– В ПКО Номенклатура отключил поиск по УИД (заодно отключился пункт Продолжить поиск по полям поиска)
– В ПКС Артикул переключатель ставлю Передавать данные в параметр и флаг Поиск объекта при загрузке по свойству. После сохранения и повторного открытия ПКС видно,ч то переключатель самостоятельно вернулся в положение Передавать данные в приемник
– в Обработчике Поля поиска написал
– если в Обработчике Поля поиска код не менять, то опять при зарузке Артикул замещается Артикулом поставщика.
Остальной код не изменял.
Когда Вы переключатель устанавливаете в положение “Передавать данные в параметр”, нужно указать имя параметра (поле “Параметр”) – “Артикул”, тогда он не будет возвращаться в положение “Передавать данные в приемник”
Уточнение по лучшему вопросу №3 “Синхронизация по полям поиска”.
Правильно понимаю, что предлагается:
1) в конфигураторе Конечной добавить строковый реквизит для хранения УИД;
2) создать ПКС без источника, перед выгрузкой заполнить значение, указать поиск по этому свойству;
3) в обработчике Поля поиска на второй итерации указать СтрокаИменСвойствПоиска = ?
Верно ли утверждение, что в типовых конфигурациях используется похожий механизм, только для оптимизации информация хранится не в самих объектах, а в регистре сведений?
Здравствуйте!
Да, в ответе на вопрос предлагается такая схема.
В типовых механизм несколько другой. Там действительно идентификаторы хранятся в регистре. И поиск по уникальному идентификатору выполняется не в базе, а в регистре. Он тоже идет как нулевая итерация, то есть до выполнения обработчика Поля поиска. В регистре указывается также узел, для которого актуально это соответствие идентификаторов. То есть один объект может иметь разные идентификаторы в трех базах, но синхронизироваться именно по идентификатору при обмене между этими базами.
Поэтому регистр – это несколько другой механизм, более удобный.
Здравствуйте!
При синхронизации данных в Конечной ИБ АртикулСобственный (9999999) замещается АртикуломПоставщика (8888888) для Дивана-кровати, чего быть не должно.
– В обработчике событий Поля поиска в ПКО Номенклатура прописан запрос:
Запрос.Текст =
"ВЫБРАТЬ
| Номенклатура.Ссылка
|ИЗ
| РегистрСведений.СоответствиеНоменклатуры КАК СоответствиеНоменклатуры
| ВНУТРЕННЕЕ СОЕДИНЕНИЕ Справочник.Номенклатура КАК Номенклатура
| ПО СоответствиеНоменклатуры.АртикулСобственный = Номенклатура.Артикул
|ГДЕ
| СоответствиеНоменклатуры.АртикулПоставщика = &АртикулПоставщика";
Запрос.УстановитьПараметр("АртикулПоставщика", СвойстваПоиска["Артикул"]);
РезультатЗапроса = Запрос.Выполнить();
Выборка = РезультатЗапроса.Выбрать();
Если Выборка.Следующий() Тогда
СсылкаНаОбъект = Выборка.Ссылка;
КонецЕсли;
– в Настройках ПКО Номенклатура ставим флаг Продолжить поиск по полям поиска
– Добавляем ПКС Артикул/Артикул (флаги Поиск объекта по при загрузке по свойству и Отключить обработку правил)
– в Конечной ИБ в регистре сведений СоответствиеНоменклатуры запись по артикулам создал (8888888/9999999)
Здравствуйте. Возникли сложности с выполнением ДЗ. Синхронизация работает, но интересует правильная ли логика решения или нет.
Т.е. я проверил так: создал в приемнике сотрудника, присвоил ему ИНН, такой же который существует в базе источнике. После обмена, новый элемент не создался, т.е. произошла синхронизация по ИНН, далее я изменил в приемнике ИНН, и еще раз загрузил, после чего произошла загрузка нового элемента. Но почему то группы все не загрузились, остается все время группа «Уволенные», а остальные я так понял почему то затираются, т.к. при обмене выгружено 8 объектов и загружено тоже 8, получается что при загрузке что то затирается. И такой вопрос: а можно это сделать не через служебное поле «Комментарий», ведь на практике может такого поля и не быть, а добавлять в типовую конфигурацию не хочется. Как то через параметр? например создать параметр, заполнить его и обратиться к нему через «ПараметрыОбъекта»?, при этом этот параметр флагом поиска тоже должен быть отмечен? и при создании такого параметра в поле «источник» может быть пусто?
Здравствуйте!
На скриншоте ПКС Наименование не отмечено флагом поиска, поэтому оно не может использоваться для поиска в базе-приемнике. В результате группы ищутся только по свойству ЭтоГруппа, оно у всех них Истина, и они сливаются в одну, которая загрузилась последней.
По комментарию искать не нужно. На самом деле в задании 1.3.1 не надо делать ничего такого сложного. Нужно поставить в ПКО флажки “Поиск по Уникальному идентификатору” и “Продолжить поиск по полям, если по идентификатору не найден”. Тогда при первом поиске объекты будут найдены по полям. (Поскольку в базе-приемнике еще нет объектов с таким же идентификатором, как в источнике). А если не будут найдены, то будут созданы новые, уже с правильным идентификатором. И дальше поиск будет происходить по идентификатору, а потом – по полям.
Скажите пожалуйста, когда мы используем обработчик “Поля поиска”, мы обязательно должны отметить поля поиска только те, что используются в этом обработчике? или мы можем пометить полей поиска больше, а использовать меньше?
т.е. если мы пометим флаги “Код”, “ЭтоГруппа”, “ИНН”. а в обработчике сделаем проверку на условие Если НомерВариантаПоиска = 1 Тогда
…. ИНН…..
а остальные не будем использовать, то как система будет осуществлять поиск? только по ИНН? или другие поля тоже будут участвовать?
Мы должны обязательно отметить флажками поиска все свойства, которые могут потребоваться для поиска. Какие именно из них использовать, можно настроить в обработчике ПоляПоиска. Если написать
СтрокаИменСвойствПоиска = “ИНН”;
, то в этом случае поиск будет идти только по ИНН, остальные свойства для этого использоваться не будут, даже если они отмечены флагами поиска. Это нормальная ситуация, так часто делают.
Здравствуйте я прошел материалы 4 главы и у меня такие вопросы:
1. В файл данных попадают данные по тем пкс, по которым настроены флаги поиска, например для справочника «Контрагенты» это УИД, ИНН, КПП, ЭтоГруппа.
А остальные поля, которые не помечены флагом поиска тоже всегда попадают в файл или не всегда? Они ведь тоже при загрузке заполняются из базы источника(обновляются). Откуда эта информация берется, если не из файла?
2. можно по подробнее про 2 флажка “Поиск” и “Отключить”. В видео 04.08 мы создавали ПКС “Артикул”, установив по нему “Поиск”, это означало, что поиск по Артикулу так же войдет в поля для поиска, но как только мы “Отключили” данное ПКС, то оно получается не будет участвовать в обмене и в поиске темболее? т.е. информация по Артикулу не будет записываться в файл.
И как я понял, если мы используем обработчик “Поля поиска”, то в нем мы можем использовать только те поля, которые обозначены флагом “Поиск”, а можем и не все использовать, т.е. например флаг поиск установлен для “Код”, но в обработчике мы так нигде его и не использовали.
3. В обработчике “Поля поиска” мы писали запрос. можно ли еще пример когда можно писать запрос? а то сложность у меня с тем, что я не всегда понимаю какими методами начать решать задачу, с чего начать. Т.е. например почему мы использовали именно обработчик Поля поиска, а не “После загрузки”, и Почему мы не использовали запрос в обработчике “перед выгрузкой”. Можно немного примеров, какой обработчик когда на практике чаще встречается?
Здравствуйте!
1. В файл данных в этом обмене все объекты, которые встретились по ссылкам, выгружаются целиком. Те свойства, что отмечены флагом поиска, представляют из себя узел ссылки. Они вставляются в свойства других объектов, чтобы можно было установить при загрузке ссылку на этот объект. Но сам объект тоже должен быть выгружен целиком.
2. Задача передачи дополнительной информации для произвольного поиска сейчас иначе решается. Нужно создать ПКС, установить там переключатель в положение “Передавать данные в параметр”, указать Источник – Артикул и имя параметра, например, тоже Артикул. Тогда в обработчике ПоляПоиска это значение можно будет получить как ПараметрыОбъекта[“Артикул”].
3. Обработчик Поля поиска всегда используют, когда нужно решить задачу, связанную с поиском объектов в информационной базе при загрузке. Он происходит, когда уже получены значения свойств поиска загружаемого объекта, но поиск еще не был произведен, на него можно повлиять. В других обработчиках еще либо нет этих свойств, либо поиск уже был произведен.
Если задача касается поиска объектов – нужно всегда использовать обработчик ПоляПоиска. Если нужно что-то сделать на стороне выгрузки – часто используют обработчики ПКО Перед выгрузкой и При выгрузке. Если на стороне загрузки нужно, например, дозаполнить объект, то это обработчик После загрузки
Спасибо.