1) Собственно как вы обновляете конфигурации, если нет возможности на рабочей делать все эти сравнения и анализ изменений.

Вот обновил я копию. Как потом обновить рабочую, чтобы у той осталась конфигурация поставщика?

Я думал можно создать файл поставки, но видимо это совсем другое. Т.к. переписанная конфигурация становится конфигурацией поставщика.

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

Сначала обновляешь основную конфу.
Потом обновляешь конфу поставщика.

А зачем конфигурация поставщик в рабочей? Чтобы место больш9е занимало?

(0) Создаешь хранилище, подключаешь туда рабочую базу и программистскую. Все делаешь в программистской как положено, через обновление, проверяешь и все прочее. Потом кладешь в хранилище и потом в рабочей получаешь из хранилища. Готово!

(0)
1. Делаешь копию базы.
2. На копии обновляешь рабочую конфу и основную.
3. Проверяешь работоспособность по максимуму возможностей
4. Выгружаешь конфу из копии.
5. Загружаешь (именно загружаешь) конфу в рабочей базе из файла, так как конфа в файле - потомок основной конфы в рабочей базе.
6. Запускаешь 1С и обработчики обновления.
Есть засада с тем, что можешь перепрыгнуть через много релизов, и обработчики обновления не смогут стартануть.

(4) Из-за таких кулибинов приходится часто обновлять через одно место.
Никогда не загружай конфу ибо можно затереть данные. И еще сам признался что не стоит перепрыгивать релизы.
Есть релизы кторые модно а есть релизы которые нельзя надо следить за этим.

+(5) В догонку.
Загружать можно но со знанием дела. Если ты полностью контролируешь ситуацию.

(5) "Никогда не загружай конфу ибо можно затереть данные"

Если у тебя ноги от плеч растут - то да, можно.

Я делаю так если на копии.
1. Делаешь копию базы.
2. На копии обновляешь рабочую конфу и основную. При чем строго следуешь по релизам.
3. Проверяешь работоспособность по максимуму возможностей
4. Выгружаешь конфу из копии.
5. На реальной базе обновляешь рабочую конфу и основную. При чем строго следуешь по релизам. Но при этом можно не следить за кодом.
5. Загружаешь (именно загружаешь) !!!иногда достаточно не загружать а объединить! конфу в рабочей базе из файла, так как конфа в файле - потомок основной конфы в рабочей базе.
6. Запускаешь 1С и обработчики обновления.

(7) К чему это я же уточнил.

Сколько извращенцев однако.

(10) Расскажи свою версию

Я делал так.
Берём сф обновляемой.
Обновляем по ключевым релизам. После каждого ключевого подготовленный сф сохраняем.
Берём рабочую и последовательно загружаем (не объединяем) подготовленные сф. После каждого - запуск 1с и отработка всех обработчиков.
Последний раз переход с летней БП2 на крайнюю БП3 по такой методике (не считая подготовки) занял 9 часов. Из них 8 - сохранение конфигураций (F7) и применение обработчиков.

У меня все просто получается. Единственно где я слежу строго когда предопределенные ПВХ меняются и план счетов. И там где на форме изменения дважды.

(12) Тоже рабочий вариант. Но если явно видишь что промежуточные сильно не отличаются и даже иногда не пересекаются с доработкой то нет смысла загружать. Можно рабочую обновлять до последнего и загрузить в копию обновленную последнем обновлении.

(14) Я сказал - "ключевые релизы". А они явно сильно отличаются, иначе не были бы ключевыми.

(15) Я это понял. Я имел ввиду если ключевые релизы ни как не пересекаются с доработками то можно не загружать конфу  с копии а просто рабочую обновлять так получается менее рискованнее. С точки зрения потери данных при загрузке.

(0) Делаешь копию, а лучше Две копии базы, можно просто конфигурацию.
И сравниваешь.

Зачем Две копии?

Затем, что бывает при сравнении надо открыть какой модуль, а он при открытии начинает как бы меняться (слетает сравнение и объединение), это особенно выстреливает на формах.
И что бы все время не делать сравнить и объединить, а точечно все устанавливать, вот так и робим в двух копиях.

