Обновление доработанных конфигураций 1С

Когда нужна эта услуга

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

Результат работы: согласованный релиз 1С с сохранёнными или адаптированными доработками и проверенными контрольными операциями. Сначала выполняем обновление на тестовой копии, затем — на рабочей базе в согласованное время.

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

Не каждое отличие — конфликт

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

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

Что именно считается доработкой

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

Если функциональность вынесена в расширения

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

С чего начинается работа

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

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

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

Как определяется итоговая конфигурация

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

Не все старые изменения нужно переносить

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

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

Почему сначала обновляется тестовая база

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

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

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

Безопасный переход на рабочей базе

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

Перед рабочим переходом проверяется актуальность резервной копии и согласовывается способ восстановления. Он зависит от файлового или клиент-серверного варианта, размера базы, СУБД и допустимого простоя. Универсальное обещание «сделаем выгрузку .dt и при необходимости вернём всё назад» было бы неверным. Если система резервирования требует отдельной настройки, доступна услуга резервного копирования баз 1С.

Как проверяется результат

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

Регрессионная проверка

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

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

Стоимость и предварительная оценка

4 500 ₽ за час работы специалиста. Это цена часа, а не фиксированная стоимость обновления любой изменённой базы. На объём влияют характер пересечений, сложность доработок, пропущенные релизы, расширения, интеграции и согласованный объём проверок. Количество отличий само по себе итоговую стоимость не определяет.

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

Что сообщить для оценки

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

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

Частые вопросы