29.11.2018 Игорь Борисенко 10872
Установка обновлений 1С. Планирование обновле...

Содержание:

1.       Обновление 1С: Инструкция и общая схема решения

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

3.       Результат оценки трудоемкости обновления

4.       Заключение


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

 
Установка обновлений 1С: Условия задачи

Рассмотрим планирование обновления и оценку его трудоемкости на следующем примере:


·         На базе типового релиза конфигурации, в нашем случае это обновление Управление торговлей 11.2.3.202

·         были внесены изменения «под заказчика» общим объемом 2000 чел./часов.

·         К моменту, когда созрела необходимость обновления, номер актуального типового релиза составлял 11.4.5.118.


Дополнительное условие:

·         Описания внесенных изменений (в объеме 2000 чел./час) нет (для управляемых форм это не критично, для обычных форм – критично). 




Пошаговая инструкция, как обновить версию 1С:

 

1.    Выделить и классифицировать изменения конфигурации


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


1.2. Выделить «новые» данные – дополнительные объекты метаданных, дополнительные реквизиты типовых объектов. Типовые релизы при обновлении их трогать не будут. Хотя контролировать их сохранность при переходе от релиза к релизу нужно. Поскольку в «следующем» типовом релизе могут появится объекты/реквизиты с «вашим» наименованием, и тогда они будут «затерты», т.е. потеряны.


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

 

2.    При движении по промежуточным релизам из цепочки обновлений:


2.1. Перед накатыванием очередного промежуточного типового релиза внести в него «изменения типовых данных».

2.2. Проверить, нет ли пересечений типовых данных и «новых данных».

2.3. Полученный промежуточный типовой релиз накатывать на рабочую базу.

 

3.    В финальный релиз:


3.1. Внести «изменения функционала».

3.2. Накатить полученный финальный релиз.

3.3. В результате получим обновленную работоспособную базу – «целевой измененный релиз». 


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


1.    Построить цепочку релизов обновления 1С:УТ и определить количество промежуточных обновлений.


Фирма «1С» и ее партнеры выпускают большое количество обновлений. Некоторые из них можно пропустить, а некоторые нельзя. Для построения цепочки обновлений можно воспользоваться, например, ресурсом «Грань IT».


В нашем случае:


Текущий релиз: 11.2.3.202

Целевой релиз: 11.4.5.118

Требуется выполнить 13 обновлений: 11.2.3.213, 11.2.3.242, 11.3.2.193, 11.3.2.218, 11.3.3.163, 11.3.3.196, 11.3.3.231, 11.3.4.67, 11.3.4.112, 11.3.4.153, 11.3.4.221, 11.3.4.228, 11.4.5.118


2.    Определить необходимость обновления платформы.


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


Текущий релиз платформы:    8.3.12.1616

Требуемый релиз платформы: 8.3.12.1469 (и выше)

Следовательно, нам требуется обновить платформу 1С.


3.    Выделить и классифицировать изменения конфигурации.


3.1. Что ищем (см. раздел «Общая схема решения»)

3.1.1. Изменения типовых данных (прил.1)

3.1.2. Новые данные

3.1.3. Изменения функционала (прил.2)


3.2. Где ищем изменения

3.2.1. В метаданных основной конфигурации

3.2.2. В расширениях конфигурации

3.2.3. Во внешних печатных формах/отчетах/обработках

3.2.4. В типовых печатных формах

 

4.    Оценить трудоемкость обновления.


4.1. Трудоемкость переноса настроек (функционала) в финальный релиз конфигурации

Здесь поможет встроенный механизм «сравнения конфигураций», который выдает описание изменений (прил.2), трудоемкость переноса которых уже можно оценить. Особо нужно отметить изменения в формах: если для управляемых форм механизм «сравнения конфигураций» выдаст описание, то для обычных форм – нет. И эти изменения придется выбирать вручную.


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

4.2.1. Оценить время одного промежуточного обновления. Для этого можно провести тестовый замер на одном переходе.

4.2.2. Учесть количество промежуточных обновлений (п.1)

