Почему в отчете «Остатки и доступность товаров» принятый товар отображается как ожидаемый?

← На главную

В конфигурациях на базе ERP 2.0 (УТ 11, КА 2) пользователи часто сталкиваются с неприятной ситуацией: товар уже фактически принят на склад приходным ордером, но в отчете «Остатки и доступность товаров» он продолжает висеть в колонке «Ожидается». Это приводит к завышению доступного остатка, неверному расчету обеспечения и путанице в работе менеджеров по закупкам. Проанализируем причины этой проблемы и разберем способы ее решения.

Разбор механики работы графика поступления

Для начала разберем, как система понимает, что товар «ожидается». В 1С:УТ 11 за это отвечает регистр накопления ГрафикПоступленияТоваров (в новых версиях данные также аккумулируются в регистре ЗапасыИПотребности). Рассмотрим стандартную цепочку документов при ордерной схеме документооборота:

Заказ поставщику: При проведении создает запись в «приход» по регистру ГрафикПоступленияТоваров. С этого момента товар считается ожидаемым.
Приобретение товаров и услуг: Фиксирует переход права собственности, но при ордерной схеме не всегда закрывает ожидание на складе.
Приходный ордер на товары: Именно этот документ должен «погасить» ожидаемый приход, сделав расходное движение по тому же регистру.

Если цепочка нарушается или в документах возникают технические ошибки, «ожидание» не схлопывается, и мы видим задвоение остатка в отчете.

Причина 1: Нарушение последовательности ввода документов

Проанализируем ситуацию, когда пользователи создают документы не «на основании», а копированием или вручную. Если Приобретение товаров и услуг или Приходный ордер созданы без привязки к Заказу поставщику (или привязаны позже через ручной выбор распоряжения), связи в регистрах могут не установиться корректно.

Посмотрим на типичную ошибку: менеджеры сначала оформляют поступление и ордер, а лишь затем пытаются «подцепить» их к заказу. В этом случае регистр ГрафикПоступленияТоваров может содержать две разные ветки движений: одну от заказа, которая никогда не закроется, и другую от приобретения/ордера, которая живет своей жизнью. Выясним, что в таких случаях перепроведение цепочки в правильном порядке Заказ -> Приобретение -> Ордер часто помогает исправить ситуацию, но не всегда. Для выявления таких расхождений подойдёт инструмент сверки заказа поставщику и его поступлений.

Причина 2: Скрытый флаг «Закрывать график поступления»

Рассмотрим более глубокую техническую причину, выявленную в ходе анализа кода конфигурации. В документе Приходный ордер на товары существует реквизит ЗакрыватьГрафикПоступления. Этот флаг не выведен на форму, но именно он определяет, будет ли ордер делать движения по регистру графика поступления.

Выясним причину некорректного поведения: в типовой логике 1С этот флаг устанавливается в Истина при вызове процедуры РаспоряжениеВыборСервер. Однако, если документ создается программно или через определенные рабочие места (например, «Приемка»), данная процедура может не сработать. В итоге создается новый ордер, у которого флаг по умолчанию равен Ложь, и ожидаемый приход по заказу остается «висеть» в отчете.

Программное решение для исправления флага

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


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

Эту процедуру необходимо вызвать в обработчике ПриСозданииНаСервере или ПриИзменении реквизита Распоряжение. Это гарантирует, что при записи документа система корректно «схлопнет» ожидаемые остатки.

Причина 3: Механизм распределения запасов

Проанализируем еще один важный аспект. Начиная с версии 11.4, отчет «Остатки и доступность» во многом опирается на данные регистра сведений РаспределениеЗапасов. Этот регистр заполняется фоновым заданием. Если задание Распределение запасов зависло или выполняется с большой задержкой, данные в отчете могут быть неактуальными, даже если все документы проведены правильно. При необходимости можно воспользоваться обработкой для выравнивания остатков в отчете доступности.

Что мы можем сделать в этой ситуации:

Перейдем в раздел Обслуживание — Регламентные операции — Регламентные и фоновые задания.
Найдем задание «Распределение запасов» и проверим время его последнего запуска.
Если данные явно расходятся с реальностью, попробуем запустить обработку «Исправление заданий распределения запасов» (в некоторых релизах она доступна через функции для технического специалиста).