Как обеспечить уникальность номеров документов при консолидации 40 баз 1С через Конвертацию данных?

← На главную

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

Вариант 1. Программная префиксация номеров в правилах конвертации (ПКО)

Проанализируем самый надежный и правильный с технической точки зрения метод — модификацию номера непосредственно в процессе выгрузки данных. Это позволит избежать конфликтов еще на этапе попадания данных в файл обмена.

Для реализации этого метода нам потребуется использовать «Конвертацию данных 2.1» (КД). В правилах конвертации объектов (ПКО) для конкретного типа документа найдем свойство Номер. Рассмотрим алгоритм действий:

В обработке выгрузки добавим параметр ПрефиксИнформационнойБазы. При запуске выгрузки из каждой базы будем указывать свой уникальный код (например, «01», «02» и т.д.).
В Правилах Конвертации Свойств (ПКС) для реквизита Номер в событии «Перед выгрузкой» пропишем код модификации значения.

Пример кода для обработки номера:


// Получаем префикс из параметров обработки
ПрефиксБЗ = Параметры.ПрефиксИнформационнойБазы; 

// Формируем новый номер: префикс + исходный номер
// Важно учитывать длину номера, чтобы строка не обрезалась
Значение = ПрефиксБЗ + "_" + Источник.Номер;

Важный момент: обратите внимание на длину стандартного реквизита Номер в конфигурации-приемнике. Если длина ограничена 11 символами, а вы добавляете префикс из 4 символов к номеру длиной 8, произойдет обрезание строки, что может привести к созданию новых дублей. В таком случае необходимо либо сокращать префикс, либо увеличивать длину номера в конфигурации (что потребует снятия с поддержки).

Вариант 2. Использование механизма «Дополнительных сведений»

Если мы не хотим изменять стандартную нумерацию в базе-приемнике или модифицировать конфигурацию, рассмотрим использование механизма дополнительных сведений (БСП). Выясним причину выбора этого метода: он позволяет хранить исходный номер документа в отдельном регистре, не нагружая структуру самого документа.

Алгоритм работы будет следующим:

В базе-приемнике создаем новый элемент в плане видов характеристик «Дополнительные реквизиты и сведения» с названием «Исходный номер».
В правилах конвертации настраиваем передачу значения Источник.Номер в этот доп. реквизит.
Реквизиту Номер в приемнике разрешаем присваивать новый номер по порядку, используя стандартный механизм автонумерации.

Этот способ хорош тем, что в базе-приемнике всегда будет порядок в нумерации, а старый номер останется доступен для поиска и отчетности. Однако стоит учитывать, что поиск документа «как в старой базе» потребует написания небольшого расширения для формы списка или специальных отчетов.

Вариант 3. Применение расширений конфигурации для хранения старых номеров

Проанализируем ситуацию, когда необходимо сохранить старый номер именно в объекте, но без снятия основной конфигурации с поддержки. Современная платформа 1С позволяет использовать механизм расширений. Мы можем добавить в расширение новый реквизит (например, СтарыйНомер) для всех необходимых типов документов.

Посмотрим на преимущества этого подхода:

Конфигурация остается на поддержке, что упрощает обновление.
Новый реквизит будет доступен в Конвертации Данных после обновления структуры из базы-приемника.
По этому реквизиту можно настроить индексацию, что сделает поиск документов мгновенным даже при огромных объемах данных.

В правилах конвертации ПКС для СтарыйНомер будет выглядеть максимально просто:

Значение = Источник.Номер;

Вариант 4. Технический обход контроля уникальности при загрузке

Выясним, что происходит, когда мы используем флаг ОбменДанными.Загрузка = Истина. В правилах конвертации, в событии «После загрузки» или «Перед записью», установка этого свойства позволяет платформе игнорировать стандартные проверки уникальности и бизнес-логику при записи объекта в базу данных.

Объект.ОбменДанными.Загрузка = Истина;

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

Вариант 5. Сохранение номера в «Комментарий»

Это самый быстрый в реализации, но наименее профессиональный способ. Рассмотрим его как временное решение. Мы можем настроить ПКС таким образом, чтобы номер источника дописывался в начало или конец строки комментария.

Пример кода в ПКС реквизита Комментарий:

Значение = "Исходный №: " + Источник.Номер + " | " + Источник.Комментарий;

Критический недостаток: поле Комментарий является строкой неограниченной длины и не индексируется в СУБД. Если вам потребуется найти документ по старому номеру среди миллионов записей из 40 баз, поиск будет выполняться крайне медленно (Full Table Scan), что может парализовать работу сервера при частом обращении.