...
Так же Если Базы Типовые, и на УФ, то пишем расширения, в которых и прописываем все изменения в интерфейсе или еще где.
В итоге у нас не поменянная основная конфа и обновляется по типовому и без принуждений. (в конце только дописываем расширение)

Как быть, если надо добавить новые реквизиты?
...Ответ: Можно их размещать в расширении, но тут есть ограничения. (не везде это можно добавить. При проверке физ. целостности данных, ваши реквизиты из расширения системой воспринимаются как ошибочными, т.е. ТиИ не видит расширение - Спасибо 1С, они все делают ради нас :) )

...Новые реквизиты лучше прописывать в основной конфе, при объединении с типовым обновлением оно не мешает, главное галочки не ставить :)



...п.с. вот как то так...

+ (0) Если доживешь до изменений базы в Расширении, самое тяжкое, это отслеживать что поменялось в основной, и в расширении.
Я делаю это через "Чек поинты", заведомо важных функциях прописываю код, который семафорить, что дескать эту функцию надо посравнивать, на всякой

(17) Тоже иногда на двух смотрел раньше. Иногда лень или этого не требуется.
А так мысли и идеи хорошие. в мемориз

(11) Рассказал уже в (3).

(18) >Если доживешь до изменений базы в Расширении

А в расширениях можно реализовывать такую схему:

Есть документ Реализация Товаров. Разработчик добавил еще 2 своих регистра. В следующих релизах разработчики конфигурации добавили 3 регистра где этот документ регистратор.

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

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

(21) В расширении к существующему и заимствованному в расширение регистратору прикручено там еще какие-то регистры (любые), но просто новые и просто с тем же регистратором.

Если в основной конфигурации произошли какие-то изменения с регистратором, появились еще какие-то регистры - ну и что?

Главное не удалять из базы само расширение и не удалять из расширения регистратор (чтоб регистр остался привязан к своему прежнему регистратору). Тогда ничего не пропадает. Ситуация проверена практическим использованием.

Но бывает, что 1С берет и пишет к старому объекту префикс Удалить и делает новый - вот этого нового в расширении не будет. Но на данных Удалить должно остаться. Если только его не снимут с проведения, конечно.

Правильный метод описан в (3). Всё делается через хранилище с полным захватом всего дерева конфигурации для редактирования.

Всё остальное - какая-то дичь. Или подходит только для случая, когда обновление готовится прямо в рабочей базе (что само по себе уже неправильно).

(23) Давай по другому. С другой стороны.

У меня есть документ. У него в Свойства - Движения добавлено что он может быть регистратором по добавленному регистру.

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

(25) хм...

А тебе не кажется, что "получить из хранилища" перезаписывает текущую точно также как и "загрузить из файла" ?

(26) Как бы объяснить, чтоб и быстро и правильно :-)

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

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

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

(28) >инфа о том, что документ является регистратором для регистра - она в регистр пишется

В конфигурации это пишется в двух местах

1. У документа. Свойства-движения по регистру.
2. У регистра. Регистраторы - документ.

Теперь смотри что получается.

С обновлением приходит документ у которого в свойствах-движения нет этого регистра. Вот это хочется сделать расширением.

Если я сохраню эту конфу и применю изменения то пропадут движения.

Особенно это муторно и противно отслеживать если надо накатить 10-20 обновлений.

(26) Хранилище к рабочей базе? Вы похоже не работали, когда в отделе 10+ разрабов.

(30) к (25)

(29) // 1. У документа. Свойства-движения по регистру.

нет!

(29) Это отображается там, но это не в документе. Сам этот признак, что документ связан с регистратором по полю Регистратор - он есть только в регистре.

(30) Работал. Поэтому знаю, что разрабам нечего делать в том хранилище, к которому подключена рабочая база.
Вообще при интенсивной разработке силами нескольких разработчиков вести разработку в едином хранилище - то ещё извращение. Оно если и возможно, то только в условиях частого и регулярного объединения всех сделанных изменений (едва ли не ежедневного помещения сделанных изменений в хранилище). В противном случае начинаются конфликты и потеря контроля над изменениями. Я даже не знаю делает ли так кто-нибудь реально, чтобы 10 разрабов сидели в одном хранилище...

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

