Пользуюсь расширениями давно, проблем не было. Сейчас впервые создал расширение с данными, т.е. добавлены реквизиты в документ и в табличную часть документа "Заказ покупателя" в Розница 2.2, которые также выведены на форму. После обмена с узлами РИБ программа на узлах стала вылетать. Т.е. просто "прекращена работа программы". Подскажите, в чем может быть проблема и как ее решить? Платформа 8.3.16. Удалил расширение (отдельно на каждом узле через конфигуратор) - все взлетело.

UP

(0) В топикстарте я прочитал и вопрос, и ответ на него.
Регистрируйте ошибку для разрабов платформы 1С.

(2) нет. Бесполезно ее регать - в голову себе надо регать, что использование инструмента нужно с включенной головой

(1) А каким РИБ созданы узлы перефирерийных баз и когда?
Т.е. сначала запустили в работу РИБ, а затем, извиняюсь, вхерачили изменение структуры метаданных в типовых объектах, заведомо включенных в РИБ и ожидаете, что все продолжит работать?

РИБ можно сломать даже не используя расширения, а просто внесением изменений в метаданные.

(4) Да, так и сделали? А что не так я сделал? Регулярно корректирую конфигурацию под свои нужды, добавляя и изменяя метаданные - никаких проблем никогда не было. И вообще, при чем тут "прекращена работа программы"? Если возникают проблемы при обмене после изменения метаданных, то обычно это выражается в том, что либо не происходит обмен в обе стороны, либо база находится в режиме обновления и дает войти пользователям, не имеющим полных прав.
Что именно не было включено в голове при использовании данного инструмента?

Ладно... бесполезно что-то доказывать.

Периферийки только вылетают, головная целая? Думаю, что они теперь почти насмерть убиты.
Конфигуратор на них вылетает или нет?
Даже не знаю. Ну ТИИ что ли. Только при ТИИ исчезнут не только значения из реквизитов, но и сами документы могут исчезнуть.

Если инфа более-менее реквизитами ценная внесена... не знаю. Других идей нет.

Сейчас еще окажется, что это все на 8.3.16 приключилось.

А! епта, ну конечно.

(8) Что, бесполезно что-то доказывать, нужно было посоветовать платформу поменять? на 15? В чем проблема с 16ой?

(9) про 15 тоже много стонов, что она глючит...

А пробовал вручную переставить расширение с головной на периферийную?

(10) Неа. Думаю, что нет смысла, т.к. после подключения расширения с данными, головная не отправляет данные обмена (или не принимает, не помню), пока не поставишь галочку "использовать в РИБ"

(6) Головная работает исправно, глючат только периферийные, Конфигуратор не вылетает. Отключил расширение - все работает исправно третий день. Проблема в том, что мне нужно это расширение, не хочу конфу редактировать. Решил все изменения по-тихому в расширения перенести, а тут такое.

(12) Ну вот я думаю, что максимум, на что можно рассчитывать - не модифицировать расширением реквизиты объектов, а добавлять новые объекты ( дополнительные какие-то может быть справочники или регистры сведений - что-то, что не имеет ввиду нарушение целостности объекта конфигурации )

Т.е. если хочешь все-таки, чтоб существовали именно новые реквизиты у прежних объектов - прямо в конфигурации их нужно устанавливать. А программный код или там замещение форм - это не столь критично.

(13) Вопрос такой: вообще кто-нибудь пользовался добавлением реквизитов объектов в расширении при использовании ИБ в РИБ? Может быть просто, действительно, я что-то не так делаю?

(14) вопрос как бы не совсем однозначный.

Большинство (но не я) добавляют реквизиты в основной конфигурации. Т.е. когда расширение внезапно умрет, например, при передаче через РИБ - базе будет пофиг на это. Делать так более менее массово стали из-за того, что запуск ТИИ на базу, в которой есть реквизиты из расширения давало ошибки.

Другие - и я в том числе - добавляют данные или через Дополнительные реквизиты или Дополнительные сведения предусмотренные в конфигурациях. Типовая при этом на замке. Программный код и формы для этих дополнительных данных содержится в расширении.

Когда функционал Расширения начал позволять - можно создавать данные просто в расширении и сохранять в нем же ссылки на объекты, для которых эти данные созданы. Проблема в том, что типовой РИБ не умеет отдавать такие данные на периферийные узлы.

Однако. Лично моя точка зрения. Типовой РИБ обладает огромным недостатком, что в угоду визуальной простоте обмена совместил в общих обменах по плану и передачу метаданных (изменений конфигурации) и передачу данных.
Если на проектах у меня есть возможность и необходимость устанавливать свои планы обменов, то делаю :
1 обмен РИБ для конфигураций и минимум системных справочников, которые гарантированно будут типовыми всегда.
2 обмен с тем же узлом, но без пометок РИБ для передачи данных по правилам. Ну и соответственно это уже моя головная боль, чтоб структурные изменения где угодно не сломали обмен в неудобное время

И да по (15), при втором обмене передача Расширения не совмещена с РИБ никак. Нужна измененная конфигурация на узле - ставь туда Расширение отдельно. С обменом данных тоже самое - отдельно. Просто бывает и такое, что расширения даже нет, но правила обмена нужны совершенно уникальные для конкретной задачи.

(15) Данный функционал как раз и был в конфигурации, но т.к. я хочу вернуть конфу на поддержку, то решил потихоньку все перенести в расширения. Проверил на тестовой - все отлично, ну и перенес на основную, не предполагая, что в РИБ разработчики не предусмотрели обменом данными из расширений.
Через доп реквизиты и сведения не получится добавить, т.к. нет реквизитов у документов в моей конфигурации. А один реквизит вообще добавляется в Табличную часть "Товары".

(17) э... немного не верно формулируешь. Обмен данными может быть и предусмотрели, но! ты модифицировал состав реквизитов типового объекта, но не внутри основной конфигурации, а в расширении - это совсем не одно и тоже.

Но все равно, Объекты, которых не было, а вручную их не смогли добавить (не успели и т.п.), таких точно нет в составе плана обмена, правил регистрации объектов обмена, правил обмена и третий там не помню (там есть и третий макет правил тоже).

Если все это переписать, то возможно он и заработает. Наверняка!

В любом случае, что меня немного удивляет, даже если модификацию метаданных делаешь прямо в основной, то нет нигде явных предупреждений в самом конфигураторе, кроме как "набить шишек", что где-то данные объектов указаны в составе плана обмена, правил и т.д. В любом случае этот прежний подход к обменам не развивается. Нужно думать о более надежных вариантах.

Вот какая красота попалась на глаза

---
План обмена распределенной информационной базы

Код ошибки: 10214341
Код(ы) обращения: HL-50785
Статус: Планируется исправление в будущих версиях Зарегистрирована: 10.09.2019
Исправлена: "Технологическая платформа", версия 8.3.18

Описание:
Если структура плана обмена распределенной информационной базы модифицируется расширениями конфигурации, то последующие изменения конфигурации не регистрируются в плане и не отправляются в узлы плана обмена.

(19) получается. если РИБ править , даже добавлять , то надо с поддержки снимать ?

(20) Ну... для меня это давно за правило.
Если хочешь нормально работать в РИБ, то конфигурацию этой базы нужно обязательно снять с поддержки.
Собственно, в данном сообщении об ошибке про сохранение конфигурации на поддержке даже не упоминается.

(21) Чёрт с ней,этой поддержкой. Хочется просто как можно меньше объектов редактировать в конфе, а то столько изменений, что обновиться позволяю себе раз в 2 года.