← На главную

В процессе эксплуатации учетных систем на платформе 1С предприятия часто сталкиваются с ситуацией, когда конфигурация не обновлялась годами и при этом содержит множество доработок под специфику бизнеса. При попытке подключить современные внешние сервисы (например, мобильную торговлю «Агент Плюс», сервисы маркировки или интеграцию с банками) техподдержка требует актуализировать релиз программы. Рассмотрим, действительно ли невозможно обновить измененную базу, как обнаружить все ранее внесенные доработки и чем отличается штатное обновление внутри редакции 10.3 от перехода на редакцию 11.

Можно ли обновить доработанную базу 1С без потери функционала

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

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

1. Исходную типовую конфигурацию старого релиза (на котором строились доработки).
2. Текущую рабочую конфигурацию с накопленными доработками.
3. Новую типовую конфигурацию целевого релиза.

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

Как выявить все доработки в старой базе данных

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

1. Создаем резервную копию рабочей информационной базы через выгрузку в .dt или средствами СУБД (MSSQL/PostgreSQL).
2. Определяем точный номер текущего релиза в окне «О программе» (например, Управление торговлей 10.3.13.2).
3. Находим чистый файл конфигурации поставщика (.cf) именно этого исходного релиза.
4. Выполняем сравнение в режиме «Конфигуратор»: выбираем меню Конфигурация — Сравнить, объединить с конфигурацией из файла и указываем чистый типовой .cf.
5. Анализируем дерево расхождений: платформа покажет все добавленные метаданные, измененные формы, новые процедуры в модулях объектов и общих модулях. Отчет о сравнении можно сохранить в текстовый документ для составления реестра доработок.

Пошаговый регламент обновления через большой разрыв релизов

Если разрыв между текущей версией (например, 10.3.13.2) и целевой (10.3.43.1) составляет десятки релизов, прямое объединение в один шаг может привести к нарушению логики работы базы. Разберем правильный алгоритм действий:

1. Работа исключительно на копии: никогда не выполняем первичное обновление на рабочей базе. Все действия отрабатываются на тестовом контуре.
2. Прохождение узловых релизов: в процессе развития конфигурации 1С изменяет структуры регистров и добавляет служебные обработчики данных (в модулях ОбновлениеИнформационнойБазы). Если пропустить ключевые переходные релизы, регламентные процедуры заполнения новых реквизитов не отработают. Обновление выполняется последовательно через контрольные релизы, указанные в файлах поставки UpdInfo.txt.
3. Перенос кода и разрешение конфликтов: при объединении с новым релизом особое внимание уделяется модулям документов и общим модулям расчета (партионный учет, проведение по регистрам взаиморасчетов и НДС).
4. Запуск в режиме «Предприятие» и контроль обработчиков: после каждого этапа конфигурация запускается в пользовательском режиме для выполнения процедур начального заполнения и реструктуризации данных.
5. Тестирование бизнес-процессов: проверяется проведение ключевых документов (заказы, реализации, поступления, кассовые и банковские ордера), печатные формы и выгрузки.

Альтернативное решение: доработка внешнего модуля интеграции

Если цель обновления сводится исключительно к восстановлению обмена с внешней системой (в данном случае с «Агент Плюс»), обновление всей конфигурации «Управление торговлей» может быть экономически нецелесообразным. Проанализируем архитектуру интеграции:

Модуль обмена «Агент Плюс» для обычных форм представляет собой внешнюю обработку (.epf) либо отдельную изолированную подсистему. Вместо рискованного обновления всей учетной базы программист может:

1. Взять свежую версию модуля обмена от разработчиков «Агент Плюс».
2. Адаптировать алгоритмы чтения/записи данных этой обработки под структуру метаданных старой конфигурации 10.3.13.2.
3. Скорректировать форматы выгружаемых XML/JSON-пакетов под требования актуального мобильного приложения.

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

Чем отличается переход на «Управление торговлей 11» от обновления

Часто переход на 11-ю версию ошибочно воспринимают как «обновление оболочки платформы». Разберем принципиальную разницу:

1. Разные программные продукты: УТ 10.3 и УТ 11 — это две совершенно разные конфигурации с несовместимой архитектурой. УТ 10.3 работает на обычных формах с классическим партионным учетом, а УТ 11 построена на библиотеке стандартных подсистем (БСП), управляемых формах и совершенно других алгоритмах расчета себестоимости и резервирования.
2. Невозможность обновления структуры: накатить УТ 11 поверх УТ 10.3 кнопкой обновления нельзя. Переход осуществляется исключительно как внедрение нового программного продукта: переносятся нормативно-справочная информация (справочники) и остатки на определенную дату с помощью правил конвертации данных.
3. Потеря всех доработок: весь программный код, написанный для УТ 10.3, неприменим в УТ 11 из-за различий в клиент-серверной модели (директивы &НаКлиенте, &НаСервере) и объектной модели метаданных. Нетиповой функционал придется разрабатывать с нуля.

Как сохранить доработки при будущих обновлениях

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

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