Занятие № 19. Курс «1С:Конвертация данных 2.1 – Профессиональная настройка правил обмена и типовые сценарии переноса данных»
Работа с правилами регистрации объектов и другие настройки Конвертации данных
Изучите теорию модуля № 4:
- Глава 7. Настройка регистрации объектов в on-line обмене
- Глава 8. Прочие настройки конвертации
Выполните практическое задание:
Отчеты по домашним заданиям размещайте по ссылкам, указанным выше. Отчеты, опубликованные на этой странице, удаляются без предупреждения.
Ваши вопросы по материалам данного занятия задавайте в комментарии ниже.
Общие вопросы по курсу, не связанные с конкретным занятием, задавайте на странице: 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 поддержки.
Комментарии / обсуждение (147):
Комментарии закрыты
Вопрос по режимам выгрузки.
“Если у справочников переключатель режима в положение “Выгружать при необходимости”, тогда эти справочники будут выгружаться полностью, но только в том случае, если они первый раз встретились по ссылкам из других выгружаемых объектов. В дальнейшем эти объекты не будут выгружаться по ссылкам целиком (выгрузится только ссылка)…”
1. Такое поведение будет только в том случае, если в ПКО справочников стоит поиск по УИД? а если его нет, то такой справочник не попадет в РС.СоответствиеОбъектовИБ и будет всегда выгружаться целиком , а не только ссылка?
2. Если в ПРО выбран режим ВыгружатьПоНеобходимости и определены условия – они будут работать совместно? т.е. проверяется соответствие режиму выгрузки + соответствие правилам регистрации?
1) Даже если поиск по уникальному идентификатору отключен, то он все-равно запишется в регистр, соответственно, после успешного обмена, выгружаться будет только ссылка.
2) Если будет стоять ВыгружатьПоНеобходимости, то будет выгружено по ссылке, даже если не соответствует условию в правилах регистрации.
AlexeyDubrovin сказал: “1) Даже если поиск по уникальному идентификатору отключен, то он все-равно запишется в регистр, соответственно, после успешного обмена, выгружаться будет только ссылка….”
Какие-то противоречивые сведения.
Или в одном из уроков или в ответах преподавателей (не помню точно в каком месте) было сказано следующее:
” Объект записывается в регистр «Соответствия объектов», только если флаг поиска по идентификатору в ПКО установлен. Если он снят, и поиск идет только по полям, то уникальный идентификатор этого объекта не переносится совсем. ”
Все-таки какое утверждение верное?
Вполне допускаю, что такое утверждение в курсе есть. Лучший способ узнать истину – проверить.
Я проверил на конфигурации, которая была под рукой (УТ 11.1.10.131)
В регистр записалось при первой выгрузке
При второй выгрузились только поля поиска
Вполне допускаю, что в разных версиях БСП может быть разная реализация этого механизма.
Провела такой эксперимент: Обмен УТ(11.1.10.145) и БП (3.0.39).
версия БСП 2.2.5. Внесла изменения в существующие ПКО для номенклатуры, убрала поиск по УИД, оставила только по полям поиска.
Т.к. ранее производился обмен, то РС.СоответствиеОбъектовИБ был заполнен, поэтому , для эксперимента, на стороне бухгалтерии удалила одну запись для эл-та номенклатуры. Далее на стороне УТ зарегистрировала этот элемент к обмену.Сразу оговорюсь, что на стороне УТ удалять такую же запись регистра соответствия сразу нельзя, т.к. режим выгрузки справочников = ПоНеобходимости и поэтому невозможно будет зарегистрировать этот элемент к обмену (см. процедуру ОбменДаннымиСобытия.ПолучитьМассивУзловДляРегистрацииВыгружатьПриНеобходимости)
В результате в файле обмена в узле Ссылка были только поля поиска и не было УИД и после обмена на стороне бухгалтерии новая запись в регистре соответствий не появилась
Эксперимент немного не соответствует или мы немного про разное говорили.
Я делал так (на стороне УТ)
1) у номенклатуры убрал поиск по УИД
2) у номенклатуры режим выгрузки при необходимости
3) сделал новую номенклатуру, она не зарегистрировалась, так как режим по необходимости
4) сделал документ ПоступлениеТоваровУслуг с этой номенклатурой
5) нажал синхронизировать и в РС в УТ появилась строчка и выгрузилась номенклатура полностью
6) убрал регистрацию всех объектов
7) Скопировал ПТУ, снова провел обмен – выгрузились только поля поиска
Собственно и у Вас выгрузились только поля поиска из УТ, а Вы говорили, что при обмене будет всегда выгружаться объект полностью, если нет поиска по УИД.
Я не утверждала, что всегда объект будет выгружаться полностью, а спрашивала :) Попробую посмотреть еще раз.
Хотелось бы еще раз остановиться на особенности выгрузки УдалениеОбъекта в ситуации, когда на момент выгрузки объект перестал отвечать фильтру по свойствам закладки Основное.
Вот ситуации такого рода на примере ДЗ:
Вариант1. у узла взведен флаг НеВыгружатьПомеченныеНаУдаление, объект зарегистрирован на узле и потом помечается на удаление
Вариант2. Объект зарегистрирован и потом очищено “Основное свойство”
В обработчике ПРО ПриОбработке прописала код:
Для каждого Узел из МассивУзлов Цикл
Если Объект.ПометкаУдаления И Узел.НеВыгружатьУдаленные и ПланыОбмена.ИзменениеЗарегистрировано(Узел, Объект) Тогда
ПланыОбмена.УдалитьРегистрациюИзменений(Узел,Объект);
КонецЕсли;
Если Объект.ОсновноеСвойство = Справочники.СвойстваНоменклатуры.ПустаяСсылка() И ПланыОбмена.ИзменениеЗарегистрировано(Узел, Объект) Тогда
ПланыОбмена.УдалитьРегистрациюИзменений(Узел,Объект);
КонецЕсли;
Конеццикла
Код отрабатывает, но регистрация объекта удаляется только для варианта1, а вот для варианта 2 – нет.
Причем в отладчике до выполнения обработчика выражение
ПланыОбмена.ИзменениеЗарегистрировано( ВсеУзлыПланаОбмена(“ОбменКонечнаяУТ11”)[0], Объект) показывает что объект зарегистрирован на узле, а после выполнения – нет, НО в итоге регистрация остается…Я так и не докопалась до причины. Подскажите в чем тут дело?
Варинт 3. Регистрируем объект – очищаем Основное свойство (регистрация почему то остается) – Помечаем на удаление (регистрация все равно остается, т.к. до обработчика дело не доходит, потому что объект не проходит фильтр ПРО по свойствам, и если выгрузить сейчас , то выгружается УдалениеОбъекта), – опять возвращаем Основное свойство не снимая пометку удаления – регистрация объекта удаляется (отрабатывает обработчик ПриОбработке)
Добрый день
А в обработчике При обработке Дополнительный написали что-нибудь? Попробуйте написать Отказ = Истина. Я думаю, дело в том, что когда Вы очищаете Основное свойство, то при проверке Объекта регистрация удаляется. А потом происходит проверка ссылки, она проходит успешно (даже если такой же код отрабатывает. Потому что объект еще не записан, и в ссылке Основное свойство заполнено). И объект опять регистрируется
В обработчике ПриОбработке (доп.) есть код Отказ = Истина и он не влияет на выгрузку УдалениеОбъекта., т.к. объект регистрируется первоначально в момент когда удовлетворяет правилам, а вот потом, когда изменения объекта уже не удовлетворяют правилам ( а он к этому времени был зарегистрирован) то выгружается УдалениеОбъекта.
Код обработчика ПРО ПриОбработке (см.выше)по идее должен удалять регистрацию таких объектов, но он почему то срабатывает только для одной ситуации: пометки на удаление зарегистрированного ранее объекта. А вот если очистить Основное свойство уже зарегистрированного к выгрузке объекта, то этот код не срабатывает, регистрация не удаляется и выгружается Удаление объекта.
Вот сами правила
Добрый день.
Не получается на моей базе воспроизвести.
Отправьте, пожалуйста, выгрузку базы на support@kursy-po-1c.ru, я на ней посмотрю
Ни в одном видео не упоминается о сценариях обмена данными. Хотелось бы узнать как их использовать
Добрый день
В форме, где настроены обмены, есть возможность настроить обмен по расписанию. Это и есть сценарий. Настраивается направление обмена, обычно сначала получение, потом отправка. И расписание – с какого времени и как часто.
Обмен будет выполняться автоматически в указанное время
Если в ПРО описать условия на вкладке Основное и в обработчике “Перед Обработкой” определить ТекстЗапроса, то условия на вкладке Основное будут проигнорированы и условия будут определяться запросом из обработчика?
Добрый день
Нет, условия на свойства плана обмена и объекта, которые настраиваются на закладке Основное, проверяются до выполнения запроса. Если эти условия не выполняются, до запроса дело не дойдет объект не будет зарегистрирован. Запрос выполняется, только если эти условия соблюдаются
Т.е. если объект проходит по условиями на закладке Основное, то мы можем дополнительно сократить массив узлов получателей с помощью запроса обработчика ПередОбработкой. А если в этом обработчике ничего не писать, то объект, удовлетворяющий условиям закладки Основное зарегистрируется на всех узлах этого плана. Все верно?
Да, именно что сократить массив. На тех узлах, по которым не выполняются условия по свойствам плана обмена, он все равно не зарегистрируется, не зависимо от того, будет запрос написан, или нет
Здравствуйте!
Возможно ли задание 4.19.1 решить полностью не используя вкладку “Основное”, к примеру в обработчике “ПередОбработкой”? Возможно ли всегда использовать в ПРО только обработку в обработчиках и будет ли это правильно с точки зрения оптимальности?
Здравствуйте
Да на оба вопроса. А что касается оптимальности, то тут вряд ли возможен однозначный ответ. Что будет оптимальнее универсальный код БСП или Ваш код, который запускается по сути через Выполнить(ВашКод) ? Опять же что оптимальнее: потратить несколько секунд на настройку отборов мышкой или несколько больше времени на написание кода обработчиков и их отладку ? Абсолютно неоднозначно. На мой взгляд в большинстве случаев оптимальнее воспользоваться конструкторами и сэкономить свое время. А в обработчики лезть, если возможностей конструкторов не хватает.
Спасибо!
Здравствуйте! В регистрацию не попадает документ (авторегистрация отключена) при изменениях в табличной части. В документе в ТЧ есть реквизит заявка и из нее заполняются остальные поля в ТЧ (количество например). Когда пользователь заходит в этот документ из ТЧ документа и меняет там количество то объект не встает на регистрацию хотя количество из заявки поменялось. В таком случае надо ставить авторегистрацию или как можно указать, что при таких изменениях нужно ставить на регистрацию?
Добрый день!
А обработкой Регистрация объектов для обмена можно этот документ зарегистрировать? И в ПКО для этого документа есть ПКС для Заявки?
Причины две может быть: либо этот документ не проходит какие-то фильтры ПРО, тогда обработкой его тоже зарегистрировать не получится. Если обработкой он регистрируется, то это работает фильтр выборочной регистрации. Регистрируются объекты только при изменении тех свойств, для которых настроены правила. Этот фильтр можно отключить, тогда объекты будут регистрироваться при любом изменении. Для этого в регистре сведений Правила для обмена данными найдите нужные правила обмена и снимите флажок Использовать фильтр выборочной регистрации.
Или можно настроить ПКС для Заявки, написать там При Выгрузке
Чтобы это ПКС фактически не отрабатывало
Убрал галку “Использовать фильтр выборочной регистрации” и документ зарегистрировался. Но я так понимаю, что правильнее сделать Значение = Неопределено; в пкс?
Сложный вопрос. Если это единственная такая ситуация, то лучше наверно добавить ПКС. Иначе много лишних объектов могут вставать на регистрацию.
Просмотрите внимательно правила обмена, много там таких потенциальных ситуаций? Если несколько, можно, наверно, и фильтр отключить
Или еще иногда бывают ошибки, а сообщения не выводятся. Тогда нужно смотреть в журнал регистрации
Здравствуйте! Есть правила регистрации для документа. В настройке узла есть ТЧ Участки и реквизит ДатаНачалаВыгрузки. Встала задача сделать датуНачалаВыгркузи для каждого участка, то есть надо В ТЧ Участки добавить колонку ДатаНачалаВыгрузки.
Сейчас правило выглядят так:
ПРО.СвойстваОбъекта.Вставить("ДатаПредполагаемойДоставки", "ДатаПредполагаемойДоставки");
ПРО.СвойстваОбъекта.Вставить("Участок", "Участок");
ПРО.СвойстваОбъектаСтрокой = "ДатаПредполагаемойДоставки, Участок";
ПРО.ТекстЗапроса = "
|ВЫБРАТЬ РАЗЛИЧНЫЕ
| ПланОбменаОсновнаяТаблица.Ссылка КАК Ссылка
|ИЗ
| ПланОбмена.ОбменАбонентУПП КАК ПланОбменаОсновнаяТаблица
|ГДЕ
| ((ПланОбменаОсновнаяТаблица.ДатаНачалаВыгрузкиДокументов <= &СвойствоОбъекта_ДатаПредполагаемойДоставки)
| И (НЕ ПланОбменаОсновнаяТаблица.ИспользоватьОтборПоУчасткам ИЛИ ПланОбменаОсновнаяТаблица.Участки.Участок = &СвойствоОбъекта_Участок))
| [ОбязательныеУсловия]
|";
получается, что будет так? :
ПРО.СвойстваОбъекта.Вставить("ДатаПредполагаемойДоставки", "ДатаПредполагаемойДоставки");
ПРО.СвойстваОбъекта.Вставить("Участок", "Участок");
ПРО.СвойстваОбъектаСтрокой = "ДатаПредполагаемойДоставки, Участок";
ПРО.ТекстЗапроса = "
|ВЫБРАТЬ РАЗЛИЧНЫЕ
| ПланОбменаОсновнаяТаблица.Ссылка КАК Ссылка
|ИЗ
| ПланОбмена.ОбменАбонентУПП КАК ПланОбменаОсновнаяТаблица
|ГДЕ
| ((НЕ ПланОбменаОсновнаяТаблица.ИспользоватьОтборПоУчасткам ИЛИ (ПланОбменаОсновнаяТаблица.Участки.Участок = &СвойствоОбъекта_Участок и ПланОбменаОсновнаяТаблица.Участки.ДатаНачалаВыгрузкиДокументов <= &СвойствоОбъекта_ДатаПредполагаемойДоставки)))
| [ОбязательныеУсловия]
|";
Добрый день
Да, похоже. Проверьте, как работает
Добрый день, возник вопрос. В обработке КонвертацияОбъектовИнформационныхБаз подсистемы “Обмены данными”
есть программный код
Или (Не ПустаяСтрока(ИмяПКО)) Тогда
Если ВыгрузитьТолькоСсылку Тогда
Если ВыгружатьОбъектПоСсылке(Значение, УзелДляОбмена) Тогда
Если Не ОбъектПроходитФильтрРазрешенныхОбъектов(Значение) Тогда
// выставляем признак того, что объект должен быть выгружен полностью
ВыгрузитьТолькоСсылку = Ложь;
// добавляем запись в регистр сопоставления
СтруктураЗаписи = Новый Структура;
СтруктураЗаписи.Вставить("УзелИнформационнойБазы", УзелДляОбмена);
СтруктураЗаписи.Вставить("УникальныйИдентификаторИсточника", Значение);
СтруктураЗаписи.Вставить("ОбъектВыгруженПоСсылке", Истина);
РегистрыСведений.СоответствияОбъектовИнформационныхБаз.ДобавитьЗапись(СтруктураЗаписи, Истина);
// добавляем объект в массив выгруженных по ссылке объектов
// для последующей регистрации объектов на текущем узле
// и для присвоения номера текущего отправленного сообщения обмена
ВыгруженныеПоСсылкеОбъектыДобавитьЗначение(Значение);
КонецЕсли;
КонецЕсли;
КонецЕсли;
так вот функция ОбъектПроходитФильтрРазрешенныхОбъектов проверяет наличие записей в РС “Соответствия объектов информационных баз”. И Если если его там нет то выгружает объект целиком. Мне необходимо чтобы объект всегда выгружался по ссылке целиком. (честно говоря прописывать в каждой строке ПКС “ВыгрузитьОбъект = Истина” или “ВыгрузитьТолькоСсылку=Ложь” по моему довольно дико). Если какой либо способ чтобы всегда допустим все справочники выгружались по сслыке из документа. Сейчас у меня есть два плана обмена, у них определен состав участников, сделаны ПКО и ПРО, настроен собственно сам обмен. Но из за такой части программного кода свойства по ссылкам выгружаются не всегда. То есть справочники сами по себе не должны приходить и уходить из ИБ в ИБ все только по ссылкам. И сразу хочу уточнить, я правильно понял что регистр “СоответствияОбъектовИнформационныхБаз” выгружается/загружается автоматически? Возникла ситуация, что в Источнике при выгрузке он заполняется (см. программный код выше), а в приемнике нет ( по этим объектам). Может ли это быть из за того что поиск по UUID по ним снят и стоит только по полям поиска
Добрый день.
Вам нужно в правилах регистрации установить для всех таких справочников переключатель режима в положение “Выгружать при необходимости”. Тогда эти справочники будут выгружаться полностью, но только в том случае, если они первый раз встретились по ссылкам из других выгружаемых объектов. В дальнейшем эти объекты не будут выгружаться по ссылкам целиком (выгрузится только ссылка), но зато будут регистрироваться к выгрузке, если их будут менять в источнике.
Приведенный Вами код относится именно к этому режиму выгрузки
Объект записывается в регистр Соответствия объектов, только если флаг поиска по идентификатору в ПКО установлен. Если он снят, и поиск идет только по полям, то уникальный идентификатор этого объекта не переносится совсем.
Здравствуйте. Можно ли использовать сложный запрос для определения необходимости регистрации объекта. Например, у меня есть справочник Договоры. Чтобы определить регистрировать его или нет мне нужно посмотреть характеристикиЗначений в регистре сведений. и это получается нужно делать уже после того как объект записался
Добрый день.
Сложный запрос сделать можно. Запрос может быть любым, он должен возвращать те узлы, на которых нужно зарегистрировать данный объект.
Стандартный механизм регистрации запускается с помощью подписки на событие ПередЗаписью, то есть тогда, когда объект еще не записан. Это позволяет сравнить его свойства до и после изменения, и решить, нужно ли его регистрировать.
ну вот например новый договор записываю. Характеристики ведь еще не записались в регистр сведений. А нужных реквизитов в самом договоре нет. Их нужно брать из регистра. Как в таком случае быть?
Возможно, нужно проанализировать, как данные попадают в регистр сведений, и исходя из этого принимать решение о регистрации.
Можно сделать правила регистрации для регистра сведений, а по факту регистрировать договор
Вообще, нужно подумать, насколько корректно поставлена задача
Спасибо, будем думать)
добрый день!
вопрос по итогам курса. вот мы разработали правила обмена внедрили бсп в свою конфигурацию, теперь можем конфигурацию продавать. Какие есть способы защиты конфигурации от нелегального распространения? то что бсп предлагает модуль проверки получения легальности обновления – это просто вопрос на который можно ответить да и спокойно пользоваться дальше. Что нибудь можете посоветовать по своей практике?
Здравствуйте!
Можно защитить код своей программы, например, установить на него пароль. Тогда Вашу конфигурацию не смогут модифицировать под собственные нужды или взять из нее фрагменты кода. А именно от нелегального распространения ничего не могу посоветовать, к сожалению.
Здравствуйте!
Просьба помочь разобраться во взаимодействии ПОД и ПРО. В каком порядке данные правила начинают свою работу?
Сформулирую задачу на конкретном жизненном примере:
Необходимо настроить синхронизацию УПП и УТ (типовые) справочника Номенклатура, только группа Материалы. Изначальный источник УПП.УТ пустая.
on-line обмен на базе БСП
1. Где настраивать правила отбора “Ссылка.Родитель В ИЕРАРХИИ “Материалы”?
1.1 Если ПРО, то только запросом в обработчике? В основном окне ПРО нет возможности настраивать подобные виды сравнения?
1.2 в ПКО номенклатуры настроить фильтрацию и отказываться от переноса “не нужной” номенклатуры.
2. В каком порядке отрабатывают ПРО и ПОД? При первой выгрузке считается, что все элементы зарегистрированы или только соответствующие правилам ПРО?
Если мы очистили приемник (УТ) после нескольких итераций синхронизации. Как сказать в УПП, что нам повторно нужно перенести “как в первый раз”?
Правильно ли я понимаю, что ПРО дает изначальную выборку данных, а далее, при синхронизации начинают отрабатывать ПОД? То есть мы в ПОД можем накладывать дополнительные условия и фильтры?
Например:
Отработали ПРО. К выгрузке 2 номенклатуры Стол и Стул
В ПКО Номенклатуры перед обработкой написано (условно):
Если Источник.Наименование = “Стол” Тогда Отказ = Истина КонецЕсли;
То перенесется только Стул?
Заранее благодарен за консультацию!
Здравствуйте!
1. Отбор выгружаемых элементов в регулярных отборах настраивают в ПРО. Да, в Вашем случае нужно использовать запрос в обработчике ПРО, поскольку в форме сравнение есть только на равенство и неравенство.
2. При создании нового узла плана обмена, на нем автоматически регистрируются все элементы, которые подходят по правилам регистрации.
В типовых конфигурациях есть обработка Регистрация изменений для обмена данными. С помощью этой обработки можно зарегистрировать снова всю информацию. Регистрироваться будут только те объекты, которые проходят ПРО.
Обычно фильтры на выгрузку объектов накладывают именно в ПРО, в этом их функция. Технически можно это сделать и в ПОД, но теряется прозрачность обменов. При выгрузке Вы можете оценить, какие объекты будут перенесены. А если какие-то из них по факту не будут выгружаться, легко запутаться, почему так происходит. Если нет весомых причин делать иначе, фильтры лучше настраивать именно в ПРО.
Ольга, спасибо Вам за развернутый ответ
Здравствуйте!
Ольга, подскажите, пожалуйста в чём может быть проблема?
При решении финального задания использую обмен УТ10.3 – БП 3.0. Настроил правила конвертации, применил, однако на стороне БП ни один из обработчиков, касаемых загрузки, не выполняется.
Я уже искал обработки типа “ОбработчикиЗагрузки” и т.п., их там нет. Загружал правила конвертации корреспондента, но всё равно он не выполняются.
Здравствуйте!
У меня вопрос по отключению режима совместимости. Настраивал обмен, как показано в видеоуроке 1C-ConvData-Module4-Chapter08-Lesson02.ufm с БП 8.3.7.1845. Несколько раз перезагружал правила. Попробовал выполнить аналогичную настройку в обратном направлении. Но обработчики загрузки срабатывают из правил конвертации, а не из обработок. Далее проанализировал код процедуры Обработки.КонвертацияОбъектовИнформационныхБаз.ИнициализироватьОбработки() в БП и исходной (БСП 2.1). В БП не обращений к функциям менеджера плана обмена ИмяОбработкиВыгрузки(), ИмяОбработкиЗагрузки(). Пришел к выводу, что БП режим совместимости используется всегда, в место этого нужно использовать ПравилаОбменаКорреспондента. Это так?
Здравствуйте!
Тоже проанализировала код по загрузке правил и по выгрузке данных в БП 3.0, действительно, свойство Режим совместимости там не используется. Режим совместимости считается включенным всегда. Есть режим отладки, в рамках этого режима можно запускать код из обработок. Но в рабочем режиме код выполняется из правил, при выгрузке из Правил обмена, при загрузке – из Правил обмена корреспондента
Здравствуйте!
При решении задачи возникает следующая ситуация: когда в имеющейся номенклатуре уже заполнено основное свойство, и пользователь очищает это свойство, после чего записывает объект, то данный объект почему-то регистрируется к выгрузке. В чем причина и можно ли это как-то победить, учитывая, что в обработчике “При обработке (доп.)” я написал “Отказ = Истина”.
Здравствуйте!
Выглядит все правильно. Попробуйте еще раз загрузить правила в регистр сведений и перезапустить базу.
Прошу прощения за вопрос не по теме. Помогите, плз.
Проблема с отладчиком. Проблема возникла с отладкой подключенной внешней
печатной формой в БП 3.0. Точка останова в
ОбщийМодуль.ДополнительныеОтчетыИОбработки
процедура ПечатьПоВнешнемуИсточнику
строка ВнешняяОбработкаОбъект.Печать(…
отладчик уходит “в никуда” и оттуда же возращается, как джин из бутылки.
Что происходит? и как решить? Может кто сталкивался…
платформа 8.3.6.2152
Здравствуйте!
Для отладки внешней печатной формы есть специальные внешние обработки. Скачать их можно на открытых ресурсах, например, на Инфостарте. Называются они “Тестирование внешних печатных форм” и т.д. Вот например, тут http://infostart.ru/public/73691/
С ее помощью можно установить точки в модуле, отладчик на них остановится.
В настройка правил регистраций не увидел возможность настраивать ПРО для констант. Конечно константы меняются очень редко, но все есть возможность кроме как подписками или разрешением авторегистрации для констант, повлиять на необходимость выгрузки константы. Весело конечно будет, если раз и сменилась валюта регламентированого учета(пришла по обмену))))), но все же, это я не нашел, или нет механизма настройки ПРО для констант))?
Здравствуйте!
Нет, для констант настроить ПРО нельзя. Не могу сказать, с чем это связано. Возможно, это редко бывает нужно, поэтому не предусмотрели.
Спасибо.
СМените аватар. Неадекватно.
Добрый день!
Настройка узла «Не выгружать помеченные на удаление» установлена.
В ПРО обработчик “При обработке (доп)” написал “Отказ = Истина”;
1. При пометке на удаление элемента справочника регистрации не происходит.
2. Но при отмене пометки на удаление регистрация происходит.
3. И затем опять при пометке на удаление объект в регистрации помечается на удаление и при выгрузке в УТ эта номенклатура удаляется.
Вопрос: как в п. 3 сделать так, что бы после пометки на удаление объекта регистрации не происходило?
Здравствуйте!
Если я правильно поняла, нужно, чтобы регистрация объекта удалялась в случае, если он помечается на удаление? Думаю, для этого оптимально использовать тот же обработчик При обработке. Он будет выполняться каждый раз перед выполнением запроса, который получает узлы планов обмена для регистрации этого объекта. Тогда нужно проверить, установлена ли у объекта пометка удаления, если да, проверить, зарегистрирован ли он на узле, и если зарегистрирован, то удалить регистрацию. А если не зарегистрирован, то просто установить Отказ в значение “Истина”.
Здравствуйте!
Спасибо за ответ.
Да, Вы правильно поняли.
1. Проверить установку пометки удаления можно так:
Объект.ПометкаУдаления;
2. Проверить, зарегистрирован ли объект на узле:
ПланыОбмена.ИзменениеЗарегистрировано(Узел,Объект);
3. Удалить регистрацию:
ПланыОбмена.УдалитьРегистрациюИзменений(Узел,Объект);
Подскажите, пожалуйста, как в ПРО в обработчике “При обработке” обратиться к узлу получателю?
В обработчике ПРО При обработке как раз нет еще никаких узлов получателей. Он происходит перед тем, как будет выполнен запрос, с помощью которого происходит поиск узлов получателей для этого объекта. Но Вы же сами знаете, какие узлы Вы используете при обмене, можете получить их по коду?
Здравствуйте!
Да, могу. ПланыОбмена.МойПланОбмена.НайтиПоКоду(“МойКод”).
Спасибо)
Добрый день.
В уроке для указания настроек и отборов была создана ФормаНастройкиУзла. В решении же домашнего задания такая форма не создается.
Опытным путем узнал, что ФормаНастройкиУзла используется лишь один раз, при создании настройки обмена (гиперссылка “изменить правила выгрузки данных”). А потом используется уже ФормаУзла. На мой взгляд очень нерационально создавать дублирующие друг друга по функционал формы.
Здравствуйте!
Вероятно, это связано с тем, что гораздо правильнее настроить все параметры еще до первой выгрузки, один раз, и больше не менять. И значения по умолчанию уже на момент первой выгрузки обязательно должны быть заданы, иначе объекты будут некорректно заполнены. Кроме того, в форме настройки узла можно сделать описание всех настроек, чтобы не ошибиться при создании нового обмена. Далеко не всегда разработкой и настройкой занимается один и тот же человек.
Добрый вечер!
У меня возникла проблема при выполнении данного ДЗ.
Текст запроса ПРО перед обработкой отрабатывает в консоли запросов, по отладчику все тоже правильно, но при попытке выполнить запрос валится на ошибке , не задан Параметр “ЭтоГруппа”, хотя параметр установлен.
В чем может быть проблема?
В приложенном файле высылаю скрин (во 2м файле)
Добрый вечер, еще раз – удалось побороть ошибку подправлен типовой код в процедуре ОбменДаннымиСобытия.МассивУзловПоЗначениямСвойств:
….
// Задаем значения параметров запроса из свойств объекта.
Для Каждого Элемент Из ЗначенияСвойств Цикл
///Запрос.УстановитьПараметр(“СвойствоОбъекта_” + Элемент.Ключ, Элемент.Значение);
Запрос.УстановитьПараметр(Элемент.Ключ, Элемент.Значение);
КонецЦикла;
Попытка
МассивУзловРезультат = Запрос.Выполнить().Выгрузить().ВыгрузитьКолонку(“Ссылка”);
Здравствуйте!
Лучше не менять типовой код, а использовать префикс “СвойствоОбъекта_” при написании запроса
Можно указать одно и то же ПРО для разных объектов?
Например одно ПРО для документов “Поступление”,”Реализация”,”Перемещение” (допустим с отбором по складу или для всех документов с отбором по дате)
Здравствуйте!
Нет, правила регистрации настраиваются для каждого вида объектов отдельно
Здравствуйте
Спасибо
Сделал в модуле объекта плана обмена проверку. Для моей задачи и так сойдёт. :-)
P.S. Ремонт начинался в стиле “хай-тэк” закончился в стиле “хай так”
Можно и проверки в коде сделать, если это не увеличит сложность обновления конфигурации
Ну ввиду столь частого обновления версий БСП сложности в любом случае будут, поэтому одна проверка в модуле объекта плана обмена особой роли не сыграет :-(
ДЗ выполнил но с одной оговоркой
Наблюдается такая проблемма: если есть объект который по всем правилам должен выгружаться, выгружается и всё вроде хорошо.
– После синхронизации данных делаем пометку на удаление
– Срабатывает подписка на событие “Перед записью” (объект ещё не записан) правила регистрации его пропускают и в файл обмена попадает информация о том что объект удалён (см. вложение)
– Ну в базе приемнике конечно же он физически удаляется
– Учитывая то что в базе источнике он остался (хоть и помеченный на удаление) не по фэншую как-то
:-(
Вариантов решения проблеммы конечно можно много придумать
Хотелось бы услышать/прочитать/увидеть Ваш вариант
P.S. Из ответа преподавателя на третий вопрос на этой странице
“2.Проверяется, соответствует ли объект или его ссылка условиям, описанным на закладке Основное. Если ни объект, ни ссылка не соответствуют, регистрация не выполняется.”
Ссылка не соответствует, а объект то соответствует…
Вопрос такой : почему при пометке на удаление передаются данные о том что объект удалён и происходит физическое удаление в базе приёмнике? Ведь объект не “удалён” а “помечен на удаление”
Здравствуйте!
Посмотрите, пожалуйста, на этой странице вопрос участника alest от 14.11.14. У него была такая же ситуация. Если это не Ваш случай, или есть сомнения, пришлите выгрузку базы, я посмотрю, что может быть причиной
Спасибо, именно оно
“Если объект зарегистрирован на узле плана обмена, но при этом правилам регистрации он не соответствует, то выгружается, действительно, удаление объекта. Другой вопрос, что добиться этой ситуации довольно сложно”
Оказалось что добиться такой ситуации просто :-)
Каким образом? Из-за того, что у незаписанного объекта ссылка проходит ПРО, а при выгрузке он уже записан? У меня почему-то не получилось смоделировать такую ситуацию
Ну я код не анализировал но судя по ответам
” соответствие элемента условиям, прописанным в правилах регистрации проверяется дважды: сначала для только что измененного объекта (там пометка удаления Истина), а потом для ссылки на этот объект в базе данных (там пометка удаления Ложь, поскольку объект еще не записан)”
получается что при пометке на удаление ранее не помеченного на удаление объекта происходит регистрация в узле плана обмена
“Если объект зарегистрирован на узле плана обмена, но при этом правилам регистрации он не соответствует, то выгружается, действительно, удаление объекта”
Ну собственно объект зарегистрирован, но правилам регистрации не соответствует
Попробуйте отключить проверку ссылки (в ПРО в событии “При обработке (доп.)” написать «Отказ = Истина;»). И попробуйте установить пометку удаления и выгрузить данные. Если удаление объекта не выгрузится при этом, значит, дело в проверке ссылки
Здравствуйте
Если создавать ПКГС с пустым источником, то при загрузке таких правил в УТ11 ругается на отсутствующий реквизит _шапки_! Там в коде стоит
Если ПустаяСтрока(СтрокаТаблицы.ИмяТабличнойЧасти) Тогда // реквизиты шапки.
Как правильно обходить такую проблему? Способа ведь вмешаться в процесс определения списка реквизитов, по которым будет определяться необходимость регистрации нет? (например, в данном случае исключить конкретный ПКГС)
Здравствуйте!
Вы можете только отключить механизм выборочной регистрации, как я писала раньше. Если нужно самому определить список реквизитов, которые влияют на регистрацию, то это нужно выполнять вручную в обработчике подписки на событие.
В каком именно обработчике и какую переменную переопределять?
Здравствуйте!
Найти нужную подписку на событие “Перед изменением” – для объектов этого типа и нужного плана обмена. Там проанализировать, какой реквизит изменился, и в зависимости от этого выполнять или не выполнять регистрацию
Здравствуйте!
Первый раз вижу такую ошибку. Нужно смотреть, на какой строке возникает.
Похоже в модуле менеджера плана обмена указано имя формы (выгрузки/загрузки/настройки …) которой нет в текущей базе.
Здравствуйте
Поясните/поправьте/уточните, пожалуйста
0. ПРО обрабатывается при записи/удалении объекта и в момент выгрузки
1. ПередОбработкой
а. получает список реквизитов и достает их из объекта
б. подготавливаем запрос к плану обмена
2. ПриОбработке
3. Выполняется запрос, подготовленный ПередОбработкой. На выходе- массив узлов
4. список реквизитов получается из ссылки (можно отключить переменной ПроверятьСсылку)
5. ПриОбработкеДоп
6. запрос к плану обмена выполняется еще раз
7. полученный массив узлов добавляется к полученному в п.3
8. ПослеОбработки
А при выгрузке события как обрабатываются?
Тема ПРО, по-моему, очень слабо освещена.
Приходится сидеть в отладчике и смотреть, как это все работает. Как будто в курсе вообще этой темы нет ((
Пока не нашел, как вместо пометки получается УдалениеОбъекта (уже задал этот вопрос)
Правила регистрации обрабатываются в момент выгрузки для тех объектов, у которых переключатель режима установлен в положение “Выгружать при необходимости” и “Выгружать по условию”. Для таких объектов еще раз проверяется, проходят ли они фильтр правил регистрации для этого узла, и если не проходят, то они не выгружаются.
Здравствуйте
Подгрузил ПРО в конечной базе, помечаю номенклатуру на удаление – регистрируется не изменение пометки на удаление, а УдалениеОбъекта, т.е. при загрузке в УТ она там удаляется.
В чем может быть причина, как этим поведением можно управлять?
Здравствуйте!
Я еще раз проверила механизм регистрации в разных версиях БСП, но я не могу понять, почему может регистрироваться удаление объекта. У меня при разных условиях, с правилами регистрации и без них всегда регистрируется только пометка удаления. Пришлите, пожалуйста, Вашу базу, буду смотреть в ней тогда.
Здравствуйте, Ольга
Спасибо, что откликнулись )
Базу выслал.
Здравствуйте!
Спасибо за интересную ситуацию, я выяснила следующее:
Если объект зарегистрирован на узле плана обмена, но при этом правилам регистрации он не соответствует, то выгружается, действительно, удаление объекта. Другой вопрос, что добиться этой ситуации довольно сложно
По всей вероятности, Вы сначала поставили пометку удаления, а потом подгрузили новые ПРО. Потому что если изменить настройку узла “Не выгружать помеченные на удаление”, то происходит проверка всех объектов, уже зарегистрированных на узле, и все, которые новой настройке не соответствуют, удаляются из таблицы регистрации.
Сейчас в Вашей базе настройка “Не выгружать помеченные на удаление” включена. И если установить пометку удаления, то регистрации не происходит, и ничего не выгружается, проверьте.
Здравствуйте!
ДЗ сделал, но не получается выяснить – как в РеквизитыРегистрации включить поле справочника Номенклатура “ОсновноеСвойство” = чтобы при его изменении Номенклатура регистрировалась к обмену – вопрос = “Как это сделать” ?
Сейчас у меня реквизиты регистрации = “Код, Наименование, ПометкаУдаления, Родитель, ЭтоГруппа”.
Скриш шот отладчика – прикрепляю.
Разобрался, хоть и в целом удивлен и интересно узнать есть ли обход данных ограничений. Суть в том – что “РеквизитыРегистрации” – берутся не из ПРО, а из состава полей, определенных в ПКО !!! У меня “Основное свойство” не участвует в составе ПКО “Номенклатура”.
То есть ситуация, когда регистрировать объект или нет – решается не на уровне ПРО, а на уровне состава полей ПКО! Фактически, получается, что я устанавливаю признак – который является командой для миграции и данные должны мигрировать, логично, что данный признак “не важен и не нужен” в базе приемнике – но изменение не будет зарегистрировано – так как это “поле-команда” не передается…
Вопрос: как можно зарегистрировать объект, если “поле-тригер” не входит в состав ПКО?
Здравствуйте!
Да, все правильно. Это механизм выборочной регистрации объектов. В регистре сведений ПравилаДляОбменаДанными есть реквизит ИспользоватьФильтрВыборочнойРегистрацииОбъектов, он регулирует этот механизм. Можно найти нужные правила обмена (именно обмена, а не регистрации) в этом регистре сведений, открыть, снять этот флажок (внизу окна), нажать “Записать и закрыть”. И перезапустить базу. Тогда фильтр выборочной регистрации будет отключен
Добрый день. Была следующая проблема, побороть которую смог только откатом. Был создан план обмена и уже была выгрузка в узлы. После этого была сделана форма “ФормаНастройкиУзла”, в нее помещены реквизиты, обработчики и поставлена точка останова, но при вызове настройки уже существующего обмена открывалась форма с точно такими же реквизитами, но это была явно не моя форма. Причем функциональная часть, связанная с изменением доступности различных реквизитов от значений других не переносилась. При создании нового обмена в этой же конфигурации открывалась моя форма. Можете пояснить взаимосвязь этих механизмов?
Здравствуйте!
Форма настройки узла открывается только из помощника создания обмена данными. Когда обмен уже создан, все настройки доступны в форме узла плана обмена, которая открывается по кнопке “Настроить правила синхронизации данных”.
Настройки доступны из формы просто как перенесенные реквизиты без переноса функционала.
Объясню. Была форма с реквизитом который делает доступным таблицу, в которую помещаются обязательные к выгрузке элементы. В помощнике именно эта форма и вызывается.
При уже настроенном плане обмена при нажатии “Настроить правила синхронизации данных” открывается форма узла обмена и там есть реквизиты, но к ним не “прикручены” обработчики. Т.е. Флаг на реквизите никак не влияет на доступность таблицы и т.д. То есть программный код из формы не был задействован. Непонятна каким образом связаны отображаемые параметры на узле и механизмы которые мы описывали в форме.
Они не связаны, ведь мы описывали их для формы настройки, а это другая форма, и здесь нужно вставить те же обработчики событий, чтобы все работало так же.
В правилах обмена в обработчике конвертации “Перед загрузкой данных” использовали параметр УзелОбменаЗагрузкаДанных, а если обработчики находятся в специальной обработки загрузки, при отключеном режиме совместимости, то там в обработчиках такого параметра нет. Есть переменная модуля УзелДляОбмена, но в ней значение Неопределено. Можно ли как-нибудь узнать узел обмена?
Здравствуйте!
Параметр УзелОбменаЗагрузкаДанных доступен в обработчике события Конвертации “После получения информации об узлах обмена”. Здесь его можно записать в Параметры, например.
Добрый день! Еще есть такой вопрос: почему мы прописывали код в модуле менеджера Плана обмена, а в более ранних версиях программы такой код писался в модуле объекта. и в более почему ранних версиях типовых конфигураций нет макетов с правилами обмена(под более ранними понимается например УПП 1.3.21.1).
И еще вопрос возможно ли будет настроить обмен по описанным в курсе шагам с такой конфигурацией, ведь там по идее уже присутствует БСП
Но вот например смотрел в конфигурации нет такого регистра как “СоответствияОбъектовИнформационныхБаз” есть только “СоответствиеОбъектовДляОбмена”, но я так понимаю это не одно и тоже.
Здравствуйте!
Регистр СоответствиеОбъектовДляОбмена и обработка ОбменДаннымиXML – это компоненты более старой версии обменов между типовыми конфигурациями. В курсе этот вариант называется Прочие обмены данными. Это еще не БСП. Настроить обмен между этим более старым вариантом и подсистемой Обмен данными БСП стандартными средствами нельзя
Добрый день! Т.е. получается чтобы настроить обмен с такой базой и иметь возможность настраивать соответствие объектов информационных баз, в такую базу необходимо интегрировать БСП как это описано в курсе или с типовыми конфигурациями так не получиться?
Здравствуйте!
Да, нужно интегрировать БСП. С типовыми это тоже должно получиться, но возможно, возникнет необходимость дополнительных настроек. Нужно будет дополнительно настроить совместную работу существующих и внедряемых объектов.
Спасибо будем пробовать)))!!!
Добрый день! Подскажите, для чего необходимо в ФормеНастройкиУзла обязательно создавать реквизит “НастройкаОтборовНаУзле”.
И второй вопрос что за параметр “ВерсияКорреспондента” версия БСП 2.1.8.4, он присутствует практически во всех процедурах, скопированных из БСП
Здравствуйте!
В реквизите НастройкаОтборовНаУзле хранятся текущие отборы, которые в этом сеансе обмена установлены для этого узла.
Параметр ВерсияКорреспондента создан, чтобы хранить номер версии конфигурации той базы, с которой происходит обмен. В зависимости от этого номера могут быть выполнены разные действия в процессе обмена.
Добрый день! тоже интересует эта версия корреспондента. По идее она должна передаваться в форму настройки узла через параметры. Но я не могу найти, откуда. В форме списка узлов нет передачи параметров в эту форму.
Здравствуйте!
Я тоже не до конца понимаю этот механизм. Но, по всей видимости, он используется только в случае подключения через внешнее соединение. Версия корреспондента передается в форму настройки узла из помощника создания обмена данными
Добрый день. Подскажите пожалуйста как вернуться к типовым правилам конвертации объектов? В УТ 11 поставил правила из файла, нужно вернуться к стандартным, в настройках синхронизации ставлю переключатель на типовые, обновляю регистр сведений ПравилаДляОбменаДанными, перезапускаю базу, а правила все равно из файла.
Здравствуйте!
Не встречалась с такой ситуацией.
Попробуйте не обновлять регистр, а там же, где указываете, что правила из макета, нажать кнопку “Загрузить”.
Спасибо, это помогло.
Добрый день!
Где можно получить финальное задание?
Добрый день!
Финальное задание опубликовано на странице: http://курсы-по-1с.рф/post-2014-02/convdata-final-flow3/
Вопрос про регистр сведений “Соответствия объектов информационных баз”. Он хранит соответствия для всех объектов и всех узлов? А если объектов десятки тысяч и сотни узлов…
Я смотрю, там полно записей где УИДы одинаковы и с точки зрения синхронизации смысла в этом нет. Но есть другой смысл: база Х знает, что объект в базе Y точно есть и можно передать реквизит-ссылку без всей дополнительной информации.
Пусть базы А и Б договорились, что объект А1 – это то же, что объект Б1, они прописали связь в свои регистры соответствия.
1. Можно при обмене баз А и Б с новой базой С автоматически сделать так, чтобы в С не возникло дублей? Или сначала надо перенести А1 в С, а затем при переносе Б1 в С вручную связать Б1 с перенесенным ранее А1?
2. Вариант, когда при переносе в С оказывается, что А1 нужно поставить в соответствие С1. Поставили, но как быть с соответствием Б1-С1?
Мне кажется, регистры соответствия решают задачу сопоставления для точка-точка, а не глобальную… Или я не прав и дела обстоят лучше, чем мне кажется?
Я такой механизм нигде не встречала, с большой долей вероятности, его нет. Вопросы миграции объектов решены в большей степени в Распределенных базах, а при обычном двустороннем обмене в меньшей. Можно для очистки совести провести эксперимент – после выполнения ДЗ у Вас должны быть пары баз с настроенным обменом на основе БСП. Попробуйте настроить обмен с третьей базой и посмотреть, как он будет работать.
Здравствуйте.
Насколько я понял, все нынешние обмены движутся в сторону построения на технологии как в БСП, то есть свойство Авторегистрация в плане обмена в конфигурации запрещается, а все регистрации объектов производятся в соответствующих модулях.
Но вот вопрос, если требуется наладить некоторый простой обмен. Без использования сложных правил регистрации, то есть вполне подойдёт разрешение авторегистрации в самой платформе. Можно ли этим пользоваться? Ведь меньше кода – меньше вероятных ошибок, проще в поддержке, и соответственно надежнее программа, не так ли?
Как в таком случае правильнее поступать (в частности, с этим свойством авторегистрации)? Или рекомендуется нынче вообще все-все любые обмены строить по методикам как в БСП?..
Здравствуйте!
Все сильно зависит от конкретных условий. Есть, например, задачи, для которых БСП использовать неудобно, а лучше Универсальный обмен. Если Авторегистрация подходит для конкретной задачи, используйте ее.
Добрый день. возникла проблема с дз. Когда в обработчике ПРО Перед обработкой пишу что-нибудь вида Отказ = Объект.ПометкаУдаления; все работает корректно.
как только делаю с ПРО
ПРО.ТекстЗапроса = “ВЫБРАТЬ РАЗЛИЧНЫЕ
| ПланОбмена.Ссылка КАК Ссылка
|ИЗ
| ПланОбмена.ОбменКонечнаяУТ11 КАК ПланОбмена
|ГДЕ
|(ПланОбмена.НеВыгружатьПомеченныеНаУдаление = ЛОЖЬ)
выдает ошибку при сохранении номенклатуры невозможно записать
и в журнале регистрации пишет : {ОбщийМодуль.ОбменДаннымиСобытия.Модуль(96)}: Для состава плана обмена ОбменКонечнаяУТ11 не указана регистрация объекта Справочник.Номенклатура
ВызватьИсключение СтрокаСообщения;
Не могу понять в чем тут дело.
Здравствуйте!
Нужно проверить состав этого плана обмена, в нем должна быть номенклатура, и авторегистрация должна быть запрещена. Возможно, запрос выбирает предопределенный узел ИБ, это тоже нужно включить в условия запроса или вставить блок “[ОбязательныеУсловия]”, как описано в видео-уроке
Иду по шагам синхронно с Евгением в видео 4-07
от МеханизмРегистрацииОбъектов 12:48
до ВыполнитьОбработчикПРОПередОбработкой 14:20
Но у меня в ПКО.ПередОбработкой в тексте запроса [ОбязательныеУсловия] не заменились и по шагам не видно, когда должна произойти замена.
Здравствуйте!
Я моделировала эти видео-уроки с использованием БСП 2.1.8.1, все работало так же, и обязательные условия подставлялись
В приложенном файле стек вызовов до того места, где заменяются Обязательные Условия в запросе. Можете проверить
У меня вызывается процедура “ОпределитьПолучателейПоУсловию” (до нее все точно так же), в самом начале у нее вызов
“ВыполнитьОбработчикПРОПередОбработкой”, при выполнении которого ошибка (тут [ОбязательныеУсловия] еще не замены)
до “ВыполнитьПравилаРегистрацииОбъектаДляСсылочногоТипа”
программа не доходит
Значит, нужно искать ошибку в коде обработчика события ПРО “Перед обработкой”.
До этого кода дело не доходит. Отладчиком я дохожу до команды ВыполнитьОбработчикПРОПередОбработкой и вижу, что в коде обработчика текст “[ОбязательныеУсловия]”. А он должен быть заменен где-то раньше в процедуре МассивУзловПоЗначениямСвойств, а где именно вызывается эта процедура (причем до “ВыполнитьОбработчикПРОПередОбработкой”) я не найду.
Естественно, вызов обработчика с “кривым” текстом завершается ошибкой…
Процедура ВыполнитьОбработчикПРОПередОбработкой() содержит одну команду – выполняет текст обработчика. Т.е. выполняется тот код, который написан в обработчике события ПРО “Перед обработкой”. Если ошибку вызывают [ОбязательныеУсловия], значит в этом обработчике выполняется запрос, который должен выполняться гораздо позже. Проверьте, что в нем написано. Прикрепите, пожалуйста, zip или rar архив с ПРО, которые Вы используете. Это Конечная база для Домашних заданий?
Для управления регистрацией создал подписчик, с процедурой:
Процедура ОбменИсходнаяБухгалтерия3ЗарегистрироватьИзменениеПередЗаписью(Источник, Отказ) Экспорт
ОбменДаннымиСобытия.МеханизмРегистрацииОбъектовПередЗаписью(“ОбменИсходнаяБухгалтерия3”, Источник, Отказ);
КонецПроцедуры
Параметр “Отказ” в вызове МеханизмРегистрацииОбъектовПередЗаписью как я понимаю означает отказ от регистрации изменения объекта.
Но получается, что этот же параметр в обработчике события означает “отказ от записи объекта” и если я создаю нового контрагента, который без ИНН, то программа его не записывает и выдает соответствующее сообщение.
=======================================================
Если параметр “Отказ” в вызове МеханизмРегистрацииОбъектовПередЗаписью означает отказ от записи, то это ТАКАЯ ЗАСАДА.
Большая система, сотни узлов.. Подключаем новый узел, пишем для него ПРО, интегрируем с БСП и бац-в результате ошибок/сбоев процедур регистрации блокируется запись объекта в центральном узле…
Здравствуйте!
Нет, параметр Отказ в процедуре МеханизмРегистрацииОбъектовПередЗаписью() тоже по факту означает только отказ от записи объекта. Если же установить “Отказ” в “Истина” в любом из обработчиков событий ПРО, то произойдет только отказ от регистрации, а отказа от записи объекта не будет, он будет записан. Значение параметра “Отказ” не передается “изнутри” процедуры регистрации “наружу” в обработчик подписки на событий.
Хорошо, зачем тогда МеханизмРегистрацииОбъектовПередЗаписью() устанавливает отказ от записи при ошибках в процедурах регистрации? Почему локальную проблему регистрации делают глобальной. Зачем механизму РЕГИСТРАЦИИ дают возможность блокировать ЗАПИСЬ объектов и ставить систему на уши?
Несколько баз, десяток планов и сотни узлов. Вот в очередном плане при регистрации изменения контрагента возникает сбой, который приводит к отказу от записи контрагента и сбою по передаче этой информации во все остальные узлы по другим планами.
Имхо, это абсолютно неверно и чревато нестабильной работой системы. Не должен сбой в работе одной подсистемы приводить к сбоям в другой порождать растущий ком проблем.
Что интересно, в более ранних версиях так и было, ошибка в регистрации не приводила к отмене записи. Однако, сейчас сделали именно так. Видимо, причина в том, что явные ошибки исправляются быстрее, чем неявные.
Печально. Боюсь, авторы нововведения не работали с большими обменами и поэтому заложили такую мину. Хорошо хоть автомобилестроители не идут по такому пути (перегорела лампочка или другая ерунда приключилась – а заблокируем двигатель пока не исправят!).
Я уж не говорю о самолетостроителях…
Как вариант, можно добавить конструкцию Попытка/Исключение в обработчики подписок на события.
Очень интересно было послушать про историю развитие конвертации (да просто расслабиться, т.к. курс весьма интенсивный). Получается, что on-line обмен вроде как и не on-line, а безопасность привела к тому, что тексты обработчиков переносятся ручками (но прям как в 7-ке).
И возник вопрос: есть общий движок преобразования объекта по правилам или V8exchange и БСП просто имеют общие корни, но у каждой свои особенности (и в перспективе они еще больше разойдутся)?
Добрый день!
Обработки “Универсальный обмен данными” и “Конвертация объектов информационных баз”, которая входит в подсистему “Обмен данными” БСП, отличаются довольно сильно. Состав и порядок вызова процедур и функций у них практически одинаковый, но логика работы во многом разная
Ольга, доброго здоровья вашим близким и Вам!
Меня вот что интересует: если разработаны некие правила и они хорошо работают для V8excange, то будут ли они также хорошо работать при переносе в БСП, не возникнет ли ошибок из-за разной трактовки правил (особенно ПКО волнует)?
Спасибо )
Скорее всего не будут. Под обмен на основе БСП нужно писать правила с учетом его особенностей. Главное отличие в том, что обработка из БСП по умолчанию не выгружает объекты по ссылкам из свойств. Чтобы выгружались объекты, в ПКС нужно писать ВыгрузитьОбъект = Истина; Есть и другие отличия, их полного списка у меня, к сожалению, нет
ПРО, контекст “при выгрузке”. Зачем нужен? При выгрузке происходит экспорт в уже известный узел и единственно для чего этот контекст нужен это вроде только для отказа от выгрузки. Ан нет, в описании событий этот контекст фигурирует почти во всех событиях, получается что при выгрузке снова строится запрос, проверяются все ограничения и т.д.?
Здравствуйте!
ПРО выполняются при выгрузке тех объектов, для которых установлен режим выгрузки “При необходимости”. Если он зарегистрирован на узле плана обмена, но не соответствует ПРО, установленным для этого узла, выгружаться он не будет все равно
Здравствуйте!
Как я понял, если в элементе справочника изменить реквизит, которого нет в правилах обмена, то регистрации изменений не происходит. Это всегда так? Или есть какой-нибудь способ изменить на проверку всех реквизитов вне зависимости от того участвуют ли они при переносе или нет?
И еще один вопрос: есть элемент справочника Номенклатура, у которого зарегистрировано изменение. Помечаем на удаление. По заданию ДЗ, элементы помеченные на удаление не должны регистрироваться, но он уже зарегистрирован?! Можно ли отменить регистрацию или возможно у меня ошибка в Правилах регистрации?
Здравствуйте!
Посмотрите Лучшие вопросы на этой странице, вопрос №1.
Это можно сделать, но в рамках ДЗ – не нужно.
Здравствуйте еще раз.
Первый понял, как решается.
На счет второго вопроса: алгоритм решения не подскажете?
Здравствуйте!
Есть два подхода к решению: можно в ПРО указать для данного типа объектов значение переключателя режима “Выгружать при необходимости”, тогда при выгрузке будет происходить проверка этого объекта на соответствие условиям в ПРО, и, если он не соответствует, то выгружаться он не будет.
Есть второй вариант: можно в ПРО в событии после обработки проверить: если нужный узел попал в массив узлов-получателей, значит, объект прошел проверку на условия ПРО. Если нужного узла нет в массиве, а объект уже зарегистрирован на этом узле, то удалить регистрацию этого объекта на этом узле
Добрый день.
Вопрос по ПРО. Возможно ли при “срабатывании” ПРО переопределить объект для регистрации?
Допустим, есть независимый и непериодический РС, назовем его “статусы”. В нем есть реквизит “Объект” ссылочного типа и ресурс “Статус”. Данный РС предназначен для хранения текущего статуса объекта. Возможно ли выгружать “объект”, который хранится в реквизите РС, по достижению определенного “статуса”? На сколько я понял материал урока – ПРО будет для РС, но в конечном итоге в таблицу регистрации нужно записать не набор записей РС, а “объект” – реквизит РС.
Здравствуйте!
Думаю, без изменения конфигурации это сделать не получится. Можно создать подписку на события этого регистра, как рассказано в видео-уроке 4.5.3. В обработчике подписки на регистрацию в видео-уроке передается Источник события, но можно передать туда что угодно.
Т.е. иными словами (если я все правильно понял), например, в ПРО, в обработчике “После обработки” следующий код будет ошибочным?
Объект = Объект.Отбор.Объект.ПолучитьОбъект(); (пример в контексте описанного мною ранее РС “статусы”, причем Объект.Отбор.Объект имеет тип, который входит в состав Плана обмена)
Знаете, я так никогда не делала, но, судя по коду, может и сработать. Нужно попробовать и на всякий случай посмотреть в отладчике, где могут возникнуть ошибки.
Попробовал, к сожалению не получилось. Как описывал выше, в обработчике прописал Объект = Справочники.Номенклатура.НайтиПоКоду(“000002”).ПолучитьОбъект(); сделал вывод диагностического сообщений, “Объект” действительно переопределяется без ошибок, но список зарегистрированных объектов остался пустым.
Нужно поставить точку остановки в подписке на событие и посмотреть, почему не получается. Там много тонкостей и настроек, возможно, Вы ее и победите
Вопрос по переключению режимов выгрузки. В видеоуроке упоминается только, как работают режимы “Регистрировать все” и “По условию”. А как работает вариант “При необходимости”?
Здравствуйте!
Вообще говоря, в видео-уроке рассказывается, как работает этот вариант. Если нужна более подробная схема, то вот она.
Допустим, для объектов определенного типа установлен переключатель с режимом “Выгружать при необходимости”.
1. Если этот объект был изменен, то он регистрируется к выгрузке только в том случае, если он уже участвовал в переносе, т.е. если ссылка на него есть в регистре сведений “Соответствия объектов информационных баз”.
2. Если этот объект не зарегистрирован к выгрузке, но встретился по ссылке из другого объекта при выгрузке, то будет произведена проверка: если этот объект есть в регистре сведений “Соответствия объектов информационных баз” (а значит, и в базе-приемнике), то будет выгружена только ссылка на него, а если его там нет, он будет выгружен полностью.
Я использовал БСП 2.1.3, заметил, что в видео уроках все исключаения заканчиваются продолжением исполнением кода, а в моей БСП везде вызывается исключение и при ошибки регистрации не удается даже записать элемент справочника. Это так сильно изменилась БСП за 1 релиз?
Здравствуйте!
Да, это изменение появилось в последнем релизе. Теперь почему-то выполнение кода прерывается, и приходится анализировать ошибки в той последовательности, в которой они возникают.