Перенос данных — одна из тех задач, которые кажутся простыми ровно до момента, когда берёшься за дело. «Ну что там, выгрузить-загрузить» — а потом три недели разбираешься с дублями контрагентов, битыми ссылками и расхождением остатков на 4 копейки, которые не дают закрыть период. Мы переносили данные между конфигурациями 1С десятки раз. Рассказываем, как это делать системно.
Когда возникает задача переноса
Типичные сценарии:
- Смена конфигурации: переход с 1С:УПП на 1С:ERP, с 1С:Бухгалтерии 2.0 на 3.0, с отраслевого решения на типовое
- Слияние баз: две компании объединяются, нужно свести данные из двух баз 1С в одну
- Разделение баз: компания выделяет подразделение, ему нужна своя база с историей
- Миграция с другой системы: данные из Excel, SAP, «самописной» базы Access нужно загрузить в 1С
Каждый сценарий имеет свою специфику, но базовый алгоритм один. Разница — в деталях маппинга и объёме подготовительной работы.
Три подхода: выбор метода переноса
Прежде чем писать код — нужно выбрать инструмент. Три основных подхода, у каждого свои границы применимости.
Правила обмена (Конвертация данных 2 / 3)
Стандартный инструмент экосистемы 1С. Визуальный конструктор, где настраиваешь соответствие объектов источника и приёмника: справочник «Номенклатура» в УПП → справочник «Номенклатура» в ERP, с маппингом реквизитов. Конвертация данных умеет обрабатывать коллизии, вести протокол, работать порциями.
Плюс — это стандарт: для типовых конфигураций правила обмена уже написаны фирмой «1С». Минус — скорость. На справочнике в 500 000 номенклатурных позиций обмен через XML может занять 8-12 часов. И отладка: когда правило не работает, найти ошибку в дереве настроек — квест.
Когда использовать: перенос между типовыми конфигурациями 1С, объём до 500 000 записей, нужна стандартизация процесса.
Прямой доступ: SQL или COM-соединение
Для больших объёмов. Читаем данные из базы-источника напрямую (через COM-соединение к 1С или SQL-запросами к СУБД), трансформируем и записываем в базу-приёмник. Полный контроль, максимальная скорость, пакетная обработка.
Минус — нужно знать внутреннюю структуру обеих баз. Имена таблиц в SQL не совпадают с именами объектов в 1С. Прямая запись в SQL мимо платформы — риск нарушить ссылочную целостность, не записать движения по регистрам, получить «битую» базу.
Когда использовать: объём больше 1 миллиона записей, нестандартные конфигурации, нужна скорость, есть разработчик с опытом работы с SQL.
Универсальный обмен XML (EnterpriseData)
Формат EnterpriseData — стандартизированный XML для обмена между конфигурациями 1С. Проще в настройке, чем Конвертация данных, но менее гибкий. Подходит для типовых сценариев: выгрузка справочников, перенос документов стандартных типов.
Когда использовать: небольшие объёмы (до 100 000 записей), типовые конфигурации, нужна простая регулярная синхронизация.
Пошаговый план переноса
Этап 1. Аудит источника (1-2 дня)
Прежде чем переносить — нужно понять, что переносим. Не «всё», а конкретный перечень объектов. Запрашиваем у заказчика: какие справочники нужны? За какой период документы? Нужны ли движения по регистрам или достаточно документов?
Параллельно — аудит качества данных. В каждой второй базе, которую мы видели, есть:
- Дубли контрагентов (одна компания — 3-5 карточек с разным написанием названия)
- «Мусорные» элементы справочников (тестовые, удалённые но не удалённые, пустые)
- Документы без движений (проведённые, но с пустыми табличными частями)
- Битые ссылки (документ ссылается на элемент справочника, который удалён)
Всё это нужно вычистить до переноса, не после. Мусор из старой базы не должен попасть в новую.
Этап 2. Маппинг (2-3 дня)
Составляем таблицу соответствий: каждый объект источника → объект приёмника. Каждый реквизит → реквизит. Каждое перечисление → перечисление.
Кажется формальностью, но именно здесь живут 80% будущих проблем. Примеры:
- В УПП «Контрагент» — один справочник. В ERP — «Контрагенты» и «Партнёры». Куда переносить? Какую связь создать?
- В старой базе тип номенклатуры — строковый реквизит «Товар/Услуга/Работа». В новой — перечисление с другим набором значений
- Единицы измерения: в источнике — «шт», «шт.», «штука», «ШТ». В приёмнике — один классификатор ОКЕИ
Для каждого такого случая — правило конвертации. Для неоднозначных — значение по умолчанию и пометка «требует ручной проверки».
Этап 3. Тестовый перенос (3-5 дней)
Самый важный этап. Полный перенос на копию базы-приёмника. Не «выборочно 100 записей», а полностью. Потому что проблемы вылезают на объёме: 100 записей переносятся идеально, а на 100 000 — выясняется, что у 47 контрагентов одинаковый ИНН, и уникальный индекс в приёмнике не даёт записать.
После тестового переноса — сверка:
- Количество записей по каждому справочнику (источник vs приёмник)
- Остатки по регистрам на контрольную дату
- Выборочная проверка 20-30 документов: реквизиты, табличные части, движения
- Формирование регламентированного отчёта (оборотно-сальдовая ведомость) — итоги должны совпадать
Расхождения будут. Всегда. Задача — выявить их все на тестовом прогоне, а не в продуктиве.
Этап 4. Донастройка (2-3 дня)
По результатам тестового переноса — исправляем правила маппинга, добавляем обработку исключений, исправляем данные в источнике (если проще починить там, чем добавлять правило конвертации).
Обязательно — повторный тестовый прогон. Минимум два полных тестовых переноса до продуктивного. На практике — три-четыре. Каждый выявляет новые edge cases.
Этап 5. Продуктивный перенос (1 день)
День Х. Последовательность действий:
- Блокировка базы-источника для пользователей (фиксируем состояние)
- Финальная выгрузка данных
- Загрузка в продуктивную базу-приёмник
- Контрольная сверка: остатки, ОСВ, ключевые документы
- Открытие доступа пользователям к новой базе
Критично: весь процесс должен уложиться в нерабочее время. Для крупных баз (миллионы записей) — в выходные. Нельзя допустить ситуацию, когда пользователи работают в старой базе, пока данные переносятся: появятся расхождения.
Типичные ошибки (из нашей практики)
Ошибка 1: «Перенесём всё, потом разберёмся». Нет. Переносить нужно только то, что реально нужно в новой базе. Историю за 2008 год, тестовые контрагенты, удалённые номенклатурные позиции — оставить в старой базе. Архив — в архиве.
Ошибка 2: Не учесть нумерацию. Две базы с пересекающимися номерами документов. После слияния — два документа «ПКО-000125» с разными данными. Решение: добавить префикс к номерам из одной базы до переноса.
Ошибка 3: Забыть про регистры. Перенесли документы, но не перенесли (или не перепровели) движения по регистрам. В базе 1 000 документов реализации, а оборотно-сальдовая показывает нули. Перепроведение 1 000 документов — это ещё 2-3 часа и новые ошибки (если зависимые данные не в том порядке).
Ошибка 4: Один тестовый прогон. Первый тестовый перенос всегда выявляет 30-50 проблем. Второй — ещё 5-10. Третий — 1-2 мелочи. Если ограничиться одним прогоном, в продуктиве вылезут те самые 5-10 проблем, которые обнаружились бы на втором тесте.
Ошибка 5: Не зафиксировать состояние источника. Во время переноса кто-то провёл документ в старой базе. Данные ушли в новую базу без этого документа. Расхождение. Обязательно — монопольный доступ или блокировка записи в источнике на время финального переноса.
Сколько это занимает
Типичные сроки для разных масштабов:
- Малая база (до 50 000 записей, 2-3 справочника): 5-7 рабочих дней
- Средняя (100 000-500 000 записей, полный набор справочников и документов): 10-15 рабочих дней
- Крупная (1 000 000+ записей, сложная доработанная конфигурация): 20-30 рабочих дней
60% времени — подготовка и тестирование. 30% — исправление ошибок маппинга. 10% — сам перенос. Если вам обещают «перенести базу за день» — уточните, включена ли в этот день сверка, тестирование и обработка исключений. Скорее всего, нет.
Перенос данных — не разовая операция, а мини-проект. С планом, тестированием, контролем качества и приёмкой. Подходите к нему именно так — и неприятных сюрпризов после запуска будет минимум.
