← На главную

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

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

Метод 1: Использование механизма РИБ (Распределенной Информационной Базы)

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

Пошаговый план действий:

1. В исходной базе БП 2.0 настроим новый узел РИБ. При настройке укажем фильтр по необходимой нам организации.
2. Выполним начальную выгрузку данных в подчиненный узел. Система автоматически отберет документы, справочники и регистры, относящиеся к выбранному юрлицу.
3. После создания и успешного открытия подчиненной базы, нам необходимо «отвязать» её от главного узла, чтобы она стала самостоятельной. Это делается с помощью специальной обработки или через параметры запуска /ResetMasterNode.
4. Полученную самостоятельную базу БП 2.0, в которой остались данные только по одной организации, обновляем стандартным способом до актуального релиза БП 3.0.

Проанализируем нюансы этого метода: Несмотря на надежность, в базе могут остаться «общие» справочники (например, Валюты, СтатьиЗатрат, Номенклатура), которые не имеют жесткой привязки к организации. Рассмотрим подробнее, как с этим бороться: после миграции рекомендуется запустить стандартную обработку Поиск и замена дублей и выполнить удаление помеченных объектов, чтобы очистить базу от неиспользуемых элементов.

Метод 2: Свертка информационной базы перед переходом

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

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

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

Такую базу обновить до БП 3.0 гораздо проще и быстрее, так как объем обрабатываемых таблиц при реструктуризации будет в разы меньше.

Метод 3: Использование универсального обмена и «Конвертации данных»

Рассмотрим более сложный, но гибкий вариант — использование правил обмена. Главная проблема обычного XML-переноса через Универсальный обмен данными заключается в различии структур метаданных 2.0 и 3.0. Прямой перенос «объект в объект» не сработает.

Для реализации этого метода нам понадобится конфигурация Конвертация данных 2.1. Выясним алгоритм работы:

1. Найдем в составе дистрибутива обновления БП 3.0 файл BP20_30.xml. Это официальные правила перехода, подготовленные разработчиками 1С.
2. Загрузим эти правила в Конвертацию данных.
3. Добавим в правила выгрузки параметр Организация.
4. В каждом правиле выгрузки объектов (ПКО/ПВД) пропишем условие проверки:
   Скопировать код

   
   Если Объект.Организация <> Параметры.НужнаяОрганизация Тогда
       Отказ = Истина;
   КонецЕсли;
   

5. Выгрузим данные из БП 2.0 с применением этих правил и загрузим их в чистую БП 3.0.

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

Метод 4: Прямой перенос через COM-соединение

Разберем ситуацию, когда нам нужно избежать промежуточных XML-файлов. Существуют специализированные обработки (в том числе коммерческие), которые подключаются из базы-приемника (3.0) к базе-источнику (2.0) через COM-соединение.

Преимущества этого подхода:

• Сопоставление на лету: мы можем искать контрагентов по ИНН и КПП, а не по внутренним идентификаторам (UUID), что предотвращает дублирование данных.
• Контроль проведения: можно сразу при загрузке пытаться проводить документы и видеть ошибки в реальном времени.
• Перенос движений: некоторые обработки позволяют переносить документы вместе с их проводками (движениями по регистрам), что избавляет от необходимости перепроводить документы в новой базе, где алгоритмы расчета себестоимости или налогов могут отличаться.

Важные аспекты после завершения миграции

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

1. Настройки учетной политики. Данные в регистрах сведений УчетнаяПолититка и НалогиИОтчеты часто не переносятся корректно при выборочной миграции. Обязательно проверьте параметры налогообложения (УСН/ОСНО), настройки ФСБУ и методы оценки ТМЦ в новой базе.

2. Ссылочная целостность. Проанализируем ситуацию с «битыми» ссылками. Если вы перенесли Реализацию, но не перенесли Счет-фактуру, в документе может остаться ссылка на несуществующий объект (Объект не найден). Используйте скрипты или типовые обработки по проверке ссылочной целостности.

3. Сверка остатков. Это обязательный этап. Сформируйте Оборотно-сальдовую ведомость в обеих базах на дату перехода. Особое внимание уделите взаиморасчетам (счета 60, 62) и остаткам на складах (счет 10, 41). Любое расхождение в копейках может свидетельствовать о том, что не все регистры сведений были перенесены правильно.

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