Как исправить ошибку статуса УПД в обработке СБИС для 1С при удалении счета-фактуры?

В процессе работы с внешними обработками от операторов ЭДО, в частности со СБИС, пользователи 1С:Бухгалтерия нередко сталкиваются с ситуациями, когда автоматизация ведет себя не так, как ожидает бухгалтер. Одной из таких проблем является некорректное определение статуса УПД при работе с реализациями, для которых счет-фактура была помечена на удаление или признана ошибочной.

Анализ проблемы взаимодействия 1С и СБИС

Разберем ситуацию, с которой сталкиваются специалисты: у нас есть документ Реализация товаров и услуг. В типовой конфигурации БП 3.0, если к реализации создана счет-фактура, 1С считает документ «фактурованным». Однако, если бухгалтер по ошибке выставил счет-фактуру, а затем пометил её на удаление или просто отменил проведение, для 1С это может означать, что документ не имеет действующей счет-фактуры. В этот момент обработка от СБИС может продолжать «видеть» связь с документом и отправлять в ЭДО УПД со статусом 1 (как счетом-фактурой), в то время как логика учета требует статус 2 (акт без счета-фактуры).

Почему это происходит? Обработки вендоров для ЭДО часто строятся на методах API, которые анализируют наличие записи в регистре или наличие привязанного объекта СчетФактураВыданный, игнорируя его состояние (проведен или не проведен, помечен на удаление). Это создает риск расхождения данных в Книге продаж и Книге покупок у контрагентов.

Возможные пути решения и методы борьбы

Когда вы сталкиваетесь с подобной некорректной работой штатной обработки, у нас есть несколько путей действий, от оперативных до радикальных:

1. Официальное обращение в поддержку вендора. Как показала практика, вендоры не всегда признают проблему с первого раза. Рекомендуем настаивать на детальном разборе, указывая на потенциальные налоговые риски. В конкретном случае, описанном пользователями, вендор Тензор признал ошибку и внес её в план исправлений для версии 43.
2. Локальное исправление через расширения. Это самый надежный способ для специалиста по 1С. Вместо изменения типового кода обработки, который затрется при следующем обновлении, создадим Расширение конфигурации или используем механизм Дополнительных отчетов и обработок, чтобы перехватить вызов метода формирования XML для СБИС.
3. Использование официальных обновлений. Мы выяснили, что систематические ошибки в работе обработок попадают в дорожную карту разработки вендора. Иногда достаточно дождаться планового релиза.

Реализация исправлений своими силами

Если ждать релиза возможности нет, разберем, как мы можем модифицировать логику формирования пакета документов. Основная задача — добавить проверку состояния счета-фактуры перед тем, как обработка сформирует статус УПД.

В коде обработки (обычно это модули объекта или формы) мы ищем функцию, которая отвечает за определение статуса УПД. Примерный алгоритм проверки должен выглядеть следующим образом:

// Пример логики проверки состояния счета-фактуры перед отправкой
Функция ПолучитьСтатусУПД(ДокументОснование) Экспорт
    Статус = 2; // По умолчанию считаем, что это акт без СФ
    
    Запрос = Новый Запрос;
    Запрос.Текст = "ВЫБРАТЬ Ссылка ИЗ Документ.СчетФактураВыданный ГДЕ ДокументОснование = &Основание И ПометкаУдаления = ЛОЖЬ И Проведен = ИСТИНА";
    Запрос.УстановитьПараметр("Основание", ДокументОснование);
    
    Результат = Запрос.Выполнить();
    Если Не Результат.Пустой() Тогда
        Статус = 1;
    КонецЕсли;
    
    Возврат Статус;
КонецФункции

Рассмотрим, что мы сделали в этом примере:

• Мы добавили проверку свойства ПометкаУдаления.
• Мы проверили свойство Проведен, чтобы исключить документы, которые были отменены пользователем.
• Мы гарантируем, что в ЭДО уйдет корректный статус, соответствующий актуальному состоянию учетной системы.

Рекомендации для специалистов по автоматизации

Для того чтобы ваша работа с обработками операторов была стабильной, рекомендуем придерживаться следующих правил:

Во-первых, не рекомендуйте пользователям выполнять действия вручную (через личный кабинет на сайте), если можно автоматизировать процесс. Ручной ввод — это прямой путь к ошибкам человеческого фактора.

Во-вторых, анализируйте код обработки. Даже если она предоставляется «как есть», понимание того, как именно происходит выгрузка документов, позволит вам быстро локализовать проблему и применить «заплатку» в виде расширения, не дожидаясь реакции технической поддержки.

В-третьих, если вы обнаружили системную ошибку, которая затрагивает множество ваших клиентов, оформляйте официальные запросы. Массовые запросы от компаний с юридическим обоснованием рисков — это единственный язык, на котором крупные операторы начинают слышать разработчиков 1С.

В конечном итоге, ситуация с ошибками — это естественный процесс развития ПО. Главное, что мы выяснили — важно фиксировать проблему, проверять актуальность версий и не бояться использовать собственные инструменты доработки для обеспечения стабильности бизнес-процессов.