4.2.3. Учесть количество изменений редакции, такие переходы, как правило, более продолжительны по времени. В нашем примере два изменения редакции: 2.2 à 2.3 и 2.3 à 2.4.


4.3. Трудоемкость адаптации расширений конфигурации

Здесь сложно дать какие-то формализованные рекомендации по оценке. Нужно анализировать код и понять, насколько он независим от типовых настроек. Косвенно можно оценить по объему объектов и строк программного кода в расширениях.


4.4. Трудоемкость адаптации внешних печатных форм/отчетов/обработок

Ситуация с оценкой здесь схожа с расширениями.


4.5. Трудоемкость тестирования и отладки

4.5.1. Построение Чек-листов для тестов

4.5.2. Проведение проверок

4.5.3. Проведение отладки

 

5.    Построение календарного план-графика обновлений.


Здесь важно совместить необходимость вывода базы из эксплуатации на время обновления (п.4.2) и сохранение работоспособности предприятия. В нашем примере для наложения всех обновлений необходимо было вывести рабочую базу из эксплуатации на 18 час. Если такой интервал не приемлем, тогда обновление следует разбивать на несколько частей и, соответственно, готовить несколько промежуточных работоспособных релизов – переносить в них нетиповой функционал. Например, в нашем случае делим обновление на два этапа по 9 часов: первая ночь обновления (9 час.) – днем база работает – вторая ночь обновления (9 час.) – днем и далее база работает.

 

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


6.1. Адаптация расширений

6.2. Адаптация внешних печатных форм/отчетов/обработок

 

7.    Тестовое обновление (на копии БД)


7.1. Обновление платформы 1С до требуемого релиза (см.п.2)

7.2. Промежуточные обновления

7.3. Финальное обновление

 

8.    Тестирование обновленного релиза на копии БД, отладка

 

9.    Обновление рабочей БД


9.1. Промежуточные обновления

9.2. Финальное обновление 

 

3.    Результат оценки трудоемкости обновления


 


4.    Заключение


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


Трудоемкость подготовки такой оценки составила 20 час.


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


Напомню, что обновлялась конфигурация, в которую внесено изменений на 2000 час. Трудоемкость ее обновления составила порядка 200 час., т.е. соотношение примерно 1/10. Пожалуй, такое соотношение близко к максимальному. Факторы, которые помогут снизить сложность обновлений:


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


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


·         Документировать вносимые изменения с обязательным указанием целей этих изменений.


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


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


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


В обоих этих случаях требуется понимание «а зачем эти изменения были внесены».

 

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

 

Приложение 1

Пример описания изменения типовых данных для переноса в промежуточных обновлениях


1.     Справочник.Номенклатура.Реквизит.ОбъемЧислитель                         Число(15,4)

2.     Справочник.Производители.ДлинаКода                                             Длина кода = 11

3.     Документ.ПередачаТоваровМеждуОрганизациями

3.1.   ЦенаВключаетНДС                                                                  Истина

3.2.   ПередачаПодДеятельность                                                     ПеречислениеСсылка.ТипыНалогообложенияНДС.ПродажаОблагаетсяНДС

4.     Документ.РасходныйКассовыйОрдер.Реквизит.ДокументОснование

4.1.   Доб.тип. ДокументСсылка.Инагро_ЗатратыТС

5.     РегистрСведений.ТоварыКДоставке.Измерение.Накладная

6.    РегистрСведений.ШтрихкодыНоменклатуры.Измерение.УникальныйИдентификаторЗаписи


Приложение 2

Пример описания изменений конфигурации и оценки трудоемкости их переноса


 

 

Специалист компании ООО «Кодерлайн»

Игорь Борисенко.

Наши проекты

ООО «Еврорадиаторы»
ООО «Еврорадиаторы»

Отрасль:
1С:ERP 2.4

Внедренное типовое решение:

Специалисты «Кодерлайн» помогли перенести базу из текущей системы «1С:ERP 2.2» в новую систему «1С:ERP 2.4». ...

