Почему при обмене УТ 11 и БП 3.0 выгружаются несуществующие счета-фактуры полученные и как исправить ошибку даты основания?

Программист 1С v8.3 (Управляемые формы) 1С:Управление торговлей Бухгалтерский учет IT и автоматизация бизнеса

При настройке типовой синхронизации между конфигурациями «1С:Управление торговлей 11» и «1С:Бухгалтерия предприятия 3.0» через универсальный формат EnterpriseData (Конвертация данных 3.0) разработчики и администраторы нередко сталкиваются с ситуацией: в поток выгрузки попадает большое количество объектов Счет-фактура полученный, хотя в самой УТ 11 отдельного списка таких документов нет. Более того, при загрузке этих данных в БП 3.0 возникает исключительная ситуация: «Преобразование значения к типу Дата не может быть выполнено» в строке вычисления НачалоКвартала(ДатаОснования).

Разберем детально механизм формирования счетов-фактур, выясним корень проблемы с типами данных и рассмотрим пошаговые способы исправления ошибки.

1. Откуда берутся счета-фактуры полученные в УТ 11

Проанализируем структуру хранения данных в УТ 11. В отличие от конфигурации «Бухгалтерия предприятия», в УТ входящий счет-фактура не всегда оформляется отдельным документом базы данных. Реквизиты входящего документа (номер и дата входящего счета-фактуры) хранятся непосредственно в первичном документе Приобретение товаров и услуг (или Поступление услуг и прочих активов).

При выполнении обмена через EnterpriseData общий модуль МенеджерОбменаЧерезУниверсальныйФормат на стороне УТ 11 динамически создает XML-узлы для счетов-фактур на основании заполненных полей в накладных. Таким образом, даже если журнал счетов-фактур в УТ пуст, правила конвертации генерируют самостоятельные объекты для приемника БП 3.0, где наличие отдельного документа СчетФактураПолученный является обязательным для целей регламентированного учета НДС.

2. Почему возникает ошибка преобразования даты основания

Рассмотрим, в какой момент возникает сбой в БП 3.0. При проведении или программной записи загруженного документа СчетФактураПолученный в модуле менеджера вызывается алгоритм проверки налогового периода:


Запрос.УстановитьПараметр("НачалоНалоговогоПериода", НачалоКвартала(ДатаОснования));

Ошибка времени выполнения Преобразование значения к типу Дата не может быть выполнено говорит о том, что переменная ДатаОснования принимает значение Неопределено, Null или пустую строку. Это происходит по следующим причинам:

Документ-основание не найден или не загрузился: счет-фактура выгрузился, но связанный документ Приобретение товаров и услуг был отсечен фильтрами синхронизации (по периоду выгрузки, организации, подразделению) либо завершился с ошибкой при записи. В результате поле основания остается пустым.
Некорректная дата входящего документа в УТ: если в документе поступления в УТ 11 номер входящего документа был указан, а поле ДатаВходящегоДокумента осталось пустым или содержит значение 01.01.0001, сериализатор передает пустые данные, которые функция НачалоКвартала() не может обработать.
Фантомная регистрация изменений: после удаления или распроведения документов в УТ в таблицах регистрации изменений плана обмена могут оставаться зависшие ссылки.

3. Пошаговые способы решения проблемы

Разберем по шагам, как локализовать и устранить ошибку.

Шаг 1. Проверка и очистка очереди регистрации изменений

Откроем обработку Регистрация изменений для обмена в УТ 11:

Перейдем в узел плана обмена с БП 3.0.
Проверим зарегистрированные объекты в ветке Приобретение товаров и услуг и Счет-фактура полученный.
Если в списке присутствуют удаленные, помеченные на удаление или неактуальные документы за старые периоды, снимем их с регистрации.

Шаг 2. Анализ данных в базе-источнике (УТ 11)

Проверим документы поступления, вызвавшие сбой (по номеру входящего документа, фигурирующему в журнале регистрации):

Убедимся, что реквизиты Номер вх. и Дата вх. заполнены корректно.
Если дата отсутствует, укажем реальную дату первичного документа от поставщика.
Если счет-фактура по данной операции не выставлялся, полностью очистим оба поля (номер и дату входящего документа), чтобы алгоритм обмена не пытался формировать счет-фактуру.

Шаг 3. Отладка обработки загрузки в БП 3.0

Для детального анализа поведения загрузки в базе-приемнике (БП 3.0) подключимся отладчиком:

Откроем общий модуль МенеджерОбменаЧерезУниверсальныйФормат.
Найдем процедуру правила конвертации объектов: ПКО_Документ_СчетФактураПолученный_Получение_ПередЗаписьюПолученныхДанных.
Установим точку останова и проанализируем структуру переданных свойств (ПолученныеДанные) и заполнение реквизитов документа-основания.

Шаг 4. Программная защита от сбоя через расширение (БП 3.0)

Чтобы единичные ошибки в данных не блокировали весь процесс фонового обмена, подключим расширение конфигурации для БП 3.0 и переопределим проверку даты основания в модуле менеджера документа СчетФактураПолученный:


&Вместо("СформироватьЗапросПроверкиПериода")
Процедура Расш_СформироватьЗапросПроверкиПериода(Параметры, ДатаОснования)
    // Проверяем валидность переданной даты основания
    Если Не ЗначениеЗаполнено(ДатаОснования) Или ТипЗнч(ДатаОснования) <> Тип("Дата") Тогда
        ДатаОснования = ТекущаяДатаСеанса();
    КонецЕсли;
    
    ПродолжитьВызов(Параметры, ДатаОснования);
КонецПроцедуры

Такой подход защищает сеанс синхронизации от падения, позволяет загрузить остальные корректные документы и дает возможность бухгалтеру штатно обработать проблемный документ непосредственно в интерфейсе базы БП 3.0.

← На главную