Как правильно рассчитать свободный остаток на складе в 1С:ERP 2.5.27 при обновлении конфигурации?

При обновлении конфигураций 1С:ERP Управление предприятием и Комплексная автоматизация с релиза 2.5.22 до 2.5.27 разработчики часто сталкиваются с существенными изменениями в подсистеме обеспечения потребностей и складского учета. Одним из таких нововведений стало появление подсистемы контроля качества и входного контроля материалов. В типовых отчетах (например, в прайс-листах и обработках подбора) алгоритмы получения доступного остатка значительно усложнились. Разберем, сохраняет ли свою работоспособность классический упрощенный запрос к регистру ЗапасыИПотребности, если новая функциональная опция не используется, и какие подводные камни таит в себе этот подход.

Исходный запрос: расчет остатка без подсистемы контроля качества

Рассмотрим типовой запрос, который многие разработчики применяли в версиях линейки 2.5.22 для формирования прайс-листов и быстрого вывода доступного товара на складах:

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

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

Скрытые проблемы и узкие места формулы

Выясним причину, почему прямой расчет разницы ресурсов регистра накопления может выдавать некорректные результаты в реальной эксплуатации базы:

1. Вычитание ресурса РезервироватьПоМереПоступленияОстаток из наличия:
   Данный ресурс предназначен для фиксации потребностей под ожидаемые поступления (заказы поставщикам, перемещения в пути), а не под фактический складской запас. Если на складе есть реальный физический остаток и одновременно оформлены заказы поставщикам с резервами под них, вычитание этого ресурса из ресурса ВНаличииОстаток приведет к необоснованному занижению свободного остатка на текущую дату. Кроме того, перенос резерва из состояния «По мере поступления» в «На складе» выполняется регламентным заданием по границе обеспечиваемого периода. Любая задержка регламентного задания вызовет рассинхронизацию данных.
2. Ордерные склады и статус отгрузки:
   На складах, где включена ордерная схема документооборота, после проведения финансового документа (например, РеализацияТоваровУслуг) до фактической отгрузки по расходному ордеру товар переходит в статус отгружаемого. В регистре ЗапасыИПотребности это состояние отражается отдельной логикой, которая не учтена в простой линейной формуле.
3. Жесткий отбор по пустому назначению:
   Условие Назначение = ЗНАЧЕНИЕ(Справочник.Назначения.ПустаяСсылка) полностью отсекает товары, зарезервированные или поступившие под конкретные направления деятельности, долгосрочные проекты или заказы. Если бизнес-процессы компании допускают свободную продажу остатков с определенных назначений, такой запрос вернет нулевой остаток, скрыв доступные позиции от менеджеров.

Архитектурные особенности: распределенный режим и фоновые задания

Начиная с версий 2.5, в системе реализован производительный режим распределения запасов. Разберем по шагам, как устроена эта модель:

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

Рекомендуемые альтернативные решения

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

1. Чтение предрассчитанных данных из регистра сведений РаспределениеЗапасов:
   Если в информационной базе активен фоновый расчет распределения, свободный складской остаток уже посчитан. Он находится в записи с состоянием ОстатокНаСкладе и хранится в явном ресурсе Свободно. Запрос к данному регистру сведений выполняется значительно быстрее, создает минимальную нагрузку на СУБД и полностью соответствует типовым отчетам программы.
2. Использование типового программного интерфейса (API):
   Вместо написания собственных запросов к таблицам остатков правильнее использовать методы общих модулей подсистемы обеспечения потребностей. Типовой программный код автоматически учитывает состояние функциональных опций (включая входной контроль качества партий), режим работы склада и наличие обособлений. Это гарантирует бесперебойную работу доработок при последующих обновлениях конфигурации на новые релизы.