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

Ссылочные объекты метаданных добавлять в конфигурацию, все остальное в расширения.
Или все в расширения, но делать копии и восстанавливать их периодчиески.

Подпишусь. Сам пока предпочитаю хранимые данные добавлять только в конфигурацию, интересна обратная практика

Стараюсь добавлять данные в основную, код в расширение. Были негативные прецеденты при обновлении базы с РИБ(ERP). Бывают жесткие требования - основную не трогать вообще... :) Тогда добавляю в расширение, но предупреждаю, что могут возникнуть проблемы.

(0) [Все ведущие курсов советуют использовать только расширения]
это пиз.доболы, которые уже ни чего не могут, кроме обучения

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

[Все ведущие курсов советуют использовать только расширения]
А что реально все ведущие курсов такое говорят? оО

Проголосовал бы за п.1, но формулировка чересчур мажорная. И вообще чёрно-белое разделение. Пунктов не хватает.

вопрос вслывает каждый квартал.

(5) Ну холивар не холивар а переживания есть - нам потом все данные восстанавливать если что. Поэтому заранее интересуемся)

(0) В вашем случае я бы добавлял доработки в конфигурацию. Обновление ERP особо не ухудшиться, это не БП.

(8) Во-во, от этого сильно быстрее ERP обновляться не станет. ) Проверять расширения после обновления всё равно надо.

(6) в смысле конкретные проблемы при использовании первого сценария?

(10) я думаю он про волнующий меня вопрос, про саму тему. Логично что многие этим интересуются.

пс. Этот как с ЕДТ - на каждом углу про него трещат и советуют переходить на него, а начинаешь слушать реальный опыт использования - всплывают неприятные моменты (ОТУС например недавно делал стрим-рассказывал) - вот и думай использовать ЕДТ или нет)

я бы добавил пункт 3. Нет разницы. Важно предусмотреть при разработке расширения выгрузку (сохранение) данных из добавленных реквизитов. "На Аллаха надейся, но верблюда привязывай"

Никаких проблем не выявлено..

(5) Думаешь когда столкнёшься тебе будет легче, что до этого ни разу не сталкивался?
P.S. Я сталкивался. Терялись данные при штатном ТиИ

"Если расширение добавляет собственный реквизит к справочнику прикладного решения, то для этого справочника создаётся отдельная таблица с новой структурой (с дополнительной колонкой для нового реквизита). "

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

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

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

Источник https://wonderland.v8.1c.ru/blog/rasshirenie-dannykh/

2. Данные лучше в основной конфигурации хранить

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

У меня в одной базе, слетают права на расширение, при любом изменении этого расширения.
И надо постоянно не забывать восстановить эти права кучи пользователей. Как победить х.з.

И таких "приколов" мне встречалось несколько

Все по возможности в расширении если нет РИБ

(19) ну так сегодня нет, а завтра есть :)

(15) Нет, не легче. Правда это если столкнусь. Можно поподробнее про потерю данных?
(16) Не все работают с данными на уровне SQL. И такая работа не предусмотрена вендором, или да?
(18) А при чём тут хранение данных в расширении и слетающие права? Обсуждение идёт именно в контексте хранения данных.

(20) Сегодня в вашей фирме нет работы через мобильного или веб-клиента, завтра есть. А ваш сегодняшний код уже это предусмотрел, не правда ли? )

(14)[Никаких проблем не выявлено]
и это было тяжёлое тиражное решение 1С с УРБД и интеграцией ?

(21) слетают галки в обработки "управление расширениями". Там отдельно устанавливаются права на расширение по пользователям.
Вот тут: https://wonderland.v8.1c.ru/upload/medialibrary/8cc/8cca86d84c5f84bec81bf5e5a31e4fd7.png

(22) ну я не про то :)
Сегодняшний код не делает невозможной работу с веб или мобильным клиентом. В отличие от пары: расширение-РИБ

(23) Отраслевое высоконагруженное решение под ERP - маркировка с десятками млн. марок, многопоточной обработкой, учет акцизов, потерь (вмешательство в план счетов, БУ, акцизную декларацию), свой RLS, оптимизация типового RLS, обмен с ЕГАИС, работа с web, ТСД на Мобильном клиенте, свои ВК. Вот УРБД не требовалось.

(23) Тиражное. Много (относительно) клиентов, не один.

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

(21) конкретно этот баг уже поправили.
Если у справочника добавить реквизит через расширение, то все "подчиненые" справочники теряли владельца при ТиИ (неверная ссылка на владельца). Т.е. если у контрагента добавить реквизит, то договора после ТиИ будут с очищенным владельцем
После добавления реквизитов через расширения 1С удаляет элементы при ТиИ

(28) ничего в конфигураторе не расставлял. В расширении вообще нет ролей. Сама конфа типовая.
Такая проблема только у пользователей с ограниченными правами.

*

Есть пара достаточно объемных баз. Проблем не было пока

не снимайте с поддержки, потом будет много проблем. всё можно реализовать расширениями и механизмом дополнительных реквизитов и сведений

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

Прецедентов с потерей данных не было.

(34) Приведи примеры. "Мужики-то не знают"

(36) да были примеры, но их пофиксили, а боязнь осталась. таких не переубедишь ) я вот данные не терял, для меня расширения - это просто спасение. а кто-то терял, и никогда их юзать не будет.

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

(38)Обновление же в разы дольше, просто в РАЗЫ

(39) Что понимается под временем обновления? Время сравнения конфигураций, так им можно пренебречь для тяжелых случае. Какая разница минуту шло сравнение или 20, если у тебя условно ручной работы на день

(39) Ну подождать подольше пока сравнятся конфигурации поставщика. Это далеко не самый длительный (да вообще незначительный) этап в процессе обновления конфигурации. К тому же делается он на полном автомате.

(41)На автомате это когда обновлятором обновил, затем зашёл в конфигуратор, при помощи kdiff3 поправил 99% модулей, какие-то чутка ручками, исправил стандартные болячки по типа режима совместимости и всё.

Ну если работа такая что попиваешь чаёк, ходишь курить по 20 минут каждый час, работаешь с парочкой конф, то наверное да, можно и подождать. Но когда реальность немного другая, то время ожидания лишним не бывает.

(42) Это вам повезло, что политики безопасности не запрещают установку стороннего софта. В своё время тоже привык к KDiff3, а потом отвыкал. (

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

(44)Извините, не понимаю вас.

Голосование остановилось на 50-50. Perfectly balanced, as it should be.
мде...

(46) Жалко выборка маленькая. Я бы послушал бы разработчика ИР.

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

(45) Я про то, что в случае разработки без расширений при обновлении ты можешь контролировать слияние изменений: "при помощи kdiff3 поправил 99% модулей, какие-то чутка ручками" - вот это всё.
В случае разработки в расширениях эти инструменты будут недоступны

(49)Вы заблуждаетесь. Вероятно вы действительно мало работали с расширениями и поэтому не поняли меня в (42).

Всё прекрасно работает, попробуйте.