(33) >Сам этот признак, что документ связан с регистратором по полю Регистратор - он есть только в регистре

Ничего подобного.

Создай новый регистр и добавь документ который есть в обновлении от поставщика регистратором по этому регистру.

Сделай несколько движений по регистру.

А потом накати обновление документа от поставщика. Которое не знает о том что ты добавил документ регистратором по этому регистру.

В результате все движения этого документа по новому регистру у тебя пропадут.

(34) А ты как собираешься совместную разработку вести без хранилища?

(34) делает. Очень часто. Тебе просто повезло.

(37) люди используют 2 хранилища. Потом особо ответственный программист мержит код из хранилища для программистов и основного. Либо он отвечает за перенос доработок из вспомогательного хранилища в основное.

(36) Я проверю. Как оно там пропадает и т.д.

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

(34) >Вообще при интенсивной разработке силами нескольких разработчиков вести разработку в едином хранилище - то ещё извращение

Почему извращение ?

Каждый разработчик захватывает в хранилище те объекты которые ему нужны. Как закончил доработку поместил в хранилище.

(40) >обрати внимание на более существенный момент - все это мы обсуждаем в расширении.

Так я этого и хочу добиться. Документы добавленные регистраторами в новые регистры в расширение. Накатывание этих документов от поставщика.

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

(42) Как ты отключишь его, если регистры с движениями в нем же сидят?

(43) Отключить расширение где документ делает движения по новым регистрам. Добавление в свойства документа возможности движений по новым регистрам.

(44) Продолжим :-)

Сделал конфу. Превратил ее в конфу с поставщиком. Есть там конфа поставщика. Документ1, Регистр1.
Действительно, если это в Основной конфигурации, то связь между документ1 и добавленным регистр2 задается через Документ1, прописывается так, как ты указал выше.
При получении метаобъекта Документ1 из конфы Поставщика, Движения у него превращаются в такие, которые указаны в конфе Поставщика, т.е. только
а регистр2 теряет связь регистратором Документ1. Хотя конфа Поставщика ссылок на регистр2 не содержит. Т.е. инфа пишется в сам документ, а не в регистратор.

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

&После("ОбработкаПроведения")

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

Т.е. Заимствованный из основной Документ1 в расширении вкладку Движения не показывает. Отредактировать их нельзя. Но в регистре вкладка Регистраторы есть - можно указать там.
Вот как-то так.

Резюмируем.
Есть разные случаи. И все они имеют право быть если это логично и правильно.
Я например пока был фри обновлял кучу баз клиентов и для этого спецом хранилище не создавал.
1. Обновлял на копии и потом обновляя рабочую базу объединял или загружал подготовленную копию.
2. Сейчас я фикси все базы у нас в хранилище. Пока я не обновлял. Но другие обновляют...
3. Бывало обновлял и базы с рашсирением. Вроде бы серьезных проблем не было. За исключением когда потребовалось изменить релиз платформы в расширение было сделано не другом релизе. Как обошли проблему не помню.
4. Обновлял еще после кривых обновлений когда релиз основной базы одно а поставщика совсем другое. Приходилось приводить в прядок через гланды. Большого мата в адрес предыдущего обновлялщика.
Каких только баз не бывало.

Я обновляю и копию и рабочую без прыжков, как-то восстанавливал базу после такого, ощущения не из лучших)

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

Ну и вообще все доработки я держу в расширениях, местами не удобно, но плюсов больше.

попытка устроить хранилище-срач детектед - пост 46 и выше на этой теме

т.е. мало того, что сам топик является попыткой срача по конфе поставщика, так еще и хранилище к этому

(48) (49) А ты, смотрю, в сортах-то разбираешься...

(50) лень просто спорить по существу.

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

А при этом все остается на том же месте и появляется посто со словом "резюмирую" и выводами с тегом #ЯграфМонтеКристо

Спокойнее, спокойнее.

(0) У нас боевая к хранилищу подключена, поэтому как ниже предлагаю загрузить конфу не вариант (в хранилище недоступна загрузка конфигурации). Мы делаем так:

