При переносе данных между конфигурациями 1С часто возникает ситуация, когда аналитика в базе-источнике настроена более детально, чем в базе-приемнике. Типичный пример: в источнике счет 43 (Готовая продукция) разбит на субсчета 43.1, 43.2 и 43.3 (причем сделано это пользователями вручную), а в типовой базе-приемнике существует только один предопределенный счет 43. Если оставить правила «как есть», система попытается создать новые счета в приемнике или выдаст ошибку сопоставления.
В этой статье мы разберем, как правильно «схлопнуть» несколько счетов в один, используя механизмы 1С:Конвертация данных 2.1, рассмотрим работу обработчиков и выясним, как сделать перенос корректным с точки зрения поиска объектов.
Наиболее эффективным и быстрым способом является подмена передаваемого кода счета непосредственно в правилах конвертации свойств (ПКС). Рассмотрим ситуацию: у нас есть ПКО (Правило конвертации объекта) для плана счетов Хозрасчетный. Нам нужно, чтобы при выгрузке любого из субсчетов (43.1, 43.2, 43.3) система передавала в файл обмена код просто «43».
Для этого выполним следующие шаги:
Хозрасчетный (ПланСчетовСсылка.Хозрасчетный).Код.Проанализируем код, который необходимо написать в этом обработчике:
// Проверяем код источника.
// Используем Лев(), чтобы захватить все субсчета, начинающиеся на 43
Если Лев(Источник.Код, 2) = "43" Тогда
Значение = "43";
КонецЕсли;
Важный нюанс: Чтобы это сработало, в настройках самого ПКО на закладке «Настройки поиска» обязательно должен быть установлен флаг «Поиск по коду». В этом случае алгоритм загрузки в приемнике возьмет переданное значение «43», найдет существующий счет с таким кодом и подставит его в документ, вместо того чтобы создавать новый элемент.
Иногда подмена значения в ПКС может быть недостаточной, если в базе-приемнике включен поиск по внутреннему идентификатору (GUID). Если система сначала найдет объект по GUID и не обнаружит его, она может создать новый счет с кодом «43», что приведет к дублированию, если такой код уже есть, но с другим GUID.
Рассмотрим более «продвинутый» вариант через обработчик «Поля поиска» в ПКО Плана счетов. Этот метод позволяет гибко управлять логикой сопоставления на стороне базы-приемника.
В обработчике «Поля поиска» мы можем прописать следующую логику:
// Проверяем, что поиск идет именно для плана счетов
Если НомерВариантаПоиска = 1 Тогда
// Получаем код из входящих данных (структура Свойства)
ТекущийКод = "";
Свойства.Свойство("Код", ТекущийКод);
Если Найти(ТекущийКод, "43.") > 0 Или ТекущийКод = "43" Тогда
// Принудительно устанавливаем код для поиска в приемнике
КодДляПоиска = "43";
// Отключаем поиск по другим полям, если нашли соответствие
ПрекратитьПоиск = Истина;
КонецЕсли;
КонецЕсли;
Этот метод хорош тем, что он не меняет данные в самом файле обмена так радикально, как ПКС, но четко указывает механизму загрузки, как именно сопоставлять объекты.
Бывают случаи, когда счета 43.1 и 43.2 должны не просто превратиться в 43, но и потянуть за собой разную аналитику (субконто). В такой ситуации лучше создать два разных правила конвертации для одного и того же объекта источника.
Разберем, как это реализовать:
Хозрасчетный (для обычных счетов).Хозрасчетный_Схлопнутый. В нем в ПКС Код жестко прописываем Значение = "43"; (или выбираем предопределенный узел).РеализацияТоваровУслуг), в ПКС, отвечающем за счет учета, прописываем логику выбора правила.Посмотрим на пример кода в обработчике «Перед выгрузкой» ПКС документа:
Если Источник.СчетУчета.Код = "43.1" Или Источник.СчетУчета.Код = "43.2" Тогда
ИмяПКО = "Хозрасчетный_Схлопнутый";
Иначе
ИмяПКО = "Хозрасчетный"; // Стандартное правило
КонецЕсли;
Такой подход считается наиболее «чистым» с точки зрения архитектуры правил конвертации данных, так как разделяет логику обработки стандартных и специфических данных.
Проанализируем ситуацию с субконто. Если вы объединяете счета 43.1 и 43.2 в один счет 43 в приемнике, вы должны быть уверены, что состав видов субконто на этих счетах совпадает.
Например:
Номенклатура, Склады.Номенклатура, Партии.В этом случае простого «схлопывания» кода будет недостаточно — данные по складам не найдут своего места, а партии останутся пустыми. Если составы аналитики различаются, вам потребуется дополнительно прописывать логику в обработчике ПередВыгрузкой или ПриЗагрузке для сопоставления значений субконто (объект ЗначенияСубконто в документах).
Часто возникает вопрос: можно ли в ПКО написать Источник = ПланыСчетов.Хозрасчетный.ГотоваяПродукция;?
Выясним причину, почему это плохая идея:
Источник в обработчиках ПКО инициализируется самой платформой при начале выгрузки объекта. Переопределение этой ссылки внутри ПКО может привести к непредсказуемому поведению (например, если объект уже начал считываться).ПланыСчетов.Хозрасчетный.ГотоваяПродукция в базе-источнике — это конкретный элемент базы-источника. Нам же нужно получить корректную ссылку в базе-приемнике.Для решения задачи объединения счетов мы рекомендуем использовать Метод 1 (изменение кода в ПКС «Код» с включенным поиском по коду) как самый простой. Если же логика сложная и затрагивает разные типы документов, стоит рассмотреть создание Алгоритмов в КД 2.1, чтобы вызывать одну и ту же проверку кода из разных мест одним вызовом Выполнить(Алгоритмы.ОпределитьСчет);.
Помните, что при работе с планом счетов в Конвертации данных 2.1 критически важно следить за тем, чтобы предопределенные элементы сопоставлялись правильно. Если счет 43 в приемнике является предопределенным, убедитесь, что в ПКО стоит галочка «Использовать для поиска предопределенные данные». Это гарантирует, что система найдет системный счет 43, а не создаст его копию.