При настройке обмена данными между конфигурациями 1С часто возникает ситуация, когда типы данных в источнике и приемнике не совпадают, хотя по смыслу они идентичны. Типичный пример — перенос данных из «1С:Управление производственным предприятием» (УПП) в «1С:Бухгалтерия предприятия» (БП), где в источнике для налогового учета используется отдельный ПланСчетовСсылка.Налоговый, а в приемнике все операции ведутся на едином плане счетов ПланСчетовСсылка.Хозяйственный. В этой статье мы подробно разберем, как правильно настроить правила конвертации в конфигурации «1С:Конвертация данных 2.1» для корректного сопоставления таких объектов.
Самый правильный и надежный способ — это создание специализированного Правила Конвертации Объектов (ПКО). Рассмотрим ситуацию: в табличной части документа источника есть реквизит СчетЗатратНУ с типом ПланСчетовСсылка.Налоговый. В приемнике соответствующий реквизит имеет тип ПланСчетовСсылка.Хозяйственный. Несмотря на то что коды счетов могут совпадать (например, «20.01» и там, и там), система считает их разными типами метаданных.
Для настройки выполним следующие шаги:
ПланСчетовСсылка.Налоговый, а в качестве Объекта-приемника — ПланСчетовСсылка.Хозяйственный.GUID (уникальному идентификатору), так как счета в разных планах счетов гарантированно имеют разные идентификаторы. Поиск должен идти строго по текстовому коду счета.Таким образом, при выгрузке счета из налогового плана счетов система возьмет его код, а при загрузке найдет счет с таким же кодом, но уже в хозяйственном плане счетов приемника.
Если большинство счетов в обоих планах счетов являются предопределенными, мы можем воспользоваться механизмом сопоставления предопределенных элементов. Рассмотрим подробнее этот механизм:
В конфигурации «Конвертация данных» для каждого ПКО доступна вкладка «Сопоставление предопределенных данных». Это позволяет жестко связать конкретный элемент источника с конкретным элементом приемника, даже если их коды различаются. Это особенно полезно для сложных случаев, когда, например, счет 91.02.7 в УПП должен превратиться в 91.02 в Бухгалтерии.
Алгоритм настройки:
ПрочиеРасходы_НеПринимаемые) и укажем соответствующее ему значение в приемнике (ПрочиеРасходы).Проанализируем ситуацию, когда в источнике (УПП) счет существует, а в приемнике (БП) — нет. Например, счет 91.02.7. В УПП налоговый учет обособлен, а в современных версиях БП налоговый учет ведется на тех же счетах, что и бухгалтерский, но с признаком вида учета в проводках.
Здесь возможны два пути решения, которые следует обсудить с методологами или бухгалтерами:
Вариант А: Создание нового счета в приемнике.
Вы можете программно или вручную создать счет 91.02.7 в БП. Однако это рискованный путь. Типовая отчетность (декларация по налогу на прибыль, баланс) «не знает» о вашем новом счете. Вам придется либо дорабатывать алгоритмы заполнения отчетов, либо вручную корректировать данные. Как правило, опытные специалисты не рекомендуют изменять типовой план счетов БП без крайней необходимости.
Вариант Б: Перенос на существующий счет с аналитикой.
Правильнее всего будет настроить маппинг (соответствие). Счет 91.02.7 (Прочие расходы, не принимаемые к НУ) в УПП должен попадать на счет 91.02 в БП. При этом признак «непринятия» расхода в БП определяется не кодом счета, а аналитикой — справочником Прочие доходы и расходы, где у соответствующего элемента в поле «Вид расхода» указано значение, не влияющее на налоговую базу.
Если соответствие счетов нельзя описать простым сопоставлением кодов, воспользуемся обработчиками событий. Рассмотрим пример в ПКС (Правило Конвертации Свойств) для счета затрат. В событии «Перед выгрузкой» можно написать следующий код:
// Пример подмены правила конвертации в зависимости от условий
Если Источник.СчетЗатратНУ.Код = "91.02.7" Тогда
// Если это специфичный счет, принудительно используем
// другое значение или логику поиска
Значение = "91.02";
Иначе
// Для остальных счетов используем стандартную логику
ИмяПКО = "СчетаНалоговыйВХозяйственный";
КонецЕсли;
Также полезно использовать событие «Поля поиска» в ПКО. Если стандартный поиск по коду не дал результатов, мы можем переопределить поиск в приемнике:
// Обработчик "Поля поиска" в ПКО
Если НомерВарианта = 1 Тогда
// Пытаемся найти счет по коду
СсылкаНаОбъект = ПланыСчетов.Хозяйственный.НайтиПоКоду(СвойстваПоиска["Код"]);
Если СсылкаНаОбъект.Пустая() Тогда
// Если счет не найден (например, тот самый 91.02.7),
// подставляем родительский или общий счет
СсылкаНаОбъект = ПланыСчетов.Хозяйственный.НайтиПоКоду("91.02");
КонецЕсли;
ПрекратитьПоиск = Истина;
КонецЕсли;
Разберем основные моменты, которые помогут избежать ошибок при загрузке данных:
Родитель. Без указания родителя счет может «повиснуть» в корне плана счетов, что нарушит логику иерархических отчетов.Подведем итог: для конвертации разных планов счетов в КД 2.1 наиболее эффективным является сочетание создания отдельного ПКО с поиском по коду и использование таблицы сопоставления предопределенных данных для исключительных случаев. Это обеспечит гибкость настройки и чистоту данных в целевой базе.