Как настроить отбор по заказам поставщика в форме Состояние обеспечения заказов без обособленного обеспечения

← На главную

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

Разберем архитектуру связей в УТ 11

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

Решение 1: Использование регистра «Распределение запасов»

В последних редакциях УТ 11 (начиная с 11.4 и 11.5) основным источником данных для анализа обеспечения является регистр сведений РаспределениеЗапасов. Этот регистр хранит информацию о том, какой «заказ-источник» (поступление) может обеспечить «заказ-потребность» (отгрузку). Даже если обеспечение не обособленное, система делает записи в этот регистр для расчета планируемых дат поставки.

Рассмотрим структуру запроса для поиска связи:


ВЫБРАТЬ РАЗЛИЧНЫЕ
    РаспределениеЗапасов.ЗаказНаОтгрузку КАК ЗаказКлиента,
    РаспределениеЗапасов.ЗаказНаПоступление КАК ЗаказПоставщику
ИЗ
    РегистрСведений.РаспределениеЗапасов КАК РаспределениеЗапасов
ГДЕ
    РаспределениеЗапасов.ЗаказНаОтгрузку ССЫЛКА Документ.ЗаказКлиента
    И РаспределениеЗапасов.ЗаказНаПоступление ССЫЛКА Документ.ЗаказПоставщику

Этот способ является наиболее современным, так как именно на этом регистре строится отчетность по состоянию обеспечения.

Решение 2: Программный анализ критерия отбора «Связанные документы»

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

Пример кода для сбора таких заказов:


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

РезультатЗапроса = Запрос.Выполнить();
СписокЗаказовСПоставщиками = РезультатЗапроса.Выгрузить().ВыгрузитьКолонку("ЗаказКлиента");

Полученный массив СписокЗаказовСПоставщиками можно передать в параметры отбора формы Состояние обеспечения заказов.

Решение 3: Модификация схемы компоновки данных (СКД) формы

Форма Состояние обеспечения заказов строится на базе системы компоновки данных. Для внедрения пользовательской галочки «Оформлен заказ поставщику» нам потребуется изменить основной запрос схемы. Рассмотрим алгоритм действий:

Создадим расширение для конфигурации.
Найдем обработку СостояниеОбеспеченияЗаказов и ее основную схему компоновки.
Добавим в запрос левое соединение с таблицей Документ.ЗаказПоставщику по полю ДокументОснование или воспользуемся данными регистра ЗапасыИПотребности.
В настройках СКД добавим новый параметр или отбор.

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

Решение 4: Использование регистра «Запасы и потребности»

Регистр накопления ЗапасыИПотребности — это сердце товарного планирования в УТ 11. В нем фиксируются все планируемые движения. Выясним причину, почему этот регистр полезен для нашей задачи: он содержит измерения Номенклатура, Склад и Заказ. Если мы проанализируем записи, где Заказ является заказом поставщику, мы сможем увидеть, под какие потребности (через поле Назначение, если оно заполнено, или через механизмы распределения) он сформирован.

Посмотрим на пример логики проверки наличия обеспечения:


ВЫБРАТЬ
    ЗапасыИПотребности.Заказ КАК ЗаказПоставщику,
    ЗапасыИПотребности.Номенклатура,
    ЗапасыИПотребности.КоличествоОстаток КАК КоличествоВПути
ИЗ
    РегистрНакопления.ЗапасыИПотребности.Остатки КАК ЗапасыИПотребности
ГДЕ
    ЗапасыИПотребности.Заказ ССЫЛКА Документ.ЗаказПоставщику

Практические советы по реализации интерфейса

Чтобы пользователю было удобно работать с этой доработкой, рекомендуется добавить на форму кнопку или флаг «Только с заказами поставщику». При изменении этого флага в процедуре ПриИзменении на сервере следует динамически менять настройки компоновки данных:

Получаем КомпоновщикНастроек текущего списка.
Находим или создаем элемент отбора по полю, которое мы добавили в схему (например, ЕстьЗаказПоставщику).
Устанавливаем Использование = Истина и ПравоеЗначение = Истина.

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

← На главную