Как получить данные о товарах в резерве и к обеспечению на определенную историческую дату в 1С:ERP?

Программист 1С v8.3 (Управляемые формы) 1С:ERP Управление предприятием Управленческий учет Торговля и дистрибуция
← На главную

При переходе с других систем (например, УПП) или при попытке построить глубокую управленческую аналитику в 1С:ERP, многие специалисты сталкиваются с неочевидной проблемой. Задача кажется тривиальной: сформировать отчет "Остатки и доступность" не на текущий момент, а, скажем, на первое число прошлого месяца. Мы хотим увидеть, сколько товара было зарезервировано, сколько требовалось к обеспечению и каков был свободный остаток именно в тот день.

Однако, открыв типовые отчеты, мы обнаруживаем, что данные по резервам и обеспечению доступны либо "на сейчас", либо отображаются некорректно при попытке выбрать прошлый период. Давайте разберем архитектурные особенности 1С:ERP, поймем, почему так происходит, и найдем способы решения этой задачи.

Понимание архитектуры: Остатки vs Намерения

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

1. Физический остаток. Это осязаемая величина. Товар либо лежит на полке, либо нет. В 1С:ERP за это отвечает регистр накопления ТоварыНаСкладах. Получить остаток на любую секунду времени в прошлом очень просто — платформа хранит физические движения (приходы и расходы).

2. Резервы и обеспечение. В идеологии 1С:ERP резерв — это не просто "галочка" на товаре. Это состояние потребности, которое живет в регистре накопления ЗапасыИПотребности (в старых версиях функционал делился с СвободныеОстатки, но в современных релизах ERP 2.4/2.5 архитектура изменилась).

Проблема кроется в том, как система работает с жизненным циклом заказа:

  1. Менеджер создает заказ, ставит статус "Резервировать". В регистре появляется запись о потребности.
  2. Через неделю происходит отгрузка. Заказ закрывается. Движения по регистру ЗапасыИПотребности, которые формировали резерв, "закрываются" (списываются), так как потребность удовлетворена.
  3. Если менеджер задним числом изменит дату отгрузки или отменит резерв в старом заказе, движения в регистре обновятся.

Таким образом, резерв — это "намерение", которое существует до момента его исполнения. Анализ форумов и документации показывает, что многие считают получение исторического резерва невозможным ("бредовым"), так как резерв — понятие динамическое. Однако для анализа эффективности работы отдела закупок или продаж нам необходимы эти цифры.

Решение 1: Использование регистра накопления "ЗапасыИПотребности"

Самый прямой технический способ получить данные — обратиться к виртуальной таблице остатков регистра накопления. Несмотря на то, что типовой отчет "Остатки и доступность" заточен под оперативную работу, данные в базе есть.

Рассмотрим, как программно получить "Резерв" на дату. Нам необходимо построить запрос к регистру ЗапасыИПотребности.

Алгоритм расчета свободного остатка на дату &Период выглядит так:

  1. Получаем физический остаток из ТоварыНаСкладах.Остатки на &Период.
  2. Получаем объем зарезервированного товара из ЗапасыИПотребности.Остатки на &Период.
  3. Вычитаем из физического остатка резерв.

Примерная структура запроса для получения резервов:


ВЫБРАТЬ
    Запасы.Номенклатура,
    Запасы.Характеристика,
    Запасы.Склад,
    СУММА(Запасы.КоличествоОстаток) КАК ВРезерве
ИЗ
    РегистрНакопления.ЗапасыИПотребности.Остатки(&НаДату, ) КАК Запасы
ГДЕ
    // Важно правильно отфильтровать типы запасов, соответствующие резерву
    // В зависимости от версии ERP это может быть измерение "ТипЗапаса" или анализ "Назначения"
    Запасы.ТипЗапаса = ЗНАЧЕНИЕ(Перечисление.ТипыЗапасов.Резерв)
СГРУППИРОВАТЬ ПО
    Запасы.Номенклатура,
    Запасы.Характеристика,
    Запасы.Склад

Важное предостережение: Этот метод покажет картину "как система видит прошлое СЕЙЧАС". Если вчера заказ был в резерве, а сегодня менеджер снял резерв и перепровел документ вчерашним днем — отчет за "вчера", сформированный сегодня, покажет, что резерва не было. Это называется "проблема заднего числа".

Решение 2: Снэпшоты (Срезы данных)

Если ваша задача — видеть реальную динамику того, что видели менеджеры в конкретный день (например, "почему мы не отгрузили товар 1-го числа, если склад был полный?"), метод прямого запроса к регистру может не подойти из-за изменений документов задним числом.

В этом случае профессиональное сообщество рекомендует использовать механизм снэпшотов (Snapshots). Это не типовой функционал, его нужно дорабатывать, но он дает 100% достоверность истории.

Как это реализовать:

  1. Создаем новый (необоротный) Регистр Сведений, например ИсторияОстатковИРезервов.
  2. Добавляем измерения: ДатаЗаписи, Номенклатура, Склад.
  3. Добавляем ресурсы: ОстатокНаСкладе, ВРезерве, КОбеспечению.
  4. Настраиваем Регламентное Задание, которое запускается каждую ночь (или чаще).
  5. В задании программно формируем данные (можно использовать функции типового отчета "Остатки и доступность") и записываем их в наш регистр с текущей датой.

Таким образом, мы фиксируем состояние системы. Даже если менеджер завтра изменит заказ месячной давности, запись в регистре ИсторияОстатковИРезервов останется неизменной, и вы сможете доказать, что на тот момент товар действительно числился в резерве.

Решение 3: Версионирование объектов

Если доработка конфигурации нежелательна, можно использовать типовой функционал "История изменений" (Версионирование).

Включив версионирование для документов ЗаказКлиента, вы сможете видеть, в какой момент времени статус строки заказа изменился с "К обеспечению" на "Резервировать". Однако построить сводный отчет "сколько всего было в резерве на дату X" на основании версий объектов крайне сложно и ресурсоемко с точки зрения производительности системы. Этот метод подходит только для точечного расследования по конкретным заказам.

Итоги и рекомендации

Подводя итог обсуждению проблемы получения резервов на историческую дату в ERP:

Если вам нужно просто проанализировать доступность товаров на дату с учетом текущих проведенных документов, достаточно написать запрос к виртуальным таблицам остатков указанных выше регистров. Это закроет 90% задач управленческого учета.

← На главную