При переходе с других систем (например, УПП) или при попытке построить глубокую управленческую аналитику в 1С:ERP, многие специалисты сталкиваются с неочевидной проблемой. Задача кажется тривиальной: сформировать отчет "Остатки и доступность" не на текущий момент, а, скажем, на первое число прошлого месяца. Мы хотим увидеть, сколько товара было зарезервировано, сколько требовалось к обеспечению и каков был свободный остаток именно в тот день.
Однако, открыв типовые отчеты, мы обнаруживаем, что данные по резервам и обеспечению доступны либо "на сейчас", либо отображаются некорректно при попытке выбрать прошлый период. Давайте разберем архитектурные особенности 1С:ERP, поймем, почему так происходит, и найдем способы решения этой задачи.
Чтобы разобраться в проблеме, нам нужно разделить два понятия: физический остаток и потребность (резерв).
1. Физический остаток. Это осязаемая величина. Товар либо лежит на полке, либо нет. В 1С:ERP за это отвечает регистр накопления ТоварыНаСкладах. Получить остаток на любую секунду времени в прошлом очень просто — платформа хранит физические движения (приходы и расходы).
2. Резервы и обеспечение. В идеологии 1С:ERP резерв — это не просто "галочка" на товаре. Это состояние потребности, которое живет в регистре накопления ЗапасыИПотребности (в старых версиях функционал делился с СвободныеОстатки, но в современных релизах ERP 2.4/2.5 архитектура изменилась).
Проблема кроется в том, как система работает с жизненным циклом заказа:
ЗапасыИПотребности, которые формировали резерв, "закрываются" (списываются), так как потребность удовлетворена.Таким образом, резерв — это "намерение", которое существует до момента его исполнения. Анализ форумов и документации показывает, что многие считают получение исторического резерва невозможным ("бредовым"), так как резерв — понятие динамическое. Однако для анализа эффективности работы отдела закупок или продаж нам необходимы эти цифры.
Самый прямой технический способ получить данные — обратиться к виртуальной таблице остатков регистра накопления. Несмотря на то, что типовой отчет "Остатки и доступность" заточен под оперативную работу, данные в базе есть.
Рассмотрим, как программно получить "Резерв" на дату. Нам необходимо построить запрос к регистру ЗапасыИПотребности.
Алгоритм расчета свободного остатка на дату &Период выглядит так:
ТоварыНаСкладах.Остатки на &Период.ЗапасыИПотребности.Остатки на &Период.Примерная структура запроса для получения резервов:
ВЫБРАТЬ
Запасы.Номенклатура,
Запасы.Характеристика,
Запасы.Склад,
СУММА(Запасы.КоличествоОстаток) КАК ВРезерве
ИЗ
РегистрНакопления.ЗапасыИПотребности.Остатки(&НаДату, ) КАК Запасы
ГДЕ
// Важно правильно отфильтровать типы запасов, соответствующие резерву
// В зависимости от версии ERP это может быть измерение "ТипЗапаса" или анализ "Назначения"
Запасы.ТипЗапаса = ЗНАЧЕНИЕ(Перечисление.ТипыЗапасов.Резерв)
СГРУППИРОВАТЬ ПО
Запасы.Номенклатура,
Запасы.Характеристика,
Запасы.Склад
Важное предостережение: Этот метод покажет картину "как система видит прошлое СЕЙЧАС". Если вчера заказ был в резерве, а сегодня менеджер снял резерв и перепровел документ вчерашним днем — отчет за "вчера", сформированный сегодня, покажет, что резерва не было. Это называется "проблема заднего числа".
Если ваша задача — видеть реальную динамику того, что видели менеджеры в конкретный день (например, "почему мы не отгрузили товар 1-го числа, если склад был полный?"), метод прямого запроса к регистру может не подойти из-за изменений документов задним числом.
В этом случае профессиональное сообщество рекомендует использовать механизм снэпшотов (Snapshots). Это не типовой функционал, его нужно дорабатывать, но он дает 100% достоверность истории.
Как это реализовать:
ИсторияОстатковИРезервов.ДатаЗаписи, Номенклатура, Склад.ОстатокНаСкладе, ВРезерве, КОбеспечению.Таким образом, мы фиксируем состояние системы. Даже если менеджер завтра изменит заказ месячной давности, запись в регистре ИсторияОстатковИРезервов останется неизменной, и вы сможете доказать, что на тот момент товар действительно числился в резерве.
Если доработка конфигурации нежелательна, можно использовать типовой функционал "История изменений" (Версионирование).
Включив версионирование для документов ЗаказКлиента, вы сможете видеть, в какой момент времени статус строки заказа изменился с "К обеспечению" на "Резервировать". Однако построить сводный отчет "сколько всего было в резерве на дату X" на основании версий объектов крайне сложно и ресурсоемко с точки зрения производительности системы. Этот метод подходит только для точечного расследования по конкретным заказам.
Подводя итог обсуждению проблемы получения резервов на историческую дату в ERP:
ЗапасыИПотребности. Вы можете написать внешний отчет на СКД, соединив данные этого регистра с ТоварыНаСкладах.Если вам нужно просто проанализировать доступность товаров на дату с учетом текущих проведенных документов, достаточно написать запрос к виртуальным таблицам остатков указанных выше регистров. Это закроет 90% задач управленческого учета.