Появился запрос от клиента на перенос доработки в расширение.
Доработка - общий модуль, документ (отдельный), роль к нему и т.д.

Я так понимаю, что вариант переноса такой:
1. Создать расширение, скопировать туда все объекты (с префиксом).
2. Добавить в расширение все нужные объекты (справочники, команды, подписки), чтобы пользоваться типовыми механизмами (типа кнопки "показать движения").
3. Обработкой перенести все документы из основной конфы в созданный документ в расширении.
4. Удалить из конфы документ (и всё остальное, что не хранит данные)
5. Перепровести документ (за весь период)
Соответственно, чтобы избавиться от проблемы перепроведения документов (в базе несколько лет), желательно сделать свертку, верно? Какие еще могут быть подводные камни? Читал раньше споры про хранение данных в расширениях - сейчас есть риск потери данных, если расширение при обновлении слетит?

(5)Переноси и документ и движения сразу, зачем перепроводить?

Ваш отдельный документ двигает отдельные или типовые регистры? Или с какой целью перепроведение?
А по поводу риска - так и метеорит может прилететь в серверную.

(2) Двигает типовые регистры

(0) с какой целью делать эту работу?, добавленные объекты надежнее хранить в основной конфе.

(1) Взять запросом набор движений с отбором по типу регистратора и подменить ссылку регистратора?

(4) "пожелание клиента"
Либо обосновать, почему так делать не рекомендуется

(6) потому что есть риск потерять данные.

(7) Насколько серьезный?
Что может повлечь потерю данных?
При обновлении? При тестировании? При "слетании" расширения после типового обновления?
Одна из целей перехода на расширение - для "автообновления"

(0) кроме п.5 вроде нормально всё.
А перенести документы и движения - проще простого. Надо выгрузить через стандартную обработку загрузки выгрузки xml документы вместе с движениями, потом открыть текстовый редактор и заменой текста найти имя документа и добавить к нему префикс.
полученный файл загрузить

(8) потеря данных наступит при удалении расширения

(6) чисто задай вопрос: А если отвалится расширение, клиент готов потерять данные? (или получить их в покоцанном виде)

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

(9) Спасибо

(10) Как если бы загрузили просто cf поверх насильно? Просто удалить расширение намного проще

(11) "Отвалится" - это когда оно становится неактивным после обновления из-за конфликта, так? Или если именно удалят?
Про потерю данных - этот вопрос обязательно задам, но тогда будет как раз вопрос, в каком случае они могут потеряться, поэтому уточняю.

(11) свои роли также с префиксом в основной конфе можно создать, в расширениях удобно что то кодом добавить, например не типовые реквизиты на форму, или править типовые модули.

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

Автообновление изменяет только данные в режимах "Объект поставщика не редактируется" и "Объект поставщика редактируется с сохранением поддержки"
При оном опасно, только если конфигурацию вернут полностью на поддержку, вот тогда потрутся все изменения

Двигать регистры основной конфигурации документом из расширения?! Месье знает толк в извращениях! Кто-то или что-то отключило расширение и, voila, ни документов ни движений... одни потерянные объекты. да еще может накрыться работа типовых объектов...

(16) Если расширение отключится, с чего "данные тю-тю"?
Если удалится - другое дело.

(16) Платформа используется рекомендуемая, указанная в обновлении.
Отключение, получается, так же затирает данные? Или они будут "объект не найден", но если галочку вернуть - то ссылки все вернутся? (кроме варианта, что расширение вообще удалили)

(14) всех причин отключения расширения, наверно, ни кто не знает
Но просто выключенное расширение, тоже уконтрапупит данные
Риски:
- у расширения достаточно снять активность (шибко любопытный админ с шаловливыми ручками)
- при автоматическом обновлении поставить режим "объект поставщика не редактируется" (и сделать это можно только специально и с танцами)

(18) с того, что документ из него перестанет существовать в пользовательском режиме
и нет гарантий, что данные не зачистятся

