Технология обновления нетиповых конфигураций 1С:Предприятия 8 (редакция 12.04.2012)
База данных - Инструменты администратора БД
В этой статье не описываются методики применения автоматического и автоматизированного обновления конфигураций с использованием внешних компонент и/или программных продуктов. Информацию по ним вы можете найти на этом и других ресурсах Интернета.
| Только качественный контент |
Возможно, вы заметили, что при каждом очередном обновлении количество объектов, требующих вашего внимания, только увеличивается. При этом вы точно знаете, что изменен, например, только один документ, а при обновлении выдается список из нескольких десятков измененных объектов. Конечно, можно воспользоваться методикой описанной в статье «Технология обновления нетиповых конфигураций 1С:Предприятия 7.7» от 27.06.2003. Да, это будет работать. Многие именно так выполняют обновления. Но я считаю данный подход неэффективным и трудоемким при обновлении конфигураций на платформе 1С:Предприятия 8. В отличие от платформы 1С:Предприятия 7.7 платформа 1С:Предприятия 8 позволяет открывать одновременно несколько конфигураций (файлы *.cf) и выполнять несколько сравнений конфигураций в одной копии конфигуратора. Исключение составляют, пожалуй, только конфигурации построенные на УПП (Управление производственным предприятием) - они слишком тяжелые, платформа падает.
Процесс обновления конфигураций 1С:Предприятия 8 более автоматизирован по сравнению с 1С:Предприятием 7.7. Достаточно высокий уровень автоматизации позволяет значительно снизить трудоемкость работ при обновлении нетиповых конфигураций. К сожалению, чаще всего процесс обновления нетиповых конфигураций не может быть выполнен полностью в автоматическом режиме и требует вмешательства специалиста.
Возможна ли ситуация, когда процесс обновления будет выполнен полностью автоматически? Конечно. Для этого изменяемые объекты должны быть добавлены и не должны использовать функционал существующей конфигурации. Т.е. эти объекты должны решать абсолютно другие учетные задачи, расширяющие функционал типовой конфигурации поставщика. Согласитесь, что описанная ситуация является крайне редкой. Практически всегда изменения затрагивают объекты типовой конфигурации поставщика.
Следует обратить внимание на то, что база данных может содержать до трех видов конфигураций:
- конфигурация базы данных – это конфигурация, с которой работают пользователи;
- рабочая конфигурация (основная) – это конфигурация, в которую мы можем вносить изменения, при этом пользователи могут продолжать работать;
- конфигурация поставщика – это исходная конфигурация поставщика, на основе которой обычно создаются рабочая конфигурация и конфигурация базы данных. В базе данных может быть несколько конфигураций от различных поставщиков. Поставщиком конфигурации может быть не только фирма «1С».
В случае, когда конфигурация снята с поддержки, конфигурации поставщика не будет. Что в свою очередь значительно повышает трудоемкость обновления.
Рассмотрим процесс обновления и разберем возможные ошибки на примере обновления конфигурации УПП (поставщик типовой конфигурации – фирма «1С», доработки компании Информ Сервис). Изначально обновление данной конфигурации выполнялось не по описанной в данной статье технологии, поэтому рассматриваемые в статье ошибки являются наиболее часто встречающимися на практике. Обновление будет выполняться с версии 1.2.6.2 на версию 1.2.14.1.
Этап 1. Подготовка.
На первом этапе приведем в соответствие рабочую конфигурацию к конфигурации поставщика. Это очень важный этап, который позволит значительно уменьшить объем работ по анализу внесенных нами ранее изменений.
Этот этап можно пропустить, если последнее обновление прошло через «поддержку» (Меню «Конфигурация» U94; «Поддержка» U94; «Обновить конфигурацию») или было выполнено по описанной в данной статье методике.
Несоответствие версий рабочей конфигурации и конфигурации поставщика может возникнуть при использовании для обновления *.cf файлов, не из дистрибутива поставщика или при использовании методов обновления отличающихся от описанных в данной статье. Напрмер, объекты добавлялись в рабочую конфигурацию копированием через буфер обмена или Drag&Drop.
1. Сравнение версий.
Проверим номера версий рабочей конфигурации и конфигурации поставщика. Номер рабочей конфигурации смотрим в меню «Конфигурация» U94; «Открыть конфигурацию» меню «Правка» U94; «Свойства». В блоке «Разработка» пункт «Версия». (Рисунок 1).
Рисунок 1.
Номер конфигурации поставщика смотрим в меню «Конфигурация» U94; «Поддержка» U94; «Настройка поддержки…» пункт «Версия». (Рисунок 2).
Рисунок 2.
Если номера совпадают, то переходим к следующему этапу. См. Этап 2.
В данном примере необходимо привести в соответствие рабочую конфигурацию и конфигурацию поставщика с постановкой на поддержку объектов, снятых с поддержки или добавленных без постановки на поддержку. Для этого выполним следующие действия:
2. Сохранение рабочей (основной) конфигурации.
Сохраним рабочую конфигурацию в файл, например work.cf. Для этого выберем пункт меню «Конфигурация» U94; «Сохранить конфигурацию в файл…».
3. Получение файла обновления для конфигурации поставщика.
Для приведения в соответствие конфигураций нам понадобится файл *.cf из дистрибутива поставщика с тем же номером версии, что у рабочей конфигурации (Рисунки 3 и 4). Данный файл можно получить при установке соответствующего дистрибутива. По умолчанию установка дистрибутива конфигурации выполняется в каталог C:\Program Files\1cv81\tmplts\. Подробнее об установке шаблонов конфигураций см. документацию.
Рисунок 3.
Рисунок 4.
Проверим каталог шаблонов. Если в каталоге шаблонов есть *.cf файл нужной версии, то переходим к пункту 4 Этапа 1.
Что можно сделать, если нет *.cf файла нужной версии конфигурации поставщика? В этом случае можно воспользоваться файлами *.cfu и повторив описанную в Этапе 1 процедуру несколько раз последовательно поднять номер версии до требуемого релиза, в данном случае до 1.2.6.2. Следует отметить, что использование файлов *.cfu может не вскрыть ошибки, допущенные ранее при обновлении. Что, согласитесь, довольно странно, учитывая тот факт, что вначале собирается файл поставщика на основе старой конфигурации поставщика и *.cfu файла, а затем выполняется обновление. Возможно это связано с тем, что в сравнении почему-то участвуют не все объекты конфигурации. Поэтому предлагаю использовать возможно более длинный путь, но и более надежный.
Необходимо создать пустую базу данных со "старой" конфигурацией поставщика. Обновить конфигурацию поставщика до нужной версии и уже её использовать при выполнении работ на 1 этапе. Для получения "новой" конфигурации поставщика нужно сделать следующее:
-
Создание "старого" файла поставщика для текущей конфигурации. Файл 1cv8.cf можно взять из дистрибутива поставщика или сохранить из рабочей базы, если конфигурация находится на поддержке. Для сохранения файла 1cv8.cf из рабочей базы необходимо в меню «Конфигурация» U94; «Поддержка» U94; «Настройка поддержки...» нажать кнопку «Сохранить в файл» и указать каталог и имя файла. Например, на рабочий стол.
-
Создание базы данных с новой конфигурацией поставщика. Базу данных можно создать, используя дистрибутив поставщика с диска ИТС или используя полученный ранее 1cv8.cf с рабочего стола. В первом случае следуем инструкции входящей в дистрибутив. Во втором случае для создания базы из расположенного на рабочем столе файла, создаем новую информационную базу без конфигурации и запускаем конфигуратор. В меню «Конфигурация» U94; «Загрузить конфигурацию из файла...» указываем файл, сохраненный ранее на рабочем столе. Открываем конфигурацию через меню «Конфигурация» U94; «Открыть конфигурацию» и обновляем до нужного релиза через меню «Конфигурация» U94; «Поддержка» U94; «Обновить конфигурацию» используя файлы *.cfu.
-
Создание файла "новой" конфигурации поставщика. Для этого выбираем пункт в меню «Конфигурация» U94; «Сохранить конфигурацию в файл...». Уточняем расположение и имя файла 1cv8.cf. Нажимаем «Сохранить».
4. Приведение в соответствие рабочей конфигурации и конфигурации поставщика через обновление.
Используя полученный *.cf файл конфигурации поставщика выполним обновление. Для этого выберем пункт меню «Конфигурация» U94; «Поддержка» U94; «Обновить конфигурацию», «Выбор файла обновления», «Готово» (Рисунок 5), «Выполнить» (Рисунок 6).
Рисунок 5.
Рисунок 6.
Итак, первая проблема – «Обнаружены ссылки на объекты, помеченные на удаление». (Рисунок 7).
Рисунок 7.
Варианты решения:
- снять пометку с объекта, которыйв конфигурации поставщика;
- удалить ссылку на объект, которыйв конфигурации поставщика.
Исходя из того, что ссылка в добавленном интерфейсе «РуководительОтдела» выполнена на объект конфигурации поставщика, поддержка с которого снята поставщиком (возможно в связи с изменением методики учета), то правильным решением в данной ситуации будет удаление ссылки на этот отчет из интерфейса «РуководительОтдела». Окно сравнения конфигураций не закрываем, ссылку на отчет «ОплатаЗаказов» в интерфейсе «РуководительОтдела» удаляем. После удаления ссылки выполним повторное сравнение конфигураций. Для этого нажмем кнопку «Обновить» в окне обновления (Рисунок 6).
5. Восстановление настроек частично утерянных на предыдущем этапе.
Для восстановления частично утерянных настроек выполним объединение с ранее сохраненным файлом рабочей конфигурации work.cf. Для этого выберем пункт меню «Конфигурация» U94; «Сравнить, объединить с конфигурацией из файла…».
6. Сохранение результатов обновления.
Сохраним изменения рабочей конфигурации и обновим конфигурацию базы данных. Для этого выберем пункт меню «Конфигурация» U94; «Обновить конфигурацию базы данных».
Здесь нас поджидает очередная проблема (Рисунок 8).
Рисунок 8.
Для решения данной проблемы посмотрим на причину её возникновения. Причин может быть несколько, но наиболее вероятны следующие из них. Данные объекты были скопированы в рабочую конфигурацию из конфигурации поставщика или поставщик удалил ранее данные объекты, а позже добавил новые с такими же именами, но с другими внутренними идентификаторами. В результате в конфигурации появляются объекты с разными внутренними идентификаторами, но с одинаковыми именами.
С ролями поступаем просто - удаляем, т.к. роли не изменялись (это можно проверить, сравнив старую конфигурацию поставщика и рабочую конфигурацию). С реквизитом документа действуем иначе. Реквизит необходимо переименовать, например ЗаказРезерв1, а после обновления перенести значения из переименованного реквизита в новый. Для этого можно воспользоваться обработкой УниверсальныеПодборИОбработкаОбъектов.epf с диска ИТС.
Рассмотрим еще одну ситуацию, аналогичную предыдущей, но возникшую при обновлении 1С:Бухгалтерии предприятия 8.1. Что делать с формами? (Рисунок 9)
Рисунок 9.
На рисунке мы видим, что ФормаСписка была удалена у поставщика, а затем добавлена поставщиком новая форма с тем же именем. Соответственно необходимо пометить обе формы для обновления и нажать кнопку «Выполнить».
В случае если будет выдано сообщение о том, что имеются ссылки на удаляемые объекты, необходимо не закрывая форму обновления очистить ссылки на удаляемую форму в свойствах объекта. В данном случае в свойствах регистра. После этого необходимо в форме обновления нажать кнопку «Обновить», пометить к обновлению свойства регистра и еще раз нажать кнопку «Выполнить».
Сохраним изменения рабочей конфигурации и обновим конфигурацию базы данных «Конфигурация» U94; «Обновить конфигурацию базы данных».
Если необходимо, перенесем значения реквизита ЗаказРезерв1 в ЗаказРезерв с помощью внешней обработки в режиме 1С:Предприятие.
После проведения подготовительных работ на Этапе 1 переходим к обновлению основной конфигурации и переносу ранее сделанных доработок типовой конфигурации поставщика.
Для обновления конфигурации нам понадобится файл *.cfu или файл *.cf из дистрибутива поставщика. Подробнее о способах их получения можно почитать здесь.
Если обновление выполняется через несколько версий конфигурации, то следует обратить внимание на ситуацию, описанную в статье «Обновление конфигураций 1С:Предприятия 8. Прыжок через 20 версий». Если обновление выполняется не на рабочей базе, то после завершения работ по подготовке каждого нового этапа сохраняем файлы *.cf. Они понадобятся при обновлении конфигурации рабочей базы данных заказчика.
Если обновление выполняется через несколько версий, то при обновлении следует обязательно обратить внимание на удаляемые объекты и на объекты с измененными именами, а также на действия, выполняемые при первом запуске после обновления. Если эти объекты используются в обработке при первом запуске после обновления, то не следует их удалять, а по объектам с измененными именами следует внести соответствующие изменения в текст модуля обработки. В этом случае, оставленные объекты могут быть удалены при повторном или следующем обновлении.
Если обновление выполняется через несколько версий, то для снижения трудоемкости обновления, можно воспользоваться методикой с вычислением ключевых релизов, описанной в статье «Обновление конфигураций 1С:Предприятия 8. Прыжок через 20 версий».
1. Подготовка баз данных.
Итак, по результатам первого этапа готовим две одинаковые базы. Первая (основная) - наш будущий результат. Вторая (вспомогательная) - для выполнения сравнений, открытия конфигураций и других подготовительных действий. Для файлового варианта это просто копирование файлов основной базы в другой каталог и подключение этого каталога в список баз, для клиент серверного - выгрузка / загрузка.
2. Трёхсторонее сравнение конфигураций.
Откроем обе базы в режиме Конфигуратор и выполним трёхсторонее сравнение конфигураций в обеих базах, используя имеющийся файл новой конфигурации поставщика. Для этого в обеих базах выберем пункт меню «Конфигурация» U94; «Поддержка» U94; «Обновить конфигурацию», «Выбор файла обновления», «Готово» (Рисунок 10).
Рисунок 10.
В результате сравнения трех конфигураций (старая конфигурация поставщика, новая конфигурация поставщика и рабочая конфигурация) получаем список измененных объектов. Устанавливаем фильтр «Показывать только дважды измененные свойства» (Рисунки 11 и 12).
Именно с этими объектами необходимо разобраться в первую очередь, т.к. после обновления, выполненные ранее настройки, могут быть утеряны.
Рисунок 11.
Рисунок 12.
Рисунок 13.
На этом работу во второй (вспомогательной) базе приостанавливаем и продолжаем в основной. Кнопку «Выполнить» во вспомогательной базе не надо нажимать. Нам эта база нужна именно в таком виде до окончания процесса обновления.
Итак, в результате получаем список объектов, дважды измененных при доработке типовой конфигурации и в новой конфигурации поставщика. Если согласиться с обновлением, то сделанные ранее доработки в этих объектах будут утеряны. Поэтому по каждому объекту необходимо принять решение о том, каким образом он будет обновлен (Рисунок 13). На этом этапе выполняем предварительное сравнение исключительно для того, чтобы уменьшить объем работ в дальнейшем. Оценка не точная быстрая - «на глазок».
Если изменений в объекте больше в новой конфигурации поставщика, то оставляем экземпляр объекта поставщика. Оставляем галочку. Затем перенесем изменения из рабочей конфигурации.
Если изменений в объекте больше в рабочей конфигурации, то оставляем экземпляр объекта рабочей конфигурации. Снимаем галочку. Затем перенесем изменения из конфигурации поставщика.
С модулями поступаем немного иначе, т.к. в нашем распоряжении есть возможность сравнивать модули попроцедурно. Т.е. в случае, если в нашей конфигурации и в конфигурации поставщика изменены различные процедуры модуля, то правильно расставив галочки мы избавим себя от ручного переноса изменений кода. Чтобы до этого добраться нажимаем кнопку как это показано на рисунке 14.
Рисунок 14.
Далее расставляем галочки, указывая какие процедуры и функции следует заменить или удалить (Рисунок 15).
Рисунок 15.
После того как определились с объектами, которые будут обновлены сразу и на которых остались галочки, дублируем состояние по галочкам во вспомогательной базе, а в основной базе нажимаем кнопку «Выполнить». В основной базе получаем почти готовую конфигурацию.
Далее все сравнения выполняем во вспомогательной базе. Одно сравнение у нас уже есть - трехстороннее. Для определения ранее внесенных изменений выполняем дополнительное второе сравнение старой конфигурации поставщика с основной конфигурацией. Для этого выберем пункт в меню «Конфигурация» U94; «Сравнить конфигурации:», выберем для сравнения «Конфигурация поставщика» и «Основная конфигурация» (Рисунок 16).
Рисунок 16.
Аналогичным образом сравниваем старую конфигурацию поставщика с новой. Для сравнения нам понадобится файл новой конфигурации поставщика. Если такого файла нет, то теперь его можно получить из основной базы. Для сохранения в файл новой конфигурации поставщика в основной базе в меню «Конфигурация» U94; «Поддержка» U94; «Настройка поддержки:» нажимаем кнопку «Сохранить в файл». (Рисунок 2). Указываем имя файла, например, new.cf. Далее делаем третье сравнение конфигураций и при сравнении в качестве второй конфигурации указываем файл new.cf.
Итак, мы получили в дополнительной базе список дважды измененных объектов. И еще два сравнения, которые помогут нам более эффективно перенести ранее сделанные настройки из старой версии в новую. В основной базе мы получили почти готовую конфигурацию, в которой необходимо разобраться с дважды измененными объектами.
Для сокращения времени на анализ изменений типовой конфигурации и, соответственно, на обновление было бы уместно комментировать все вносимые в конфигурацию изменения, отмечая не только измененный текст модулей, но и цель выполненных изменений. По ряду причин очень часто этого не делают. При выполнении обновления интересуют не причины внесения изменений, а их последствия. А именно необходимость сохранить функционал измененной конфигурации. Возможно это потребует не переноса измененных строк, а полной переработки добавленного (измененного) кода под функционал новой конфигурации поставщика.
Сравнение форм, таблиц, и модулей объектов в конфигурации выполняется с достаточной степенью детализации (Рисунок 17). Этого вполне достаточно для принятия решений.
Рисунок 17.
Но в некоторых случаях данные в отчетах о сравнении представляются в виде, не позволяющем принять решение быстро. Например, в случае изменения типа реквизитов, имеющих составной тип данных, состав вводимых на основании объектов и т.д. Именно на данном этапе, ввиду его сложности, происходит потеря доработок при обновлении. Рассмотрим эту ситуацию на примере реквизитов, имеющих составной тип данных. При формировании отчета о сравнении объектов (Рисунок 17) различающиеся данные в сравниваемых конфигурациях представлены в виде списков, содержащих состав типов данных, разделенных запятыми. При этом в отчете совершенно не видно, какие типы данных были добавлены или удалены. Конечно, для выявления различий отчет можно распечатать и «скрыжить». В рассматриваемом примере таких объектов около 200. Очевидно, что процесс сравнения представляется достаточно трудоемким и составит около 50 часов.
Для снижения трудоемкости работ при сравнении объектов можно воспользоваться конфигурацией «Сравнение ячеек», разработанной компанией Информ Сервис. Примерно в 20 раз может выть снижена трудоемкость работ при сравнении составных объектов.
Конфигурация «Сравнение ячеек» запускается в режиме 1С:Предприятие и позволяет представить информацию из отчета о сравнении объектов в наглядном виде (Рисунки 18 и 19). Для сравнения используются возможности 1С:Предприятия 8.
Рисунок 18.
Рисунок 19.
Схема работы конфигурации проста. В конфигураторе создаем отчет о сравнении объектов (Рисунок 17) и сохраняем в файл, например ОтчетОСравнении.mxl. Открываем 1С:Предприятие и в диалоге (Рисунок 18) выбираем сохраненный файл и указываем сравниваемые ячейки. Для этого дважды щелкаем правой клавишей мыши на выбранной ячейке табличного документа. По кнопке «Сравнить» получаем результат сравнения, в котором различающиеся позиции выделены цветом (Рисунок 19).
Далее, исходя из того, что сравнение выполняется по тем же принципам сравнения объектов, схема действий будет выглядеть так. Сохраняем следующий отчет под тем же именем файла. Нажимаем кнопки «Обновить» и «Сравнить». Более подробное описание данной обработки можно посмотреть здесь «Сравнение ячеек».
Особо пристальное внимание следует уделить шаблонам RLS по измененным ролям пользователей.
После завершения обновления и переноса, ранее сделанных изменений типовой конфигурации выполним синтаксический контроль модулей и проверим работу измененных объектов. После успешного тестирования процесс обновления конфигурации можно считать завершенным. Теперь осталось обновить внешние печатные формы, отчеты и обработки. Для некоторых конфигураций необходимо проверить формы отчетности подключенные как внешние.
Этап 3. Сдача работ.
В приведенном примере объем работ по исправлению ошибок, допущенных при предыдущих обновлениях, а также по обновлению на версию 1.2.14.1 и переносу ранее внесённых в типовую конфигурацию изменений составляет порядка 100-150 часов. Выполнить такой объем работ, выполняя обновление непосредственно в базе заказчика, не представляется возможным. Соответственно подготовительные работы необходимо выполнить на копии базы данных, а результат обновления перенести в рабочую базу заказчика.
Вначале внимательно изучаем инструкцию из дистрибутива поставки. Выполняем необходимые работы перед обновлением в рабочей базе.
Если в рабочей базе данных заказчика во время подготовки обновления не проводились работы по изменению конфигурации, а обновление готовилось на актуальной копии рабочей базы данных, то для переноса настроек сохраним рабочую конфигурацию в файл, например work_2.cf, выбрав пункт меню «Конфигурация» U94; «Сохранить конфигурацию в файл…».
Дальнейшие действия на стороне заказчика будут следующие:
- создать резервную копию базы данных;
- используя файл work_2.cf, переносим изменения. Для этого выберем пункт меню «Конфигурация» U94; «Загрузить конфигурацию из файла…»;
- на вопрос об обновлении конфигурации базы данных ответим согласием.
Если в рабочей базе данных заказчика во время подготовки обновления проводились работы по изменению конфигурации, то эти изменения необходимо также отразить при обновлении.
Если обновление готовилось не на актуальной копии рабочей базы данных, то для переноса настроек воспользуемся методикой использованной на первом этапе. Для этого нам понадобится файл *.cf типовой конфигурации поставщика (1.2.14.1) и результат обновления в виде также *.cf файла. Для этого сохраним рабочую конфигурацию в файл, например work_2.cf, выбрав пункт меню «Конфигурация» U94; «Сохранить конфигурацию в файл…».
Дальнейшие действия на стороне заказчика будут следующие:
- создать резервную копию базы данных;
- используя файл *.cf типовой конфигурации поставщика, выполним обновление. Для этого выберем пункт меню «Конфигурация» U94; «Поддержка» U94; «Обновить конфигурацию», «Выбор файла обновления», «Готово» (Рисунок 10), «Выполнить»;
- используя файл work_2.cf, переносим изменения. Для этого выберем пункт меню «Конфигурация» U94; «Сравнить, объединить с конфигурацией из файла…»;
- сохраним изменения рабочей конфигурации и обновим конфигурацию базы данных. Для этого выберем пункт меню «Конфигурация» U94; «Обновить конфигурацию базы данных».
Далее следуем инструкциям из дистрибутива поставки и выполняем необходимые работы после обновления.
Правильное выполнение данного этапа позволит в дальнейшем избежать работ, описанных в Этапе 1.
04.05.2008 /Константинов Алексей Викторович/
редакция от 12.04.2012
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
Инструментарий разработчика Чистка данных Свертка базы Инструменты администратора БД Системный администратор Разработчик Руководитель проекта 1С:Предприятие 8 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 Россия Платные (руб)
Инструмент представляет собой обработку для проведения свёртки или обрезки баз данных. Работает на ЛЮБЫХ конфигурациях (УТ, БП, ERP, УНФ, КА и т.д.). Поддерживаются серверные и файловые базы, управляемые и обычные формы, интерфейс 8.5. Может выполнять свертку одновременно в несколько потоков, а также без непосредственного участия пользователя. Решение в Реестре отечественного ПО.
24900 руб.
20.08.2024 83192 432 171
Инструменты администратора БД Роли и права Системный администратор Разработчик Пользователь 1С 8.3 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Документооборот 1С:Зарплата и кадры государственного учреждения 3 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Платные (руб)
Роли… Вы тратите много времени и сил на подбор ролей среди около 2400 в ERP или 1500 в Рознице 2, пытаясь понять какими правами они обладают? Вы все время смотрите права в конфигураторе или отчетах чтоб создать нормальные профили доступа? Вы хотите наглядно видеть какие права дает профиль и редактировать все в простом виде? А может хотите просто указать подсистему и дать права на просмотр и добавление на объекты и не лезть в дебри прав и чтоб обработка сама подобрала нужные роли? Все это теперь стало возможно! Обновление от 17.04.2026, версия 1.4.1, работает в 1С:ФРЕШ!
23180 руб.
06.12.2023 25055 85 14
Инструменты администратора БД Инструментарий разработчика Роли и права Разработчик 1С:Предприятие 8 1C:Бухгалтерия Россия Платные (руб)
Расширение позволяет без изменения кода конфигурации выполнять проверки при вводе данных, скрывать от пользователя недоступные ему данные, выполнять код в обработчиках. Не изменяет данные конфигурации, легко устанавливается практически на любую конфигурацию на управляемых формах.
17000 руб.
10.11.2023 28707 103 46
Поиск данных Инструменты администратора БД Корректировка данных Разработчик Бухгалтер Пользователь 1С:Предприятие 8 1С:Управление торговлей 10 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x 1С:Управление нашей фирмой 3.0 Россия Платные (руб)
Решение для автоматической сверки данных между любыми конфигурациями 1С. Помогает контролировать и проверять обмены, проверять наличие документов при переносах данных, находить изменения в закрытых периодах
9760 руб.
14.11.2025 6150 28 8
Информационная безопасность Инструменты администратора БД Инструментарий разработчика Учет документов Системный администратор Разработчик Аналитик Бухгалтер Пользователь Руководитель проекта 1С 8.3 1С 8.5 Розничная и сетевая торговля (FMCG) Платные (руб)
Контроль ввода данных в 1С: проверка заполнения реквизитов, обязательные поля, контроль перед записью и проведением, запрет проведения документа. Позволяет настраивать любые проверки данных в 1С 8.3/8.5 от обязательных полей до сложных условий – без открытия конфигуратора и написания кода. Готовое расширение, которое подключается и работает сразу.
6000 руб.
15.04.2026 4152 12 0
Инструментарий разработчика Инструменты администратора БД Системный администратор Разработчик Аналитик 1С:Предприятие 8 1С 8.3 1С 8.5 1C:ERP 1С:УТ 1С:ДО 1С:Бухгалтерия 3.0 1С:ERP. Управление холдингом 1С:Зарплата и Управление Персоналом 3.x 1С:Управление нашей фирмой 3.0 1С:Управление торговлей 11 Россия Платные (руб)
Универсальный инструмент программиста для администрирования конфигураций. Сборник наиболее часто используемых обработок под единым интерфейсом.
5000 руб.
14.01.2013 217300 1252 0
Закрытие периода Инструменты администратора БД Корректировка данных Бухгалтер Пользователь 1С:Предприятие 8 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Платные (руб)
Расширение «Оперативное проведение» в 4 раза уменьшает время проведения документов и закрытия месяца. Является комплексным решением проблем 62 и 60 счетов. Оптимизирует проведение при включенной функциональной опции «Раздельный учет НДС». Используется в более 10 организациях уже 2 года. Совместимо с конфигурацией Бухгалтерия 3.0 (+КОРП).
14640 руб.
29.04.2020 52926 145 164
Файловый обмен (TXT, XML, DBF), FTP Поиск данных Инструменты администратора БД Корректировка данных Системный администратор Разработчик 1С:Предприятие 8 1C:Бухгалтерия 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Платные (руб)
Данная обработка позволит Вам легко и просто, а главное - быстро, выполнить сравнение данных между ЛЮБЫМИ базами (и РИБ, по правилам конвертаций) по контрольным суммам выбранных объектов баз 1С, работающих на платформах 8.3 и выше. Удобный и понятный интерфейс в виде "мастера". Высокая скорость сравнения достигается за счет специального алгоритма расчета контрольной суммы объекта/записи и сравнения по данным суммам объектов 2х баз через файл. Имеется возможность выбора реквизитов, по которым система будет сравнивать объекты. Сравнение количества записей в движениях документов, возможность сравнивать данные по правилам конвертации и не только! Выбор объектов конфигурации для КАЖДОГО узла в отдельности с индивидуальным отбором для каждого объекта конфигурации, работа с FTP, сохранение или загрузка настроек, сохранение или загрузка результата сравнения, регистрация на обмен объекта и его движений. (Обновление от 12.11.2024, версия 2.2-2.5)
24400 руб.
27.10.2017 47838 33 15
Но все равно процесс обновления не идеальный, мне так не хватает при обновлении возможность формирования окончательного кода в процессе обновлении, и редактирования экранных форм.
Смысл такой: все содержимое конфигурации вытаскивается в виде дерева из файлов и каталогов. Соответственно форма раскладывается на: файл с описанием визуальной формы, файл модуля формы, файл с описанием, файлы с таблицами (если есть)... Сравнить отдельные файлы и собрать из них конфигурацию непомерно легче, чем пользоваться конфигуратором. Кроме того, так можно изменить и цифровые идентификаторы объектов, вовсе недоступные штатными средствами.
используя файл *.cf типовой конфигурации поставщика, выполним обновление. Для этого выберем пункт меню «Конфигурация» à «Поддержка» à «Обновить конфигурацию», «Выбор файла обновления», «Готово» (Рисунок 9), «Выполнить»;
используя файл work_2.cf, переносим изменения. Для этого выберем пункт меню «Конфигурация» à «Сравнить, объединить с конфигурацией из файла…»;
не объединить в один?
используя файл work_2.cf выполним обновление. Для этого выберем пункт меню «Конфигурация» à «Поддержка» à «Обновить конфигурацию», «Выбор файла обновления», «Готово» (Рисунок 9), «Выполнить»;
Просто ли?
п.1 В другом случае не будут поставлены?
п.2 О чем речь? При каких условиях, на каких этапах?
п.3 О как? Ты хотел сказать больше? Ты предлагаешь хранить в базе данных пользователя две конфигурации. В предложенном варианте - это одна конфигурация.
Лучше если в базе данных у пользователя будет включен режим запрета редактирования конфигурации. В этом случае и конфигураций будет меньше, и пользователь ничего не сможет изменить, и пункт меню Конфигурация» à «Сравнить, объединить с конфигурацией из файла…» работать не будет.
Конфигурация пользователя должна стоять на поддержке у твоей конфигурации, а твоя - у фирмы 1С.
Я понимаю какой именно порядок выполнения обновления предлагается в 11 посте.
Я торжественно клянусь подумать над этим и в будущем отразить это в статье.
Если рассматривать предлагаемый в 11 посте вариант, то применительно к "твоей конфигурации".
п.1 Не имеет смысла, т.к. третий этап не нужен, а вместо этого выполняется создание файлов поставки
п.2 При выполнении этапа 1
п.3 Поправка. Предлагаю хранить 3 конфигурации: Конфигурация поставщика (старая), Основная конфигурация и Конфигурация базы данных.
Если рассматривать предлагаемый в 11 посте вариант, то применительно к "конфигурации пользователя" данная статья не имеет смысла. Т.к. на стороне пользователя процесс обновления аналогичен обновлению типовой конфигурации, а статья про нетиповые.
2. Повторно сравнение объединение будет выполняться быстрее;
п.2 О чем речь? При каких условиях, на каких этапах?
п.2 При выполнении этапа 1
п.2 При выполнении этапа 1 при очередном обновлении? Почему бы не воспользоваться результатом этапа 2 предыдущего обновления? Если этот результат сохранить, то надобность в 1-м этапе отпадает?
Совершенно верно. При условии выполнения этапа 1. На этапе 2.
И при всех последующих обновлениях на этапе 2 минуя этап 1.
Собственно к этому все и велось - снизить трудоемкость подготовки обновлений.
- Запустить обновление до актуальной конфигурации поставщика в режиме "Поддержки"
- В появившемся списке измененных объектов СНЯТЬ ВСЕ ФЛАГИ
- Выполнить обновление
В этом случае будет полностью актуализирована конфигурация поставщика, а измененная конфигурация затронута не будет. И не надо ничего выгружать, сравнивать, объединять, переобновлять и т.п.
Или, может, я специфики не понял?
(16) Совершенно верно, но только в том случае, если у вас есть необходимый файл поставки для "старой конфигурации поставщика". Если такого файла нет и нет возможности его собрать, то эффект может быть противоположным. Т.к. придется разбирать/сравнивать все объекты которые были изменены.
(17) "ребята капусту шинкуют". Это наша конфигурация. Мы на ней работаем и затачиваем под себя. 100-150 часов это фактически выполненные работы - на себя, а не на клиента. Т.е. типа "бесплатно". Статья писалась непосредственно в процессе обновления с исправлением допущенных ранее "ошибок". Так что все здесь написаное это из жизни.
Файл поставки можно получить, выгрузив в файл конфигурацию поставщика. И, если Вы её обновили до актуального релиза (что является обязательным для возможности корректного сравнения), то получить необходимый файл поставки для "старой конфигурации поставщика" - дело нескольких кликов мышки.
В итоге все новые объекты были со значком поддержки.
Сначала попробовал вашим способом - обновить конфигурацию поставщика текущей версии, убрав все галки с объектов. На первый взгляд, все встало на свои места.
Но при обновлении на следующий релиз, возникла проблема. Не показывались дважды измененные объекты. Вернее показывались, но далеко не все.
Решил действовать по описанному в статье порядку действий. А именно, загрузил cf поставщика текущего релиза. Затем, через сравнение/объединение перенес изменения конфигурации. После этого начал обновлять на новый релиз.
После этого дважды измененные стали отражаться корректно.
Собственно сейчас возник вопрос. А как правильно обновлять продуктивную базу? Чтобы при следующем обновлении проблем не было таких?
У меня сейчас есть cf текущего релиза с восстановленной конфигурацией поставщика. Если я его загружу в продуктивную базу, а дальше по описанному алгоритму в статье - обновляем на новый релиз и переносим наши изменения через сравнение объединение, это будет правильно?
Или можно восстановить конфигурацию поставщика через обновление до текущего релиза(с отжатием всех галочек), а дальше по вышеописанному алгоритму?
Проще, по-моему, получить актуальный релиз типовой конфигурации, используя ЦФУ, из нее - выгрузить нормальный ЦФ-ник и объединить все одним махом.
Про обработку удаленных объектов или переименованных объектов - все оч. грамотно написано.
1. При сравнении текстов модулей стандартными возможностями иногда 1С себя ведет неадекватно (неправильно отмечает фрагменты текстов как измененные, добавленные, удпаленные). Обойти это можно следующим образом:
- Сохранить в текстовые файлы тексты обоих модулей методом копи-паст :)
- Воспользоваться стандартным функционалом 1С: "Файл - Сравнить файлы". Там все обычно, как ни странно, корректно! Также можно воспользоваться дополнительным ПО, таким, как Exam2dif.
2. В статье не рассмотрен, наверное, самый сложный момент поддержки измененных конфигураций: объединение измененных ролей! Но это, скорее, тема отдельной статьи...
ЗЫ. 100-150 часов - повеселило!!! ппц ребята капусту шинкуют :)))
В общем, за статью - плюс. Полезно!
Не могу сообразить, почему приведение конфигурации поставщика в соответствие с релизом основной конфигурации нельзя сделать так:
1. Создаём информационную базу из дистрибутива с версией, такой же, как у нашей основной конфигурации.
2. Сравниваем, объединяем конфигурацию этой базы с конфигурацией из файла work.cf.
В результате, ведь, должны получить cf с правильным релизом конфигурации поставщика? Или я чего-то не понимаю? Такое ощущение, что здесь подводные камни есть, но не могу понять какие.
Разумеется это касается только конфигураций, где были изменения в структуре базы данных (Перечислений, ПлановОбмена и т.п. это тоже касается). Если изменения были в модулях или формах диалога, то описанный вами вариант вполне подойдет.
Ещё есть вопрос. Как быть в ситуации, если между релизом Конфигурации поставщика и и релизом Основной конфигурации существуют промежуточные релизы типовых конфигураций. Здесь необходимо обновлять конфигурацию поставщика последовательно, или можно обновить её сразу на последний релиз? Если пойти по первой ветке этого моего предположения, то не получится ли так, что основная конфигурация "обновится" до более старой версии, чем она есть сейчас? А если пойти по второй - обновить сразу на последний релиз типовой, то не возникнет ли каких-нибудь лишних несоответствий?
Этот последний вопрос у меня возникает из-за незнания вот чего: Конфигурация поставщика нужна только для обновления, или на её метаданные имеются "ссылки" из основной конфигурации? (если не "ссылки", то, видимо связь есть по внутренним идентификаторам?)
Проясните пожалуйста!
Для определения цепочки обновлений самым надежным способом будет - следовать рекомендациям разработчика - фирмы 1С. Пример построения цепочек обновлений можно посмотреть в здесь
Но в случаях когда структура метаданных не подвергается изменениям разработчиком, то обновления можно объединить.
По поводу конфигураций. В базе данных хранятся: Конфигурация базы данных и Конфигурации поставщиков (чаще всего одна), а также не сохраненные в конфигурации базы данных изменения.
При обновлении через поддержку конфигурация поставщика обновляется при записи. Даже если при этом конфигурация базы данных не обновлена, а только сохранены изменения основной конфигурации. Если после сохранения основной конфигурации вернуться к конфигурации базы данных, то конфигурация поставщика останется обновленной.
Еще раз повторюсь. В базе хранятся: Конфигурация поставщика, Конфигурация базы данных и изменения к конфигурации базы данных. Основная конфигурация получается из конфигурации базы данных и изменений к конфигурации базы данных (если они есть, т.е. в случае когда основная конфигурация отличается от конфигурации базы данных).
Нетиповыми бывают не только УПП. При стоимости БП 10 т.р. приобрести еще автоматическое обновление за 400 т.р. :)
Для снижения трудоемкости работ при сравнении ролей можно воспользоваться отчетом «Информация по ролям»
Если добавишь будут благодарен ;)
Дело в том, что методика описанная в данной статье лишь позволяет снизить издержки на последующие обновления конфигурации. Это совершенно не означает, что не существует других способов обновления конфигураций. Другие способы есть. Их много. В конце концов вы можете разработать свою методику. :)
Честно говоря не совсем понял в чем заключается ошибка, если объект при обновлении никуда не девается???? Как состав предопределенных объектов связан с сылками на объект ПВХ?? Спасибо.
Зачем столько гемороя с 1м пунктом, если чтобы обновить конфу поставщика нужно всего лишь:
Если основная конфа полностью снята с поддержки - поставить на поддержку. Поставить на поддержку можно путем сравнения/объединения с типовым cf, и собственно сняв галку с конфигурации, т.е. по сути ничего кроме поставки на поддержку не происходит.
1. взять типовой cf
2. зайти в конфигурация-поддержка-обновление, выбрать типовой cf. Т.к. конфа поставщика отстает от основной конфы в типовом cf, то нам будет предложено обновление (обновление на типовой cf работает с любого релиза).
При обновлении, опять же, снимаем все галки и продолжаем обновление (фактически мы даем системе понять что не хотим ничего менять в основной конфе, при этом конфигурация поставщика обновляется автоматически), предварительно выбрав установку порядка объектов по новой конфигурации поставщика. Вуаля таким способом мы обновили только конфигурацию поставщика, без лишних затрат. Для полной красоты после обновления конфы поставщика можно зайти в поддержку, сравнить/объединить с конфой поставщика, опять же убрать все галки и установить порядок объектов по конфигурации поставщика.
З.Ы. автор пиши в личку, поделюсь опытом =)
З.Ы.Ы. зачем постоянно ставим "установить порядок объектов по конфигурации поставщика"? - чтобы последующие сравнения быстрее выполнялись, а в итоге не было лишнего мусора в виде измененного порядка объектов при обновлении.
Ключевой в данном случае является рабочая конфигурация, а не конфигурация поставщика.
Насчет опыта. Если переписка будет через личку, то об этом опыте никто не узнает. В данном случае важна не только статья, но и комментарии к ней, и форум. Жаль конечно, что он перестал работать.
Или это какой-то секретный опыт? Тогда конечно же в личку...
Не очень понятно. Ты хочешь убрать мусор который получился из-за накаток конфигурации вместо обновлений? Какая цель 1го пункта?
По результатам сравнения необходимо будет выполнить обновление новой рабочей конфигурации. Обновлять желательно именно ее, тогда вашу новую обновленную конфигурацию можно будет просто загрузить в рабочую базу данных. При этом обновятся и рабочая конфигурация, и конфигурация поставщика.
Так как не указано с какого релиза на какой выполняется обновление, я предположил, что между релизами не было ключевых
В некоторых случаях перенос кода (процедур) не даст нужного результата, так как могут в значительной степени измениться учетные методики. Соответственно это потребует переработки кода. Технология не исключает творчества, а лишь позволяет снизить временные затраты на рутинных операциях и избежать наиболее типовых ошибок.
Все же остался вопрос по дальнейшем обновлению.
Допустим
1. Установили клиенту типовую конфигурацию (для примера релиз 1)
2. На копии внесли изменения (добавили реквизиты существующих объектов)
3. На копии "Конфигурация" - "Сохранить конфигурацию в файл..." - получаем релиз 1 с доработками.
4. У клиента на рабочей базе "Конфигурация" - "Сравнить, объединить с конфигурацией из файла..." и подсовываем файл из п.3
Далее сам вопрос.
Вышло обновление поставщика (релиз 2)
Как лучше обновиться?
А. (У Вас это этап 3)
1. Взять чистый релиз 2 и внести в него все наши изменения, затем Конфигурация" - "Сохранить конфигурацию в файл..." - получаем релиз 2 с доработками.
2. У клиента "Конфигурация" - "Поддержка" - "Обновить конфигурацию" - "Выбор файла обновления" и подсунуть типовой релиз поставщика 2
3. У клиента на рабочей базе "Конфигурация" - "Сравнить, объединить с конфигурацией из файла..." и подсовываем файл из п.1
Смущает, не потеряются ли изменения в рабочей базе на этапе 2 этого варианта? (добавленне реквизиты типовых объектов). Или нужно снимать все флаги при выполнении пункта 2???
Б.(а можно ли так?)
1. Взять копию базы клиента
2. дальше не знаю :(
Правильно ли я понимаю, что если пропустить п.2 в варианте А, то конфигурация поставщика не обновится?
И если можно, в двух словах, в чем плюсы и подводные камни обновления через создание файлов поставки? И в каких случаях они рекомендуются?
С уважением.
А кто говорит про УПП ? И вообще про типовую конфу, способную занять сектор рынка ? Если серьезно ( в отличие от моего предыдущего сообщения), такие вещи не делают быстро и в одиночку. Но вот толково автоматизировать учет одной конкретной (непроизводственной!) фирмы за 150 часов вполне реально. Согласитесь, это несопоставимо с тратами 150 часов всего лишь на одно обновление.
(73) В статье ведь указано, что ранее при обновлении были допущены ошибки. Как результат - резкое увеличение трудоёмкости обновления. Кроме этого описанный в статье переход через большое количество релизов сопровождался исправлением ошибок, допущенных при предыдущих обновлениях, а также переписыванием некоторых измененных механизмов, связанных с обменом данными, правами пользователей и т.д. Последнее же обновление с подготовкой, тестированием и установкой с 1.2.38.1 на 1.2.39.1 заняло 3 часа. 3 часа - это много?
Но если уже есть извращенная конфигурация, кто ж тебе даст внедрять другую :o
К автору несколько замечаний:
1.
Обновление через cfu не может быть быстрее, так как сначала платформа на основании конфигурации поставщика и файла обновления создает cf
2. при выборочном обновлении модулей опасно расставлять галки, так как может сбиться порядок процедур и функций
это может быть критично, если в модуле есть директивы препроцессора
3. при обновлении обычных форм, если нужно обновить только саму форму, но оставить модуль формы неизменным, нужно быть осторожным, так как в этом случае мало предсказуемые казусы (сама форма обновляется частично). Возможно, они имеют место быть и при частичном обновлении модуля формы, но я сталкивался с таким только если снять флаги со всех процедур и функций
Я конечно понимаю что лучше один раз сделать руками самому чем языком балаболить... и возможно станет все понятно...
но на данном этапе - я запутался.. что к чему приводим, какую конфигурацию обновлять.. и как...
P.S.
Не сочтите за наглость и бахвальство, на самом деле, это пока самая полная и подробная статья по обновлению что я нашел... но и она тяжела в понимании и все потому что автор иногда пропускает важные детали где они нужны... и описывает там где и так все понятно.
[quote=alexk-is]Какой именно момент не понятен? [/quote]
Вот конкретный непонятный фрагмент:
[quote=alexk-is]Итак, по результатам первого этапа готовим две одинаковые базы. Первая (основная) - наш будущий результат. Вторая (вспомогательная) - для выполнения сравнений, открытия конфигураций и других подготовительных действий.
Используя имеющийся файл новой конфигурации, выполним обновление. Для этого выберем пункт меню «Конфигурация» → «Поддержка» → «Обновить конфигурацию», «Выбор файла обновления», «Готово» (Рисунок 10).[/quote]
Алексей, в какой базе мы выполним обновление? В какой из двух? В основной или во вспомогательной?
А ведь нужно всего лишь немного видоизменить фразу:
«Открываем вспомогательную базу и, используя имеющийся файл новой конфигурации, выполним обновление.»
Я видимо очень начинающий.. ибо перечитываю сатью уже 5-й раз... и постоянно путаюсь... что в какой конфигурации делать.. какая из них первая.. какая вторая... как-то сумбурно написано... в некоторые детали автор погружается как для полных даунов.. в плоть до кнопочки на картинке... а там где надо понять что в какой конфигурации делается... автор пробежался вскользь...
Я конечно понимаю что лучше один раз сделать руками самому чем языком балаболить... и возможно станет все понятно...
но на данном этапе - я запутался.. что к чему приводим, какую конфигурацию обновлять.. и как...
P.S.
Не сочтите за наглость и бахвальство, на самом деле, это пока самая полная и подробная статья по обновлению что я нашел... но и она тяжела в понимании и все потому что автор иногда пропускает важные детали где они нужны... и описывает там где и так все понятно.
Тут тоже подписываюсь. Очень сложно и перегружено. А описывать понятное - подробно, а темные моменты - обходить - вполне в духе 1С:)
Но в любом случае спасибо за труд! Какие-то моменты могут оказаться полезными!
Есть измененная конфигурация (слабо изменена), к примеру УТ 11.0.6.9. Штатным способом обновляю до 11.0.7.13.
В окне Сравнения И Объединения конфигураций по большому счету ничего не меняю (типовые объекты загружаются из новой конфигурации). После обновления делаю сравнение Основной конфигурации с Конфигурацией поставщика, и тут видна проблема: бОльшая часть объектов обновилась почему-то не полностью - свойство "Справочная информация" различается. Хотя эти объекты полностью брались из новой конфигурации, а следовательно и все их свойства (в т.ч. и "Справочная информация") должна была так же обновиться. В итоге обновление как бы не проходит полностью. Почему так?
Скрин (настройка обновления/объединения)
Скрин (сравнение с "Конфигурацией поставщика" или типовой конфигурацией 11.0.7.13 после обновления)
Делал Тестирование и исправление (до/после), объединял напрямую с типовой конфой 11.0.7.13, пробовал промежуточное обновление 11.0.7.8. Не помогает.
Загрузить уже готовую конфу 11.0.7.13 (с нормальной "Справочной информацией"), а уже на нее накатить свои изменения не могу, т.к. потеряются ссылки на предопределенные объекты.
Ниже же 8.2.14.540 релиза УТ 11 опускаться не рекомендует...
Попробовал так же на 8.2.13.219 - ошибка в процессе обновления, программа вылетает (очевидно, что рекомендации 1С по мин. релизу платформы определенно не лишние =) )
Лучше поздно, чем никогда.
С такой же проблемой столкнулся. Правда у меня количественно проще - справочная информация лишь по одному документу рабочей базы перестала совпадать с таковой у поставщика. Понятно, что мелочь, но глаза мозолила при обновлениях.
Решил так. Выгрузил конфигурацию поставщика в файл. Создал пустую ИБ, туда залил выгруженную конфигурацию. После из этой базы скопировал html-код справки по документу (не отформатированный текст, с ним не прокатит) в свойство "Справочная информация" документа в базе рабочей. Всё - справка одинакова что у меня, что у поставщика.
Попробовал сравнить чем же отличаются "одинаковая" справочная информация, которая при объединении не обновляется - оказывается вот в этом месте:
Т.е. по какой-то причине изменился ID конфигурации, хотя конфигурации - одинаковые
Автору ЖИРНЫЙ ПЛЮС за труды :)
тут написано: Если в рабочей базе данных заказчика во время подготовки обновления не проводились работы по изменению конфигурации, а обновление готовилось на актуальной копии рабочей базы данных, то для переноса настроек сохраним рабочую конфигурацию в файл, например work_2.cf, выбрав пункт меню «Конфигурация» → «Сохранить конфигурацию в файл…».
че та это у меня не получаеться, может еще что надо до деловать или я туплю
создать резервную копию базы данных;
используя файл work_2.cf, переносим изменения. Для этого выберем пункт меню «Конфигурация» → «Загрузить конфигурацию из файла…»;
на вопрос об обновлении конфигурации базы данных ответим согласием.
Потом запуск 1С:Предприятия с полными правами и выполнение регламента при переходе на новую версию. Всё...
Имеется в виду описанный здесь длинный и сложный способ?
В какой базе мы всё-таки выполняем это действие? В основной или вспомогательной?
Ты написал [quote]Для этого в основной базе выберем пункт...[/quote]
Вроде бы понятно, ты говоришь об основной базе. Но затем (после рисунка 13) ты пишешь противоположное:
[quote]На этом работу во второй (вспомогательной) базе приостанавливаем и продолжаем в основной.
[/quote]
В какой же базе выполнять этот пункт???
а как быть с фразой:
[quote]На этом работу во второй (вспомогательной) базе приостанавливаем и продолжаем в основной. Кнопку «Выполнить» во вспомогательной базе не надо нажимать. Нам эта база нужна именно в таком виде до окончания процесса обновления.[/quote]
???
Ведь можно написать конкретно по шагам:
Создаём вспомогательную базу. Для этого копируем папку основной базы, прописываем её в окне запуска 1С с именем "Вспомогательная"
2. Открываем основную базу, идём в меню «Конфигурация» → «Поддержка» → «Обновить конфигурацию», «Выбор файла обновления», «Готово».
3. Открываем вспомогательную базу, и выполняем ту же самую последовательность действий.
4. Теперь у нас открыты два окна конфигуратора.
5. В окне "Основной" базы делаем следующее...
... и т.д.
Пытаюсь сейчас применить на практике.
Кстати, вот ещё вопрос, его бы тоже неплохо коснуться хотя бы мимоходом.
Обновляю БП, в плане счетов добавлены предопределённые счета, и в новой конфигурации поставщика тоже есть новые предопределённые счета.
Как правильно действовать в данной ситуации? В какой момент вносить новые счета в ПС ?
1) Не убирать галочку при загрузке обновления (т.е обновить ПС на типовой и стереть старые настройки), а потом добавить настройки руками?
2) При загрузке обновления убрать галочку (т.е. не обновлять ПС), потом вручную добавить новые типовые счета?
После обновления зашёл в режиме Предприятия, и был неприятно удивлён.
Счета, которые были в старой конфиге добавлены вручную, после обновления пометились на удаление (и с них снялся признак предопределённых).
И добавились такие же новые предопределённые счета (с теми же кодами и наименованиями).
Наверно, нужно было делать по второму варианту?
Как пожелание: добавить в статью информацию по обновлению по разделам: справочники, документы, интерфейсы, регистры, планы счетов и т.д. и т.п. с указанием узких мест и способами благополучного обхода.
Статья дает хороший толчек и в дальнейшем может служить как справочное руководство к действию.
По крайней мере с моеим первым обновлением нетипичной конфигурации, да и еще с моим вообще первым обновлением, получилось справиться.
Спасибо!
Сам делал обновление без дополнительных сравнений. Всегда имел проблемы с обновлением форм и ролей. Теперь знаю способ увидеть "детальки".
Ну и всегда интересно как другие делают. Подглядел некоторые возможности и настройки.
Из-за того, что я не могу понять, что именно происходит на этом этапе, я не могу понять и вторую часть цитаты - какие ошибки, откуда они, почему не вскрываются.
на этом этапе мы стираем все внесенные изменения?
Получил рабочую конфигурацию.
Далее через «Конфигурация» → «Поддержка» → «Обновить конфигурацию» используя файлы *.cfu. выполнил обновление и сразу вышло окно "Обновление основная конфигурация - Навая конфигурация поставщика"
Устанавливаю фильтр «Показывать только дважды измененные свойства»
Что если при сравнении модулей сделать "Объединить с приоритетом основной конфигурации" ?
Какие при этом могут быть последствия и что я делать не правильно ?
И что делать в таких ситуациях:
Спасибо за помощь !
может наоборот? с 1.2.14.1 на 1.2.6.2?
Однако жизнь не без приключений. Обновляла с 1.3.26.1 на 1.3.28.1. Вроде все обновилось нормально, база работоспособная. Стала обновляться на 1.3.29.1. получила ошибку "Нарушена целостность структуры конфигурации". В результате поиска получила такую вот веселую картинку
Для начала необходимо определиться, какая у вас всё-таки конфигурация: 26 или 28? Затем нужно снять конфигурацию с поддержки, а потом объединить с конфигурацией поставщика соответствующей версии (26 или 28). Будет вопрос о постановке на поддержку, согласитесь. После выдачи окна об измененных объектах, снимайте все галочки и жмите "Выполнить".
Скорее всего конфигурация починится, но не факт. Возможно, что проблема в платформе 1С ...или в видео-драйвере, а дальше переходим к шаманским танцам...
Я, собственно говоря примерно представляю, что делать и с какими бубнами плясать, этим и занимаюсь. Просто скинула интересную картинку - если вы ее правильно разглядели, то там показывает в одном месте версию конфигурации поставщика 28, а в другом 26 этой же конфигурации поставщика :) И при попытке обновить она распознавалась сначала как 28 и, соотв, в окне возможных обновлений показывалась следующая - 29, но далее выкидывалась ошибка. Как так получилось - не могу сказать :)
Как закончу шаманить - расскажу, что помогло. Думаю, что кто-то еще столкнется с такой проблемой.
1. Нужна была cf 28 релиза. Поскольку у меня нет привычки хранить cf-ки, пришлось получить ее последовательным обновлением с 1.3... бог знает какого релиза.
2. Из рабочей базы (в которой оказалась битая конфигурация поставщика) выгрузила в файл конфигурацию БД, также имеющую 28 релиз. Почему не основную? Так повелел шаман Мбонго.
3. Далее типовую 28 методом "сравнить, объединить" объединила с с конфигурацией, полученной в п.3. Таким образом, полученная база содержит конфигурацию поставщика 28 типовую, конфигурацию основную и конфигурацию БД - 28 с изменениями. Для проверки получаем картинку как в (187). Ура, номера релизов конфигурации поставщику не глючат.
4. Сохраняем полученную конфигурацию в файл, загружаем конфигурацию в рабочую базу (не забыв сделать копию).
Танец помог, конфигурация живая, обновление на 29 пошло без ошибки.
З.Ы. Ради интереса расскажу и другой танец, который оказался неудачным. Сначала хотела полученную типовую 28 cf принудительно подсунуть в качестве файла обновления. Не получилось :)
Нашел статью из-за рассинхронизации версий конфигураций. Создал пустышку, залил старый .cf поставщика.
Последовательно обновил до текущей версии основной конфигурации. При попытке обновить через поддержку по статье (где "указать файл") выпало сообщение, что обновлений нету.
Снял основную с поддержки. Попытался выполнить объединение с помощью Сравнить-Объединить.
В итоге Конфигуратор предложил поставить на поддержку - согласился.
Начинается сравнение, я так понимаю - конфигурации поставщика и БД и критическая ошибка.
Вариантов 2: Завершить и Перезагрузить.
chdbfl пишет, что все ОК. Причем ошибка на Регламентированном отчете.
И в сети многие пишут про такую ситуацию. Пока что предложения, выложенные на форумах не помогают.
Когда решу вопрос - отпишу о результате :)).
Вот уже часа 3 идет реструктуризация регистра бух. База файловая 4 гига. Спасибо за инструкцию.
Посмотрим, останутся ли в программе отчеты, которые создавались бухами и которые я удалил/перезалил.
У меня только один вопрос.
Для чего дублировать состояние по галочкам во вспомогательной базе, если там мы не нажимаем кнопку "Выполнить"?
(196) bessectrisa, для того чтобы знать, с какими объектами конфигурации ещё предстоит разобраться, а на какие уже не стоит обращать внимания. Ведь после нажатия кнопки "Выполнить" любое сравнение конфигураций в основной базе не даст нам первоначальной оценки, т.к. конфигурация поставщика уже обновиться и трехстороннее сравнение конфигураций в основной базе уже не получить. Трехстороннее сравнение конфигураций остается во вспомогательной базе и с ним продолжаем работать. Для этого и нужна вспомогательная база - для сохранения результатов трехстороннего анализа.
(200) Например - мой пример.
Версия КП установлена в новую, а обновление выполнено неполностью, т.е. некоторые галочки сняты исскуственно. Или как сделал я недавно - скачал последнее обновление, запустил его, снял все галочки и заменил только пару новых регл. отчетов, которые были "ну очень срочно нужны". Осталось дошаманить когда появится время.
Но я "споткнулась" на 1-м этапе, где описывается ситуация «Обнаружены ссылки на объекты, помеченные на удаление».
У меня обнаружились ссылки на типовой общий модуль из добавленного интерфейса. Вижу это, если делаю поиск ссылок на объект или поиск ссылок в объекте:
Объект "ОбщийМодуль.УниверсальныеМеханизмы" использован в:
Интерфейс.ПлановыйОтдел.Интерфейс
Объект "Интерфейс.ПлановыйОтдел" ссылается на:
ОбщийМодуль.УниверсальныеМеханизмы
А вот найти эту ссылку в интерфейсе и затем удалить не могу. Прошлась по всем пунктам интерфейса, но нигде не обнаружила ОбщийМодуль. Подскажите, как поступить?
Сделала, как Вы посоветовали. Вернее, начала делать.
Подобных ссылок у меня очень много. Причем версии конфигурации поставщика и рабочей конфигурации совпадают.
А ошибка:"Неразрешимые ссылки. Обнаружены ссылки на следующие объекты, помеченные на удаление" возникает при обновлении Бухгалтерии 2.0 на Бухгалтерию 3.0.
Почерпнул массу полезных мыслей :).
Как правело при обновлении вначале анализировал, что важнее и быстрее - обновить всю коныигурацию ,
или только в рабосей подправить ошибки, исправленные 1С.
А вот когда накапльвается серия ключевых релизов... Да и еще с запреьом редактирования даных предыдущего
периода. Как произошло с украинскими конфигурациями , после введения нового налогового кодекса.
Вот тогда и начинается не просто песня , целый концерт...
после обновления и внесения своих изменений - сравниваю осн конфигурацию и конфигурацию поставщика(=типовой обновленной).
Для некоторых документов выдает различия:
Характеристики
ВидыХарактеристик = СвойстваОбъектов, ПолеОтбораВидов = Назначение свойства, ЗначениеОтбораВидов = , ПолеКлюча = Ссылка, ЗначенияХарактеристик = СвойстваОбъектов, ПолеОбъекта = Объект, ПолеВида = Дополнительный реквизит, ПолеЗначения = Значение
Что это значит? и где/что нужно подправить?
Спасибо!
Вопрос1, если можно. Как сделать всё тоже самое, но удалённо. Задача:есть актуальная копия базы клиента, которую надо обслужить удалённо... Делаем всё как описано в статье и имеем .cf файл. Гнать его по сети - издеваться над клиентом. Очевидно, необходимо как-то получить файл .cfu и использовать его. Как сделать это правильно.
Вопрос2... 3-ий этап:после всех проведённых работ цитирую "...сохраним рабочую конфигурацию в файл, например work_2.cf, выбрав пункт меню «Конфигурация» - «Сохранить конфигурацию в файл…» и далее "используя файл work_2.cf, переносим изменения. Для этого выберем пункт меню «Конфигурация» → «Загрузить конфигурацию из файла…» Разве таким образом не переносятся изменения только в рабочую конфигурацию. Конфигурация поставщика при этом обновляется?! Заранее прошу прощение за вопрос - наверное я всё-таки что-то не понял...
1) .cfu можно получить используя для создания поставки файл .cf рабочей базы, сохраненный до начала обновления (work.cf)
2) В этом вся фишка. Обновятся обе конфигурации и рабочая, и поставщика. Т.к. при сохранении они обе выгрузятся в work_2.cf.
кажется у меня не получалось на основе файла work_2.cf получить .cfu - платформа вроде требовала пред. файл поставки... Такое ощущение, что файл поставки .cf и файл, полученный способом "«Конфигурация» - «Сохранить конфигурацию в файл…»" это принципиально разные файлы, хотя и с одним расширением. Может я не внимательно что-то сделал - буду ещё пробовать...
...И ещё немного переформулирую задачу,для уточнения.. Базу клиента необходимо обновлять удалённо регулярно, т.е. с выходом новых версий поставщика. При этом, необходимо сохранить/внести изменения от нас ну опять те же условия - гонять .cf по сети никак нельзя.
Вопрос1:Будет ли при этом конфигурация, которую я использую на своём рабочем месте оставаться актуальной?
Вопрос2:В зависимости от ответа на 1-й вопрос - наши дальнейшие действия...
Можно сэкономить на .cfu файле, но при этом все объекты встанут на поддержку, т.к. в .cfu будут все изменения, общие, а не отдельно для рабочей конфигурации и отдельно для конфигурации поставщика. Обновлены будут также обе конфигурации. Т.е. уже не будет различия между конфигурацией поставщика и рабочей конфигурацией.
Можно наверное что-нибудь покрутить передавая 2 .cfu файла, свой и поставщика, но это несколько усложнит технологию. Например, так:
1. Базу клиента обновляем с помощью нашего файла .cfu, конфигурацию базы не обновляем
2. Снимаем конфигурацию с поддержки и сохраняем в файл .cf
3. Возвращаемся к конфигурации базы данных
4. Обновляем с помощью .cfu файла поставщика, конфигурацию базы не обновляем
5. Делаем сравнение объединение с ранее сохраненным файлом .cf
6. Обновляем конфигурацию базы данных
Предполагаю, что при этом "конфигурация, которую я использую на своём рабочем месте" уже не будет оставаться актуальной и нужно будет получить копию получившейся конфигурации из базы клиента.
Что может быть проще? Заложить в конфигурации все будущие изменения законодательства и все хотелки юзверей, плюс все возможные изменения прогреров, положить в коробку и пусть все пользуются ))))))))))))))))))))))))))))))))))))))
Вебинар, на котором на примерах разобрано, как с использованием внешних программ существенно, на порядок, повысить производительность выполнения обновления конфигураций 1С: Предприятие 8 на платформе 8.3.6.
конфигурация базы данных – это конфигурация, с которой работают пользователи;
рабочая конфигурация (основная) – это конфигурация, в которую мы можем вносить изменения, при этом пользователи могут продолжать работать;
конфигурация поставщика – это исходная конфигурация поставщика, на основе которой обычно создаются рабочая конфигурация и конфигурация базы данных. В базе данных может быть несколько конфигураций от различных поставщиков. Поставщиком конфигурации может быть не только фирма «1С».
- Это как азбука или таблица Д. Менделеева. Но есть еще конфигурация. Она живет до сохранения в оперативной памяти. И ещё возможны N количество расширений конфигурации :)
используя файл work_2.cf, переносим изменения. Для этого выберем пункт меню «Конфигурация» U94; «Загрузить конфигурацию из файла…»;
Или я чего-то не догоняю, но не работает данный пункт.
Ошибка: "Для выполнения операции требуется разблокировать все объекты"
Если конфигурация находится на поддержке с возможностью изменения, а это именно тот вариант обновления рассматриваемый в статье, в конфигурации обязательно существуют объекты находящиеся на "замочках".
Кстати, в продвинутом курсе Гилев Е. в этом месте говорит о необходимости выбора пункта "Сравнить объединить с конфигурацией из файла"
Вы предлагаете сначала выполнить обновление конфигурации с помощью типового cf, а затем поверх этого обновления выполнить сравнение / объединение с подготовленным для обновления файлом cf.
Почему нельзя просто выполнить загрузку этого подготовленного cf?
Ведь он уже будет содержать в себе актуальную конфигурацию поставщика и все наши доработки.
То есть этап "Сдача работ" мне представляется так:
1) выгружаем подготовленный для обновления cf из тестовой базы;
2) загружаем его в рабочую (при этом выполнив все необходимые обряды вроде создания резервных копий и завершения сеансов пользователей).
Есть возражения?
Прошу прощения, но я не знаю куда мне написать. Столкнулся с проблемой при обновлении конфигурации. Дело в том, что при обновлении в графе Поставщик разные поставщики.
Вопрос, можно ли обновляться в данном случае? Не будет ли работать база неправильно?
Спасибо большое!
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 18562
Создание 15.12.08 10:01
Обновление 16.09.14 05:07
Просмотры 507015
Загрузки 0
Рейтинг
1024
Комментарии 249
Код открыт Не указано
Рубрики Инструменты администратора БД
Кому
Системный администратор
,
Разработчик
Тип файла Нет файла
Платформа 1С:Предприятие 8
Конфигурация 1C:Бухгалтерия
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