Фармацевтическое предприятие «Оболенское»
АО «Фармацевтическое предприятие «Оболенское»

Отрасль:
Фармацевтическая промышленность

Внедренное типовое решение:
1С:Управление производственным предприятием

- Адаптации блоков/подсистем планирования продаж, закупок и казначейства. ...

Внедрение «1С:Зарплата и управление персоналом 8 КОРП» в компании «ПБК»
ООО «Партнер Бухгалтер Консультант»

Отрасль:
Бухгалтерские услуги

Внедренное типовое решение:
1С:Зарплата и управление персоналом

- Интеграция продукта с базой данных оперативного учета Axapta;
- Доработка функционала подсистемы...

Автоматизации бизнес-процессов учета и планирования на базе «1С:ERP Управление предприятием 2.0»
ООО «Буровая сервисная компания «ГРАНД»

Отрасль:
Нефтесервис

Внедренное типовое решение:
1С:ERP Управление предприятием 2.0

- Создание полноценной управленческой системы взамен существующих
- Внедрением подсистем «Нормативное планирования», «Мобильное АРМ», «Ре...

ООО «Стейдж Энтертейнмент Россия»
ООО «Стейдж Энтертейнмент Россия»

Отрасль:
Театральная деятельность

Внедренное типовое решение:
Платформа 1С:Предприятие 8

Реализован процесс трансформации данных бухгалтерского учета по РСБУ в данные международного учета (ГААП) на платформе «1С:Предприятие 8»:...

ФГУП «Почта России»
ФГУП «Почта России»

Отрасль:
Почта, доставка

Внедренное типовое решение:
1С:Зарплата и управление персоналом

- Бухгалтерский учет
- Расчет зарплаты и кадровый учет
- Налоговый учет ...

Установка программного продукта БИТ.Финанс для 1С:Бухгалтерия 8
ООО «Джи Эй Си Шиппинг энд Лоджистикс»

Отрасль:
Транспорт

Внедренное типовое решение:
БИТ.Финанс

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

ООО "ОМЗ"
ООО "ОМЗ"

Отрасль:
Металлургическая промышленность, металлообработка

Внедренное типовое решение:
1С:Управление производственным предприятием

Автоматизация бизнес-процессов...

Внедрение системы финансового учета БИТ:Финанс
ООО «Алькор и Ко» (Л’Этуаль)

Отрасль:
Торговля

Внедренное типовое решение:
БИТ.Финанс

- Финансовый учет;
- Поддержка проекта внедрения МСФО;
- Регламентные работы по обслуживанию сервера MS SQL;
- Оптимизация производ...

ООО «ПКП КАБЭЛЕКТРОСНАБ»
ООО «ПКП КАБЭЛЕКТРОСНАБ»

Отрасль:
Производство кабельной продукции

Внедренное типовое решение:
1С:Управление небольшой фирмой 1.6

- Оформление заказов покупателей;
- Управление складскими запасами;
- Анализ запасов/остатков...

Автоматизация документооборота в компании ООО "Ликард"
ООО «Ликард» (ОАО ЛУКОЙЛ)

Отрасль:
Нефтесервис

Внедренное типовое решение:
1С:Документооборот КОРП

- Отказ от бумажного документооборота, от громоздких систем на базе офисного пакета;
- Создан единообразный интерфейс как в офисе, так и...

Внедрение блока расчета себестоимости РАУЗ в 1С:УПП 8
ООО «Пелигрин Матен»

Отрасль:
Производство

Внедренное типовое решение:
1С:Управление производственным предприятием

– Оформление заказов покупателей;
– Взаиморасчеты с покупателями;
– Оформление заказов поставщикам;
– Управление отношениями с ...

Наши соц. сети

Telegram-канал «Koderline 1С» Группа в Вконтакте «Кодерлайн КОРП» Rutube

Остались вопросы - обратитесь к нам!

Впишите свои Имя и Телефон, чтобы мы ответили на все интересующие Вас вопросы.
ФИО*
E-mail*
Телефон*
Сообщение