Как связаны Заказ клиента и Заказ поставщику в 1С:УТ 11

В современных конфигурациях на платформе 1С:Предприятие 8.3, таких как Управление торговлей ред. 11, ERP Управление предприятием или Комплексная автоматизация, механизмы связи между документами закупки и продажи стали значительно сложнее и гибче, чем в старых версиях. Рассмотрим подробнее, как именно система отслеживает цепочку от потребности покупателя до заказа товара у поставщика, и почему иногда «Структура подчиненности» кажется пустой.

Вариант 1: Прямая связь через реквизит ДокументОснование

Самый простой и очевидный способ связи — это использование стандартного механизма 1С «Создать на основании». Если мы открываем ЗаказКлиента и на его основании генерируем ЗаказПоставщику, система автоматически заполняет реквизит ДокументОснование в шапке нового документа.

Проанализируем, как это работает технически:

1. При создании на основании данные из ЗаказКлиента копируются в ЗаказПоставщику.
2. Реквизит ДокументОснование в ЗаказПоставщику получает ссылку на исходный ЗаказКлиента.
3. Стандартный критерий отбора СвязанныеДокументы анализирует этот реквизит и корректно выводит дерево в структуре подчиненности.

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

Вариант 2: Связь через критерии отбора

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

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

Вариант 3: Ключевой механизм — справочник Назначения

В актуальных версиях УТ 11 (начиная с 11.4 и выше) основным связующим звеном выступает не сам документ, а уникальный объект — Назначение. Этот механизм используется при так называемом обособленном обеспечении.

Рассмотрим по шагам, как формируется эта связь:

1. В документе ЗаказКлиента для конкретной позиции товара устанавливается вариант обеспечения «Обособленно».
2. Система автоматически создает элемент в справочнике Назначения. Этот элемент жестко связан с данным ЗаказКлиента.
3. При формировании заказа поставщику (особенно через «Помощник формирования заказов по потребностям») это Назначение копируется в табличную часть Товары документа ЗаказПоставщику.

Таким образом, связь переносится с уровня «документ-документ» на уровень «строка документа — назначение — документ». Это позволяет одному ЗаказПоставщику обеспечивать потребности десятков разных заказов клиентов. Каждая строка в табличной части «знает», для кого именно закупается товар.

Анализ данных в регистрах накопления

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

Посмотрим на структуру данных в этом регистре:

• Номенклатура: закупаемый товар.
• Назначение: ссылка на конкретный ЗаказКлиента.
• Заказ: ссылка на ЗаказПоставщику, который должен обеспечить эту потребность.

Именно благодаря этим записям система понимает, что когда товар придет по накладной (Приобретение товаров и услуг), его нельзя просто так продать другому клиенту — он уже «забронирован» под конкретное Назначение.

Что делать, если структура подчиненности пустая?

Разобьем проблему на составляющие. Если вы объединили несколько клиентских заказов в один заказ поставщику через помощник обеспечения, стандартная структура подчиненности действительно может не показать связь. Это происходит потому, что обработка ищет ссылку в шапке, а не в строках табличной части.

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

1. Анализ выполнения заказов поставщику: позволяет увидеть, под какие распоряжения (Заказы клиентов) закуплен товар.
2. Остатки и доступность товаров: при установке группировки по «Назначению» вы увидите четкую связь между ожидаемым товаром и заказчиком.

Пример программного поиска связей

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

Проанализируем пример запроса (схематично):

ВЫБРАТЬ РАЗЛИЧНЫЕ
    ЗаказПоставщикуТовары.Назначение.ЗаказПокупателя КАК ЗаказКлиента
ИЗ
    Документ.ЗаказПоставщику.Товары КАК ЗаказПоставщикуТовары
ГДЕ
    ЗаказПоставщикуТовары.Ссылка = &СсылкаНаЗаказПоставщику
    И ЗаказПоставщикуТовары.Назначение <> ЗНАЧЕНИЕ(Справочник.Назначения.ПустаяСсылка)

Этот код наглядно показывает, что связь «спрятана» внутри реквизита Назначение. Если поле ЗаказПокупателя (или Заказ) внутри назначения заполнено, значит, данная строка товара жестко зарезервирована под конкретную сделку.

Резюме

Подведем итоги нашего анализа. Прямая связь через ДокументОснование — это лишь верхушка айсберга, удобная для простых операций. В сложных бизнес-процессах 1С:УТ 11 использует аналитику Назначения.

Важные моменты для запоминания:

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

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