(17) месье надо четко обосновать, почему переносить все доработки в расширение - есть плохо. со всеми рисками. Потому что цель - возвращение конфигурации на поддержку и автообновление. Хотя я вообще не доверяю обновлениям в расширениях, нередко слетали доработки в них, а когда их много, то проверить всё нереально. Когда оно в конфе - сравнение конфигураций даёт 99% инфы, где что-то может поменяться. Единственный случай на моей памяти, когда доработка ссылалась на типовой метод, который был изменен - тогда была ошибка вроде при реструктуризации. При работе с расширениями, тем более, когда работает автообновление - это бомба замедленного действия

Ну либо сделать, как хочет клиент, если его не переубедить

(21) Чего пользователь не видит - того не существует? Трудно с этим согласиться.
А вот эта мантра про "нет гарантий" - она и вне контекста обсуждения расширений имеет место быть.

(14) отвалится - когда удалят. если оно не активно, то таблицы с данными остаются.

когда только появились расширения, действительно данные местами пропадали. Но сейчас давно такого не наблюдаю

(19) И? Вопросы могут вылезти и через время т.к. все особенности существующих конфигураций учесть не получится
Совсем очевидные проблемы, зачастую, вылавливаются на предрелизном контроле

(22) для чего автообновление? как часто обновляетесь? ту же БП или ЗУП обычно достаточно раз в квартал обновлять

(23) Не факт, что просто не видит

Получается пока вижу 2 основных риска потери данных:
1) при переходе на новую платформу, на которой по какой-то причине расширение сбойнет.
2) если шаловливые руки пользователя с полными правами не просто снимут галочку расширения, но еще и удалят расширение

Ну и гемор, что расширение при обновлении может "не встать", и это не сразу заметят

(14)
https://bugboard.v8.1c.ru/error/000158895

"Тестирование и исправление информационной базы не исправляет повреждение записей в служебных таблицах, хранящих информацию о расширениях конфигурации,

которое приводит информационную базу в неработоспособное состояние."
есть уверенность, что подобное не повторится?

(27) Располагаете фактами, что при отключении активности у расширения пропадают данные? Может, в какой-то статье рассматривался вопрос и можете поделиться ссылкой? Ну вот на самом деле интересно. Или просто Одна Бабка Сказала?

(26) Обновляются так часто, как выходят обновления, как минимум где меняется не последняя цифра. В начале года вот сейчас будет несколько обновлений с новогодними изменениями.
Автообновление хотят, чтобы экономить на обновлениях.

(29) Спасибо за ссылочку. Приложу

(31) Обновляются так часто, как выходят обновления
в этом нет необходимости
Автообновление хотят, чтобы экономить на обновлениях.
если есть риски потерять данные, то экономия не стоит того.

(18) Именно. Отключение расширения не стирает данные, а удаление расширения - стирает.

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

(31) вот не ставьте новогодние обновления пока что. Самое нужное всегда выкатывают числа 25 декабря.

(33)
Говоришь клиенту -- тут куча работы. С вас 300к руб за работу.
А потом вы сможете на обновлениях наэкономить!

(22) "Потому что цель - возвращение конфигурации на поддержку и автообновление." Добавленные объекты поддержке не мешают, а автообновление зло. Разве никогда не видели отозванных релизов? Вышло обновление - подожди дней пять, нет паники и воплей пострадавших, значит можно ставить.

(37)

Одна из причин, по который я начал читать мисту -
это ожидание "начали ли мышки кушать кактус и сильно ли укололись"

(0) Если используется (или планируется) РИБ - то реквизиты в расширении потребуют обязательного синхрона расширений.

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

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

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

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

При всем этом лично моя рекомендация - реквизиты в конфу, весь код и формы в расширение.

(37) Иногда обновления "срочные", что прям ждем. Но обычно ждем выходных, чтобы в случае чего дождаться патчей или хотя бы фиксации проблем )

(39) Спасибо