Создание файлов поставки и обновления

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

В «1С:Предприятии 8» любая конфигурация может стоять на поддержке одной или нескольких других конфигураций, называемых конфигурациями поставщика.

В качестве конфигурации поставщика может выступать конфигурация, созданная командой меню «Конфигурация» — «Поставка конфигурации» — «Создать файлы поставки и обновления конфигурации».

Файл, подготовленный командой «Конфигурация» — «Сохранить конфигурацию в файл», в качестве конфигурации поставщика использовать нельзя.

Для того чтобы получить конфигурацию поставщика в виде файла информационной базы (.1cd) или файла выгрузки информационной базы (.dt), требуется:

Настройка поставки 1С

Настройка поставки (команда меню «Конфигурация» — «Настройка поставки…») позволяет задать правила, по которым будет осуществляться поддержка конфигурации у пользователей.

Следует обратить внимание:

Правила поставки объекта конфигурации:

Эти варианты определяют допустимые правила поддержки, которые будут устанавливаться пользователем.

Правила поставки модулей объекта:

Отмена использования при поставке полного файла конфигурации (. cf):

Например, изменение типа реквизита справочника со строки на ссылку на другой справочник требует «двухпроходного обновления»:

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

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

Использование флажка «Файл поставки может использоваться для обновления» позволяет поставщику подстраховаться от ошибок пользователя в процессе обновления.

Общая схема может быть примерно такой:

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

ВАЖНО! Следует иметь в виду недостаточную гибкость этого средства. При его отключении пользователь не сможет при необходимости выполнить «обратное обновление» с более поздней версии.

Стандартная структура каталогов файлов поставки и обновления 1С

Механизм поставки конфигураций предлагает определенную схему размещения на диске файлов поставки и поддержки разных версий. В диалоге «Создание файлов поставки и обновления конфигурации» нажав кнопку «Каталог файлов поставки» можно задать корневой каталог для размещения создаваемых файлов. Файлы поставки и обновления будут по умолчанию располагаться в подкаталогах, имеющих имена, соответствующие свойству «Версия» конфигурации.

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

Следует иметь ввиду, что корневой каталог не сохраняется внутри самой конфигурации и будет изменен при переносе файла информационной базы «1 cd » на другой компьютер.

Создание файлов поставки и обновления конфигурации

Файлы поставки и обновления могут создаваться из диалога «Создание файлов поставки и обновления»:

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

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

ВАЖНО! Файлы обновления не являются кумулятивными, то есть создание обновления с версии «4» до версии «6» не позволит с помощью этого файла произвести обновление с версии «5», если только она не была указана при создании.

Для выбора файлов предыдущих версий можно пользоваться:

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

Добавить комментарий Отменить ответ

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

Источник

Настройка поставки и создание файлов поставки и обновления

Рассмотрим вопрос подготовки и создания комплектов поставки прикладных решений.

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

Настройка поставки

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

Эти варианты определяют допустимые правила поддержки, которые будут устанавливаться пользователем. Более подробно вопрос описан в разделе «Введение в поставку и поддержку конфигураций».

Для объектов так же можно задать правила поставки модулей. Для этого используется флажок «Включать тексты модулей объекта». В случае отмены поставки текстов модулей пользователь не будет иметь возможности просматривать и изменять тексты программ на встроенном языке «1С:Предприятия», что может являться как элементом защиты интеллектуальной собственности поставщика, так и элементом поддержки логической целостности конфигурации.

В настройке поставки конфигурации так же можно установить флажок «Файл поставки может использоваться для обновления». Как было описано в разделе «Введение в поставку и поддержку конфигураций», для обновления конфигурации поставщика могут использоваться как специальные файлы обновления ( cfu ), так и полные файлы конфигурации ( cf). Сброс данного флажка отменяет последнюю возможность. Это может быть полезно, когда новая версия конфигурации требует сложной обработки базы данных.

