Управление назначениями запасов: реклассификация и перераспределение в 1С:ERP

14 августа 2026 · infolimp.ru

Контекст и ситуация

Механизм назначений запасов в 1С:ERP 2.5 — это не просто справочный признак. Это система, определяющая, какой заказ (клиентский, внутренний, производственный) получит конкретную партию товара при дефиците. Реклассификация (изменение назначения) и перераспределение (физическое перемещение между складами/ячейками) — два разных процесса, которые в интерфейсе часто смешивают.

Ключевой тезис: Реклассификация меняет только аналитику учёта, не затрагивая физическое местоположение. Перераспределение — наоборот. Попытка сделать одно через другое приводит к «зависанию» резервов в статусе Ожидание.

Технический разбор: как работает резервирование

Когда вы меняете назначение запаса через документ «Реклассификация товаров», система выполняет две операции в регистрах:

• Списание с аналитики старого назначения (например, «Свободный остаток» → «Под заказ клиента»);
• Приход на новое назначение, но с тем же физическим складом и ячейкой.

Проблема возникает, когда на момент реклассификации заказ, под который вы хотите перевести товар, уже имеет частичный резерв по другому складу. Механизм не проверяет пересечение временных интервалов резервирования — он просто накладывает новый слой поверх старого.

// Пример: проверка пересечения резервов перед реклассификацией
Запрос = Новый Запрос;
Запрос.Текст = 
"ВЫБРАТЬ
 |  Резервы.Номенклатура,
 |  Резервы.Склад,
 |  РЕЗЕРВЫ.КоличествоОстаток КАК КоличествоРезерва
 |ИЗ
 |  РегистрНакопления.ТоварыНаСкладах.Остатки(
 |    &МоментВремени,
 |    Заказ = &ЗаказПолучатель И
 |    Номенклатура = &Номенклатура
 |  ) КАК Резервы
 |ГДЕ
 |  Резервы.КоличествоОстаток > 0";

Запрос.УстановитьПараметр("МоментВремени", ТекущаяДата());
Запрос.УстановитьПараметр("ЗаказПолучатель", СсылкаНаЗаказ);
Запрос.УстановитьПараметр("Номенклатура", НоменклатураСсылка);

Результат = Запрос.Выполнить();
Выборка = Результат.Выбрать();

Пока Выборка.Следующий() Цикл
    // Если резерв уже есть на другом складе — реклассификация создаст дубль
    Сообщить("Внимание: товар уже зарезервирован на складе " + Выборка.Склад);
КонецЦикла;

Ловушки реклассификации: что не пишут в справке

На основе реальных примеров внедрений выделим три типовые ошибки, которые совершают даже опытные специалисты.

Ловушка №1: «Реклассификация без указания заказа-получателя»

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

Предупреждение: Проверяйте заполнение реквизита «Заказ» в документе реклассификации. Пустая аналитика = товар, который числится зарезервированным, но не может быть отгружен ни одному клиенту.

Ловушка №2: «Перераспределение через перемещение без учёта назначений»

Стандартный документ «Перемещение товаров» не переносит назначения. Если вы перемещаете товар со склада А (назначение «Под заказ клиента 1») на склад Б, то на складе Б товар приходуется как «Свободный остаток». Заказ клиента 1 остаётся без резерва, хотя физически товар существует. Это приводит к каскадному сбою: система пытается зарезервировать товар заново, но уже на другом складе, создавая избыточные резервы.

// Фрагмент обработки перемещения с сохранением назначения
// Через реальный API ИТС: использование регистра "ТоварыНаСкладах"
НаборЗаписей = РегистрыНакопления.ТоварыНаСкладах.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.Регистратор.Установить(ДокументПеремещение);

// Читаем текущие записи с назначениями
Запрос = Новый Запрос;
Запрос.Текст = 
"ВЫБРАТЬ
 |  ТоварыНаСкладах.Номенклатура,
 |  ТоварыНаСкладах.Склад,
 |  ТоварыНаСкладах.Заказ,
 |  ТоварыНаСкладах.Назначение,
 |  ТоварыНаСкладах.Количество
 |ИЗ
 |  РегистрНакопления.ТоварыНаСкладах КАК ТоварыНаСкладах
 |ГДЕ
 |  ТоварыНаСкладах.Регистратор = &Регистратор";

// ... обработка с переносом назначения в новый склад
// (полный код — в статье на Infostart)

Ловушка №3: «Массовая реклассификация в период закрытия месяца»

При массовой обработке (например, переквалификация 1000 позиций) в момент, когда работает регламентное задание «Расчёт себестоимости», возникает блокировка на уровне таблиц регистров. Механизм реклассификации использует УправлениеБлокировкамиДанных, но не все версии ERP корректно обрабатывают взаимоблокировки. Результат — часть документов проводится, часть — нет, а остатки «разъезжаются».

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

На основе анализа типовых ошибок сформулируем алгоритм, который минимизирует риски.

Чек-лист: безопасная реклассификация

1. Проверьте пересечение резервов — выполните запрос из примера выше перед созданием документа.
2. Заполните заказ-получатель — если назначение «Под заказ», реквизит «Заказ» обязателен.
3. Используйте специализированную обработку — для массовых операций применяйте «Помощник реклассификации» (меню: Склад → Сервис), а не ручное создание документов.
4. Избегайте пиковых нагрузок — не запускайте массовую реклассификацию одновременно с регламентными заданиями по расчёту себестоимости.
5. Контролируйте результат — после операции проверьте отчёт «Анализ резервов» на наличие записей с пустым заказом.

Типичные ошибки и их последствия