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