Например, изменение типа реквизита справочника со строки на ссылку на другой справочник требует «двухпроходного обновления». Сначала требуется добавить новый реквизит типа ссылки, заполнить его на основе значения старого реквизита, и только потом можно удалить старый реквизит, а новый переименовать. Такую процедуру нельзя выполнить в рамках одного изменения структуры базы данных с предшествующим и / или последующим выполнением специальной обработки. Требуется подготовить промежуточную версию конфигурации, в которой новый реквизит будет добавлен, а старый еще не удален, и написать соответствующие обработки. Процедуру обновления конфигурации в этом случае, конечно, следует подробно описать в документации, но всегда существует вероятность ошибочных действий со стороны пользователя. Использование флажка «Файл поставки может использоваться для обновления» позволяет поставщику подстраховаться от ошибок пользователя в процессе обновления. Общая схема может быть примерно такой:

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

Стандартная структура каталогов файлов поставки и обновления

Механизм поставки конфигураций предлагает определенную схему размещения на диске файлов поставки и поддержки разных версий. В диалоге «Создание файлов поставки и обновления конфигурации» нажав кнопку «Каталог файлов поставки» можно задать корневой каталог для размещения создаваемых файлов. Файлы поставки и обновления будут по умолчанию располагаться в подкаталогах, имеющих имена, соответствующие свойству «Версия» конфигурации. Использование этой схемы позволит упростить подготовку обновлений для новых версий конфигурации, как это будет описано ниже. Следует иметь ввиду, что корневой каталог не сохраняется внутри самой конфигурации и будет изменен при переносе файла информационной базы «1 cd » на другой компьютер.

Создание файлов поставки и обновления конфигурации

Файлы поставки и обновления могут создаваться как одновременно, так и раздельно, из диалога «Создание файлов поставки и обновления». Но одновременно может быть создан только один файл обновления. Для создания нескольких файлов обновления с разного набора предыдущих версий следует выполнить процедуру создания файлов обновления несколько раз. Файл поставки при этом может быть создан только однажды. Впрочем, отказ от создания файла поставки не приведет к ускорению создания файла обновления. В случае конфигурации большого объема это достаточно длительный процесс, время исполнения которого зависит от количества выбранных версий, подлежащих обновлению.

При включении флажка «Создать файл обновления конфигурации» следует указать один или несколько файлов предыдущих версий, для которых и будет подготовлено обновление. Следует напомнить что, как было описано в разделе «Введение в поставку и поддержку конфигураций», файлы обновления не являются кумулятивными, то есть создание обновления с версии «4» до версии «6» не позволит с помощью этого файла произвести обновление с версии «5», если только она не была указана при создании. Для выбора файлов предыдущих версий можно пользоваться как кнопкой «Добавить» и прямым выбором файла, так и кнопкой «Добавить из предыдущих версий», которая сама найдет и предложит для выбора файлы, если они были размещены на диске в соответствии с описанной выше стандартной структурой каталогов. С помощью команды «Добавить» можно указать и файлы других конфигураций. После чего обновление может быть выполнено и для них, однако это должны быть именно файлы поставки, а не произвольные файлы конфигурации.

Создание файлов поставки других форматов

Открыв в режиме конфигуратора файл информационной базы, содержащий необходимые данные, следует выполнить команду «Конфигурация\Загрузить конфигурацию из файла. «, согласиться на замену текущей конфигурации и выполнить обновление конфигурации базы данных. Полученную в результате информационную базу можно использовать для поставки. Для подготовки файла выгрузки конфигурации ( dt ) следует в ее среде выполнить стандартную команду «Администрирование\Выгрузить информационную базу».

Источник

Введение в поставку и поддержку конфигураций

Предназначение

Рассмотрим типичную ситуацию. Фирма-поставщик выпускает тиражную конфигурацию. Клиент приобретает ее и адаптирует под свои требования. Через некоторое время поставщик выпускает новую версию, и перед клиентом встает вопрос обновления, то есть интеграции своих изменений с изменениями поставщика. Ручное объединение в подобных случаях очень трудоемко. Требуется составить список всех отличий своей конфигурации от старой конфигурации поставщика и заново внести их в новую версию. Можно делать и наоборот, то есть подготовить список изменений поставщика и внести их в свою конфигурацию, но это ничего не меняет. Многое также зависит от механизма сравнения конфигураций и подготовки отчета различий. В платформе «1С:Предприятие» версии 8 этот механизм был существенно улучшен по сравнению с «1С:Предприятием» версии 7.7, но даже самый лучший и подробный отчет от дальнейшей утомительной ручной работы не освобождает. Механизм поставки и поддержки конфигураций в значительной степени автоматизирует этот процесс.

