Как настроить работу ордерного склада в 1С:УНФ, чтобы товар не попадал в свободный остаток без подтверждения кладовщика

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

Анализируем причину проблемы: архитектура регистра «Запасы»

Для начала разберем внутреннее устройство программы. В отличие от более сложных решений (например, 1С:ERP), где складской и финансовый учет разнесены по разным регистрам, в 1С:УНФ основным «двигателем» остатков является единый регистр накопления Запасы. Именно на его основе строятся отчеты «Остатки товаров» и рассчитывается доступность товара в подборе.

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

Решение 1: Смена методологии (схема «Ордер — Накладная»)

Рассмотрим официальную позицию вендора и логику, заложенную в ИТС. В 1С:УНФ для ордерных складов приоритетным является сценарий «неотфактурованной поставки» или приемки товара раньше документов. Посмотрим на правильную последовательность действий:

1. Создание документа Приходный ордер: Кладовщик принимает товар по факту, пересчитывает его и фиксирует количество. В этот момент товар уже попадает на остатки склада, так как он физически прибыл.
2. Создание Приходной накладной на основании ордера: Менеджер или бухгалтер получает финансовые документы от поставщика и вводит их в систему, «закрывая» складской приход ценами и суммами.

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

Решение 2: Использование промежуточного склада «Товары в пути»

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

Разберем алгоритм по шагам:

1. Создаем новый склад (тип — «Обычный»), называем его Товары в пути.
2. В документе Приходная накладная в качестве склада-получателя указываем этот виртуальный склад. Товар числится за организацией, долг поставщику возник, но на Основном складе остатки не изменились.
3. В момент реальной разгрузки кладовщик создает документ Перемещение запасов с виртуального склада на Основной склад.
4. Поскольку Основной склад является ордерным, на основании перемещения создается Приходный ордер. Только после его проведения товар станет доступен для отгрузки с основного склада.

Решение 3: Программная корректировка движений (6 строк кода)

Если методологические решения не подходят и требуется, чтобы Приходная накладная по ордерному складу вообще не делала движений по регистру Запасы до момента ввода ордера, можно прибегнуть к доработке. Выясним причину, где именно происходит запись. В модуле менеджера или объекта документа Приходная накладная при обработке проведения система анализирует настройки склада.

Посмотрим на пример логики, которую можно внедрить в процедуру ОбработкаПроведения (через расширение):

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

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

Решение 4: Настройка контроля остатков

Выясним, как программа контролирует ордера. В настройках склада (карточка склада, раздел «Настройки») существует флаг Контролировать остатки по складским ордерам. Проанализируем его работу:

• Если флаг включен, система не позволит отгрузить (оформить Расходную накладную) товар, по которому нет Расходного ордера.
• Однако на приход этот флаг влияет иначе: он не запрещает видеть свободный остаток, сформированный накладной.

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

Резюме

Мы выяснили, что «ужас» ордерных складов в УНФ — это следствие упрощенной архитектуры программы, где финансовый приход первичнее складского. Чтобы навести порядок, выберите один из путей: либо приучите сотрудников делать Ордер перед Накладной, либо используйте транзитный склад для товаров в пути. Если же требуется жесткое разделение на уровне кода, будьте готовы к тому, что придется переписывать логику движений обоих документов (накладной и ордера) через механизмы расширений.