Как реализована построчная связь между Заказом клиента и Реализацией товаров и услуг в 1С:УТ 11?

При доработке типовых конфигураций (1С:Управление торговлей 11, 1С:Комплексная автоматизация 2, 1С:ERP) часто возникает необходимость сопоставить конкретную строку документа РеализацияТоваровУслуг со строкой исходного документа ЗаказКлиента. Например, это требуется при выводе дополнительных реквизитов строк заказа в печатную форму УПД, контроле цен или расчете специфических скидок. Разберем подробно, какие реквизиты отвечают за эту связь и как правильно организовать выборку данных в запросах.

Механизм связывания: назначение реквизитов КодСтроки и КлючСвязи

В табличных частях документов товародвижения присутствуют два похожих по назначению реквизита, которые выполняют принципиально разные задачи:

1. КодСтроки (сквозная связь между документами) — это числовой идентификатор строки распоряжения (заказа). При оформлении реализации на основании заказа клиента (или через рабочее место оформления накладных) значение поля КодСтроки из табличной части заказа переносится в соответствующую строку реализации. Именно связка документа ЗаказКлиента и поля КодСтроки используется системой для закрытия остатков по регистрам накопления (например, в регистре ЗаказыКлиентов).
2. КлючСвязи (внутренняя связь внутри одного документа) — числовой идентификатор, предназначенный исключительно для связывания строк подчиненных табличных частей с основной табличной частью внутри одного объекта. Например, он соединяет строку табличной части Товары со строками табличных частей Серии, ВидыЗапасов или СкидкиНаценки того же самого документа. Для связи разных документов между собой КлючСвязи не применяется.

Особенности работы со сквозным идентификатором КодСтроки

Проанализируем ключевые нюансы, которые необходимо учитывать при построении логики на основе КодСтроки:

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

Пример запроса для получения данных строки заказа в печатной форме

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

ВЫБРАТЬ
	РеализацияТовары.НомерСтроки КАК НомерСтрокиРТУ,
	РеализацияТовары.Номенклатура КАК Номенклатура,
	РеализацияТовары.Характеристика КАК Характеристика,
	РеализацияТовары.Количество КАК Количество,
	ВЫБОР
		КОГДА РеализацияТовары.ЗаказКлиента <> ЗНАЧЕНИЕ(Документ.ЗаказКлиента.ПустаяСсылка)
			ТОГДА РеализацияТовары.ЗаказКлиента
		ИНАЧЕ РеализацияШапка.ЗаказКлиента
	КОНЕЦ КАК ДокументЗаказ,
	РеализацияТовары.КодСтроки КАК КодСтрокиРТУ
ПОМЕСТИТЬ ВТ_ТоварыРеализации
ИЗ
	Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТовары
	ВНУТРЕННЕЕ СОЕДИНЕНИЕ Документ.РеализацияТоваровУслуг КАК РеализацияШапка
		ПО РеализацияТовары.Ссылка = РеализацияШапка.Ссылка
ГДЕ
	РеализацияТовары.Ссылка = &СсылкаНаРеализацию
;

ВЫБРАТЬ
	ВТ.НомерСтрокиРТУ КАК НомерСтрокиРТУ,
	ВТ.Номенклатура КАК Номенклатура,
	ВТ.Характеристика КАК Характеристика,
	ВТ.Количество КАК Количество,
	ЕСТЬNULL(ЗаказТоварыПоКоду.ДополнительныйРеквизит, ЗаказТоварыПоПолям.ДополнительныйРеквизит) КАК ДополнительныйРеквизитИзЗаказа
ИЗ
	ВТ_ТоварыРеализации КАК ВТ
	// Основное соединение по точному коду строки заказа
	ЛЕВОЕ СОЕДИНЕНИЕ Документ.ЗаказКлиента.Товары КАК ЗаказТоварыПоКоду
		ПО ВТ.ДокументЗаказ = ЗаказТоварыПоКоду.Ссылка
		И ВТ.КодСтрокиРТУ = ЗаказТоварыПоКоду.КодСтроки
		И ВТ.КодСтрокиРТУ > 0
	// Резервное соединение по номенклатуре и характеристике на случай ручного ввода строк
	ЛЕВОЕ СОЕДИНЕНИЕ Документ.ЗаказКлиента.Товары КАК ЗаказТоварыПоПолям
		ПО ВТ.ДокументЗаказ = ЗаказТоварыПоПолям.Ссылка
		И ВТ.Номенклатура = ЗаказТоварыПоПолям.Номенклатура
		И ВТ.Характеристика = ЗаказТоварыПоПолям.Характеристика
		И (ВТ.КодСтрокиРТУ = 0 ИЛИ ЗаказТоварыПоКоду.Ссылка ЕСТЬ NULL)

Альтернативные архитектурные решения

В зависимости от требований к учету и производительности системы можно применить альтернативные варианты передачи данных:

1. Денормализация (дублирование реквизита в реализацию): добавить аналогичный реквизит в табличную часть Товары документа реализации и заполнять его в обработчике ОбработкаЗаполнения или через подписку на событие при вводе на основании. Это повышает скорость формирования печатных форм и фиксирует состояние данных на момент отгрузки, защищая печатную форму от последующих правок в исходном заказе.
2. Использование типовых дополнительных реквизитов: если выводимое значение характеризует сам товар, а не уникальные условия строки конкретной сделки, целесообразно вынести его в механизм ДополнительныеРеквизитыИСведения для справочника Номенклатура или ХарактеристикиНоменклатуры, избегая изменения структуры табличных частей документов.