Общая схема обновления

Подробно рассмотрим ситуацию на примере любого свойства объекта метаданных. Возможны следующие варианты:

Таблица 1. Правила обновления по умолчанию

Нетрудно заметить, что варианты 1, 3, 4 в большинстве случаев не требуют модифицировать предложенное правило. Самый сложный случай – второй. Здесь нельзя сделать никаких предположений, но можно по крайней мере автоматически определить все такие свойства и предоставить пользователю отфильтрованный список для указания правила в каждом конкретном случае.

Реализация в платформе «1С:Предприятие 8»

Общие понятия

Рисунок 1. Общая схема взаимодействия поставщика и пользователя

Выполнение обновления

Модификация алгоритма обновления с помощью правил поддержки

Приведем расширенный вариант таблицы 1, с учетом правил поддержки.

Таблица 2. Правила обновления по умолчанию с учетом правил поддержки

Ограничения действий пользователя со стороны поставщика с помощью правил поставки

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

Далее приводятся правила поддержки (по умолчанию и доступные для выбора пользователем), соответствующие различным правилам поставки.

Рисунок 2. Соответствие правил поставки и поддержки

Источник

Технология обновления нетиповых конфигураций 1С:Предприятия 8 (редакция 12.04.2012)

Данная статья основана на многолетнем опыте по развитию и поддержке учетных решений на платформе 1С:Предприятия. В статье описаны некоторые довольно часто встречающиеся ситуации, вызывающие сложности при обновлении нетиповых конфигураций 1С:Предприятия 8.

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

Процесс обновления конфигураций 1С:Предприятия 8 более автоматизирован по сравнению с 1С:Предприятием 7.7. Достаточно высокий уровень автоматизации позволяет значительно снизить трудоемкость работ при обновлении нетиповых конфигураций. К сожалению, чаще всего процесс обновления нетиповых конфигураций не может быть выполнен полностью в автоматическом режиме и требует вмешательства специалиста.

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

Следует обратить внимание на то, что база данных может содержать до трех видов конфигураций:

Рассмотрим процесс обновления и разберем возможные ошибки на примере обновления конфигурации УПП (поставщик типовой конфигурации – фирма «1С», доработки компании Информ Сервис). Изначально обновление данной конфигурации выполнялось не по описанной в данной статье технологии, поэтому рассматриваемые в статье ошибки являются наиболее часто встречающимися на практике. Обновление будет выполняться с версии 1.2.6.2 на версию 1.2.14.1.

Этап 1. Подготовка

Этот этап можно пропустить, если последнее обновление прошло через «поддержку» (Меню «Конфигурация» → «Поддержка» → «Обновить конфигурацию») или было выполнено по описанной в данной статье методике.

Несоответствие версий рабочей конфигурации и конфигурации поставщика может возникнуть при использовании для обновления *.cf файлов, не из дистрибутива поставщика или при использовании методов обновления отличающихся от описанных в данной статье. Напрмер, объекты добавлялись в рабочую конфигурацию копированием через буфер обмена или Drag&Drop.

1. Сравнение версий.

Проверим номера версий рабочей конфигурации и конфигурации поставщика. Номер рабочей конфигурации смотрим в меню «Конфигурация» → «Открыть конфигурацию» меню «Правка» → «Свойства». В блоке «Разработка» пункт «Версия». (Рисунок 1).

Номер конфигурации поставщика смотрим в меню «Конфигурация» → «Поддержка» → «Настройка поддержки…» пункт «Версия». (Рисунок 2).

Если номера совпадают, то переходим к следующему этапу. См. Этап 2.

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

2. Сохранение рабочей (основной) конфигурации.

Сохраним рабочую конфигурацию в файл, например work.cf. Для этого выберем пункт меню «Конфигурация» → «Сохранить конфигурацию в файл…».

3. Получение файла обновления для конфигурации поставщика.

