При настройке интеграции и переноса данных между конфигурациями 1С:Предприятие с помощью конфигурации «Конвертация данных 2.1» (КД 2.1) разработчики часто сталкиваются с необходимостью трансформации типов данных. Типичный пример — перенос платежных документов (например, из «Управления торговлей 11» в «Бухгалтерию предприятия 3.0»), где реквизиты налогового периода в источнике хранятся в виде строки (например, МС.12.2019), а в приемнике должны быть записаны в полноценный реквизит с типом Дата.
В рамках данной статьи мы подробно разберем, как правильно реализовать алгоритм разбора такой строки, какие подводные камни могут возникнуть при различных налоговых периодах (месяц, квартал, полугодие, год), а также детально изучим методику устранения популярной ошибки загрузки «Поле объекта не обнаружено» на строке 7176 обработки «Универсальный обмен данными XML».
При проектировании правил обмена в КД 2.1 у нас есть выбор, в каком обработчике событий производить конвертацию типов. Некоторые разработчики пытаются делать это в обработчике ПередВыгрузкой правила конвертации объектов (ПКО), передавая значение во входящие данные. Однако наиболее лаконичным, прозрачным и простым в обслуживании является написание кода непосредственно в Правиле конвертации свойства (ПКС) для конкретного реквизита.
Выполним следующие шаги для настройки ПКС:
СписаниеБезналичныхДенежныхСредств, а приемником — СписаниеСРасчетногоСчета).ПоказательПериода (строка), Приемник — НалоговыйПериод (дата).Значение.Когда мы присваиваем результат переменной Значение в обработчике ПКС Перед выгрузкой, исходный реквизит источника игнорируется, а в файл выгрузки XML помещается именно то значение, которое мы сформировали программно.
Рассмотрим простейший вариант конвертации, который часто используют начинающие специалисты. Если строка имеет строго фиксированный вид МС.12.2019, то можно попытаться просто вырезать составляющие функции и склеить их для передачи в конструктор Дата():
ПоказательПериода = Источник.ПоказательПериода;
ПозицияПериода = Найти(СокрЛП(ПоказательПериода), ".");
ПозицияГода = Найти(Сред(СокрЛП(ПоказательПериода), ПозицияПериода + 1), ".") + ПозицияПериода;
СтрокаНомерПериода = Сред(СокрЛП(ПоказательПериода), ПозицияПериода + 1, ПозицияГода - ПозицияПериода - 1);
СтрокаГодПериода = Сред(СокрЛП(ПоказательПериода), ПозицияГода + 1);
Значение = Дата(Строка(СтрокаГодПериода + СтрокаНомерПериода + "01"));
Почему этот код крайне опасен для реального учета? Проанализируем его слабые стороны:
КВ.02.2020 (второй квартал), то простой перенос номера периода в качестве месяца даст нам «02» (февраль). Но второй квартал начинается с 1 апреля (01.04.2020). Налоговые органы не примут такую отчетность.ГД.00.2019. Склеивание строк попытается создать дату с нулевым месяцем: 20190001. Платформа 1С выдаст критическую ошибку «Преобразование значения к типу Дата не может быть выполнено», и процесс выгрузки аварийно завершится.МС.3.2020), склеенная строка даты потеряет нужную длину, что также приведет к системному сбою.Для того чтобы избежать этих проблем, разработаем универсальный, отказоустойчивый алгоритм. Вместо устаревших функций Найти и Сред задействуем современную функцию платформы СтрРазделить, которая мгновенно разобьет строку по точкам-разделителям. Мы также учтем специфику всех типов налоговых периодов (МС, КВ, ПЛ, ГД):
ПоказательПериода = СокрЛП(Источник.ПоказательПериода);
Значение = '00010101'; // Инициализируем пустой датой на случай непредвиденного формата
Если Найти(ПоказательПериода, ".") > 0 Тогда
МассивЧастей = СтрРазделить(ПоказательПериода, ".");
Если МассивЧастей.Количество() = 3 Тогда
Периодичность = ВРег(МассивЧастей[0]);
НомерПериода = Число(МассивЧастей[1]);
ГодПериода = Число(МассивЧастей[2]);
Месяц = 1; // По умолчанию первый месяц периода
Если Периодичность = "МС" Тогда
Месяц = НомерПериода;
ИначеЕсли Периодичность = "КВ" Тогда
// КВ.01 -> Январь (1), КВ.02 -> Апрель (4), КВ.03 -> Июль (7), КВ.04 -> Октябрь (10)
Месяц = (НомерПериода - 1) * 3 + 1;
ИначеЕсли Периодичность = "ПЛ" Тогда
// ПЛ.01 -> Январь (1), ПЛ.02 -> Июль (7)
Месяц = (НомерПериода - 1) * 6 + 1;
ИначеЕсли Периодичность = "ГД" Тогда
Месяц = 1; // Для годовых платежей всегда устанавливаем 1 января
КонецЕсли;
Попытка
// Используем безопасный конструктор даты по числовым параметрам
Значение = Дата(ГодПериода, Месяц, 1);
Исключение
// Если дата некорректна (например, неверный год), возвращаем пустую дату
Значение = '00010101';
КонецПопытки;
КонецЕсли;
КонецЕсли;
Этот код защищен от сбоев преобразования типов, корректно интерпретирует кварталы и полугодия, а также использует конструктор Дата(Год, Месяц, День), который не зависит от региональных настроек операционной системы сервера.
Представим ситуацию: выгрузка прошла успешно, в сформированном XML-файле мы видим долгожданную строку вида 2020-04-01T00:00:00. Но при попытке загрузить этот файл в базу-приемник «Бухгалтерия предприятия» обработка загрузки падает с ошибкой:
Ошибка при загрузке данных: {ВнешняяОбработка.УниверсальныйОбменДаннымиXML.МодульОбъекта(7176)}: Поле объекта не обнаружено
Выясним причину этой проблемы. В конфигурации КД 2.1 при автоматической генерации правил обмена или при ручном копировании строк ПКС в таблице свойств могут образовываться так называемые «фантомные» (пустые) строки. У такой строки полностью отсутствует имя источника и имя приемника, однако само правило остается активным и записывается в XML-файл правил обмена. Когда универсальный загрузчик парсит правила и пытается сопоставить свойства, он наталкивается на это пустое свойство и пытается выполнить код вида Объект[""] = Значение, что и вызывает исключение.
Вторая распространенная причина — **несоответствие метаданных**. Если ваша конфигурация БП 3.0 обновилась, и разработчики фирмы «1С» переименовали или удалили какой-то реквизит из документа СписаниеСРасчетногоСчета (либо перенесли его в другую табличную часть), а правила обмена не обновлялись, то загрузчик попытается записать данные в несуществующее поле.
Рассмотрим по шагам методы отладки и устранения этой ошибки.
Самый простой способ локализовать «безымянный» реквизит — открыть сохраненный файл правил обмена (не файл с данными, а именно XML-файл правил) в текстовом редакторе типа Notepad++ или Visual Studio Code.
Ctrl + F и запустите поиск строки: Приемник="" или Источник="".<Свойство>, у которого атрибут Приемник пустой (или отсутствует вовсе, при этом у него нет признака виртуального свойства), обратите внимание на родительский тег ПКО. Так вы поймете, в правилах какого именно объекта закралась ошибка.Если визуальный поиск в XML не дал результатов, воспользуемся штатным механизмом отладки, встроенным в обработку «Универсальный обмен данными XML»:
ИмяРеквизита или Свойство.Приемник). Вы сразу увидите, на каком именно реквизите спотыкается система.После выявления проблемного реквизита останется лишь исправить его в конфигурации КД 2.1 — либо обновив описание метаданных приемника, либо удалив некорректное правило конвертации свойства.