Ведение учета нескольких организаций в одной информационной базе — стандартная и очень удобная возможность программы «1С:Бухгалтерия предприятия 3.0» (БП 3.0). Это позволяет использовать единые справочники контрагентов, номенклатуры, статей затрат, а также значительно упрощает подготовку отчетности и администрирование системы. Однако, когда возникает необходимость слить две ранее независимые базы в одну, специалисты сталкиваются с целым рядом технических и методологических трудностей.
В этой статье мы подробно разберем по шагам весь процесс объединения баз, проанализируем возможные подводные камни, рассмотрим особенности работы со справочниками и разберем правильный порядок переноса начальных остатков.
---
Прежде чем приступать к техническим манипуляциям, нам необходимо определиться со стратегией объединения. Слияние баз «в лоб» без предварительного планирования гарантированно приведет к хаосу в учете. Выясним ключевые организационные моменты:
---
Одной из главных проблем при слиянии баз является пересечение номеров документов и кодов справочников. Чтобы избежать затирания и конфликтов нумерации, настроим уникальные префиксы.
Выполним следующие действия в обеих базах ДО начала выгрузки данных:
Благодаря этому при переносе документов система автоматически добавит префиксы к номерам документов, исключая возможность их перезаписи.
---
Рассмотрим важную техническую особенность платформы 1С:Предприятие 8.3. Предопределенные элементы справочников, планов счетов и планов видов характеристик (ПВХ) создаются системой автоматически, но в разных базах они имеют разные уникальные идентификаторы (GUID/UUID).
Если мы воспользуемся стандартной обработкой «Выгрузка и загрузка данных XML» старых версий, система сопоставит объекты по UUID. В результате в базе-приемнике продублируются счета из плана счетов или предопределенные статьи движения денежных средств. Это приведет к полной неработоспособности базы.
Решение проблемы: для выгрузки данных используйте актуальную версию обработки ВыгрузкаЗагрузкаДанныхXML83.epf (она поставляется вместе с дистрибутивом «1С:Конвертация данных 2.0»). В этой обработке реализован специальный алгоритм, который умеет сопоставлять предопределенные элементы не по их внутреннему UUID, а по имени (идентификатору) в метаданных. Это гарантирует сохранение целостности плана счетов.
---
Переносить всю историю документов из базы-донора за несколько лет крайне не рекомендуется — это перегрузит объединенную базу историческим мусором. Нам нужно получить чистые остатки.
Разберем два возможных варианта действий:
Минус метода: штатная свертка часто формирует остатки по регистрам бухгалтерии в виде ручных документов Операция (бухгалтерский и налоговый учет). Сводить и проверять такие документы в новой базе крайне тяжело.
Ввод начальных остатков по новой организации. Если объем данных небольшой, ввод остатков по счетам 10, 41, 60, 62, 01 дешевле и надежнее выполнить вручную, сверившись с оборотно-сальдовой ведомостью базы-донора. При больших объемах данных пишется простое правило переноса в «1С:Конвертация данных 2.0» для выгрузки остатков в документы ввода остатков.---
При слиянии баз неизбежно возникнет дублирование элементов в справочниках Контрагенты, Номенклатура, Физические лица и др. Например, один и тот же поставщик «Альфа» мог быть заведен в обеих базах с разными наименованиями, но с одинаковым ИНН.
Проанализируем процесс наведения порядка в справочниках:
ВыгрузкаЗагрузкаДанныхXML83.epf.ИНН и КПП.Для предварительного анализа базы на наличие дубликатов контрагентов перед слиянием мы можем использовать следующий запрос в консоли запросов:
ВЫБРАТЬ
ИНН,
КПП,
КОЛИЧЕСТВО(Ссылка) КАК КоличествоДублей
ПОМЕСТИТЬ ВТ_Дубли
ИЗ
Справочник.Контрагенты
ГДЕ
ИНН <> ""
СГРУППИРОВАТЬ ПО
ИНН,
КПП
ИМЕЮЩИЕ
КОЛИЧЕСТВО(Ссылка) > 1
;
ВЫБРАТЬ
Контрагенты.Ссылка КАК КонтрагентСсылка,
Контрагенты.ИНН,
Контрагенты.КПП
ИЗ
Справочник.Контрагенты КАК Контрагенты
ГДЕ
(Контрагенты.ИНН, Контрагенты.КПП) В (ВЫБРАТЬ ВТ_Дубли.ИНН, ВТ_Дубли.КПП ИЗ ВТ_Дубли)
УПОРЯДОЧИТЬ ПО
Контрагенты.ИНН
Этот запрос наглядно покажет нам все элементы справочника, которые имеют одинаковые ИНН и КПП, что позволит оценить масштаб проблемы перед объединением.
---
Рассмотрим критически важную проблему, о которой часто забывают разработчики при удалении дублей в объединенной базе.
Если ваша мастер-база БП 3.0 ранее была синхронизирована с базой «1С:Зарплата и управление персоналом» (ЗУП) или «1С:Управление торговлей» (УТ), то в ней заполнен регистр сведений Публичные идентификаторы синхронизируемых объектов. В этом регистре хранятся соответствия между уникальными идентификаторами (UUID) объектов в БП и внешних базах.
Выясним причину сбоя синхронизации после удаления дублей:
Если вы объединили двух дублирующихся контрагентов или физических лиц, выбрав в качестве оригинала элемент, перенесенный из базы-донора, старая запись в регистре синхронизации для мастер-базы сотрется или станет невалидной. При следующем сеансе обмена ЗУП или УТ не сможет сопоставить объект и создаст его дубль заново!
Решение: при замене дублей с помощью обработки поиска и удаления дублей всегда выбирайте в качестве «Оригинала» (выживающего элемента) тот объект, который изначально существовал в мастер-базе. Если же пришлось оставить элемент из базы-донора, потребуется вручную очистить или перенастроить правила сопоставления в узлах обмена синхронизации данных.
Посмотрим на пример кода, с помощью которого можно программно проверить наличие записей в регистре публичных идентификаторов для конкретного объекта перед его удалением:
Функция ЕстьЗаписьСинхронизации(СсылкаНаОбъект) Экспорт
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ ПЕРВЫЕ 1
| ПубличныеИдентификаторы.Ссылка
|ИЗ
| РегистрСведений.ПубличныеИдентификаторыСинхронизируемыхОбъектов КАК ПубличныеИдентификаторы
|ГДЕ
| ПубличныеИдентификаторы.Ссылка = &Ссылка";
Запрос.УстановитьПараметр("Ссылка", СсылкаНаОбъект);
РезультатЗапроса = Запрос.Выполнить();
Возврат Не РезультатЗапроса.Пустой();
КонецФункции
---
Если ваши исходные базы работают в файловом режиме (файл базы данных 1Cv8.1cd), помните о жестком ограничении платформы 1С:Предприятие.
Размер одной таблицы (например, таблицы индексов или регистров бухгалтерии) в файловой базе данных не может превышать 4 ГБ. При слиянии двух средних баз в одну общий объем накопленной информации может легко превысить этот лимит. Это приведет к критическому сбою СУБД и невозможности войти в программу.
Рекомендация: проводите процедуру слияния крупных баз исключительно на клиент-серверном варианте (под управлением MS SQL, PostgreSQL и др.). Если такой возможности нет, предварительно выполните тестирование и исправление баз с обязательным сжатием таблиц и очисткой неиспользуемых объектов.
---
ВыгрузкаЗагрузкаДанныхXML83.epf для корректного переноса плана счетов без задвоения предопределенных элементов.Ввод начальных остатков в объединенной базе на выбранную дату (например, на 01.01.2024).Выполняя эти шаги последовательно и аккуратно, мы гарантируем безопасное, быстрое и корректное слияние нескольких баз «1С:Бухгалтерия 3.0» в единую многофирменную систему.