Для приведения в соответствие конфигураций нам понадобится файл *.cf из дистрибутива поставщика с тем же номером версии, что у рабочей конфигурации (Рисунки 3 и 4). Данный файл можно получить при установке соответствующего дистрибутива. По умолчанию установка дистрибутива конфигурации выполняется в каталог C:Program Files1cv81tmplts. Подробнее об установке шаблонов конфигураций см. документацию.

Проверим каталог шаблонов. Если в каталоге шаблонов есть *.cf файл нужной версии, то переходим к пункту 4 Этапа 1.

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

Используя полученный *.cf файл конфигурации поставщика выполним обновление. Для этого выберем пункт меню «Конфигурация» → «Поддержка» → «Обновить конфигурацию», «Выбор файла обновления», «Готово» (Рисунок 5), «Выполнить» (Рисунок 6).

Итак, первая проблема – «Обнаружены ссылки на объекты, помеченные на удаление». (Рисунок 7).

5. Восстановление настроек частично утерянных на предыдущем этапе.

Для восстановления частично утерянных настроек выполним объединение с ранее сохраненным файлом рабочей конфигурации work.cf. Для этого выберем пункт меню «Конфигурация» → «Сравнить, объединить с конфигурацией из файла…».

6. Сохранение результатов обновления.

Сохраним изменения рабочей конфигурации и обновим конфигурацию базы данных. Для этого выберем пункт меню «Конфигурация» → «Обновить конфигурацию базы данных».

Здесь нас поджидает очередная проблема (Рисунок 8).

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

Рассмотрим еще одну ситуацию, аналогичную предыдущей, но возникшую при обновлении 1С:Бухгалтерии предприятия 8.1. Что делать с формами? (Рисунок 9)

На рисунке мы видим, что ФормаСписка была удалена у поставщика, а затем добавлена поставщиком новая форма с тем же именем. Соответственно необходимо пометить обе формы для обновления и нажать кнопку «Выполнить».

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

Сохраним изменения рабочей конфигурации и обновим конфигурацию базы данных «Конфигурация» → «Обновить конфигурацию базы данных».

Если необходимо, перенесем значения реквизита ЗаказРезерв1 в ЗаказРезерв с помощью внешней обработки в режиме 1С:Предприятие.

Этап 2. Обновление

Для обновления конфигурации нам понадобится файл *.cfu или файл *.cf из дистрибутива поставщика.

Если обновление выполняется через несколько версий конфигурации, то следует обратить внимание на ситуацию, описанную в статье«Обновление конфигураций 1С:Предприятия 8. Прыжок через 20 версий». Если обновление выполняется не на рабочей базе, то после завершения работ по подготовке каждого нового этапа сохраняем файлы *.cf. Они понадобятся при обновлении конфигурации рабочей базы данных заказчика.

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

Если обновление выполняется через несколько версий, то для снижения трудоемкости обновления, можно воспользоваться методикой с вычислением ключевых релизов, описанной в статье «Обновление конфигураций 1С:Предприятия 8. Прыжок через 20 версий».

1. Подготовка баз данных.

2. Трёхсторонее сравнение конфигураций.

Откроем обе базы в режиме Конфигуратор и выполним трёхсторонее сравнение конфигураций в обеих базах, используя имеющийся файл новой конфигурации поставщика. Для этого в обеих базах выберем пункт меню «Конфигурация» → «Поддержка» → «Обновить конфигурацию», «Выбор файла обновления», «Готово» (Рисунок 10).

В результате сравнения трех конфигураций (старая конфигурация поставщика, новая конфигурация поставщика и рабочая конфигурация) получаем список измененных объектов. Устанавливаем фильтр «Показывать только дважды измененные свойства» (Рисунки 11 и 12).

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

На этом работу во второй (вспомогательной) базе приостанавливаем и продолжаем в основной. Кнопку «Выполнить» во вспомогательной базе не надо нажимать. Нам эта база нужна именно в таком виде до окончания процесса обновления.

Если изменений в объекте больше в новой конфигурации поставщика, то оставляем экземпляр объекта поставщика. Оставляем галочку. Затем перенесем изменения из рабочей конфигурации.

Если изменений в объекте больше в рабочей конфигурации, то оставляем экземпляр объекта рабочей конфигурации. Снимаем галочку. Затем перенесем изменения из конфигурации поставщика.

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

