Многие компании сталкиваются с ситуацией, когда весь учет ведется в старой, сильно дописанной конфигурации «1С:Бухгалтерия предприятия» редакции 2.0 (БП 2.0). В базе могут быть добавлены новые поля в накладные, реализована сложная загрузка из Excel, изменены печатные формы. При этом встает острая необходимость перехода на «1С:Бухгалтерию предприятия» редакции 3.0 (БП 3.0). Рассмотрим подробнее, как организовать процесс миграции, если стандартные механизмы перехода вызывают опасения из-за большого количества нетиповых доработок.
Когда разработчик или системный администратор планирует переход с нетиповой двойки на тройку, обычно рассматриваются следующие сценарии:
Разберем по шагам каждый из этих вариантов, выясним их плюсы, минусы и скрытые риски.
Прежде чем выбирать технический инструмент, проанализируем текущую ситуацию с поддержкой старых конфигураций. Идея «оттянуть агонию» за счет перехода с версии ПРОФ на КОРП уже не актуальна.
Фирма «1С» полностью и окончательно прекратила поддержку «Бухгалтерии предприятия 2.0» версии ПРОФ в апреле 2022 года. Ограниченная поддержка версии КОРП также официально завершилась 1 апреля 2024 года. Это значит, что любая дальнейшая работа в БП 2.0 сопряжена с критическими рисками: вы больше не получите обновлений регламентированных форм отчетности, новых ставок налогов и изменений в законодательстве. Работать в двойке и сдавать из нее отчетность невозможно.
Сценарий, при котором пользователи продолжают работать в старой нетиповой БП 2.0, а программист раз в квартал переносит документы (поступления, реализации, счета-фактуры, ПКО, РКО, выписки) в типовую БП 3.0, несет в себе огромные методологические риски.
Механизмы проведения документов, структура регистров и реализация учетной политики в старой (Обычные формы) и новой (Управляемые формы) редакциях кардинально различаются. Посмотрим на возможные проблемы:
Именно поэтому от поддержки регулярного обмена между поколениями конфигураций следует решительно отказаться. Наша цель — разовый перенос.
Официальная методика перехода, которую предлагает разработчик платформы, — это последовательное обновление конфигурации. Однако на практике для баз с большим количеством внедренного кода этот метод работает плохо.
Главная техническая проблема кроется в рассинхронизации внутренних идентификаторов объектов метаданных. Если вы принудительно обновите сильно измененную БП 2.0 (где снимали конфигурацию с поддержки и добавляли объекты в основное дерево), процесс станет необратимым. В будущем, при каждом выходе нового релиза БП 3.0, вы будете сталкиваться с жесткими конфликтами при сравнении и объединении конфигураций. Это потребует постоянного вмешательства квалифицированного программиста.
Поэтому эксперты настаивают на «чистом» переходе: разворачивании абсолютно пустой типовой конфигурации БП 3.0 и разовом переносе в нее накопленных данных.
Если мы отказались от обновления конфигурации, нам необходимо перенести справочники, остатки по счетам и, при необходимости, документы за текущий год в новую базу. Рассмотрим варианты реализации:
УниверсальныйОбменДаннымиВФорматеXML.Готовые правила, как правило, уже умеют корректно сворачивать остатки на начало года и переносить документы за выбранный период. Их покупка обойдется значительно дешевле, чем оплата десятков часов работы программиста для написания обмена с нуля.
Современный стандарт разработки диктует новые правила работы с нетиповыми базами. Идеальный путь миграции выглядит следующим образом:
Реализуя доработки через Расширения, мы решаем самую главную проблему обновлений. База остается типовой. Когда выйдет новый релиз законодательства, системный администратор или даже бухгалтер сможет обновить программу в автоматическом режиме без вызова программиста. Расширение будет применяться поверх типовой конфигурации динамически.
Подводя итоги, скажем: не пытайтесь настроить постоянную синхронизацию между поколениями программ и не обновляйте «в лоб» сильно измененные конфигурации. Инвестируйте время в адаптацию ваших доработок под механизм Расширений и выполните чистый разовый перенос данных. Это сэкономит бизнесу огромные ресурсы на дальнейшее обслуживание и поддержку учетной системы.