Нетиповая конфигурация 1С, это когда: 1) конфигурация 1С написана с нуля самостоятельно программистом, 2)конфигурация 1С была типовой, но в нее добавили изменения, даже если добавили один реквизит.
В данной статье мы рассмотрим, как необходимо корректно обновлять конфигурации 1С, а также несколько приемов по мягкому изменению типовых конфигураций, т.е. правильному изменению, которое не будет влиять на возможность дальнейшего обновления.
Для того, чтобы внести любые изменения в типовую конфигурацию 1С, необходимо разблокировать изменение типовой конфигурации 1С, а в некоторых случаях «снять ее с поддержки».
В самом оптимальном варианте обновления конфигурация 1С может обновляться в полностью автоматическом режиме, это возможно, когда у нас запрещены изменения конфигурации. Довольно часто требуется включать изменение конфигурации, поскольку необходима адаптация прикладных решений под бизнес-требования заказчика, на этом варианте мы и остановимся.
Прежде чем выполнять обновление настоятельно рекомендуется сделать резервную копию базы данных, сделать это можно через меню Администрирование/Выгрузить информационную базу.
Существует 2 варианта обновления: а) Обновление 1С через поддержку (вызов через диалог Конфигурация/Поддержка/Обновить конфигурацию) и б) через Сравнение объединение с конфигурацией из файла. Следует обратить особое внимание, что разница между этими двумя пунктами в том, что в первом случае обновляется и основная конфигурация и конфигурация поставщика, а при сравнении объединении конфигураций обновляется только основная конфигурация, конфигурация поставщика остается старой. Таким образом наиболее рекомендуемым вариантом является обновление через Обновить конфигурацию. Для обновления через Поддержку конфигурации используются файлы поставки поставщика CF или CFU, которые можно найти поиском, в каталоге шаблонов, указав путь в Интернете, или напрямую указать путь к нужному файлу на жестком диске.
При обновлении конфигурации 1С без возможности внесения изменений обновление после выбора файла обновления происходит в автоматическом режиме, если в конфигурации включена возможность внесения изменений, тогда после выбора файла обновления будет выведено окно сравнения конфигураций. В этом диалоге мы можем увидеть как система предлагает нам обновить нашу нетиповую конфигурацию 1С. В нижней части диалогового окна расположена соответствующая легенда по статусам объектов: "Статусы по соответствиям объектов" обозначают сравнение "Основной конфигурации" и "Новой конфигурации", "Статусы по истории объектов" обозначают сравнение объектов конфигураций с объектами "Старой конфигурации поставщика".
Проставляя флажки рядом с объектами, можно выбирать, изменятся текущий объект конфигурации, или останется старым, а также способ изменения объекта. В меню действия есть возможность проставить галочки по подсистемам (это полезно, если конфигурация находится на поддержке у нескольких поставщиков). Также в этом меню есть возможность указать приоритет объединения для всех объектов разом, по умолчанию система считает более приоритетной конфигурацию поставщика. Настройки фильтра позволяют указать, какие объекты конфигурации нам стоит выводить для возможности детального указания режима объединения. Существуют несколько стандартных шаблонов фильтра, кроме этого можно указать фильтры для каждой пары сравниваемых конфигураций. Есть возможность установить в настройках "Фильтр" галочку "Показывать только дважды измененные свойства", это позволит отсеять объекты, при обновлении которых не возникло конфликтов между изменениями поставщика и доработками этих объектов:
Итак, в результате получится список объектов, дважды измененных при доработке типовой конфигурации и в новой конфигурации поставщика. Если согласиться с обновлением, то сделанные ранее доработки в этих объектах будут утеряны. Поэтому по каждому объекту необходимо принять решение о том, каким образом он будет обновлен. На этом этапе следует выполнить предварительное сравнение исключительно для того, чтобы уменьшить объем работ в дальнейшем. Оценка не точная быстрая - "на глазок". Если изменений в объекте больше в новой конфигурации поставщика, то оставляем экземпляр объекта поставщика. Оставляем галочку. Потом нужно будет перенести изменения из рабочей конфигурации. Если изменений в объекте больше в рабочей конфигурации, то оставляем экземпляр объекта рабочей конфигурации. Снимаем галочку. Затем нужно будет перенести изменения из конфигурации поставщика. С модулями можно поступить немного иначе, т.к. есть возможность сравнивать модули попроцедурно.
Т.е. в случае, если в нашей конфигурации 1С и в конфигурации поставщика изменены различные процедуры модуля, то, правильно расставив, галочки мы избавим себя от ручного переноса изменений кода. Чтобы до этого добраться, необходимо нажать кнопку в виде лупы рядом с названием режима объединения модулей:
При выводе меню действий по объекту (например нажатием правой кнопки мыши) мы можем вызвать отчет о сравнении объектов.
Чтобы подтвердить проведенное обновление 1С - нужно выбрать пункт меню Конфигурация/Обновить конфигурацию базы данных.
Чтобы отказаться от обновления 1С – нужно выбрать пункт меню Конфигурация/Вернуться к конфигурации БД.
Несколько правил, которые упрощают будущее обновление конфигураций 1С:
Основное правило обновления 1С: нужно добавлять новые объекты, т.к. при обновлении новые объекты системой не затрагиваются
При изменении текстов модулей желательно также добавлять свои новые процедуры и функции, а из существующих вызывать свои новые
Использование подписок на события, благодаря этому можно дорабатывать типовые механизмы, не изменяя типового кода
Использование типового функционала конфигураций
Программное создание элементов формы (В событии ПриСозданииФормыНаСервере)
Спасибо!
В них подробно и понятно объясняются ключевые моменты обновления типовых конфигураций.
Чего там нет? Собственно самой технологии обновления. То есть поэтапного описания действий при анализе Основной конфигурации и Обновления. Попробуем описать этот процесс в виде алгоритма:
- После того как вы сделали копию информационной базы, запустили механизм обновления. Появится окно сравнения, объединения конфигураций.
- Понять какие объекты были изменены в конфигурации до Вас. Это можно сделать при помощи установки фильтра: Показывать отличия основной конфигурации от старой конфигурации поставщика(не забудьте при этом проверить текущий релиз конфигурации поставщика).
- Понять какие объекты должны будут изменены в ходе обновления. Это можно сделать несколькими способами. Первый способ, использовать файл описания изменённых объектов который можно найти в каталоге обновления либо на сайте users.v8.1c.ru. Второй способ, отключить фильтр, установить шаблон в значение «Показывать все». В этом случае все изменённые объекты будут содержать отметку о изменении объекта напротив соответствующего объекта в колонке (зеленый карандаш).
На следующем шаге необходимо обратить внимание на объекты, которые были изменены до Вас и которые необходимо изменить в ходе обновления. Для этого установим фильтр: Показывать только дважды измененные объекты. С этими объектами необходимо разбираться в первую очередь. Итак, если объект изменен, это означает что изменилось одно из следующих составляющих:- Изменено какое-либо свойство объекта;
- Изменены реквизиты объекта или реквизиты табличной части объекта;
- Изменён макет объекта;
- Изменён модуль объекта;
- Изменена форма объекта.
- По каждой составляющей необходимо принять решение о объединении.
- Если свойство объекта изменено в основной конфигурации и не изменяется в обновлении, то в этом случае необходимо установить соответствующий режим объединения этих свойств: «Объединить с приоритетом основной конфигурации».
- Если свойство объекта не изменялась в основной конфигурации (нет зеленого карандаша рядом с свойством в колонке «Основная конфигурация») в этом случае необходимо установить режим: «Взять из загружаемой конфигурации».
- Если свойство объекта было изменено в основной конфигурации, и должно быть изменено в ходе обновления: В этом случае можно устанавливать одно из возможных вариантов объединения. Примем за основу тот факт, что при обновлении необходимо максимально сохранить доработанный функционал, при этом добавив обновление в конфигурацию. В этом случае в зависимости от того что изменилось Модуль объекта, модуль формы или свойство, реквизит, макет, элементы формы будет разная стратегия обновления. Итак, если изменения коснулись модуля: Можно принять решение о каждом конкретном изменении, при этом существует 4 различных варианта исхода:
- Объединить с приоритетом основной.
- Отключить объединение модуля.
Если изменения коснулись реквизита, формы, макета то решение принимается в целом на подчиненный объект, в зависимости от степени изменения. Здесь так же 4 варианта объединения:
- Взять из загружаемой конфигурации.
- Объединить с приоритетом основной
- Объединить с приоритетом загружаемой конфигурации.
- Отключить объединение объекта.
После того как принято решение о варианте объединения, не лишним будет отметить, для себя, те объекты, к которым нужно будет вернуться после объединения для проверки работоспособности, и исправлений если они понадобятся.
5. В целом для объектов, которые остались нетронутыми можно установить такие режимы объединения. Если объект был изменен по сравнению со старой конфигурацией поставщика, то его не нужно вообще обновлять. То есть необходимо снять флаг объединения. Если объект нужно обновить, необходимо установить режим в значение: «Взять из загружаемой конфигурации». Более детально о том какой результат объединения получится в результате установки того или иного режима для различных объектов можно почитать.
6. После настройки режимов обновления необходимо нажать кнопку «Выполнить».
7. Иногда возникает проблема в ходе обновления, что ссылка на какие-либо объекты использующиеся в других объектах не участвуют в обновлении при этом система выводит соответствующее сообщение. Необходимо вернуться в режим сравнения и объединения и выбрать вариант объединения этих объектов.
8. Еще одна ситуация к которой необходимо отнестись с вниманием, это вот такое сообщение:
(смотри картинку анонса:)
Коротко говоря: «Вы сотрете доработки конфигурации». Нужно вернуться и еще раз все проверить, или же осознано выполнить замещение объектов.
Рассмотрим обновление на примере нетиповой конфигурации УПП 1.3 находящейся на поддержке с возможностью изменения с релиза 1.3.61.2 на релиз 1.3.62.1. Так как конфигурация сама по себе довольно тяжелая, то это накладывает некоторые особенности, в частности, не всегда получается открыть в одном конфигураторе несколько окон сравнения конфигурации.
Для обновления я использую две одинаковые копии базы данных старого релиза. В одной из них выполняю подготовку *.cf для обновления, назовем ее, например, for_ updating . Другая база остается не тронутой и служит только как вспомогательная, для сравнения конфигураций, назовем ее base . В принципе, в качестве вспомогательной может использоваться конфигурация рабочей базы.
В базе for_updating выполняем *.cfu нового релиза. Начинается процедура обновления, в результате которой появляется окно обновления.
Нажать кнопку «Выполнить », на данном этапе нет пока необходимости что-либо смотреть, так как целью является лишь получение конфигурации поставщика нового релиза.
В процессе обновления может появиться окно «Неразрешимые ссылки », нажимаем «Продолжить ». О причинах появления данного окна поговорим ниже.
Появится сообщение о том, что измененные нами объекты будут загружены из новой конфигурации, соглашаемся.
Откроется окно «Настройка правил поддержки » - для новых объектов (верхний раздел) с обеих сторон ставим «Объект редактируется с сохранением поддержки », для существующих объектов поставщика (нижний раздел) во всех четырех местах ставим флаг «Сохранять текущий режим », нажимаем «ОК ».
Произошло обновление основной конфигурации. Сама по себе основная конфигурация на данном этапе нам не нужна, цель - получение новой конфигурации поставщика. Поэтому основную конфигурацию не сохраняем, конфигурацию базы данных не обновляем.
Выполняем «Конфигурация » - «Поддержка » - «Настройка поддержки ». В открывшемся окне выбираем «Сохранить в файл » и сохраняем в *.cf конфигурацию поставщика нового релиза.
Основная конфигурация в том виде, в котором она на данный момент имеется, нам не нужна. Закрываем конфигурацию. «Конфигурация » - «Закрыть конфигурацию ». Отказываемся от сохранения изменений.
В конфигурации для сравнения base запускаем сравнение конфигурации поставщика (старый релиз) и конфигурации поставщика из файла (новый релиз).
Таким образом, мы увидим только те изменения, которые будут выполнены в конфигурации при обновлении на новый релиз.
В базе for_updating снова запускаемобновление конфигурации через поддержку «Конфигурация» - «Поддержка» - «Обновить конфигурацию» , в открывшемся окне выбираем *.cfu нового релиза. Начинается процедура обновления, в результате которой появляется окно обновления.
При нажатии на кнопку «Фильтр » откроется окно «Настройка фильтров просмотра ». В данном окне устанавливаем флаг «Показывать только дважды измененные свойства ».
При обновлении без нашего вмешательства происходит следующее:
- - объект не изменен нами, изменен в новом релизе - обновляется из нового релиза;
- - объект изменен нами, не изменен в новом релизе - остается наш объект;
- - объект изменен нами, изменен в новом релизе - это и есть дважды измененный объект, если ничего не менять - он загрузится из нового релиза.
Таким образом, наиболее пристальное внимание следует уделить именно дважды измененным объектам, их и будем рассматривать.
В данном примере изменено несколько общих модулей, в том числе и общий модуль « УчетНДС ».
По умолчанию в окне обновления показаны отличия основной и новой конфигурации поставщика от старой конфигурации поставщика.
Если посмотреть различия конфигураций в общем модуле «УчетНДС », то мы увидим следующую картину:
Если же сравнить эти модули в базе для сравнения base , то картина будет другая:
Очевидно, что функции «СобратьДанныеДляПечатиИсправленияСчетаФактуры », «СобратьДанныеДляПечатиКорректировочногоСчетаФактуры » и прочие содержат наши доработки, но не меняются при обновлении, а значит, нет смысла тратить время на их просмотр и анализ.
Поэтому, выполняя по процедурное обновление с выделенных процедур и функций можно снять флаги:
Многие скажут, что увидеть отличия старой конфигурации поставщика от новой можно с помощью изменения настройки фильтров просмотра в текущем конфигураторе, не используя сравнение конфигураций в базе base .
Например, так:
Однако, как показывает практический опыт это не так, процедуры и функции все равно отображаются в окне сравнения модулей, даже при установленном фильтре «показывать отличия новой конфигурации поставщика от старой конфигурации поставщика ».
Сделав не большое мысленное усилие, выявим дважды измененные процедуры и функции, только они будут нуждаться в доработках после процесса объединения. С данными процедурами и функциями нужно определиться, что легче:
- - либо взять процедуру или функцию из новой конфигурации поставщика и потом, после объединения, внести наши доработки;
- - либо снять флаг обновления, тем самым сохранив наши доработки, и уже потом добавить нужный код из конфигурации поставщика.
Объединение с приоритетом основной конфигурации и объединение с приоритетом новой конфигурации поставщика использую редко, в принципе и без использования данных режимов результат получится качественным.
После того как общие модули были проанализированы и у части процедур сняты флаги обновления, видим, что у модулей теперь установлен режим объединения - индивидуальная настройка:
Двигаемся далее. Среди дважды измененных объектов имеется форма элемента справочника «ОсновныеСредства ». Прежде чем определиться обновлять ли данную форму из новой конфигурации поставщика, нужно выяснить, что по факту меняется при обновлении.
Для этого в базе base с помощью контекстного меню вызовем «Отчет о сравнении объектов…». В открывшемся окне должны стоять все флаги в группе «Объекты».
Мне нравится режим вывода отчета в табличный документ, когда различия показываются графически, но это дело вкуса.
В результате сравнения формы элемента справочника «ОсновныеСредства » видим, что изменения есть только в модуле формы , а изменений в диалоге формы в обновлении нет.
Но так как форма элемента попала в дважды измененные объекты, то наши доработки есть либо в диалоге формы, либо в модуле.
Выполнив аналогичное сравнение в базе for_updating можно увидеть, что доработки есть в диалоге формы.
Причина тому, добавление справочника «ОсновныеСредства » в план видов характеристик «СвойстваОбъектов ». Если обновить форму элемента справочника «ОсновныеСредства » мы получим неразрешимые ссылки, о чем и будет свидетельствовать окно:
В данном случае самым лучшим вариантом будет не обновлять форму элемента справочника «Основные средства » и уже потом добавить необходимый код в модуль формы элемента. В этом случае окно «Неразрешимые ссылки » при обновлении появляться не будет.
Сделаем отступление и представим, что диалог формы элемента справочника «Основные средства » меняется при обновлении на новый релиз, тогда лучшим вариантом было бы обновление формы. Уже потом, после объединения, нужно было бы добавить в форму наши изменения, как в модуль , так и в диалог . Если в модуле много наших доработок и мало от поставщика, то после объединения можно полностью вернуть наш модуль и добавить изменения поставщика.
В этом случае в процессе объединения появилось бы окно «Неразрешимые салки ». Вариантов выбора в данном окне два: 1) «Пометить все для объединения» ; 2) «Продолжить ».
На мой взгляд, правильнее выбирать «Пометить все для объединения ».
В этом случае план видов характеристик «СвойстваОбъектов » будет добавлен как объект для объединения в дереве во вновь открывшемся окне «Обновление …»
Естественно, что после обновления в план видов характеристик «СвойстваОбъектов » нужно будет добавить наши изменения, сделать это лучше с помощью сравнения и объединения с текущей конфигурацией.
Рассмотрим, что произошло бы, если бы мы выбрали «Продолжить » в окне «Неразрешимые ссылки ». В этом случае форма элемента справочника «ОсновныеСредства » стала бы новой, а план видов характеристик «СвойстваОбъектов » остался бы старым. В этом случае у нас затрутся изменения в диалоге формы элемента справочника, а именно на странице «СвойстваИЗначения », смотри рисунок ниже.
Данная проблема тоже не является не преодолимой, если конечно о ней не забывать.
Конечно, лучше всего стараться как можно меньше вносить изменений в диалоги форм , например, создавать реквизиты и кнопки на форме программно.
Многие вообще рекомендуют не менять типовые формы, а создавать их копии с нашими доработками и делать их основными. Мне данный вариант не нравится потому, что если поставщик добавил что-то в диалоге форме - на моей форме это не появится и мне придется делать добавления вручную, а изменений поставщика может быть гораздо больше, чем наших.
Отдельное внимание хотелось бы уделить по процедурному обновлению форм (часть процедур беру из конфигурации поставщика, а часть нет - индивидуальная настройка). Рассмотрим, как при данном режиме происходит обновление диалога формы в отличие от режима « взять из конфигурации поставщика ».
Пример не имеет отношения к данному обновлению конфигурации, но показателен, поэтому рассмотрим его.
В справочник «Контрагенты » добавлено несколько реквизитов, и они помещены на форму элемента.
При обновлении конфигурации на новый релиз через поддержку будет предложено окно сравнения и объединения конфигурации, в котором можно сделать различные настройки. Сравним несколько вариантов:
1. Флаг обновления формы выставлен, но обновление сделано по процедурно , т.е. по факту выполнена индивидуальная настройка
Многие думают, что диалог формы должен взяться из конфигурации поставщика, а процедуры в зависимости от сделанных настроек. Посмотрим, насколько это так после выполнения объединения. Сделаем сравнение конфигурации поставщика с основной конфигурацией.
Очевидно, что на формах нарушились привязки и прочее, т.е. диалог формы не был полностью взят из конфигурации поставщика. В данном случае в диалоге формы остались наши объекты, с одной стороны это хорошо, с другой стороны, местоположение наших элементов на форме не всегда оптимально, особенно в связи с добавлением новых элементов поставщика, наблюдается изменение позиций обхода и нарушение привязок. В некоторых случаях легче вручную добавить наши элементы в диалог формы, чем делать исправления.
2. Флаг обновления формы выставлен, обновление сделано в режиме «Взять из новой конфигурации поставщика »
В данном случае диалог формы элемента полностью приводится в соответствие с диалогом формы элемента поставщика.
Вернемся к обновлению. С модулями объекта и модулями менеджера документов поступаем также как с общими модулями, обновляем их по процедурно. С формами документов поступаем аналогично тому, как поступали с формами справочников.
Отдельно нужно выделить работу с ролями. Не смотря на то, что в примере не требуется обновлять роли поговорить об этом стоит. Рассмотрим самый простой случай, когда в конфигурации поставщика содержится новый объект. В этом случае потребуется обновление роли « Полные права », но данная роль может содержать какие-то созданные нами объекты, например, справочники, документы и прочее.
Кажется, что с ролью «Полные права » все просто, объединяем их полностью, права на нетиповые объекты сохранятся в них все равно. Так и есть, права на нетиповые объекты никогда не пропадут, но у всех этих объектов будет включен флаг «Интерактивное удаление », что не всегда хорошо. При сравнении конфигураций старого релиза и подготовленной нового релиза это хорошо видно:
С остальными ролями поступаем аналогично тому, как мы работаем с модулями - если наших изменений больше, то не объединяем роль, после обновления добавляем в нее то, что добавил поставщик в новом релизе.
После того как проработали все дважды измененные объекты в окне обновления нажимаем «Выполнить
»
На вопрос о том, что измененные нами объекты будут загружены из новой конфигурации, отвечаем утвердительно.
В открывшемся окне «Настройка правил поддержки » проверяем, установленные флаги, хотя по умолчанию должны стоять правильно, нажимаем «ОК ».
По окончании процесса объединения сохраняем основную конфигурацию, конфигурацию базы данных пока не обновляем.
Теперь в конфигурацию for_ updating добавляем те минимальные доработки, которые не удалось правильно обновить штатными средствами.
Чтобы удобнее было проконтролировать выполнение данного процесса, в базе base запустим сравнение конфигурации поставщика и основной конфигурации старого релиза.
В базе for_updating сделаем тоже самое. Контролируем дважды измененные объекты, различий быть не должно.
После того как обновление в базе for_undating будет завершено обновляем конфигурацию базы данных и тестируем некоторые моменты, что именно хорошо бы протестировать станет понятно в процессе обновления, тут все индивидуально.
Обновление в рабочей базе желательно выполнять с помощью поддержки «Конфигурация» - «Поддержка» - «Обновить конфигурацию». При этом дважды измененные объекты будут загружены из нового релиза, т.е. наши изменения затрутся (конфигурацию не сохраняем!), но потом при объединении с подготовленной конфигурацией мы их восстанавливаем. После этого можно сохранить конфигурацию, обновить конфигурацию базы данных.
Обновлять конфигурацию сразу на несколько релизов весьма опасно. Дело в том, что после каждого обновления конфигурации запускается обновление информационных баз в режиме "1С:Предприятие". Поэтому если актуализировать только последний релиз, информационные базы могут не соответствовать последней конфигурации. В статье Дмитрий Рудаков, специалист компании ЗАО "Сибирская Аграрная Группа", делится личным опытом по единовременному обновлению конфигурации на 12 релизов.
Проверка режима изменения конфигурации
Представим себе такую ситуацию. Разработчики "Управления производственным предприятием" (далее - УПП) в релизе 1 (номера релизов здесь и далее присвоены условно) измерению (показателю) регистра расчета назначили тип "СправочникСсылка.ФизическоеЛицо" с наименованием "ФизЛицо". В релизе 2 они добавили еще одно измерение - "Сотрудник" с типом "СправочникСсылка.Сотрудники". При запуске "1С:Предприятие" включается обработка, которая заполняет измерение "Сотрудник", соответствующим измерению для "ФизЛица" образом. И потом в релизе 3 разработчики "1С" удалили измерение "ФизЛицо" и оставили только "Сотрудник". Если обновить конфигурацию с релиза 1 сразу до релиза 3, то можно очистить весь регистр расчета.
А если конфигурация стоит на поддержке с возможностью изменения, и в этой же базе данных формируется регламентированная отчетность, то необходимо обновлять конфигурацию на каждый релиз, что может быть очень дорого в человеко-часах. Например, обновление сильно измененной "УПП" на 1 релиз может занять 30 часов рабочего времени опытного специалиста.
Поэтому прежде чем приступать к обновлению, нужно определить: работаете вы в типовой конфигурации с возможностью изменения или в конфигурации без возможности изменения? Для этого зайдите в конфигуратор, где в меню выполните действия "Конфигурация - Поддержка - Настройка поддержки ".
Рис.1. Вызов окна настройки поддержки конфигурации
Если установлено "На поддержке" , то эта конфигурация типовая, а если "Включена возможность изменения" - конфигурация, скорее всего, изменена (по крайней мере, такая возможность заложена). Третье состояние - "Конфигурация снята с поддержки". Различные состояния конфигурации показаны на рисунках 2, 3, 4.
Рис. 2. Типовая конфигурация без возможности изменений
Рис. 3. Типовая конфигурация с включенной возможностью изменения
Рис. 4. Конфигурация, снятая с поддержки
Алгоритм обновления измененных конфигураций
Недавно передо мной встала задача обновления измененной конфигурации "Управление торговлей", релиз 10.3.13.2. Конфигурация была изменена в результате объединения с отраслевым решением "БИТ: Управление автосервисом 8" и непрерывно дорабатывалась в течение двух лет. Теперь конфигурацию нужно было обновить до релиза 10.3.25.1, то есть на 12 релизов. Я разбил всю процедуру обновления на несколько этапов.
Этап 1. Оценка стоимости и сроков процедуры обновления
Прежде чем приступать к самостоятельной работе, я решил получить независимую оценку специалистов в этой области. Единственная компания, располагающая возможностью обновления измененных конфигураций автоматизированными методами, это ООО "1С-ИжТиСи". Я обратился к специалистам этой компании с просьбой оценить стоимость обновления моей конфигурации. Для оценки времени и стоимости работ я предоставил текущую конфигурацию, нуждающуюся в обновлении. Через день я получил письмо с отчетом.
Отчет по итогам оценки стоимости и сроков проведения обновления конфигурации:
Конфигурация: Управление торговлей, редакция 10.3
Текущая версия конфигурации: 10.3.13.2
Обновление до версии: 10.3.25.1
Количество обновляемых модулей: 1 847
Количество контрольных релизов: 8
Результаты оценки меня удивили, поскольку на сайте компании была указана стоимость по акции - 1000 руб. за обновление на один релиз. Комментарий "1С-ИжТиСи":
"Стоимость обновления на каждый пропущенный релиз у нас не выше 2000 рублей. Сейчас проходит акция, поэтому стоимость не превышает 1000 руб. Но окончательная цена услуг определяется по результатам оценки трудозатрат на обновление и может быть ниже 1000 руб./релиз ".
Также я уточнил, каким образом были выбраны релизы, необходимые для обновления. В ответ на свой вопрос я получил скриншот, на котором это было наглядно продемонстрировано (рис. 5). В столбце "Номер версии" указана версия конфигурации, до которой необходимо обновиться. В столбце "Обновление версии" указано, с какого релиза возможно обновление. В результате оценки количество необходимых обновлений сократилось до 9.
Рис. 5. Выбор релизов, которые обязательно нужно использовать для корректного обновления конфигурации
После изучения отчета "1С-ИжТиСи" я подсчитал личные временные затраты на тот же самый объем работы. Каждая процедура обновления занимает у меня приблизительно 6 часов. Следовательно, общие временные затраты составляют 56 (9х6) рабочих часов, то есть приблизительно семь рабочих дней. Кроме того, существует вероятность, что после обновления выявятся какие-то недочеты: к примеру, пользователь пожалуется, что нужные для него изменения в конфигурации утеряны, и тогда временные затраты серьезно увеличатся. Между тем, специалисты компании "1С-ИжТиСи" предлагают проделать весь объем работы за три-четыре рабочих дня. Поэтому я решил воспользоваться их услугами.
Теперь кратко поясню, что именно было изменено в конфигурации.
Сильно измененные объекты. Это объекты, в которых изменено много типовых свойств. Корректировки имеют комплексный характер. Реквизиты объекта добавлены в табличную часть, выведены на форму объекта и на форму списка. Дописаны обработчики добавленных реквизитов в формах. Изменен типовой механизм проведения документа или записи набора движения для регистра.
Сильно измененные документы:
- "Заказ поставщику";
- "Перемещение товаров";
- "Требование-накладная";
- "Поступление товаров и услуг".
Сильно измененные регистры:
- "Партии товаров на складах";
- "Товары на складах".
Значительно измененные объекты. Объекты, в которых добавлены реквизиты, изменены либо формы объектов, либо модули объекта (как правило, проведение документа нетиповое).
- Документ "Приходный кассовый ордер";
- Регистр сведений "Комплектующие номенклатуры";
- Регистр сведений "Списанные товары";
- Общие модули.
Незначительно измененные объекты. В объектах изменены только формы и добавлены реквизиты.
Справочники:
- "Виды номенклатуры";
- "Договоры контрагентов";
- "Контрагенты";
- "Номенклатура";
- "Типы цен номенклатуры";
- "Ряд регистров сведений".
В разделе "Общие" изменены подписки на события, макеты, роли, общие модули. Почти все было изменено отраслевым решением.
Этап 2. Удаление конфиденциальной информации
Прежде чем предоставлять сотрудникам "1С-ИжТиСи" информационную базу для тестирования, в ней нужно удалить конфиденциальную информацию. Для таких случаев фирма "1С" рекомендует использовать обработку "Изменение конфиденциальной информации", которая не очень широко известна.
Обработка "Изменение конфиденциальной информации" предназначена для выборочного изменения или очистки информации в информационной базе. Обработку можно использовать для подготовки информационной базы перед передачей на тестирование, где необходимо скрыть (очистить, изменить) некоторую информацию.
Обработка ИзменениеКонфиденциальнойИнформации.epf есть на диске ИТС в каталоге 1CIts\EXE\EXTREPS\UNIREPS81\UpdatePrivateInformation. Также данную обработку можно скачать по ссылке: http://its.1c.ru/db/metod81#content:1644:1 .
Естественно, конфиденциальная информация в каждой компании разная, но обращаю ваше внимание на данные, которые, вероятнее всего, нужно изменить:
- Справочники: Физические лица, Контактные лица, Контактные лица контрагентов, Контрагенты, Типы цен.
- Регистры сведений: Паспортные данные физического лица, ФИОФизЛиц.
Ваш список, вероятно, будет шире, но это наиболее распространенные данные. Их изменение вряд ли повлияет на возможность тестирования вашей информационной базы. Также можно групповой обработкой удалить все те объекты, работа с которыми обслуживающей компанией не предполагается.
Этап 3. Получение результатов обновления
Через три дня мне предоставили cf-файлы и исчерпывающие инструкции по их установке. Для контрольных релизов предоставляются cf-файлы, которые нельзя использовать для работы пользователей, так как в них обновлены только метаданные. Они предназначены только для корректного обновления на последнюю версию.
По результату проведенной работы могу сказать, что все изменения в конфигурации были сохранены, при визуальном просмотре все объекты, которые были изменены, сохранили свои особенности и отличия от типовой конфигурации. В ходе эксплуатации никто из пользователей не сообщил, что какие-то изменения были утрачены.
В результате обновления я выделил две небольшие задачи для самостоятельного решения.
Первая. В силу того, что обновление проводится с использованием механизма "Сравнение, объединение", конфигурация БД действительно обновляется, и обновляется правильно, без технических рисков благодаря учету контрольных релизов. Однако не обновляется конфигурация поставщика. Разумеется, технически грамотный специалист без проблем дополнит данную работу, однако я попросил "1С-ИжТиСи" выслать более полную инструкцию по обновлению. В соответствии с ней, обновление сможет произвести даже неопытный специалист.
Вторая. В результате обновления все объекты остаются на поддержке с возможностью изменения, что тоже может быть косвенным недостатком. Если нужно воспользоваться этими услугами единовременно, тогда нужно все объекты снова ставить на поддержку. Сделать это у меня пока получается только перебором всех объектов метаданных. К сожалению, пока этот процесс выполняется вручную, но в будущем и он будет автоматизирован.
Кроме двух названных задач, был обнаружен один небольшой недочет, который, в принципе, не влияет на качество обновления и редко проявляется. В результате обновления строки кода исходной конфигурации и обновленной визуально совпадают, но в конце строк по каким-то причинам добавлены пробелы. Это является недостатком, так как несколько увеличивает объем измененного кода. И в случае дальнейшего ручного обновления было бы лучше не иметь таких участков кода. На рис. 6 приведен пример до обновления, а на рис. 7 - пример после обновления.
Конфигурация
, с точки зрения пользователя, это программное решение, заточенное под определенные бизнес-задачи. Например, есть конфигурация 1С:Управление торговлей, для автоматизации торговых операций. С точки зрения разработчика, бизнес-логика данного программного решения реализована с помощью конкретных объектов конфигурации - электронных форм ввода, отчетов, справочников, алгоритмов etc. Эти объекты сгруппированы в виде дерева конфигурации
:
Объекты конфигурации, купленной у какого-либо вендора, по умолчанию защищены от внесения изменений. Если функциональность такой конфигурации не закрывает каких-то бизнес-задач, то ее можно доработать - внести изменения в типовые объекты или добавить новые. Для этого типовую конфигурацию придется снять с поддержки - через меню Конфигурация -> Поддержка -> Настройка поддержки, Включить возможность изменения :
Далее можно будет внести доработки. Измененная конфигурация будет отличаться от типовой; оба варианта (основная конфигурация , измененная, и конфигурация поставщика , исходная типовая) будут храниться в базе данных, при необходимости их можно просмотреть и сравнить:
После внесения изменений, их нужно "спроецировать" на ту конфигурацию, в которой хранятся непосредственно бизнес-данные - на конфигурацию базы данных . Например, новый реквизит после добавления в основную конфигурацию не будет сразу доступен для пользователя, так как конфигурация базы данных еще не изменена. Для обновления конфигурации базы данных нажимаем F7; после обновления конфигурация базы данных становится равной основной конфигурации:
Подводя итог. В каждой базе данных 1С одномоментно существует три конфигурации: конфигурация поставщика, основная конфигурация и конфигурация базы данных. В типовом решении, без включенной возможности изменения, все три равны между собой.
Каждая конфигурация состоит из прикладных объектов, сгруппированных в дерево конфигурации по принципу схожести. Например, дерево объектов типа Документ:
Каждый из объектов конфигурации может нести в себе определенную логику, задаваемую алгоритмами ; алгоритмы прописываются в модулях программы с помощью встроенного языка 1С :
Число объектов конфигурации может быть очень велико; для их произвольной классификации по назначению используется механизм подсистем. Каждый объект конфигурации может быть включен в одну или несколько подсистем. Отбором пр подсистеме можно выбрать весь перечень объектов, имеющих отношение к данной прикладной задаче:
Вопрос 01.02 экзамена 1С:Профессионал по платформе. В каком объекте содержится редактируемая пользователем информация?
- Объект конфигурации
- Объект встроенного языка
- Объект информационной базы
- Верны ответы 1 и 3
- Верны все варианты
Вопрос 01.05 экзамена 1С:Профессионал по платформе. Выберите верный набор ассоциаций "Объект" - "тип файла":
- внешняя обработка -"epf", внешний отчет – "erf", конфигурация – "сf"
- внешняя обработка -"ert", внешний отчет – "mxl", конфигурация – "pfl"
- внешняя обработка -"ert", внешний отчет – " erf", конфигурация – "cfu"
- внешняя обработка -"epf", внешний отчет – "mxl", конфигурация – "cfu"
Правильный ответ первый. External processor file это расширение внешних обработок, External report file расширение внешних отчетов, Configuration file это расширение файла конфигурации.
Вопрос 01.21 экзамена 1С:Профессионал по платформе. Из чего состоит конфигурация?
- Объекты конфигурации
- Объекты встроенного языка
- Объекты информационной базы
- Верны ответы 1 и 3
- Верны все варианты
Вопрос 01.27 экзамена 1С:Профессионал по платформе. Какие объекты используются при описании алгоритма?
- Объекты конфигурации
- Объекты встроенного языка
- Объекты информационной базы
- Верны ответы 1 и 3
- Верны все варианты
Вопрос 01.34 экзамена 1С:Профессионал по платформе. Какую конфигурацию можно изменять интерактивно в конфигураторе?
- Основная конфигурация
- Конфигурация базы данных
- Конфигурация поставщика
- Внешние конфигурации
Вопрос 01.57 экзамена 1С:Профессионал по платформе. Произвольная классификация объектов конфигурации осуществляется с помощью …
- свойства Комментарий у объекта конфигурации
- создания реквизита "Классификация"
- с помощью объекта конфигурация Подсистемы
- верны варианты 1 и 2
- верны все варианты
Вопрос 01.63 экзамена 1С:Профессионал по платформе. Сколько информационных баз может быть с одной и той же конфигурацией?
- Только одна
- Только две (рабочая и демонстрационная)
- Неограниченно
- Определяется комплектом поставки прикладного решения
- Определяется в настройках конфигурации
Вопрос 01.64 экзамена 1С:Профессионал по платформе. Сколько конфигураций обязательно должно существовать в прикладном решении?
- Сколько угодно
Вопрос 03.13 экзамена 1С:Профессионал по платформе. В каком случае в окне конфигурации доступно изменение метаданных?
- Всегда
- Только для основной конфигурации
- Для основной конфигурации и конфигурации базы данных
- Для конфигурации поставщика
- Для конфигурации открытой из файла
