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