Объединение двух действующих информационных баз 1С:ERP в одну общую систему — это сложнейший проект, требующий от архитектора и программиста не только глубоких технических знаний платформы «1С:Предприятие 8.3», но и детального понимания методологии учета. Ситуация, когда организации велись параллельно в разных базах с идентичной конфигурацией, а затем возникла необходимость их слияния, встречается достаточно часто. Основная цель такого проекта — уйти от двойного ввода нормативно-справочной информации (НСИ) и получить единую точку формирования консолидированной отчетности.
В этой статье мы подробно разберем по шагам, как правильно спланировать и реализовать этот процесс, как обойти критические ловушки платформы и минимизировать риски рассинхронизации данных.
Проводя аудит подобных проектов, мы часто сталкиваемся с подходом, когда разработчики пытаются настроить выгрузку всех исторических документов через КД 2 (Конвертацию данных) с последующим групповым перепроведением в целевой базе. Для систем класса ERP это смертельный номер, который гарантированно разрушит учет по следующим причинам:
Правильное решение: Исторические данные за закрытые периоды переносить исключительно методом ввода начальных остатков на определенную контрольную дату (например, начало нового квартала или года). Старая база-источник при этом переводится в режим «только для чтения» и остается в качестве архива. Если же требуется перенести документы за текущий открытый период, их необходимо переносить вместе с движениями по регистрам (без перепроведения) с помощью специализированных правил конвертации.
Даже если конфигурации баз абсолютно идентичны, они создавались независимо. Это рождает неочевидные технические проблемы на уровне СУБД, о которых важно знать заранее:
Предопределенный элемент не уникален.Перед началом слияния обязательно нужно проанализировать и сопоставить предопределенные элементы. При написании правил в КД 2 необходимо жестко прописать поиск таких элементов по ключевым полям (например, валюты — по коду, ставки НДС — по значению), отключив сопоставление по GUID.
Рассмотрим детальный алгоритм действий, который позволит минимизировать риски и провести слияние систем максимально гладко.
Прежде чем переносить данные, необходимо детально сравнить настройки функциональности обеих баз. Выясним следующие моменты:
Справочники — это фундамент ERP. Самая большая проблема — это Справочник.Номенклатура и Справочник.Контрагенты. Если в базах велся ручной ввод, одна и та же позиция будет записана по-разному. Слияние номенклатуры «в лоб» приведет к хаосу на складах. Нам потребуется:
ИНН + КПП. Для номенклатуры — Артикул или уникальный код, согласованный со службой НСИ.Рассмотрим пример кода обработчика ПоляПоиска в Конвертации Данных 2.5 для сопоставления контрагентов:
// Пример обработчика "Поля поиска" для справочника Контрагенты
Если СвойстваПоиска.Получить("ЭтоГруппа") = Истина Тогда
// Группы сопоставляем по наименованию
СтрокаИменСвойствПоиска = "Наименование, Родитель";
Иначе
// Элементы сопоставляем строго по ИНН и КПП
Если ЗначениеЗаполнено(СвойстваПоиска.Получить("ИНН")) Тогда
СтрокаИменСвойствПоиска = "ИНН, КПП";
КонецЕсли;
КонецЕсли;
За основу (целевую базу) всегда берется более крупная база (например, База А). В ней проводится полный технологический аудит, удаляются помеченные на удаление объекты, запускается тестирование и исправление базы данных. В целевой базе создается новая организация (организация Б), под которую будут загружаться данные.
В базе-источнике (База Б) полностью закрывается отчетный период, рассчитывается себестоимость, формируется и сдается отчетность. На дату перехода формируются документы ввода остатков:
Для переноса остатков используются типовые документы ERP Документ.ВводНачальныхОстатков. Эти документы переносятся в базу А с помощью правил конвертации или обработки «Универсальный обмен данными XML».
В 1С:ERP встроен полноценный блок расчета зарплаты и кадрового учета. Его объединение имеет критически важную специфику:
ФизическиеЛица, чтобы корректно формировалась отчетность по НДФЛ и РСВ. При этом в справочнике Сотрудники должно остаться два разных элемента (по одному на каждую организацию).ПереносДанных (документы технического ввода сведений с префиксом ЗУП).Если в сливаемых базах ведется производственный учет, то перенос активных, незавершенных спецификаций, заказов на производство и этапов крайне затруднен, так как в ERP 2.5 документы этапов жестко привязаны к локальным регистрам распределения материалов и трудозатрат.
Рекомендация: На момент слияния баз необходимо максимально закрыть все этапы производства в базе-источнике. Остатки незавершенного производства (выпущенные, но не распределенные полуфабрикаты, распределенные, но не списанные материалы) необходимо зафиксировать и перенести через специализированный документ ВводНачальныхОстатковПолуфабрикатовПроизводственногоПроцесса или ВводНачальныхОстатковНезавершенногоПроизводства по подразделениям и партиям.
После переноса НСИ и документов ввода остатков в базу А, наступает важнейший этап — сверка. Формируются оборотно-сальдовые ведомости (ОСВ) по всем счетам учета, а также аналитические отчета по складам (ведомость по товарам на складах), взаиморасчетам (ведомость расчетов с клиентами/поставщиками) в обеих базах на дату перехода. Отчеты по новой организации в целевой базе должны сойтись «копейка в копейку» с исходными данными базы-источника.
Рассмотрим по шагам контрольный список отчетов для сверки:
Только после того, как все показатели сошлись, база А передается пользователям для ведения текущего оперативного учета обеих организаций в едином информационном пространстве.