1. Обновить тестовую на ближайший совместимый релиз. Окончательный файл настроек сравнения сохраняю. Запустить, дождаться выполнения всех обработчиков, все протестировать, вылезшие косяки кода поправить. Уже поправленный итоговый Cf тоже сохраняю.
2. В боевой базе запустить обновление на нужный релиз через Конфигурация - Объединить.
3. Загрузить файл настроек из п.1 в сравнение. Если файл потеряли, то оставить галочки по умолчанию, тоже норм, но изменения в таком случае я просматриваю на всякий. Нажать Выполнить.
4. Сравнить-объединить с итоговым cf из тестовой из пункта 1, поставить все галочки, нажать Выполнить.
5. Запустить боевую, дождаться выполнения всех обработчиков.

Повторить все пункты для следующего ключевого релиза.

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

(45) >При получении метаобъекта Документ1 из конфы Поставщика, Движения у него превращаются в такие, которые указаны в конфе Поставщика, т.е. только
а регистр2 теряет связь регистратором Документ1

Именно так.

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

И это приходиться отслеживать при накатывании каждого обновления.

Я не пойму - в чем проблема при работе с хранилищем по схеме в (36) ? Все очень удобно.

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

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

(55) // И это приходиться отслеживать при накатывании каждого обновления.

Вот именно _это_ (допрегистры накопления и движение по допрегистрам) при использовании расширения отслеживать не придется, если оно будет сделано механизмами расширения

(58) >Вот именно _это_ (допрегистры накопления и движение по допрегистрам) при использовании расширения отслеживать не придется, если оно будет сделано механизмами расширения

А потом можно будет убрать расширение и добавить движение по допрегистрам вручную ?

То есть такая схема

1. Создается расширение в которое добавляется движения существующего документа по допрегистрам.
2. Накатываются обновления поставщика где у документа нет движений по допрегистрам. Наличие движений документа по допрегистрам регулируется расширением.
3. Отключение расширения и добавление движений существующего документа по допрегистрам в свойства документа.

(59) объясни - на кой их убирать и добавлять куда-то вручную?

И почему, если уж в голову вдарит убирать, почему нельзя написать обработку, которая просто закопирует сформированные движение на новое место, также примерно, как это делает типовое обновление?

но самый первый вопрос - зачем их из расширения убирать?

(61) >самый первый вопрос - зачем их из расширения убирать?

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

И не иметь никаких проблем с расширениями. Даже теоретических

(61) Подскажи один момент пожалуйста. Не пойму что делаю не так.

Добавляю расширение.

Назначение "Дополнение".

Щелкаю по документу "РеализацияТоваровУслуг". Добавить в расширение.

В расширении открываю этот документ.

Где для этого документа сказать что он должен делать движения по допрегистру ? В свойствах документа в расширении этого не вижу.

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

В расширениях для заимствованных документов в самих документах список регистров не доступен. Заходишь в созданный регистр в расширении и там указываешь нужный регистратор.
Если свой новый документ - этот список доступен.

(64) >Заходишь в созданный регистр в расширении и там указываешь нужный регистратор.

1. Добавил в расширение существующий документ.
2. Добавил в расширение новый регистр.

Ни у документа ни у регистра в расширении не вижу где их связать по схеме "документ является регистратором регистра".

(65) может платформа совсем старая?

Я их использую начиная с режима совместимости 8.3.14. Может эти возможности и раньше появились, но не помню.

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

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

А вообще, попробовал только что прикольную штуку. Сделал Документ1 и Регистр1. Документ2 и Регистр2. Т.е. пары, не зависящие друг от друга.
Затем ставлю в Расширение заимствование Документ1 и Регистр2. В основной они не связаны друг с другом. Если накатывать из Поставщика - оторвутся друг от друга наверняка.

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

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

(66) >может платформа совсем старая?

Платформа 8.3.17.1851)

Пробую на конфе Бухгалтерия предприятия, редакция 3.0 (3.0.82.24)

У нее режим совместимости стоит Версия 8.3.14

Может в этом дело.

у меня все работает. в БП совместимость 8.3.14 - так и есть.

Бухгалтерия предприятия КОРП, редакция 3.0 (3.0.88.28)
И свое расширение Менеджер склада, т.к. учет в производство не настолько замороченный, чтоб имело смысл ставить КА