Почему проданный товар продолжает отображаться в подборе в 1С:УТ 11.5 и как это исправить?

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

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

Для понимания причины проблемы проанализируем, как 1С версии 11.5 работает с остатками. В отличие от старых версий, где подбор ориентировался преимущественно на регистры накопления, в новой архитектуре ключевую роль играет регистр сведений РаспределениеЗапасов.

1. Регистр накопления ТоварыНаСкладах — отвечает за физическое наличие. Именно по нему строятся классические ведомости и проверяется возможность проведения документа.
2. Регистр сведений РаспределениеЗапасов — отвечает за логическое состояние товаров. Он хранит информацию о том, сколько товара зарезервировано, сколько доступно для свободной продажи и сколько ожидается к поступлению.

Проблема «зависания» товара в подборе — это классический случай рассинхронизации между этими двумя объектами. Физически товара нет, но в регистре сведений он продолжает числиться как свободный остаток. Подбор обращается именно к РаспределениеЗапасов для быстрого вывода данных, поэтому пользователь видит неактуальные цифры.

Выясним причину ошибки: режим «Заказ как счет»

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

Логика работы системы в дефектных релизах выглядела следующим образом:

• При проведении документа Реализация товаров и услуг, созданного на основании такого заказа, система списывала товар из регистра накопления (физический остаток уходил).
• Однако механизм обновления регистра сведений РаспределениеЗапасов не срабатывал корректно. Транзакция по очистке этого товара из категории «Свободный остаток» попросту не инициировалась.

Способ 1: Установка патчей и перепроведение документов

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

Последовательность действий для исправления:

1. Перейдем в раздел НСИ и администрирование — Обслуживание — Обновление программы — Установленные исправления (патчи).
2. Убедимся, что загружены актуальные патчи для вашего релиза (в частности, исправляющие работу распределения запасов при оформлении реализаций по заказам).
3. После установки патчей необходимо перепровести документы за период, в котором наблюдаются расхождения. Это заставит систему заново сформировать записи в регистре РаспределениеЗапасов.

Способ 2: Использование обработки «Исправление ошибок в распределении запасов»

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

Разберем, как найти этот инструмент по шагам:

1. Включим режим «Функции для технического специалиста» (через главное меню — Настройки).
2. В окне поиска введем название обработки: Исправление ошибок в распределении запасов.
3. В открывшемся окне выберем склад или организацию, по которым наблюдаются расхождения.
4. Запустим процесс поиска и исправления ошибок.

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

Способ 3: Проверка единиц измерения и дат документов

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

Проанализируем запрос, который может использовать система:

// Пример логики, которую может использовать подбор
ВЫБРАТЬ
    РаспределениеЗапасов.Товар,
    РаспределениеЗапасов.Свободно
ИЗ
    РегистрСведений.РаспределениеЗапасов КАК РаспределениеЗапасов
ГДЕ
    РаспределениеЗапасов.Склад = &Склад

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

Также стоит проверить Единицы измерения. Если товар поступил в «упаковках по 10 шт.», а продавался в «штуках», и при этом были допущены ошибки в коэффициентах или в спецификациях номенклатуры, регистр распределения может зафиксировать дробный остаток, который в округленном виде будет виден в подборе как «1 шт.», хотя по факту товара нет.

Диагностика через отчеты

Для финальной проверки корректности данных мы рекомендуем сравнить два отчета:

1. «Ведомость по товарам на складах» — этот отчет строится по регистру накопления. Он является «истиной» в вопросе физического наличия.
2. «Остатки и доступность товаров» — этот отчет (особенно колонки «Доступно», «Резерв», «Ожидается») берет данные именно из регистра распределения запасов.

Если в первом отчете остаток равен 0, а во втором вы видите положительное число — вы нашли подтверждение того, что регистр РаспределениеЗапасов нуждается в исправлении вышеуказанными способами.

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