Постановка на поддержку конфигурации. Много объектов
Всем доброе время суток !
Ситуация следующая.
База БП 3.0.
Конфигурация полностью находится в режиме "Редактирование с сохранением поддержки" (на всех объектах желтые кубики).
Есть небольшие изменения - добавлена пара справочников и документов, у нескольких существующих справочников и документов добавлено несколько реквизитов.
Стоит задача - поставить конфигурацию на поддержку с возможностью изменения (установить замочки где только можно).
Насколько я знаю фирма 1С предлагает нам в такой ситуации два варианта решения.
Первый вариант.
Загрузка конфигурации поставщика из файла. В этом случае вся конфигурация заменится конфигурацией поставщика, на всех объектах появятся замочки но все изменения в данных в результате реструктуризации будут утеряны.
Второй вариант
Конфигурация - Поддержка - Настройка поддержки - Сравнить, объединить
В этом варианте мы можем отдельно менять режим поддержки по каждому объекту.
Но возникает проблема в трудоемкости этого процесса если объектов много.
В в той же БП 3.0 это именно так.
К сожалению фирма 1С не дает в руки механизма поставить замочки например на все справочники сразу или сразу на все перечисления - только по одному.
Может есть еще какой то вариант решения ?
Ситуация следующая.
База БП 3.0.
Конфигурация полностью находится в режиме "Редактирование с сохранением поддержки" (на всех объектах желтые кубики).
Есть небольшие изменения - добавлена пара справочников и документов, у нескольких существующих справочников и документов добавлено несколько реквизитов.
Стоит задача - поставить конфигурацию на поддержку с возможностью изменения (установить замочки где только можно).
Насколько я знаю фирма 1С предлагает нам в такой ситуации два варианта решения.
Первый вариант.
Загрузка конфигурации поставщика из файла. В этом случае вся конфигурация заменится конфигурацией поставщика, на всех объектах появятся замочки но все изменения в данных в результате реструктуризации будут утеряны.
Второй вариант
Конфигурация - Поддержка - Настройка поддержки - Сравнить, объединить
В этом варианте мы можем отдельно менять режим поддержки по каждому объекту.
Но возникает проблема в трудоемкости этого процесса если объектов много.
В в той же БП 3.0 это именно так.
К сожалению фирма 1С не дает в руки механизма поставить замочки например на все справочники сразу или сразу на все перечисления - только по одному.
Может есть еще какой то вариант решения ?
По теме из базы знаний
- Технология обновления нетиповых конфигураций 1С:Предприятия 8 (редакция 12.04.2012)
- АИС: Обмен данными с ЕГАИС 4.0 для конфигураций 1С 7.7
- Синхронизация хранилища 1С и git-репозитория с применением OneScript и Gitsync. Методика и пошаговая инструкция для создания скрипта и его регулярного запуска
- Многопоточный CI-контур для 1С c Packer, Vagrant и Jenkins. Часть 1. Описание системы и обзор инструментария
- Самые используемые методы БСП 3.1.9
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Тю. Загрузи из файла, но конфу БД не обновляй. Включи возможность изменения где надо, объедини со своей старой, залив нужные изменения и только после этого обновляй конфу БД. Перед обновлением БД сделай еще через "Сравнить конфигурации" сравнение основной конфы и конфы БД, чтобы ничего не провтыкать.
(2) я правильно понимаю - последовательность следующая
1. загружаем конфигурацию поставщика. происходит замена конфигурации. все изменения внесенные в конфигурацию удаляются.
2. сохраняем конфигурацию. обновить конфигурацию базы данных - нет.
3. сравнение с конфигурацией БД предварительно выгруженной в файл, внесение нужных изменений.
4. сравнение основной конфы и конфы БД - изменений быть не должно.
после этого обновить конфигурацию БД.
1. загружаем конфигурацию поставщика. происходит замена конфигурации. все изменения внесенные в конфигурацию удаляются.
2. сохраняем конфигурацию. обновить конфигурацию базы данных - нет.
3. сравнение с конфигурацией БД предварительно выгруженной в файл, внесение нужных изменений.
4. сравнение основной конфы и конфы БД - изменений быть не должно.
после этого обновить конфигурацию БД.
(6) ерунда какая то получается все равно
взял из конфигурации БД (с которой сравнивал) (которую предварительно сохранил в файл) документ, перечисление и регистр
а в результате реструктуризации получают вот такое сообщение
причем реально в конфигурации добавлены документ, перечисление и регистр.
все остальное в штатном режиме (конфигурации - поддержка - сравнение с конфигурацией поставщика) ставится по отдельности на поддержку.
взял из конфигурации БД (с которой сравнивал) (которую предварительно сохранил в файл) документ, перечисление и регистр
а в результате реструктуризации получают вот такое сообщение
причем реально в конфигурации добавлены документ, перечисление и регистр.
все остальное в штатном режиме (конфигурации - поддержка - сравнение с конфигурацией поставщика) ставится по отдельности на поддержку.
Прикрепленные файлы:
(9)
это в режиме сравнения-объединения?
по скрину
все вроде ровно - у вас добавлены три новых объекта по сравнению с типовой.
у вас не показано главное - нет значка восклицательного знака - на что конкретно ругается и не дает сохранить.
(10)
ну в принципе это норм. при загрузке + сравнение с доработанной-сохранение - он может показать при сохранении много объектов.
взял из конфигурации БД (с которой сравнивал) (которую предварительно сохранил в файл) документ, перечисление и регистр
это в режиме сравнения-объединения?
по скрину
все вроде ровно - у вас добавлены три новых объекта по сравнению с типовой.
а в результате реструктуризации получают вот такое сообщение
у вас не показано главное - нет значка восклицательного знака - на что конкретно ругается и не дает сохранить.
(10)
при реструктуризации получаю сообщения что константы изменены.
ну в принципе это норм. при загрузке + сравнение с доработанной-сохранение - он может показать при сохранении много объектов.
у вас не показано главное - нет значка восклицательного знака - на что конкретно ругается и не дает сохранить.
мне по этой схеме обновления не понятны два момента
первый - почему у меня при реструктуризации показывает создание новых констант (если по константам вообще изменений нет и все их по отдельности я могу поставить на поддержку).
вот скриншот сравнения основной конфигурации и конфигурации поставщика - на нем четко видно что по константам изменений нет. почему же получается после загрузки конфигурации поставщика показывает что константы созданы ?
второй момент.
при реструктуризации ругается на регистр сведений ЦеныНоменклатурыДокументов.
однако сравнение с конфигурацией поставщика показывает что по этому регистру вообще нет изменений !
причем по сравниваемым конфигурациям все нормально
основная конфигурация Бухгалтерия предприятия, редакция 3.0 (3.0.46.19)
конфигурация поставщика 3.0.46.19
Прикрепленные файлы:
(9) Неправильно сравниваете. После подготовки основной конфы перед обновлением конфы БД сравниваете так:
1) в конфигураторе меню "Конфигурация" - "Сравнить конфигурации".
2) первая конфигурация - "Конфигурация базы данных", вторая конфигурация - "Основная конфигурация"
3) Важно! Галка внизу "Устанавливать соответствия по именам объектов" должна быть снята! В этом случае сравнение будет производиться по идентификаторам метаданных, а не именам.
Вот когда сравните так, то сразу увидите ту проблему, которую вам отобразило окно реструктуризации: судя по всему, какие-то обновления вы накатывали через сравнить/объединить и получилось так, что одни и те же объекты метаданных у вас и в типовой конфигурации имеют разные идентификаторы. В итоге реструктуризация предлагает вам удалить ваши объекты и создать новые.
Короче, при таких раскладах предложенный мною путь не канает (через загрузку конфы). Надо через штатные механизмы обновления делать (как предлагали) или вручную настраивать поддержку - при этом учитывается возможность отличий внутренних идентификаторов метаданных (оно там внутре соответствие делает).
1) в конфигураторе меню "Конфигурация" - "Сравнить конфигурации".
2) первая конфигурация - "Конфигурация базы данных", вторая конфигурация - "Основная конфигурация"
3) Важно! Галка внизу "Устанавливать соответствия по именам объектов" должна быть снята! В этом случае сравнение будет производиться по идентификаторам метаданных, а не именам.
Вот когда сравните так, то сразу увидите ту проблему, которую вам отобразило окно реструктуризации: судя по всему, какие-то обновления вы накатывали через сравнить/объединить и получилось так, что одни и те же объекты метаданных у вас и в типовой конфигурации имеют разные идентификаторы. В итоге реструктуризация предлагает вам удалить ваши объекты и создать новые.
Короче, при таких раскладах предложенный мною путь не канает (через загрузку конфы). Надо через штатные механизмы обновления делать (как предлагали) или вручную настраивать поддержку - при этом учитывается возможность отличий внутренних идентификаторов метаданных (оно там внутре соответствие делает).
(12) изменения по метаданным увидел.
показало в режиме сравнения Конфигурация Поставщика - Основная конфигурация
по константам все стало понятно.
вопрос по регистру сведений ЦеныНоменклатурыДокументов остался.
по нему изменений любой режим сравнения не показывает. однако в реструктуризацию он попадает.
показало в режиме сравнения Конфигурация Поставщика - Основная конфигурация
по константам все стало понятно.
вопрос по регистру сведений ЦеныНоменклатурыДокументов остался.
по нему изменений любой режим сравнения не показывает. однако в реструктуризацию он попадает.
Прикрепленные файлы:
(12)
это делал мой предшественник.
(12)
скажите это можно как то исправить ?
сейчас даже если я ставлю объект метаданных на поддержку без возможности изменения
при сравнении конфигураций мне показывает что все равно есть различия.
я хочу выправить различия по идентификаторам метаданных чтобы можно было загрузить конфигурацию поставщика, объединить ее с основной конфигурацией (предварительно выгруженной в файл) и после этого не попасть на реструктуризацию которая мне удалит перечисление и создаст заново (но уже с новым идентификатором).
судя по всему, какие-то обновления вы накатывали через сравнить/объединить
это делал мой предшественник.
(12)
получилось так, что одни и те же объекты метаданных у вас и в типовой конфигурации имеют разные идентификаторы
скажите это можно как то исправить ?
сейчас даже если я ставлю объект метаданных на поддержку без возможности изменения
при сравнении конфигураций мне показывает что все равно есть различия.
я хочу выправить различия по идентификаторам метаданных чтобы можно было загрузить конфигурацию поставщика, объединить ее с основной конфигурацией (предварительно выгруженной в файл) и после этого не попасть на реструктуризацию которая мне удалит перечисление и создаст заново (но уже с новым идентификатором).
Прикрепленные файлы:
(6) то есть например в режиме конфигурации - поддержка - сравнение с конфигурацией поставщика я по константам изменений не вижу. по одной все поставил на поддержку.
а когда делаю через загрузить конфигурацию поставщика потом при реструктуризации получаю сообщения что константы изменены.
а когда делаю через загрузить конфигурацию поставщика потом при реструктуризации получаю сообщения что константы изменены.
Хм... Может, это просто чепуха какая типа настроек поддержки, порядка или еще чего.
Я обычно полностью доверяю сравнению по той методике, что описал. Раз по внутренним идентификаторам все совпадает - значит таблицы перефигачивать не должен.
Для гарантии можно кэш конфы почистить еще.
Со сбойным после динамических обновлений кэшем конфы проблемы могут быть.
Я обычно полностью доверяю сравнению по той методике, что описал. Раз по внутренним идентификаторам все совпадает - значит таблицы перефигачивать не должен.
Для гарантии можно кэш конфы почистить еще.
Со сбойным после динамических обновлений кэшем конфы проблемы могут быть.
я лично делал так:
1) выгрузил измененную основную
2) загрузил типовую
3) включил возможность изменения, выбрал те пункты что я менял
4) сравнить-объединить с пунктом 1
5) сохранить конфигурацию, применить изменения к базе данных.
не объединял по идентификаторам, просто по именам. данные не затирались все было норм.
ПРУФ в теме
1) выгрузил измененную основную
2) загрузил типовую
3) включил возможность изменения, выбрал те пункты что я менял
4) сравнить-объединить с пунктом 1
5) сохранить конфигурацию, применить изменения к базе данных.
не объединял по идентификаторам, просто по именам. данные не затирались все было норм.
ПРУФ в теме
(18) что делать с объектами у которых идентификаторы метаданных отличаются ?
посмотрите (17) как это выглядит на практике.
в результате когда мы будем делать пункт 5) сохранить конфигурацию, применить изменения к базе данных.
система сделает следующее - удалит метаданные с идентификаторами которых нет, и тут же создаст их снова с идентификатором который идет в конфигурации поставщика.
и в результате реструктуризации мы потеряем все данные по этим объектам метаданных.
например при реструктуризации будет удалено перечисление СпособыЗаполненияЦен (потому что у него отличаются идентификаторы между основной конфигурацией и конфигурацией поставщика, тут же создастся заново но данные будут утеряны.
а теперь представьте что данные этого перечисления используются в проводках. последствия представляете ?
в вашем случае по всей видимости таких сложностей не было поэтому все прошло гладко.
посмотрите (17) как это выглядит на практике.
в результате когда мы будем делать пункт 5) сохранить конфигурацию, применить изменения к базе данных.
система сделает следующее - удалит метаданные с идентификаторами которых нет, и тут же создаст их снова с идентификатором который идет в конфигурации поставщика.
и в результате реструктуризации мы потеряем все данные по этим объектам метаданных.
например при реструктуризации будет удалено перечисление СпособыЗаполненияЦен (потому что у него отличаются идентификаторы между основной конфигурацией и конфигурацией поставщика, тут же создастся заново но данные будут утеряны.
а теперь представьте что данные этого перечисления используются в проводках. последствия представляете ?
в вашем случае по всей видимости таких сложностей не было поэтому все прошло гладко.
(22)
конечно.
на скриншоте ясно видно что в реальности отличий нет просто отличается порядок метаданных между конфигурациями.
но из за этого при применении изменений к БД попадаем на реструктирузацию по всем этим объектам - в (9) скриншот как это выглядит.
версии конфигурации поставщика и основной одинаковые?
конечно.
на скриншоте ясно видно что в реальности отличий нет просто отличается порядок метаданных между конфигурациями.
но из за этого при применении изменений к БД попадаем на реструктирузацию по всем этим объектам - в (9) скриншот как это выглядит.
(18) вот смотрите наглядно как это выглядит по документам
в результате мы по всем получим реструктуризацию с удалением отличающихся по идентификаторам реквизитов и создание новых с идентификаторами как в конфигурации поставщика. с потерей данных хранящихся в этих реквизитах.
в результате мы по всем получим реструктуризацию с удалением отличающихся по идентификаторам реквизитов и создание новых с идентификаторами как в конфигурации поставщика. с потерей данных хранящихся в этих реквизитах.
Прикрепленные файлы:
Простых способов поменять идентификаторы метаданных я не знаю. Штатно разве что через перенос данных из копии в новые пересозданные таблицы.
Но и большого смысла с этим гемороиться я не вижу. Сам с этой фигней на поддержке я не сталкивался, но точно знаю что на поддержке можно настроить соответствие своих метаданных с метаданными конфигурации поставщика на уровне соответствий внутренних идентификаторов и в будущем проблем возникнуть не должно.
Но и большого смысла с этим гемороиться я не вижу. Сам с этой фигней на поддержке я не сталкивался, но точно знаю что на поддержке можно настроить соответствие своих метаданных с метаданными конфигурации поставщика на уровне соответствий внутренних идентификаторов и в будущем проблем возникнуть не должно.
(20)
смысл огромный.
если есть способ настроить соответствие своих метаданных с метаданными конфигурации поставщика тогда все становится просто отлично - делаем как подробно расписано в (18), сохраняемся и при применении изменений к базе данных не имеем проблем с реструктуризацией потому что идентификаторы наших метаданных и метаданных конфигурации поставщика одинаковые.
и в результате мы избегаем необходимости вручную ставить признак поддержки (замочки) по нескольким десяткам а то и сотням объектов конфигурации.
Но и большого смысла с этим гемороиться я не вижу
смысл огромный.
если есть способ настроить соответствие своих метаданных с метаданными конфигурации поставщика тогда все становится просто отлично - делаем как подробно расписано в (18), сохраняемся и при применении изменений к базе данных не имеем проблем с реструктуризацией потому что идентификаторы наших метаданных и метаданных конфигурации поставщика одинаковые.
и в результате мы избегаем необходимости вручную ставить признак поддержки (замочки) по нескольким десяткам а то и сотням объектов конфигурации.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот