Перенос документов 1С — между базами

Перенос документов — это всегда «дороже, чем остатки». Главный вопрос проекта миграции: насколько глубокая история нужна в новой базе, и стоит ли её туда тащить.

Переносим или оставляем в архиве

Часто правильный ответ — «не переносим». Архивная старая база с правом чтения закрывает большинство задач без расходов на перенос.

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

Когда перенос документов оправдан

• Длинный цикл сделок — Производство оборудования с гарантией 5+ лет, девелопмент, лизинг — историю реализации и поступлений нужно иметь под рукой в одной базе.
• Сложная аналитика — Маркетинг и продажи строят отчёты на 2–3 года вглубь (LTV, когортный анализ, сравнение с прошлым годом). Без истории документов в новой базе провал в отчётности.
• Регуляторика — Маркировка «Честный знак» требует хранения истории движений по марке. Прослеживаемость импорта — то же самое. Если эти движения регулярно нужны — лучше в одной базе.
• Налоговая проверка с большой вероятностью — Если компания уже под камеральными или выездными проверками — открывать архивную базу неудобно, документы лучше иметь в новой.

Когда лучше оставить в архиве

• Микро-бизнес и ИП — Налоговая запрашивает старые документы редко, аналитика на 3 года не используется. Архивная база на отдельном сервере или в виде .dt + бэкап БД — достаточно.
• Короткий цикл сделок — Розница, услуги, продажа софта — исторические документы не нужны в оперативной работе. Достаточно остатков + текущих документов от даты перехода.
• Очень большая база — Перенос 5+ лет документов на базе 50+ ГБ может добавить 6–12 месяцев к проекту и сильно увеличить бюджет. Архивация почти всегда выгоднее.

Если переносим — как именно

Перенос документов делается пакетами после переноса справочников и остатков. Порядок строго: НСИ → остатки → документы.

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

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

Изменилась структура регистров — переписываем правила. В УТ 10.3 был регистр «Партии товаров», в УТ 11.5 — «Себестоимость товаров». Документ реализации в этих регистрах пишет по-разному. В правилах конвертации движения каждого типа документа нужно явно переложить под новую структуру регистров. Просто «переносим документ как есть» — не работает.

Что делать со старой базой

Даже если переносим документы — старую базу обычно сохраняют как архив. Это требование 5-летнего срока хранения по ФНС.

• Read-only база на отдельном сервере — Простой вариант: оставить базу на старом сервере, отключить пользователей кроме 1–2 «архивных», подключаться по требованию. Затраты — хостинг отдельного сервера, восстановление данных мгновенное.
• .dt + дамп СУБД в защищённом хранилище — Выгружаем базу в .dt (Конфигуратор → Администрирование → Выгрузить ИБ) + полный дамп PostgreSQL/MSSQL. Храним в шифрованном виде минимум 5 лет (срок ФНС по ст. 23 НК РФ). Восстановление — 1–3 дня.
• Бумажные отчёты ключевых форм — ОСВ, КУДиР, налоговые декларации — распечатать и хранить в бумаге по ФЗ-402. Это дублирующий канал, не заменяет цифровой архив, но снимает риск «потеряли .dt-файл».
• Журнал «как открыть архив» — Через год после миграции команда забудет, как развернуть старую базу: какая платформа, какие СУБД, где ключи. Описать процедуру восстановления и сохранить вместе с архивом.

Premium-формат

См. структурированный premium-вариант выше.

Часто задаваемые вопросы

Можно ли перенести только последний год документов?

Да, это самый распространённый компромисс. Большинство компаний переносят 12–24 месяца документов в новую базу, всё остальное — оставляют в архивной. Это даёт оперативную аналитику за «свежий» период и не раздувает бюджет миграции. Технически в правилах Конвертации данных ставится фильтр «Дата документа >= такое-то число», и переносятся только подходящие документы. Остатки при этом переносятся на дату начала окна (не на дату перехода). Архивная база остаётся read-only — открывают при необходимости по запросам налоговой или для исторических отчётов.

Что лучше: перенести документы из 1С 7.7 в 8.3 или оставить 7.7 в архиве?

Почти всегда правильный ответ — оставить в архиве. 1С:Предприятие 7.7 имеет принципиально другую модель данных по сравнению с 8.3, перенос документов один-в-один невозможен, правила пишутся практически вручную. Это объём работы, сравнимый с написанием новой конфигурации. Альтернатива: поднять 7.7 как архивную базу на отдельном сервере (Windows Server, RDP-доступ для 1–2 человек). Через 7.7 можно сформировать любые отчёты за прошлые периоды по требованию. Бюджет такого решения — на порядок ниже, чем перенос документов.

Можно ли использовать прямые SQL-операции для переноса миллионов документов?

Технически — да, на очень больших базах (десятки миллионов документов) это иногда единственный реалистичный способ. Но это рискованный путь: легко нарушить целостность ссылок, прав доступа, итогов регистров. Делается только опытной командой, обязательно: 1) С полной резервной копией (.dt + дамп СУБД, проверенные восстановлением на тестовом контуре). 2) С тестовой загрузкой части документов и регрессионной проверкой. 3) С планом отката, если после переноса всплывут проблемы. Прямое SQL без этих гарантий — слишком опасно для продуктива.

Документы перенесли, но регистры пустые. Что делать?

Самая частая причина: документы перенесены без движений (только заголовки и табличные части), а движения регистров — нет. Решение — групповое перепроведение в новой базе через типовую обработку «Перепроведение документов» (НСИ и администрирование → Обслуживание → Корректировка данных). Запускается за период, например, год. Время на 100 000 документов — от нескольких часов до суток в зависимости от железа и сложности регистров. Перед перепроведением — обязательный бэкап и желательно тестовый прогон на копии.