Обновление не типовой конфигурации.Журнал изменений
Доброго времени суток!
Есть конфигурация нетиповая 1С: Комплексная автоматизация 8(база большая, 10Гб+), ее нужно обновить до актуального релиза и чтобы остались изменения внесенные ранее. Человек, который будет обновлять запросил полный журнал изменений не типовой конфигурации(т.е. текущей нашей) по отношению к актуальному релизу.
Подскажите пожалуйста, как сделать этот журнал? Можно ли как-то стандартными средствами?
Заранее извиняюсь, если вдруг не в том разделе создал тему.
Есть конфигурация нетиповая 1С: Комплексная автоматизация 8(база большая, 10Гб+), ее нужно обновить до актуального релиза и чтобы остались изменения внесенные ранее. Человек, который будет обновлять запросил полный журнал изменений не типовой конфигурации(т.е. текущей нашей) по отношению к актуальному релизу.
Подскажите пожалуйста, как сделать этот журнал? Можно ли как-то стандартными средствами?
Заранее извиняюсь, если вдруг не в том разделе создал тему.
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) список различий ваш доработанный релиз <==> типовой релиз того же номера
список различий типовой релиз того же номера <==> последний актуальный релиз
на основе этих списков можно построить список изменений, которые нужно перенести в актуальный релиз.
"человек, который будет обновлять" может и сам его составить, но если бы вы вели такие записи при обновлениях, работать было бы гораздо легче.
Поговорите с обновленцем, может, он сам вам этот журнал сделает.
список различий типовой релиз того же номера <==> последний актуальный релиз
на основе этих списков можно построить список изменений, которые нужно перенести в актуальный релиз.
"человек, который будет обновлять" может и сам его составить, но если бы вы вели такие записи при обновлениях, работать было бы гораздо легче.
Поговорите с обновленцем, может, он сам вам этот журнал сделает.
(5) Для определения делается 3 сравнения:
1. сравнение конфигурации базы данных старый релиз (дописанная) и конфигурации поставщика того же релиза (типовая) - получим изменения сделанные сторонним программистом
2. сравнение конфигурации поставщика старый релиз (типовая) и конфигурации поставщика новый релиз (типовая) - получим изменения сделанные 1С
3. сравнение основной конфигурации базы данных старый релиз (нетиповая) с конфигурацией поставщика новый релиз (типовая) - делается автоматически при обновлении и показывает отличия старого нетипового релиза и нового типового.
В принципе журнал строится по первому пункту а остальные это уже для специалиста который будет обновлять. По идее он и сам может это все построить и лучше смотреть не в текстовое описание со слов кого-либо а напрямую в код, тогда точно видно что и где добавлено и изменено.
1. сравнение конфигурации базы данных старый релиз (дописанная) и конфигурации поставщика того же релиза (типовая) - получим изменения сделанные сторонним программистом
2. сравнение конфигурации поставщика старый релиз (типовая) и конфигурации поставщика новый релиз (типовая) - получим изменения сделанные 1С
3. сравнение основной конфигурации базы данных старый релиз (нетиповая) с конфигурацией поставщика новый релиз (типовая) - делается автоматически при обновлении и показывает отличия старого нетипового релиза и нового типового.
В принципе журнал строится по первому пункту а остальные это уже для специалиста который будет обновлять. По идее он и сам может это все построить и лучше смотреть не в текстовое описание со слов кого-либо а напрямую в код, тогда точно видно что и где добавлено и изменено.
(8) а еще может быть что конфигурация поставщика не обновлена. и может быть нюанс. после обновления конфы поставщика он не найдет по внутренним идентификаторам совпадений с объектами текущей конфигурации.
тут может идти обновление через CF, тогда
1) типовая база
2) объединяем с нашим текущим доработанным CF
3) обновляем на релиз(ы)
4) выгружаем обновленный CF, грузим его в текущую базу
PS по поводу первого пункта нашел такое решение -
1) предварительно выгружаем измененный CF
2) загружаем типовой CF поставщика в текущую базу, этим мы обновили поставщика, не сохраняем изменения
3) снимаем галочки на нужных объектах
4) объединяем с измененным CF
5) сохраняем изменения
смысл в том что, как я понял, при сравнении с конфой поставщика идет сравнение через идентификатор, а при сравнить-объединить через наименование.
то есть мы сначала восстановили внутр ид, потом накатили наши доработки.
может я неправ - поправьте, кто еще какие способы использует
тут может идти обновление через CF, тогда
1) типовая база
2) объединяем с нашим текущим доработанным CF
3) обновляем на релиз(ы)
4) выгружаем обновленный CF, грузим его в текущую базу
PS по поводу первого пункта нашел такое решение -
1) предварительно выгружаем измененный CF
2) загружаем типовой CF поставщика в текущую базу, этим мы обновили поставщика, не сохраняем изменения
3) снимаем галочки на нужных объектах
4) объединяем с измененным CF
5) сохраняем изменения
смысл в том что, как я понял, при сравнении с конфой поставщика идет сравнение через идентификатор, а при сравнить-объединить через наименование.
то есть мы сначала восстановили внутр ид, потом накатили наши доработки.
может я неправ - поправьте, кто еще какие способы использует
(8) Это все понятно. Но опять же - не у всех руки растут из нужного места. Просто ,встречалось не раз, что при сравнении основной конфигурации с конфигурацией поставщика вываливалось практически все дерево метаданных (тут конечно надо смотреть возможно везде были изменения ) , но все-таки такое случается .
Один случай из жизни. Работал у нас один парень. Досталось ему обновлять не типовую конфую. На копии базы он все подготовил и вместо того что бы выгрузить конфигурацию в файл , он создал файл поставки с обновленной конфы !!!! и с помощью его обновил основную базу )))
А еще есть любители обновлять через сравнение и объединение
Один случай из жизни. Работал у нас один парень. Досталось ему обновлять не типовую конфую. На копии базы он все подготовил и вместо того что бы выгрузить конфигурацию в файл , он создал файл поставки с обновленной конфы !!!! и с помощью его обновил основную базу )))
А еще есть любители обновлять через сравнение и объединение
Странный подход. А если что то затрётся он потом пожалуется на то что ему не корректные данные предоставили? Если хочешь что то сделать хорошо сделай сам. Так что пусть анализирует+можно посмотреть на корректность внесения изменений с возможностью реструктуризации для более лёгкого дальнейшего обновления.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот