В современных версиях конфигурации «Управление торговлей» (начиная с 11.5) механизмы резервирования и движения товаров с резервами претерпели значительные изменения по сравнению с более старыми редакциями. Теперь это не просто запись в один регистр накопления, а сложная экосистема, взаимодействующая с подсистемой обеспечения потребностей и динамическим распределением запасов. Разберем по шагам, как интегрировать свой документ в эту схему, чтобы резервы отображались корректно во всех типовых отчетах и формах подбора.
Прежде чем приступать к написанию кода, проанализируем, как система хранит данные о резервах и проводит выравнивание остатков. В УТ 11.5 логика разделена на два уровня:
ЗапасыИПотребности: это первичный источник данных. Здесь фиксируется сам факт возникновения потребности. Если ваш документ делает приход по этому регистру с определенным вариантом обеспечения, система «понимает», что товар затребован.РаспределениеЗапасов: это производный регистр. Он не заполняется напрямую при проведении в обычном смысле, а обновляется программно. Именно данные из этого регистра используются в форме «Остатки и доступность товаров». Если вы запишете данные только в ЗапасыИПотребности, но проигнорируете распределение, ваш резерв будет «невидимым» для большинства типовых механизмов.Чтобы система начала воспринимать новый документ как полноценный участник товародвижения, его необходимо включить в состав нескольких определяемых типов. Без этого шага типовые серверные модули будут выдавать ошибки при попытке обработать ссылку на ваш документ.
Рассмотрим, в какие типы нужно добавить ссылку на ваш документ:
ИсточникЗапасовИПотребностей — основной тип для работы с одноименным регистром.ОснованиеКонтроляЗапасов — необходим, если вы планируете задействовать проверку остатков при проведении.ОбъектРаспределенияЗапасов — критически важен для работы фоновых заданий, которые пересчитывают остатки и резервы в реальном времени.Перейдем к реализации программной части. В УТ 11.5 крайне не рекомендуется писать движения напрямую в набор записей регистра. Вместо этого следует использовать механизмы общего модуля ЗапасыСервер. Рассмотрим типовой алгоритм в обработке проведения документа.
Сначала подготовим структуру для формирования движений. Проанализируем следующий пример кода:
Процедура ОбработкаПроведения(Отказ, РежимПроведения)
// Подготавливаем таблицу для движений
ТаблицаДвижений = ЗапасыСервер.ПодготовитьДвиженияЗапасыИПотребности();
// Заполняем данные (это можно вынести в отдельную функцию модуля менеджера)
СформироватьТаблицуЗапасов(ТаблицаДвижений, Ссылка);
// Отражаем движения в регистре
ЗапасыСервер.ОтразитьЗапасыИПотребности(Ссылка, ТаблицаДвижений, Движения.ЗапасыИПотребности, Отказ);
// Не забываем про обновление распределения!
Если Не Отказ Тогда
РаспределениеЗапасовДвижения.ОбновитьЗаписиПоДокументу(Ссылка);
КонецЕсли;
КонецПроцедуры
Выясним причину использования РаспределениеЗапасовДвижения.ОбновитьЗаписиПоДокументу(Ссылка). Этот метод инициирует немедленный пересчет данных в регистре сведений РаспределениеЗапасов на основании только что сделанных движений в регистре накопления. Если этого не сделать, данные обновятся только после выполнения регламентного задания, что создаст временной лаг и ошибки в оперативной работе склада.
Для корректного резервирования важно правильно заполнить измерения регистра. Основным полем, отвечающим за логику резерва, является ВариантОбеспечения. Рассмотрим основные значения:
Также важно правильно сформировать ключи аналитики учета номенклатуры. Вместо прямого заполнения склада и номенклатуры, система часто оперирует ключами. Посмотрим на пример получения ключа:
ПараметрыКлюча = НоменклатураКлиентСервер.ПараметрыКлючаАналитикиУчетаНоменклатуры();
ПараметрыКлюча.Номенклатура = СтрокаТовара.Номенклатура;
ПараметрыКлюча.Характеристика = СтрокаТовара.Характеристика;
ПараметрыКлюча.Склад = СкладДокумента;
КлючАналитики = НоменклатураКлиентСервер.ПолучитьКлючАналитикиУчетаНоменклатуры(ПараметрыКлюча);
В типовых решениях (например, в Заказе клиента) резерв создается только при определенном статусе документа (например, «К выполнению»). Если вы создаете свой документ, реализуйте аналогичную проверку. Если документ находится в статусе «Черновик» или «На согласовании», движения по регистру ЗапасыИПотребности либо не должны создаваться, либо должны иметь другой вариант обеспечения (например, «Не обеспечивать»).
Проанализируем ситуации, которые могут привести к некорректной работе вашего механизма:
ЗапасыИПотребности. Ваши прямые записи будут затерты при первом же обновлении системы.ОчередьРаспределенияЗапасов. Если вы делаете движения программно (например, обработкой), важно добавлять ссылку на ваш документ в эту очередь, чтобы фоновые задания знали о необходимости пересчета.Реализация собственного резервирования требует строгого следования архитектуре БСП. Основной принцип: сначала записываем потребность в ЗапасыИПотребности через ЗапасыСервер, затем инициируем обновление через РаспределениеЗапасовДвижения. Таким образом, ваш документ станет органичной частью системы обеспечения, будет учитываться в отчетах «Остатки и доступность» и правильно обрабатываться складскими формами.