1с как получить типовую конфигурацию
Иногда случается так, что в вашей базе есть какие-то доработки (исключения составляют внешние отчеты и внешние печатные формы), и вы по каким-либо причинам хотите из вашей нетиповой базы сделать типовую (поставить базу на поддержку в 1с). Для чего такое может понадобиться? Рассмотрим банальный пример, клиент хочет обновляться в автоматическом режиме, но это можно делать только в типовой базе. Поскольку доработки в базе клиента были очень маленькие и несущественные, то клиент решил от них отказаться и сделать из своей базы типовую конфигурацию, ведь тогда можно будет обновляться в автоматическом режиме, а это в первую очередь экономия собственных денег, так как клиенту больше не нужно будет платить за услуги программиста 1с.
Теперь давайте разберемся, какие действия нам нужно будет выполнить, если мы захотели сделать базу типовой (поставить базу на поддержку в 1с).
Для начала заходим в конфигуратор, и смотрим текущую версию нашей базы, Конфигуратор ---> Справка ---> О программе
После этого Вы должны увидеть окно примерно следующего вида
Вы видите название и версию конфигурации, они выделены красным.
Чтобы поставить базу на поддержку 1с и сделать типовой нам необходима типовая конфигурация такой же версии. Создадим новую базу и загрузим туда типовую базу, или установим соответствующий релиз 1с. После того как мы установили типовую базу, нам необходимо будет открыть конфигуратор этой базы. Если зайдя в конфигуратор сама конфигурация не открыта, то откроем ее соответствующей кнопкой.
После нажатия данной кнопки откроется дерево объектов конфигурации, выглядит это примерно так
Теперь нам нужно сохранить конфигурацию в файл, для этого выполним следующие действия.
Щелкаем по вкладке конфигурация ---> сохранить конфигурацию в файл. Откроется окно в котором необходимо выбрать имя файла и путь где этот файл будет находиться. Нажимаем сохранить, в левом нижнем углу вы увидите процент выполнения сохранения конфигурации в файл.
Теперь когда файл сохранился, у нас есть файл с типовой конфигурацией. Далее мы должны открыть конфигуратор той базы, у которой мы хотим обновить конфигурацию поставщика, и загрузить туда наш *.cf файл (наша типовая конфигурация).
Для этого заходим Конфигуратор ---> Конфигурация ---> Загрузить конфигурацию из файла. После этих действий откроется диалоговое окно в котором нужно выбрать наш *.cf файл и нажать кнопку открыть. Теперь мы можем наблюдать процент загрузки нашей конфигурации, когда конфигурация загрузится не забываем обновить конфигурацию нашей базы данных, для этого нужно нажать клавишу F7 или нажать на синенький бочонок на панели конфигуратора.
ВЫПОЛНИТЕ ОБЯЗАТЕЛЬНО ЭТИ ДЕЙСТВИЯ:
- Перед любыми работами делайте архивную копию Вашей базы данных (Конфигуратор ---> Администрирование ---> Выгрузить информационную базу).
- Номера конфигураций (Вашей и типовой) должны быть ОДИНАКОВЫМИ! Посмотреть название и номер конфигурации (Конфигуратор ---> Справка ---> О программе)
ПОМНИТЕ ОБ ЭТОМ:
Все доработки в вашей базе будут удалены автоматически после того как вы сделаете базу типовой!
Как понять типовая база перед нами или нет?
Кто-то возможно скажет что в конфигураторе есть замочек, и если он включен то база типовая, это ошибочное мнение! Да, изначально на всех типовых базах стоит защита от внесения изменений в конфигурацию (видим замочек в дереве объектов, в конфигураторе), но после того как мы включили возможность изменения (сняли замочек) и допустим внесли какие-то изменения в конфигурацию, то конфигурация автоматически становится НЕТИПОВОЙ, потом мы можем опять закрыть конфигурацию от редактирования (поставить замочек), но это не будет означать что база ТИПОВАЯ.
Для того чтобы точно понять типовая база или нет перед нами, выполним следующие действия:
Теперь выберем в меню Конфигурация ---> Сравнить конфигурации, если база типовая то мы увидим следующий список сравнения баз.
А если база нетиповая к этому списку добавляется возможность сравнения с конфигурацией поставщика.
При возникновении потребности создания тиражируемого прикладного решения на платформе 1С столкнулся с трудностями создания поставки конфигурации и настройки для последующего использования. Чтение тематического материала на ИТС, текущем или иных ресурсах не дало цельного представления работы механизма, в связи с чем было принято решение опубликовать статью на эту тему.
Аналогичные публикации
Оглавл ение
Описание окружения
Все дальнейшие действия будут выполнены на версии платформы 8.3.10.2466. Для демонстрации работы потребуется 2 информационные базы: одна для создания поставки, вторая для создания и обновления базы из файлов поставки.
Создадим каталог в файловой системе "Демонстрационная поставка" со следующими подкаталогами "Distribute" и "Versions".
Создание первой поставки
Откроем конфигуратор базы для создания поставки, это может быть абсолютно любая конфигурация, будь то снятая с поддержки типовая конфигурация или написанная с нуля. В данном примере будет создана новая пустая база, в конфигурации которой будут произведены следующие изменения в свойствах конфигурации:
- Имя: ОтраслевоеРешение
- Синоним: Отраслевое решение
- Поставщик: Моя компания
- Версия: 1.0.0.1
Настройки поставки (Конфигурация - Поставка конфигурации - Настройка поставки) оставим без изменений, так как на дальнейшие действия это не повлияет.
Перейдем к созданию файлов поставки
- Конфигурация - Поставка конфигурации - Создать файлы поставки и обновления конфигурации.
- Выберем наш ранее созданный каталог Versions через кнопку Каталог файлов поставки.
- Снимем флажок Создать файл обновления конфигурации.
- После нажатия кнопки Выполнить в указанном каталоге будет создан файл 1Cv8.cf
Файлы поставки созданы, перейдем к созданию комплекта поставки
- Комплект поставки (Конфигурация - Поставка конфигурации - Комплект поставки)
- Выберем Создать новое описание комплекта поставки
- Наименование и поставщика оставим без изменений
- Укажем путь: MyCompany\IndustrySolution\1_0_0_1. По этому пути будет установлен шаблон
- Оставим флажки Текущая конфигурация и Текущая информационная база без изменений
- После нажатия кнопки Готово откроется форма комплекта поставки
- Позиционируемся на файле конфигурации и изменяем значение свойства наименование в шаблоне: Моя компания\Отраслевое решение. Это своего рода каталог в списке шаблонов
- Позиционируемся на файле выгрузки информационной базы и изменяем значение свойства наименование в шаблоне: Моя компания\Отраслевое решение (демо)
- Создадим каталог 1.0.0.1 в ранее созданном каталоге Distribute
- Создадим комплект, откажемся от сохранения описание комплекта поставки, выберем созданный на прошлом шаге каталог 1.0.0.1
В указанном каталоге будут созданы установочные файлы комплекта, которые можно упаковать в SFX архив для отправки.
В форме комплекта поставки присутствует две кнопки:
- Создать файлы комплекта - в выбранном каталоге создаст файлы комплекта согласно указанному пути (MyCompany\IndustrySolution\1_0_0_1).
- Создать комплект - в выбранном каталоге создаст установочные файлы комплекта, после установки которого мы получим файлы комплекта.
Создание базы из шаблона
Установим ранее созданный комплект поставки, после установки в каталоге шаблонов пользователя будет создан каталог "MyCompany\IndustrySolution\1_0_0_1" с файлами комплекта.
Добавим новую базу из установленного шаблона, после зайдем в конфигуратор и убедимся в установленной поддержке конфигурации без возможности редактирования.
Создание файла обновления
Перед созданием первого файла обновления представим месяцы анализа, разработки и тестирования функционала нашего отраслевого решения.
Откроем конфигуратор первой базы из которой создавали первую поставку и изменим свойство версия на 1.0.0.2. Сохраним конфигурацию базы данных и приступим к созданию файла обновления.
- Создадим файлы поставки (Конфигурация - Поставка конфигурации - Создать файлы поставки и обновления конфигурации)
- Выберем наш ранее созданный каталог Versions через кнопку "Каталог файлов поставки"
- Используя кнопку Добавить из предыдущих версий добавим версию 1.0.0.1 - именно из этой версии конфигурации мы сможем выполнить обновление на текущую 1.0.0.2
- Нажмем кнопку Выполнить и убедимся в наличии созданных файлов в каталоге "Versions\1.0.0.2"
Файлы поставки созданы, перейдем к созданию комплекта поставки (Конфигурация - Поставка конфигурации - Комплект поставки)
- Выберем Создать новое описание комплекта поставки
- Наименование и поставщика оставим без изменений
- Укажем путь: MyCompany\IndustrySolution\1_0_0_2
- Оставим флажки Текущая конфигурация и Текущая информационная база без изменений
- После нажатия кнопки Готово откроется форма комплекта поставки
- Позиционируемся на файле конфигурации и изменяем значение свойства наименование в шаблоне: Моя компания\Отраслевое решение
- Позиционируемся на файле выгрузки информационной базы и изменяем значение свойства наименование в шаблоне: Моя компания\Отраслевое решение (демо)
- Добавляем в текущий шаблон конфигурации отдельный файл, указываем ранее созданный файл обновления .cfu
- Добавляем вариант поставки "Обновление", у добавленного варианта поставки указываем поставляемые файлы: файл обновления 1Cv8.cfu
- Создадим каталог "1.0.0.2" в каталоге "Distribute"
- Создадим комплект, откажемся от сохранения описания комплекта поставки, выберем вариант поставки "Обновление", выберем созданный на прошлом шаге каталог "1.0.0.2"
Обновление конфигурации
- Установим созданный комплект поставки (1.0.0.2)
- Откроем конфигуратор базы, которую создавали за первого шаблона
- Выполним обновление Конфигурация - Поддержка - Обновить конфигурацию
Если снять флажок Показывать конфигурации, то отобразится только шаблон обновления
Настройка для обновления через FTP
Описывать этап настройки FTP сервера в рамках данной статьи не буду, для демонстрации настроил FTP на локальной машине по следующему каталогу "D:\FTP".
- Перед помещением шаблонов необходимо создать файл описания этих шаблонов. В конфигураторе переходим Конфигурация - Поддержка - Шаблоны конфигураций и обновлений
- Для выбранного каталога шаблонов создадим файл описания по кнопке Создать файл списка шаблонов. В выбранном каталоге будет создан файл v8cscdsc.lst
- Копируем содержимое папки шаблонов "tmplts" в каталог шаблонов на FTP.
На этом настройка завершена, запускаем процесс обновления конфигурации на поддержке.
Для примера была установлена новая база из созданного нами шаблона, на этапе обновления указываем путь к каталогу FTP
Если настройка FTP сервера дает право чтения анонимным пользователям, то мы увидим окно со списком шаблонов конфигурации, в противном случае потребуется ввести логин и пароль от FTP сервера.
Конфигурация поставщика не соответствует конфигурации БД. Пример, когда наименование конфигурации поставщика идентично типовой, но состав отличается. Как установить корректную конфигурацию поставщика?
В моем случае «Управление торговлей», редакция 10.3 дополнена отраслевым решением «БИТ: Управление автосервисом 8». Компании, использующие отраслевые решения, как правило, дорабатывают конфигурацию под свои нужды и не обновляют их на новые релизы от поставщика. Следовательно, осталась «Управление торговлей», релиз 10.3.13.2. Плюс конфигурация поставщика хоть и называется «Управление торговлей», тем не менее, объекты, относящиеся к конфигурации «БИТ: Управление автосервисом 8», так же находятся на поддержке (рис. 1). Это случай, когда релизы конфигурации поставщика и конфигурация базы данных (далее БД) формально совпадают, а фактически конфигурация поставщика – не «Управление торговлей», редакция 10.3.
Рис. 1. Пример конфигурации поставщика, содержащей объекты, которые не должны быть на поддержке
Следовательно, при обновлении на следующий релиз «Управление торговлей» механизм обновления предложит удалить все объекты, которые относились с отраслевому решению (рис. 2).
Рис. 2. Обновление конфигурации на новый релиз
Таким образом, возникает задача востановления поставщика конфигурации. Также данная задача может возникнуть, если обновление БД проводилось через «Сравнение, объединение» с новым файлом конфигурации.
Задача решается в два этапа. Для этого понадобится cf-файл конфигурации, который соответствует релизу БД. Релиз БД можно посмотреть в «Справка» − «О программе» (рис. 3).
Рис. 3. Информация о релизе «Управление торговлей» в «Справка» - «О программе»
Внимание! Перед проделыванием следующих операций сделайте резевную копию БД.
Обратите внимание, что пиктограмма с изображением желтого кубика в дереве конфигурации больше не отображается.
Рис. 4. Снятие с поддержки конфигурации
2) Нажимаем «Конфигурация» − «Сравнить, объединить с конфигурацией из файла». Появится окно с предложением поставить конфигурацию на поддержку. Отвечаем «Да» (рис. 5).
Рис. 5. Постановка конфигурации БД на поддержку с данной конфигурацией поставщика
Теперь, чтобы не потерять изменения типовых объектов в конфигурации, снимаем галочку с корневого узла и нажимаем «Выполнить». В настройках правил поддержки отвечаем «ОК» (рис. 6).
Рис. 6. Постановка на поддержку
Теперь конфигурация поставщика соответствует конфигурации БД. Однако есть небольшое техническое замечание − объекты, у которых были изменения, не находятся на поддержке (рис. 7). При обновлении такие объекты меняться не будут. Так что, нужно поставить их на поддержку с возможностью редактирования.
Рис. 7. Объекты, имеющиеся в конфигурации поставщика, но не стоящие на поддержке в БД
3) Нажимаем «Конфигурация» − «Поддержка» − «Настройки поддержки». В появившемся окне нажимаем «Сравнить, объединить». В окне сравнения, объединения снимаем все галочки, выделяем объект, который ставим на поддержку, и нажимаем «Изменить». В появившиеся окне выбираем «Объект поставщика редактируется с сохранением поддержки», нажимаем «ОК» и «Выполнить» (рис. 8). Галочка «Устанавливать для подчиненных объектов» полезна в том случае, если проводимое изменение справедливо для всех подчиненных объектов. Платформа «1С:Предприятие 8» не позволит провести изменения, если, например, в подчиненных объектах добавлены реквизиты, и вы поставите их на поддержку.
В этой статье будет рассказано про обновление нетиповой конфигурации 1С (редакций 8.2 и 8.3), с сохранением всех изменений внесенных вами (или другими разработчиками) в типовую конфигурацию 1С 8.
Обновление нетиповой конфигурации 1С пошаговая инструкция
Рассмотрим по шагам алгоритм обновления конфигурации 1С 8. Данный алгоритм является универсальным, первые одиннадцать его шагов описывают процесс обновления любой типовой конфигурации 1С 8, а все пункты в совокупности описывают обновление нетиповой конфигурации 1С 8:
Обновление нетиповой конфигурации 1С разбор примера
Перейдем к подробному разбору правильного обновления нетиповой конфигурации 1С 8. Вся проблема обновления такой конфигурации заключается в том, что в типовые объекты метаданных (общие модули, роли, документы, справочники и т.д.) внесены сторонние изменения. Надо сделать так, что бы все ваши изменения остались на своем месте, в целости и сохранности, но при этом все изменения фирмы 1С, содержащиеся в файле обновления, тоже были применены. Именно для этого при обновлении измененной конфигурации появляется окно сравнения Основной конфигурации (с вашими изменениями) и Новой конфигурации поставщика (обновленная типовая конфигурация).
В данном окне присутствует две колонки, каждая из которых содержит дерево метаданных. В первой показаны метаданные текущей конфигурации базы данных, а во второй обновленные метаданные конфигурации поставщика (обновленная типовая конфигурация). Зелеными карандашиками отмечены измененные объекты, в первом столбце помечены измененные вами типовые объекты метаданных, а во втором измененные обновлением типовые объекты метаданных. Таким образом, чтобы произвести правильное обновление нетиповой конфигурации 1с, нужно найти все объекты метаданных, которые изменены и вами и обновлением (то есть дважды измененные).
Для это нажмите расположенную внизу окна кнопку Фильтр, в открывшемся окне установить флаг Показывать только дважды измененные свойства и нажмите ОК.
Теперь в окне сравнения будут видны только нужные нам объекты, что значительно облегчает процесс обновления. Следует заметить, что если в вашей конфигурации добавлены новые нетиповые документы, справочники, роли, модули и т. п., то их обновление конфигурации не затрет, они останутся на своем месте и ничего с ними не случиться. Проблему составляют только измененные типовые объекты.
Для правильного обновления разных объектов метаданных нужен свой подход, поэтому рассмотрим на несложных примерах различные ситуации. Замечу также, что обновление сильно переписанных конфигураций задача сложная и требует максимальной внимательности и сосредоточения.
Обновление общего модуля.
- Рассмотрим пример: В общий модуль КонтрольВерсииКонфигураци вы внесли следующие изменения:
- В процедуре ПроверитьВерсиюКонфигурации() закомментировали строку:
- Добавили в модуль свою процедуру с именем МояТестоваяПроцедура().
При обновлении этот модуль изменился, поставив в окне сравнения фильтр по дважды измененным мы увидим, что он попал в список.
Рассмотрим подробнее данное окно, и поймем какую информацию из него мы сможем почерпнуть. Во-первых, мы видим, что общий модуль изменен и в основной конфигурации и в обновленной конфигурации поставщика, об этом говорят зеленые карандашики в обоих столбцах. Во-вторых, в первом столбце мы видим установленный флажок возле имени общего модуля, он говорит о том, что будет произведено объединение модулей (того, что изменен нами и типового обновленного). В-третьих, в последнем столбце мы видим в каком режиме произойдет объединение модулей. В данном случае установлено значение: Взять из новой конфигурации поставщика, это означает, что наши изменения будут полностью затерты, а изменения внесенные обновлением будут полностью применены.Другие режимы объединения предлагают частичное объединение модулей, с различными приоритетами. Но я вам настоятельно рекомендую не использовать эти режимы, так как после этого в вашем модуле может получиться натуральная «каша»: некоторые ваши изменения будут затерты, а некоторые типовые изменения не применятся. Поэтому изменять значения в столбце Режим объединения… мы никогда не будем. В-четвертых, если снять галку установленную в первом столбце напротив модуля, то объединение производиться не будет и модуль останется в том виде в котором он был до обновления.Исходя из перечисленных пунктов есть два способа обновить общий модуль:
- Затереть ваши изменения установив типовые. После чего вручную внести затертые изменения в обновленный модуль;
- Не обновлять модуль и внести типовые изменения вручную.
Механизмы сравнения конфигураций
Для сравнения изменений в модуле можно воспользоваться следующими встроенными механизмами окна сравнения-объединения конфигураций:
- Просмотр различий в модулях. Для этого в окне сравнения щелкните на модуле правой кнопкой мыши выберите пункт Показать различия в модулях… После чего откроется окно сравнения модулей, в котором можно увидеть, какие именно процедуры в обновленном и измененном вами модуле различаются. Верхняя часть экрана разделена на две колонки: в левой представлен список процедур основной конфигурации, которые были изменены, а в правой аналогичный список процедур обновленной типовой конфигурации. Нижняя часть окна также разделена на две части, по тому же принципу. В ней отображается код выделенных процедур. Строки, которые присутствуют только в основной конфигурации выделены синим цветом. Строки, которые присутствуют только в обновленной типовой конфигурации выделены зеленым цветом. Строки, которые присутствуют в обоих конфигурациях, но не совпадают между собой, выделены красным цветом.
- Отчет о сравнении объектов. Для сравнения модулей также можно использовать отчет о сравнении объектов. Чтобы вызвать его в окне сравнения щелкните на модуле правой кнопкой мыши выберите пункт Отчет о сравнении объектов. В открывшемся окне, в области Формат, установите флаг Подробно. В открывшемся отчете можно увидеть, какие строки модуля изменены и как они выглядят в обоих конфигурациях.
Не смотря на то, что данный отчет предоставляет всю информацию о изменениях, он не удобен в работе (по крайней мере при обновлении модулей). Гораздо более интересны две его модификации: Отчет о сравнении объектов основной конфигурации со старой конфигурацией поставщика (в этом отчете видны только изменения внесенные вами) и Отчет о сравнении объектов новой конфигурации поставщика со старой конфигурацией поставщика (в этом отчете видны только только изменения внесенные в модуль обновлением).
При помощи первого отчета можно увидеть во скольких местах внесены ваши изменения в модуле, это позволит быстро найти их в окне Просмотра различий в модулях. Во втором же отчете можно увидеть во скольких местах типовое обновление внесло свои изменения.
Мы разобрали все инструменты необходимые для обновления модуля. Для того, что бы показать их практическое применение рассмотрим по шагам процесс обновления модуля КонтрольВерсииКонфигураци с перечисленными выше изменениями. Обновим модуль двумя способами:
- Обновим модуль, затерев внесенные в него изменения. Внесем их вручную после обновления;
- Не будем обновлять модуль. Изменения полученные в обновлении внесем после.
- Второй способ полностью повторяет первый, за исключением того, что действует он от обратного. Поэтому опишу его кратко;
- Создаем текстовый документ с такой же структурой;
- Сформируем отчет Отчет о сравнении объектов новой конфигурации поставщика со старой конфигурацией поставщика;
- Используя сформированный отчет и окно сравнения модулей выпишем в текстовый документ изменения внесенные новой конфигурацией поставщика;
- В окне сравнения / объединения конфигураций проверяем, что возле модуля КонтрольВерсииКонфигураци СНЯТ ФЛАГ. Это означает, что данный модуль не будет обновляться;
- Обновляем конфигурацию, вносим изменения из текстового документа в модуль КонтрольВерсииКонфигураци.
Обновление плана обмена.
Рассмотрим пример: в состав плана обмена ПоОрганизации вы включили справочник ВнешниеОбработки. При обновлении нетиповой конфигурации 1с состав данного плана обмена изменился и перед нами стоит задача правильно обновить план обмена, не затерев ни типовые изменения, ни свои. Инструменты используемые для сравнения измененных объектов метаданных были подробно описаны в предыдущих пунктах, поэтому для данного случая все будет описано кратко.
Рассмотрим по шагам обновление состава плана обмена ПоОрганизации с указанными изменениями:
- В созданный при обновлении общего модуля текстовый документ добавим новые строки:
- Найдем план обмена ПоОрганизации в окне сравнения / объединения, раскроем его до ветки Состав. Замечу, что в плане обмена вами может быть изменен и модуль, его надо обновлять по правилам описанным для общего модуля. В данном случае нас интересует именно обновление состава плана обмена;
- Как и в случае с общим модулем, состав плана обмена можно либо обновить, после этого добавив свои изменения вручную, либо не обновлять, добавив типовые изменения вручную. Если ваших изменений в составе больше, чем типовых, то обновлять лучше вторым способом, если меньше то первым. Посмотреть каких изменений больше можно при помощи все тех же отчетов:
- Отчет о сравнении объектов основной конфигурации со старой конфигурацией поставщика — только ваши изменения;
- Отчет о сравнении объектов новой конфигурации поставщика со старой конфигурацией поставщика — только типовые. Замечу, что в данном отчете выводятся все типовые изменения, включая модуль. В данном случае следует их игнорировать;
Обновление подписки на событие.
Рассмотрим пример: в источник подписки на событие ПередУдалениемСправочникаДляОбменаПоОрганизации вы включили справочник ВнешниеОбработки. При обновлении состав источников изменился, задача аналогичная предыдущим — выполнить обновление нетиповой конфигурации 1с правильно.
Рассмотрим по шагам обновление состава источников подписки на событие с указанными изменениями:
Обновление ролей в 1С
Перед тем, как начать рассказывать про обновление ролей в 1С 8, хочется заметить, что лучше не изменять типовые роли, в этом нет никакой необходимости, к тому же сильно затрудняется обновление нетиповой конфигурации 1с. Если вы дорабатываете какую либо типовую конфигурацию и добавляете в нее свои документы, справочники и т.д., то создайте свою роль (или несколько, в зависимости от ситуации), в которую включите новые объекты метаданных. Если вы так не сделаете, то со временем вам будет очень тяжело обновлять типовые роли (а под час невозможно), так как почти в каждом релизе они сильно изменяются и отчеты о сравнении конфигураций могут выглядеть не слишком понятно.
Но все же часто бывают случаи когда роль уже изменена, и не один раз, а разбираться зачем и почему времени нет. Поэтому рассмотрим пример: в типовой роли Бухгалтер для справочника НалоговыеОрганы добавлены права на чтение и просмотр, при обновлении набор прав роли также был изменен.
Рассмотрим обновление роли по шагам:
На этом статья про Обновление нетиповой конфигурации 1С завершена. Если после прочтения у вас остались вопросы — смело задавайте их в комментариях! По желанию читателей в следующей статье я могу рассказать о других интересных и сложных аспектах обновления нетиповой конфигурации 1С 8.
Введение в поставку и поддержку конфигураций
Рассмотрим типичную ситуацию. Фирма-поставщик выпускает тиражную конфигурацию. Клиент приобретает ее и адаптирует под свои требования. Через некоторое время поставщик выпускает новую версию, и перед клиентом встает вопрос обновления, то есть интеграции своих изменений с изменениями поставщика. Ручное объединение в подобных случаях очень трудоемко. Требуется составить список всех отличий своей конфигурации от старой конфигурации поставщика и заново внести их в новую версию. Можно делать и наоборот, то есть подготовить список изменений поставщика и внести их в свою конфигурацию, но это ничего не меняет. Многое также зависит от механизма сравнения конфигураций и подготовки отчета различий. В платформе "1С:Предприятие" версии 8 этот механизм был существенно улучшен по сравнению с "1С:Предприятием" версии 7.7, но даже самый лучший и подробный отчет от дальнейшей утомительной ручной работы не освобождает. Механизм поставки и поддержки конфигураций в значительной степени автоматизирует этот процесс.
Общая схема обновления
Подробно рассмотрим ситуацию на примере любого свойства объекта метаданных. Возможны следующие варианты:
Пользователь Поставщик Правило обновления 1 Менял Не менял Взять из конфигурации пользователя 2 Менял Менял ? 3 Не менял Не менял Взять из конфигурации пользователя 4 Не менял Менял Взять из конфигурации поставщика Таблица 1. Правила обновления по умолчанию
Нетрудно заметить, что варианты 1, 3, 4 в большинстве случаев не требуют модифицировать предложенное правило. Самый сложный случай – второй. Здесь нельзя сделать никаких предположений, но можно по крайней мере автоматически определить все такие свойства и предоставить пользователю отфильтрованный список для указания правила в каждом конкретном случае.
Реализация в платформе "1С:Предприятие 8"
Общие понятия
В "1С:Предприятии 8" любая конфигурация может стоять на поддержке одной или нескольких других конфигураций, называемых конфигурациями поставщика. В качестве конфигурации поставщика может выступать конфигурация, созданная командой Конфигурация - Поставка конфигурации - Создать файлы поставки и обновления конфигурации . В результате выполнения этой команды создается файл конфигурации ( cf) . Файл, подготовленный командой Конфигурация - Сохранить конфигурацию в файл , в качестве конфигурации поставщика использовать нельзя. Для того чтобы получить конфигурацию поставщика в виде файла информационной базы (1cd) или файла выгрузки информационной базы (dt), требуется подготовленный вышеописанным способом файл cf загрузить в требуемую информационную базу (возможно, в пустую), выполнив команду Конфигурация - Загрузить конфигурацию из файла . Затем, при необходимости, можно штатными средствами создать файл dt.
Существуют два способа встать на поддержку конфигурации поставщика. Первый - использовать конфигурацию, подготовленную вышеописанным способом (при необходимости внося в нее изменения). Фактически подготовленная конфигурация поставщика находится на поддержке той конфигурации, в которой она была создана. Аналогичный результат достигается через команды Конфигурация - Загрузить конфигурацию из файла и Администрирование - Загрузить информационную базу . Второй способ позволяет поставить на поддержку уже созданную конфигурацию пользователя. Для этого необходимо выполнить команду Конфигурация - Сравнить, объединить с конфигурацией из файла . Если в качестве выбранного файла указывается файл конфигурации поставщика, и конфигурация пользователя уже не находится на ее поддержке, предлагается после объединения встать на поддержку.
Существуют два режима поддержки. Первый - в конфигурацию поставщика не вносятся изменения, она используется как есть. Такой режим возможен только при первом способе постановки на поддержку, и именно в нем конфигурация поставщика находится после ее создания. Все объекты конфигурации в этом случае заблокированы для изменений (в том числе и для добавления новых объектов). Второй режим - конфигурация находится на поддержке с возможностью изменений. Для того чтобы перейти в этот режим, необходимо открыть диалог настройки поддержки командой Конфигурация - Поддержка - Настройка поддержки и нажать кнопку Включить возможность изменения .
Способы обновления конфигурации. Обновление конфигурации может выполняться как с помощью файлов конфигурации поставщика новой версии, так и с помощью специальных файлов обновления конфигурации ( cfu) . Обновление конфигурации с помощью файлов (cf) может выполняться с любой версии (в том числе и более новой, при необходимости отказаться от внесенных изменений). При создании файла обновления поставщик указывает, для каких версий конфигурации он предназначен. Таких версий может быть несколько, но обновление может быть выполнено только с них. Это связано с тем, что файлы обновления включают в себя не всю конфигурацию, а только те изменения, которые существуют между конечной версией и указанными при создании файла обновлениями. Важно отметить, что файлы cfu не поддерживают обновления не только для более ранних версий конфигурации, чем они предназначены, но и для более поздних.
Приведем пример. Если конечная версия "4", а обновление создается только для версии "2", то невозможно будет выполнить обновление не только для версии "1", но и для версии "3". Такое ограничение связано с возможностью "обратных" изменений. То есть представим себе, что при переходе к версии "3" поставщик увеличил длину строки в типе реквизита, а в версии "4" изменил ее обратно. При подготовке обновления "2" - "4" это свойство в файл не попадет (поскольку в этих версиях значения совпадают). Если позволить использовать такой файл для обновления версии "3", то у пользователя окажется неправильная, увеличенная длина строки. Файлы обновления конфигурации имеют минимальный размер не только за счет включения в них только необходимых объектов, но и за счет применяемого в них сжатия данных. Они оптимальны для доставки обновления пользователю по низкоскоростным каналам связи. Обратной стороной является описанная выше меньшая гибкость их применения. С точки зрения дальнейшего процесса обновления применение файлов cf и cfu ничем не отличается.
Рисунок 1. Общая схема взаимодействия поставщика и пользователя
Выполнение обновления
Если конфигурация пользователя находится на поддержке без возможности внесения изменений, обновление представляет собой тривиальный, полностью автоматизированный процесс. Пользователь выполняет команду Конфигурация - Поддержка - Обновить конфигурацию , и после получения подтверждения выполняется обновление. Рассмотрим второй, наиболее интересный случай. Пользователь включил возможность изменения. Обновление конфигурации производится с использованием стандартного механизма сравнения и объединения, но пользователю предоставляется существенный дополнительный сервис. В процессе сравнения участвуют не две а три конфигурации - конфигурация пользователя, старая конфигурация поставщика (она хранится в конфигурации пользователя) и новая конфигурация поставщика, до которой и производится обновление. При этом система автоматически производит анализ сделанных изменений и, в соответствии с таблицей 1, расставляет правила объединения. Главную сложность представляет собой вариант 2, когда и пользователь, и поставщик меняли одно и то же свойство. Как отмечалось, разумных предположений автоматически сделать невозможно, но можно выделить эти случаи для пользователя. Все подобные свойства в дереве объединения показываются жирным шрифтом. Кроме того, в настройке фильтра просмотра можно указать флажок Показывать только дважды измененные свойства , и в дереве объединения будут показываться только те свойства, которые требуют ручной установки правил объединения. После выполнения объединения хранимая внутри пользовательской конфигурации конфигурация поставщика будет обновлена до новой версии.
Модификация алгоритма обновления с помощью правил поддержки
Пользователь может модифицировать приведенный алгоритм обновления с помощью правил поддержки, которые можно установить для каждого объекта метаданных. Необходимость в этом может возникнуть, если пользователь собирается самостоятельно выполнять дальнейшую модификацию объекта на себя и ему неинтересны изменения, вносимые поставщиком. Частный случай - пользователю вообще не требуется данный объект, и он хочет его удалить. Существуют три правила поддержки объекта метаданных:
- "Объект поставщика не редактируется" - пользователь не может изменять объект поставщика. Основное предназначение этого правила будет описано ниже, но пользователь может установить его с целью страховки от случайных изменений. При обновлении такие объекты будут полностью заменяться на объекты поставщика новой версии.
- "Объект поставщика редактируется с сохранением поддержки" - основное правило. В этом случае алгоритм объединения в точности совпадает с описанным.
- "Объект поставщика снят с поддержки" - пользователь не хочет выполнять дальнейшие обновления данного объекта. Для того чтобы удалить объект поставщика, предварительно ему необходимо установить данное правило.
Приведем расширенный вариант таблицы 1, с учетом правил поддержки.
Пользователь Поставщик Правила поддержки и обновления 1 Менял Не менял Любое Взять из конфигурации пользователя 2 Менял Менял Объект поставщика не редактируется Невозможно Объект поставщика редактируется с сохранением поддержки Взять из конфигурации поставщика Объект поставщика снят с поддержки Взять из конфигурации пользователя 3 Не менял Не менял Любое Взять из конфигурации пользователя 4 Не менял Менял Объект поставщика не редактируется Взять из конфигурации поставщика Объект поставщика редактируется с сохранением поддержки Взять из конфигурации поставщика Объект поставщика снят с поддержки Взять из конфигурации пользователя Таблица 2. Правила обновления по умолчанию с учетом правил поддержки
Ограничения действий пользователя со стороны поставщика с помощью правил поставки
Поставщик может ограничить возможные изменения пользователя с помощью правил поставки, которые можно устанавливать для каждого объекта метаданных. Данная возможность призвана ограничить возможные изменения конфигурации поставщика, нарушающие логику ее работы, после которых дальнейшая поддержка конфигурации теряет смысл. Существуют три правила поставки:
- "Изменения разрешены";
- "Изменения не рекомендуются";
- "Изменения запрещены".
Далее приводятся правила поддержки (по умолчанию и доступные для выбора пользователем), соответствующие различным правилам поставки.
Читайте также: