Почему в УТ 11.5 отличаются остатки в отчетах и в форме подбора товара, и как это исправить?

← На главную

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

В этой статье мы подробно разберем архитектуру хранения запасов в последних версиях конфигураций, выясним причины возникновения таких "фантомных" остатков и рассмотрим пошаговый алгоритм диагностики и лечения базы данных, основанный на реальном опыте решения подобной проблемы.

Архитектура хранения запасов: три кита УТ 11.5

Чтобы понять причину проблемы, нам нужно разобраться, откуда программа берет цифры. В старых версиях (УТ 11.4 и ранее) основным регистром для контроля обеспечения были СвободныеОстатки. В версии 11.5 архитектура изменилась. Теперь система опирается на три ключевых регистра:

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

Важный момент: форма подбора товаров показывает данные именно из регистра сведений РаспределениеЗапасов. Отчеты же чаще всего строятся по регистрам накопления (либо ТоварыНаСкладах, либо ЗапасыИПотребности). Если между этими таблицами возникает рассинхронизация, пользователь видит разные цифры.

Причины возникновения рассинхронизации

Проанализируем основные причины, почему данные в этих регистрах могут "разъехаться":

Асинхронное обновление. Регистр РаспределениеЗапасов часто обновляется фоновым заданием, а не в момент проведения документа (чтобы не блокировать работу). Если фоновое задание "зависло" или отключено, данные в подборе устаревают.
Некорректный переход или обновление. При обновлении с версий 11.4 на 11.5 происходит миграция данных. Ошибки в этом процессе могут привести к тому, что ТоварыНаСкладах верны, а ЗапасыИПотребности — нет.
Проблема "Фантомных серий". Это самый коварный случай, описанный в разбираемой нами ситуации. Если в базе велся учет по сериям, а затем эту опцию отключили (сняли галочку в настройках), данные в регистрах не очищаются автоматически. В базе остаются записи с заполненной серией и записи с пустой серией. Для системы это разные товары, которые могут давать "плюс" по одному измерению и "минус" по другому.

Диагностика: ищем отклонения с помощью запросов

Для начала нам необходимо определить масштаб бедствия. Нельзя просто взять и перезаполнить регистры наугад. Воспользуемся консолью запросов, чтобы сравнить данные в разных регистрах.

Шаг 1. Сравнение логических запасов и кэша распределения

Проверим, соответствует ли регистр ЗапасыИПотребности (основной для планирования) регистру РаспределениеЗапасов (тому, что видит пользователь в подборе).


ВЫБРАТЬ
    ЗапасыИПотребностиОстатки.Номенклатура КАК Номенклатура,
    РаспределениеЗапасов.Номенклатура КАК НоменклатураРаспЗап,
    ЗапасыИПотребностиОстатки.ВНаличииОстаток КАК ВНаличииОстаток,
    РаспределениеЗапасов.ВНаличии КАК РаспрНаличие,
    ISNULL(ЗапасыИПотребностиОстатки.ВНаличииОстаток, 0) - ISNULL(РаспределениеЗапасов.ВНаличии, 0) КАК Откл
ИЗ
    РегистрНакопления.ЗапасыИПотребности.Остатки(, ) КАК ЗапасыИПотребностиОстатки
        ПОЛНОЕ СОЕДИНЕНИЕ РегистрСведений.РаспределениеЗапасов КАК РаспределениеЗапасов
        ПО (ЗапасыИПотребностиОстатки.Номенклатура = РаспределениеЗапасов.Номенклатура)
ГДЕ
    ISNULL(ЗапасыИПотребностиОстатки.ВНаличииОстаток, 0) <> ISNULL(РаспределениеЗапасов.ВНаличии, 0)

Если этот запрос выдает данные, значит, механизм обновления РаспределениеЗапасов не сработал корректно. Часто это лечится запуском штатной обработки "Исправление данных по остаткам товаров" или перезапуском регламентного задания.

Шаг 2. Сравнение физических и логических остатков

Это более глубокая проблема. Если ТоварыНаСкладах (физика) не совпадают с ЗапасыИПотребности (логика), то система планирования обеспечения работает на неверных данных. Именно это часто является первопричиной.


ВЫБРАТЬ
    ЗапасыИПотребностиОстатки.Номенклатура КАК Номенклатура,
    ЗапасыИПотребностиОстатки.ВНаличииОстаток КАК ВНаличииОстаток,
    ТоварыНаСкладахОстатки.Номенклатура КАК НоменклатураСклад,
    ТоварыНаСкладахОстатки.ВНаличииОстаток КАК ВНаличииСклад
ИЗ
    РегистрНакопления.ЗапасыИПотребности.Остатки КАК ЗапасыИПотребностиОстатки
        ПОЛНОЕ СОЕДИНЕНИЕ РегистрНакопления.ТоварыНаСкладах.Остатки КАК ТоварыНаСкладахОстатки
        ПО (ЗапасыИПотребностиОстатки.Номенклатура = ТоварыНаСкладахОстатки.Номенклатура)
ГДЕ
    ISNULL(ЗапасыИПотребностиОстатки.ВНаличииОстаток, 0) <> ISNULL(ТоварыНаСкладахОстатки.ВНаличииОстаток, 0)

Этот запрос показывает товары, по которым есть фундаментальное расхождение. Как выяснилось в ходе обсуждения, причиной часто является "грязный" учет серий.

Решение проблемы "Фантомных серий"

Рассмотрим ситуацию: в базе велся учет по сериям (например, сроки годности). Потом учет отключили. В регистре ТоварыНаСкладах могут остаться движения с заполненной аналитикой "Серия". А новые движения идут с пустой серией. Визуально в отчетах (если серии выключены в настройках отчета) все схлопывается в ноль, но на уровне базы данных (SQL) это разные записи.

Симптомы:

В отчетах без детализации всё красиво.
При попытке списания товара возникает ошибка "Не хватает остатка", хотя остаток вроде бы есть.
Запросы выше показывают расхождения.

Алгоритм исправления:

Временное включение серий (на копии базы для теста).
Если вы подозреваете проблему с сериями, имеет смысл временно включить функциональную опцию использования серий. Затем сформировать отчет «Ведомость по товарам на складах» с группировкой по сериям. Вы увидите "минусы" на пустых сериях и "плюсы" на старых сериях (или наоборот).
Корректировка данных.
Самый надежный способ — использовать документ Корректировка регистров или документы Списание товаров + Оприходование товаров.

Вам необходимо:
- Списать количество "зависших" товаров с указанием старых серий (чтобы обнулить их остаток в регистре).
- Оприходовать это же количество товара уже без указания серии (с пустой аналитикой).
Если товаров много (как в обсуждаемом случае — сотни позиций), делать это руками трудоемко. Можно написать простую обработку, которая:
- Читает остатки регистра ТоварыНаСкладах в разрезе серий.
- Формирует движения, закрывающие серии в ноль и открывающие остаток на пустую серию.
Выравнивание регистров.
После того как вы привели в порядок физический регистр ТоварыНаСкладах (убрали лишние аналитики), необходимо синхронизировать его с ЗапасыИПотребности.

Для этого в разделе НСИ и администрирование – Поддержка и обслуживание – Корректировка данных существует обработка Исправление расхождений в остатках товаров и резервах. Она анализирует ТоварыНаСкладах и дописывает корректирующие движения в ЗапасыИПотребности.
Обновление Распределения запасов.
Когда ЗапасыИПотребности выровнены с ТоварыНаСкладах, регистр РаспределениеЗапасов должен обновиться автоматически регламентным заданием. Если этого не произошло, можно воспользоваться инструментом Исправление данных по остаткам товаров (в том же меню корректировки данных) или принудительно перезапустить фоновое задание по распределению запасов.

Резюме

Проблема отличия остатков в подборе и отчетах в УТ 11.5 почти всегда указывает на рассинхронизацию цепочки регистров:
ТоварыНаСкладах (Физика) -> ЗапасыИПотребности (Логика) -> РаспределениеЗапасов (Кэш для форм).

Решение всегда начинается с проверки "фундамента" — регистра ТоварыНаСкладах. Если в нем есть "мусор" в виде старых серий при отключенном учете, никакие пересчеты итогов не помогут, пока вы не схлопнете аналитику. После исправления физических остатков используйте типовые механизмы корректировки данных для выравнивания зависимых регистров.