Далее расставляем галочки, указывая какие процедуры и функции следует заменить или удалить (Рисунок 15).

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

Аналогичным образом сравниваем старую конфигурацию поставщика с новой. Для сравнения нам понадобится файл новой конфигурации поставщика. Если такого файла нет, то теперь его можно получить из основной базы. Для сохранения в файл новой конфигурации поставщика в основной базе в меню «Конфигурация» → «Поддержка» → «Настройка поддержки:» нажимаем кнопку «Сохранить в файл». (Рисунок 2). Указываем имя файла, например, new.cf. Далее делаем третье сравнение конфигураций и при сравнении в качестве второй конфигурации указываем файл new.cf.

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

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

Сравнение форм, таблиц, и модулей объектов в конфигурации выполняется с достаточной степенью детализации (Рисунок 17). Этого вполне достаточно для принятия решений.

Но в некоторых случаях данные в отчетах о сравнении представляются в виде, не позволяющем принять решение быстро. Например, в случае изменения типа реквизитов, имеющих составной тип данных, состав вводимых на основании объектов и т.д. Именно на данном этапе, ввиду его сложности, происходит потеря доработок при обновлении. Рассмотрим эту ситуацию на примере реквизитов, имеющих составной тип данных. При формировании отчета о сравнении объектов (Рисунок 17) различающиеся данные в сравниваемых конфигурациях представлены в виде списков, содержащих состав типов данных, разделенных запятыми. При этом в отчете совершенно не видно, какие типы данных были добавлены или удалены. Конечно, для выявления различий отчет можно распечатать и «скрыжить». В рассматриваемом примере таких объектов около 200. Очевидно, что процесс сравнения представляется достаточно трудоемким и составит около 50 часов.

Для снижения трудоемкости работ при сравнении объектов можно воспользоваться конфигурацией «Сравнение ячеек», разработанной компанией Информ Сервис. Примерно в 20 раз может выть снижена трудоемкость работ при сравнении составных объектов.

Конфигурация «Сравнение ячеек» запускается в режиме 1С:Предприятие и позволяет представить информацию из отчета о сравнении объектов в наглядном виде (Рисунки 18 и 19). Для сравнения используются возможности 1С:Предприятия 8.

Схема работы конфигурации проста. В конфигураторе создаем отчет о сравнении объектов (Рисунок 17) и сохраняем в файл, например ОтчетОСравнении.mxl. Открываем 1С:Предприятие и в диалоге (Рисунок 18) выбираем сохраненный файл и указываем сравниваемые ячейки. Для этого дважды щелкаем правой клавишей мыши на выбранной ячейке табличного документа. По кнопке «Сравнить» получаем результат сравнения, в котором различающиеся позиции выделены цветом (Рисунок 19).

Далее, исходя из того, что сравнение выполняется по тем же принципам сравнения объектов, схема действий будет выглядеть так. Сохраняем следующий отчет под тем же именем файла. Нажимаем кнопки «Обновить» и «Сравнить». Более подробное описание данной обработки можно посмотреть здесь «Сравнение ячеек».

Особо пристальное внимание следует уделить шаблонам RLS по измененным ролям пользователей.

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

Этап 3. Сдача работ

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

Если в рабочей базе данных заказчика во время подготовки обновления не проводились работы по изменению конфигурации, а обновление готовилось на актуальной копии рабочей базы данных, то для переноса настроек сохраним рабочую конфигурацию в файл, например work_2.cf, выбрав пункт меню «Конфигурация» → «Сохранить конфигурацию в файл…».

Дальнейшие действия на стороне заказчика будут следующие:

Если обновление готовилось не на актуальной копии рабочей базы данных, то для переноса настроек воспользуемся методикой использованной на первом этапе. Для этого нам понадобится файл *.cf типовой конфигурации поставщика (1.2.14.1) и результат обновления в виде также *.cf файла. Для этого сохраним рабочую конфигурацию в файл, например work_2.cf, выбрав пункт меню «Конфигурация» → «Сохранить конфигурацию в файл…».

Дальнейшие действия на стороне заказчика будут следующие:

Правильное выполнение данного этапа позволит в дальнейшем избежать работ, описанных в Этапе 1.

Источник