Как настроить контроль объемов отгрузки по договору или заказу клиента без резервирования в 1С:Управление торговлей?

← На главную

В оптовой торговле нередко встречается сценарий, когда долгосрочный договор с клиентом имеет жестко оговоренную спецификацию: конкретный перечень номенклатуры и фиксированный объем поставки. При этом отгрузка выполняется частями на протяжении длительного времени по мере поступления товара на склад или по заявкам покупателя. Возникает типовая управленческая задача: менеджер единожды фиксирует общий согласованный объем заказа, а операторы склада или учетчики выписывают документы реализации строго в пределах этого объема, не имея права отгрузить лишнее.

В типовой подсистеме закупок связка документа Заказ поставщику и последующих документов Приобретение товаров и услуг (или Поступление товаров и услуг) решает эту задачу штатно: накладная не позволяет оприходовать больше позиций, чем указано в заказе. Однако при попытке настроить зеркальную схему в продажах многие специалисты сталкиваются с неочевидными ограничениями программы. Разберем по шагам, почему типовые настройки контроля не дают ожидаемого результата и как правильно организовать контроль отгрузок.

Почему не работает типовой запрет отгрузки сверх заказа при режиме «Заказ как счет»

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

В настройках программы выбирается упрощенный вариант использования заказов: «Заказ как счет», чтобы исключить сложный механизм резервирования и статусов строк.
Для профиля групп доступа оператора отключается роль РеализацияСверхЗаказа (или снимается соответствующее право).
Создается документ Реализация товаров и услуг с количеством, превышающим указанное в заказе клиента. Документ успешно проводится без каких-либо предупреждений и блокировок со стороны системы.

Выясним причину такого поведения конфигурации. В прикладных решениях 1С (УТ 11, КА 2, ERP) подсистемы закупок и продаж концептуально разделены:

Заказ поставщику представляет собой плановый график поступлений. Он не взаимодействует с распределением запасов и резервами компании, поэтому контроль исполнения в накладной поступления работает по прямой табличной сверке суммарных количеств.
Заказ клиента глубоко интегрирован в подсистему «Обеспечение потребностей». В типовых режимах использования («Заказ только со склада» или «Заказ со склада и под заказ») контроль отгрузки опирается на регистр накопления Заказы клиентов и действия в табличной части (действие Отгрузить).
Когда мы включаем опцию «Заказ как счет», документ Заказ клиента полностью исключается из подсистемы обеспечения. Он перестает формировать остаточные движения по регистру Заказы клиентов. Механизм проведения накладной реализации в этом режиме в принципе пропускает проверку на превышение объемов. Соответственно, роль РеализацияСверхЗаказа физически не задействуется в коде проведения, и запрет не срабатывает.

Ограничения использования статусов обеспечения

Рассмотрим альтернативную типовую идею: вернуться к полному варианту работы с заказами, но не резервировать товар сразу на весь объем договора. В таком случае в строках долгосрочного заказа устанавливается действие «Не обеспечивать».

Здесь возникает административный тупик в распределении прав сотрудников:

Чтобы оператор смог провести документ реализации по строке заказа, эта строка должна быть переведена в статус «Отгрузить».
Если дать оператору полные права на изменение заказа клиента, теряется смысл контроля: оператор сможет произвольно изменить исходные лимиты договора, цены или номенклатурный состав. В типовой системе прав невозможно разрешить редактирование только одной колонки «Действие», заблокировав остальные реквизиты строки.
Если перекладывать изменение статусов на менеджера, процесс оперативной выписки накладных парализуется постоянными согласованиями и очередями на корректировку заказов.
Штатная регламентная обработка автоматического обеспечения потребностей тоже не всегда применима: если один и тот же товар на складе поступает общими партиями и расходуется на разные нужды (например, внутренние перемещения в другие подразделения), алгоритм распределения по правилу FIFO заблокирует свободный остаток под долгосрочный заказ клиента.

Вариант 1. Контроль превышения объемов через расширение конфигурации (рекомендуемый)

Наиболее надежный и удобный способ решения — сохранить режим «Заказ как счет» (избавив пользователей от механизма резервирования) и реализовать контроль лимитов через расширение конфигурации без снятия с поддержки.

Разберем логику проверки по шагам:

В расширении перехватываем процедуру проверки заполнения или проведение документа РеализацияТоваровУслуг (событие ОбработкаПроверкиЗаполнения или подписка на событие ОбработкаПроведения).
Для строк реализации, у которых заполнен реквизит ЗаказКлиента, формируем запрос к информационной базе.
Запрос сопоставляет количество в исходном заказе с суммарным количеством по всем ранее проведенным реализациям, оформленным по этому заказу, с добавлением количества из текущего документа.
Если накопленное количество превышает количество в заказе, проведение отменяется с выводом понятной ошибки оператору.

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


Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |	ТекНакладная.Номенклатура КАК Номенклатура,
    |	ТекНакладная.Характеристика КАК Характеристика,
    |	СУММА(ТекНакладная.Количество) КАК КоличествоВДокументе
    |ПОМЕСТИТЬ ВТ_ТекущиеСтроки
    |ИЗ
    |	&ТаблицаТоваров КАК ТекНакладная
    |СГРУППИРОВАТЬ ПО
    |	ТекНакладная.Номенклатура,
    |	ТекНакладная.Характеристика
    |;
    |
    |////////////////////////////////////////////////////////////////////////////////
    |ВЫБРАТЬ
    |	ЗаказТовары.Номенклатура КАК Номенклатура,
    |	ЗаказТовары.Характеристика КАК Характеристика,
    |	СУММА(ЗаказТовары.Количество) КАК ЛимитПоЗаказу
    |ПОМЕСТИТЬ ВТ_ЛимитыЗаказа
    |ИЗ
    |	Документ.ЗаказКлиента.Товары КАК ЗаказТовары
    |ГДЕ
    |	ЗаказТовары.Ссылка = &ЗаказКлиента
    |СГРУППИРОВАТЬ ПО
    |	ЗаказТовары.Номенклатура,
    |	ЗаказТовары.Характеристика
    |;
    |
    |////////////////////////////////////////////////////////////////////////////////
    |ВЫБРАТЬ
    |	РеализацияТовары.Номенклатура КАК Номенклатура,
    |	РеализацияТовары.Характеристика КАК Характеристика,
    |	СУММА(РеализацияТовары.Количество) КАК УжеОтгружено
    |ПОМЕСТИТЬ ВТ_ИсторияОтгрузок
    |ИЗ
    |	Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТовары
    |ГДЕ
    |	РеализацияТовары.Ссылка.ЗаказКлиента = &ЗаказКлиента
    |	И РеализацияТовары.Ссылка.Проведен = ИСТИНА
    |	И РеализацияТовары.Ссылка <> &ТекущаяРеализация
    |СГРУППИРОВАТЬ ПО
    |	РеализацияТовары.Номенклатура,
    |	РеализацияТовары.Характеристика
    |;
    |
    |////////////////////////////////////////////////////////////////////////////////
    |ВЫБРАТЬ
    |	ВТ_ТекущиеСтроки.Номенклатура КАК Номенклатура,
    |	ВТ_ТекущиеСтроки.Характеристика КАК Характеристика,
    |	ЕСТЬNULL(ВТ_ЛимитыЗаказа.ЛимитПоЗаказу, 0) КАК ЛимитПоЗаказу,
    |	ЕСТЬNULL(ВТ_ИсторияОтгрузок.УжеОтгружено, 0) КАК УжеОтгружено,
    |	ВТ_ТекущиеСтроки.КоличествоВДокументе КАК КоличествоВДокументе,
    |	ЕСТЬNULL(ВТ_ИсторияОтгрузок.УжеОтгружено, 0) + ВТ_ТекущиеСтроки.КоличествоВДокументе - ЕСТЬNULL(ВТ_ЛимитыЗаказа.ЛимитПоЗаказу, 0) КАК Превышение
    |ИЗ
    |	ВТ_ТекущиеСтроки КАК ВТ_ТекущиеСтроки
    |	ЛЕВОЕ СОЕДИНЕНИЕ ВТ_ЛимитыЗаказа КАК ВТ_ЛимитыЗаказа
    |		ПО ВТ_ТекущиеСтроки.Номенклатура = ВТ_ЛимитыЗаказа.Номенклатура
    |		И ВТ_ТекущиеСтроки.Характеристика = ВТ_ЛимитыЗаказа.Характеристика
    |	ЛЕВОЕ СОЕДИНЕНИЕ ВТ_ИсторияОтгрузок КАК ВТ_ИсторияОтгрузок
    |		ПО ВТ_ТекущиеСтроки.Номенклатура = ВТ_ИсторияОтгрузок.Номенклатура
    |		И ВТ_ТекущиеСтроки.Характеристика = ВТ_ИсторияОтгрузок.Характеристика
    |ГДЕ
    |	ЕСТЬNULL(ВТ_ЛимитыЗаказа.ЛимитПоЗаказу, 0) < ЕСТЬNULL(ВТ_ИсторияОтгрузок.УжеОтгружено, 0) + ВТ_ТекущиеСтроки.КоличествоВДокументе

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

Вариант 2. Программное управление действием строки заказа в привилегированном модуле

Если на предприятии принципиально используется штатный режим ведения заказов («Заказ со склада и под заказ»), но операторам нельзя давать права на открытие и редактирование заказов, можно применить программное обновление статусов:

Менеджер вводит долгосрочный заказ клиента, устанавливая по всем позициям действие «Не обеспечивать».
При создании накладной оператор выбирает заказ в качестве основания.
В расширении конфигурации (в обработчике перед проведением реализации) в привилегированном режиме вызывается процедура, которая считывает необходимые объемы из документа реализации, находит исходный ЗаказКлиента, программно разбивает строки и переводит нужное количество в действие «Отгрузить», после чего записывает заказ.
Штатные типовые механизмы видят статус «Отгрузить» и успешно проводят реализацию. При этом оператор не получает интерактивного доступа к заказу и не может отредактировать согласованные спецификации.

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