При слиянии двух информационных баз 1С:Бухгалтерия предприятия 3.0 КОРП часто возникает классическая архитектурная сложность. Несмотря на идентичность конфигураций, настройки плана счетов в базах могут существенно отличаться. Например, на счете 20.01 в базе-источнике настроено субконто Склады, а в базе-приемнике — Продукция. При обычном переносе данных через «Конвертацию данных 2.0» (КД 2.0) это приведет к потере аналитики или ошибкам загрузки из-за несоответствия типов данных.
В данной статье мы разберем, как обойти эти ограничения, используя программные механизмы КД 2.0, и проанализируем наиболее эффективные методы трансформации субконто «на лету».
Рассмотрим ситуацию: вы решили использовать механизм РИБ (распределенных информационных баз) для объединения данных. На первый взгляд, это кажется логичным, но на практике этот метод требует полной идентичности не только кода, но и метаданных, включая настройки планов счетов. Если в приемнике аналитика счета отличается, механизм синхронизации либо проигнорирует «лишние» данные, либо очистит существующие. Поэтому единственным надежным способом остается использование правил обмена.
Проблема «напролом» через КД 2.0 заключается в том, что когда мы пытаемся сопоставить разные виды субконто, система жестко привязывается к ПКО (Правилам Конвертации Объектов). Если мы принудительно меняем ИмяПКОВидСубконто, это может затронуть другие документы, где такая замена не требуется. Разберем более гибкие решения.
Этот способ подходит, если нам нужно точечно изменить аналитику для конкретных счетов прямо в процессе формирования файла выгрузки. Мы будем использовать обработчик «При выгрузке» в правилах конвертации свойств (ПКС) для движений регистра бухгалтерии (Хозрасчетный).
Проанализируем алгоритм: мы перебираем субконто документа и, если встречаем определенный счет (например, 26 или 91.02), принудительно подставляем нужный вид субконто и ищем соответствующее значение в справочнике по наименованию.
// В обработчике ПКС СубконтоДТ (или КТ) ПКО движений Хозрасчетный
Если ОбъектКоллекции.СчетДТ.Код = "26" Тогда
Для Каждого Суб Из ОбъектКоллекции.СубконтоДТ Цикл
// Проверяем тип текущего субконто в источнике
Если ТипЗнч(Суб.Значение) = Тип("СправочникСсылка.Склады") Тогда
// Устанавливаем новый вид субконто для приемника
ВидСубконто = ПланыВидовХарактеристик.ВидыСубконтоХозрасчетные.НайтиПоНаименованию("Подразделения");
// Ищем подходящее значение в справочнике приемника (по логике задачи)
Субконто = Справочники.ПодразделенияОрганизаций.НайтиПоНаименованию(Суб.Значение.Наименование);
КлючИЗначение = Новый Структура(ВидСубконто, Субконто);
КонецЕсли;
КонецЦикла;
ИначеЕсли ОбъектКоллекции.СчетДТ.Код = "91.02" Или ОбъектКоллекции.СчетДТ.Код = "91.01" Тогда
Для Каждого Суб Из ОбъектКоллекции.СубконтоДТ Цикл
Если ТипЗнч(Суб.Значение) = Тип("СправочникСсылка.Склады") Тогда
ВидСубконто = ПланыВидовХарактеристик.ВидыСубконтоХозрасчетные.НоменклатурныеГруппы;
Субконто = Справочники.НоменклатурныеГруппы.НайтиПоНаименованию(Sub.Значение.Наименование);
КонецЕсли;
КонецЦикла;
КонецЕсли;
Важный нюанс: поиск по наименованию внутри обработчиков выгрузки замедляет процесс и может привести к созданию «пустых ссылок», если объект в приемнике еще не создан. Этот метод хорош для разовых правок, но для массового слияния лучше использовать второй вариант.
Более профессиональный подход заключается в том, чтобы не «хардкодить» условия в каждом ПКО, а создать глобальный обработчик в базе-приемнике. Мы можем сформировать соответствие субконто счетам и хранить их в глобальных переменных Параметры.
Рассмотрим пример реализации в обработчике «После загрузки» для документа. Мы выгружаем табличные части во временные таблицы, анализируем счета и программно перераспределяем субконто согласно метаданным приемника.
// Пример логики обработки загруженных данных
МассивТЧ = Новый Массив;
МассивТЧ.Добавить("ОтражениеВУчете");
ВидыАналитики = Новый Массив;
ВидыАналитики.Добавить("Дт");
ВидыАналитики.Добавить("Кт");
Для Каждого ТекТЧ ИЗ МассивТЧ Цикл
Для Каждого Строка ИЗ Объект[ТекТЧ] Цикл
АналитикаСтруктура = Новый Структура;
Для Каждого ТекВид ИЗ ВидыАналитики Цикл
// Получаем настроенное соответствие субконто для данного счета в приемнике
СоответствиеСубконто = Параметры["СоответствияСубконто"].Получить(Строка["Счет" + ТекВид]);
Если СоответствиеСубконто = Неопределено Тогда
Продолжить;
КонецЕсли;
Для Сч = 1 ПО 3 Цикл
Если ЗначениеЗаполнено(Строка["Субконто" + ТекВид + Сч]) Тогда
// Проверяем, на каком месте (1, 2 или 3) должен стоять данный тип субконто в приемнике
НомерСубконто = СоответствиеСубконто.Получить(ТипЗнч(Строка["Субконто" + ТекВид + Сч]));
Если НЕ НомерСубконто = Неопределено Тогда
ЗначениеСубконто = Строка["Субконто" + ТекВид + Сч];
// Заполняем структуру для последующей вставки в объект
АналитикаСтруктура.Вставить("Субконто" + ТекВид + НомерСубконто, ЗначениеСубконто);
КонецЕсли;
КонецЕсли;
КонецЦикла;
КонецЦикла;
// Применяем изменения к строке документа
ЗаполнитьЗначенияСвойств(Строка, АналитикаСтруктура);
КонецЦикла;
КонецЦикла;
Этот метод позволяет динамически определять, в какое именно «гнездо» (субконто1, субконто2 или субконто3) должно попасть значение, исходя из реальных настроек плана счетов базы-приемника на момент загрузки.
Выясним причину частых ошибок при работе с пользовательскими видами субконто. В 1С:Бухгалтерия 3.0 пользователи часто добавляют свои виды субконто вручную. В КД 2.0 такие объекты не являются предопределенными, а значит, поиск по «Имени» в метаданных не сработает.
Для корректного переноса необходимо:
ВидыСубконтоХозрасчетные, настроив поиск по Наименованию.UUID, программно сопоставить его через НайтиПоНаименованию() в обработчике ПередЗагрузкой.После того как данные загружены с подменой аналитики, работа не заканчивается. Проанализируем обязательные шаги по приведению базы в порядок:
ОбменДанными.Загрузка = Истина) итоги могут не обновиться автоматически. Обязательно выполните процедуру «Управление итогами» и «Тестирование и исправление» (пункт «Пересчет итогов»).Резюме: Слияние баз с разной аналитикой — это всегда компромисс. Либо вы приводите план счетов источника к виду приемника до выгрузки, либо пишете гибкие обработчики трансформации в КД 2.0. Второй путь сложнее в реализации, но он позволяет сохранить работоспособность обеих систем в процессе миграции без остановки учета.