Одной из самых распространенных и сложных задач в практике сопровождения 1С является слияние двух и более информационных баз в одну. Ситуация, когда есть основная база ("ПРОФ" с несколькими организациями) и необходимость добавить в нее данные из другой базы (например, из "облака" или филиала), требует тщательной подготовки. Просто взять и загрузить данные стандартными средствами часто нельзя — это приводит к дублированию справочников (валют, номенклатуры, контрагентов) и нарушению учета.
В этой статье мы подробно разберем, почему возникают эти проблемы, как их избежать и какие инструменты платформы 1С лучше использовать для корректного переноса данных.
Прежде чем приступать к техническим манипуляциям, давайте разберемся, почему при использовании стандартной обработки "Выгрузка и загрузка данных XML" или обменов без детальной настройки возникают дубли. Казалось бы, валюта "Рубль" с кодом "643" есть и там, и там.
В платформе 1С каждый ссылочный объект (элемент справочника, документ) имеет Уникальный Идентификатор (UUID или GUID). Это внутренняя ссылка, которую мы обычно не видим.
Рассмотрим ситуацию:
Когда мы выгружаем данные из облака, система тащит за собой UUID. При загрузке в локальную базу 1С ищет объект именно по этому UUID. Не находя его (так как в локальной базе UUID другой), она создает новый элемент "Рубль". В итоге мы видим в списке две одинаковые строки, но для программы это совершенно разные сущности.
Чтобы этого избежать, нам необходимо изменить стратегию поиска объектов при загрузке.
Перед тем как начать перенос, мы обязаны выполнить проверку настроек обеих баз. Это критически важный этап, о котором часто забывают, что приводит к потере аналитики.
Давайте проанализируем Функциональность программы (раздел Администрирование — Функциональность) и Параметры учета.
Представим ситуацию:
Если мы просто загрузим документы из облака в приемник, то информация о складах может быть потеряна или проводки сформируются некорректно, так как в плане счетов приемника нет соответствующего субконто. В худшем случае, настройки приемника могут "затереть" аналитику в переносимых документах.
Что нужно сделать:
Рассмотрим три основных стратегии решения задачи.
Если вы используете "Универсальный обмен данными в формате XML", вам потребуются Правила Обмена. Для их создания или редактирования используется конфигурация "Конвертация данных 2.0".
Чтобы избежать дублей НСИ (номенклатуры, контрагентов, валют), нам нужно настроить Поля поиска (Identification Fields).
В правилах конвертации объектов (ПКО) для каждого критичного справочника (Валюты, ЕдиницыИзмерения, КлассификаторЕдиницИзмерения, Банки) необходимо:
Например, для справочника Контрагенты правильнее всего настроить поиск по ИНН и КПП. Для справочника Номенклатура — по Артикулу или Наименованию.
Важно: Это трудоемкий процесс, требующий навыков программирования. Вам придется проанализировать все справочники, используемые в учете.
В современных конфигурациях (Бухгалтерия 3.0) существует механизм синхронизации через формат EnterpriseData. Это "родной" и более толковый механизм, чем старые XML-обмены.
Мы можем настроить синхронизацию "Бухгалтерия предприятия" <-> "Бухгалтерия предприятия" (или РИБ, если конфигурации полностью идентичны, но для слияния разных баз лучше использовать обмен "По правилам" или "Полный интерфейс").
Преимущество этого метода:
При настройке синхронизации платформа предложит этап "Сопоставление данных". Перед тем как данные попадут в базу, откроется окно, где мы увидим:
Этот метод позволяет визуально контролировать процесс и избежать дублей без написания кода.
Иногда перенос всей истории документов за несколько лет нецелесообразен. Это создает огромную нагрузку на базу, риск "поплывших" периодов и ошибок в старых декларациях.
Рассмотрим вариант свертки базы-источника:
ВводНачальныхОстатков.В этом случае объем данных меньше, а контролировать правильность переноса (сошлись ли суммы по ОСВ) гораздо проще.
Если мы все же решили переносить документы, давайте используем методику поэтапной загрузки, чтобы не превратить базу в свалку.
Шаг 1. Перенос НСИ (Нормативно-справочной информации).
Сначала переносим только справочники. На этом этапе мы вылавливаем дубли. Используем обработку "Поиск и удаление дублей" в разделе Администрирование — Обслуживание — Корректировка данных. Приводим справочники в идеальный порядок до загрузки документов.
Шаг 2. Перенос документов частями.
Загружаем документы небольшими периодами (например, поквартально). После загрузки каждого периода:
При объединении баз существует риск случайно изменить данные уже существующих организаций в базе-приемнике (например, если "прилетит" изменение в общем справочнике или регистре сведений, таком как "Курсы валют" или "Счета учета номенклатуры").
Обязательные меры:
Проблема дублей при слиянии баз решается отказом от поиска по внутренним идентификаторам (UUID) в пользу поиска по ключевым полям (Код, Наименование, ИНН). Для этого лучше всего подходят либо грамотно настроенные правила в "Конвертации данных", либо использование штатного механизма синхронизации с интерактивным сопоставлением данных. Не забывайте про предварительную синхронизацию настроек функциональности программы, чтобы не потерять аналитику учета.