← На главную

Переход со старых версий программ на современную платформу нередко сопровождается техническими трудностями. При переносе данных из информационной базы «1С:Бухгалтерия 7.7» в «1С:Бухгалтерию предприятия 3.0» специалисты часто сталкиваются со сбоями COM-соединения, ошибками обработчиков конвертации данных, несоответствием структур метаданных и частичной потерей информации. Проанализируем типичные причины возникновения этих ошибок и разберем по шагам надежные варианты решения проблемы.

Причина 1. Ошибка COM-соединения 0x800401F3 «Недопустимая строка с указанием класса»

При попытке выполнить загрузку напрямую из информационной базы 7.7 система «1С:Предприятие 8» может выдать исключение вида: Ошибка при вызове конструктора (COMObject): -2147221005(0x800401F3): Недопустимая строка с указанием класса. Выясним причину такого поведения.

Платформа «1С:Предприятие 7.7» является исключительно 32-разрядным приложением (x86) и регистрирует в операционной системе 32-битный COM-сервер с идентификатором V77.Application или V77S.Application. Если целевая база «1С:Бухгалтерия 8.3» запущена в 64-разрядном клиенте (1cv8c.exe x64) или процедура выполняется в фоновом задании на 64-разрядном сервере «1С:Предприятия», 64-битный процесс не может напрямую взаимодействовать с 32-битным COM-сервером.

Для исправления ситуации выполним следующие действия:

1. Проверим регистрацию COM-сервера 7.7 в Windows. Если платформа 7.7 копировалась вручную или разворачивалась без полноценного дистрибутива, зарегистрируем библиотеки заново. Запустим командную строку Windows от имени Администратора и выполним команду регистрации: "C:\Program Files (x86)\1Cv77\BIN\1cv7.exe" /regserver
2. Используем 32-разрядный клиент «1С:Предприятия 8». Запустим «1С:Бухгалтерию 8.3» строго через 32-битный толстый или тонкий клиент. При клиент-серверном варианте базы операцию переноса рекомендуется выполнять в локальной файловой копии, чтобы исключить инициализацию серверных 64-разрядных процессов.
3. Откажемся от прямого COM-соединения. Наиболее стабильным решением является перенос через промежуточный внешний XML-файл: сначала выполняется штатная выгрузка из базы 7.7 в файл данных, а затем загрузка этого файла в базу 8.3.

Причина 2. Рассинхронизация файлов правил и названий метаданных

При переносе через файл нередко возникают ошибки вида Тип не определен (РегистрСведенийЗапись...), Поле объекта не обнаружено или Преобразование значения к типу Число не может быть выполнено. Причина кроется в использовании устаревших правил конвертации данных (обычно файл имеет название Acc77_80.xml), встроенных в старый релиз базы 7.7.

Конфигурация «Бухгалтерия предприятия 3.0» постоянно развивается, состав и типы реквизитов ее регистров и справочников меняются от релиза к релизу. Если использовать правила конвертации, входящие в поставку конфигурации-источника, они могут содержать ссылки на удаленные или переименованные объекты конфигурации-приемника.

Разберем, как получить актуальные правила обмена непосредственно из базы «1С:Бухгалтерия 8.3»:

1. Откроем «1С:Бухгалтерию 8.3» и перейдем в раздел Справочники и настройки учета (или Администрирование, в зависимости от версии интерфейса).
2. Найдем пункт Перенос данных из 1С:Предприятия 7.7.
3. На открывшейся форме нажмем кнопку Сохранить правила переноса и запишем актуальный XML-файл правил на диск.
4. В базе 7.7 при запуске обработки выгрузки укажем сохраненный актуальный файл правил конвертации вместо стандартного, после чего сформируем файл данных повторно.

Если в процессе выгрузки в 7.7 появляется ошибка Значение не представляет агрегатный объект (Код), это свидетельствует о нарушении ссылочной целостности базы-источника (наличие «битых» ссылок или пустых субконто, к реквизитам которых алгоритм правила обращается напрямую). В таком случае перед повторной выгрузкой обязательно выполним в Конфигураторе 7.7 полное Тестирование и исправление информационной базы с проверкой физической целостности и пересчетом итогов.

Причина 3. Перенос только части объектов (свертка и транзакции)

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

1. Откат единой транзакции при ошибке проведения. Если в обработке обмена включен режим загрузки в рамках одной транзакции, то любая ошибка при автоматическом проведении документа вызывает откат всей операции. В базе остаются только объекты нормативно-справочной информации, записанные до старта транзакции документов. Для предотвращения этого отключим автоматическое проведение документов при загрузке или снимем флаг единой транзакции, чтобы документы проводились отдельно после успешного импорта.
2. Логика типовых правил. Типовые правила миграции ориентированы не на сплошной перенос всей исторической первичной документации за прошлые годы, а на ввод начальных остатков на выбранную дату (например, на начало года). При этом из справочников переносятся только те элементы, по которым имеются актуальные остатки или обороты в выбранном периоде.

Рекомендуемый обходной путь: двухэтапная миграция (7.7 -> БП 2.0 -> БП 3.0)

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

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

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