Есть список номенклатуры, необходимо для каждого элемента выбрать самую раннюю партию.
Исходные данные:
 Список номенклатуры
 Регистр Накопления партии товаров, есть ресурс ДокументОприходования  (партия)

Подскажите как это можно сделать одним запросом?

Делаешь в запросе внутренний запрос, в котором получаешь для каждой номенклатуры самую меньшую дату, потом во внешнем запросе ищешь по этой дате документ. Будет работать, если нет документов с одинаковой датой, а если есть, то придется ещё подумать.

(1) Даже с одинаковой датой можно через группировку с функцией МИНИМУМ выбрать данные по моменту времени.

(2) Момент времени не идет в группировку :(

(2) Хм.
Кстати,
МИНИМУМ(ПартииТоваров.ДокументОприходования) КАК ДокументОприходования
каким образом отработает при полном совпадении дат документов оприходования? Учтет момент времени?

(4) Нет. Дата не будет учитываться.



+(2) Пример на тему


ВЫБРАТЬ
   ВложенныйЗапрос.Номенклатура,
   МИНИМУМ(ТоварыНаСкладахОбороты.Регистратор) КАК Регистратор
ИЗ
   (ВЫБРАТЬ
       ТоварыНаСкладахОбороты.Номенклатура КАК Номенклатура,
       МИНИМУМ(ТоварыНаСкладахОбороты.Регистратор.Дата) КАК РегистраторДата
   ИЗ
       РегистрНакопления.ТоварыНаСкладах.Обороты(, , Регистратор, ) КАК ТоварыНаСкладахОбороты
   
   СГРУППИРОВАТЬ ПО
       ТоварыНаСкладахОбороты.Номенклатура) КАК ВложенныйЗапрос
       ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ТоварыНаСкладах.Обороты(, , Регистратор, ) КАК ТоварыНаСкладахОбороты
       ПО ВложенныйЗапрос.Номенклатура = ТоварыНаСкладахОбороты.Номенклатура
           И ВложенныйЗапрос.РегистраторДата = ТоварыНаСкладахОбороты.Регистратор.Дата

СГРУППИРОВАТЬ ПО
   ВложенныйЗапрос.Номенклатура

+(5) к (4) СП: Правила сравнения значений


....

Отношения между различными ссылочными типами определяются на основе внутренних ссылочных номеров таблиц, соответствующих тому или иному типу.

...

Если типы данных совпадают, то производится сравнение значений по следующим правилам:
....
ссылочные типы сравниваются на основе своих значений (номера записи и т. п.);

Интересно а почему Момент времени не идет МИНИМУМ(МоментВремени)

(7) Откуда взяться моменту времени в чистом виде в запросах  ?

да можно еще по номеру отсортировать на дату)

+(9) получили минимальную дату, получили минимальный номер в этой дате и взяли то, что нам нужно

(9) Ерунда. Номера никакого отношения к "моменту времени" не имеют и могут повторятся для разных видов документов.

(5) точно. это ж момент времени у нас дата + ссылка. тут и получается сначала минимум даты, а потом в рамках минимума даты выбираем минимум по ссылке.

и все как всегда потому, что в одной секунде документов уйма может быть))

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

(14) А ты думаешь как сейчас платформа позицию определяет ?

(15)2.14 - пока не разбирался

(16) Так я как бы намекаю, что именно так и работает платформа. И всякие "восстановления последовательности" и решают эту проблему

(17) как-бы последовательность самостоятельный объект и у него свой список кто за кем в очереди.

(18) Последовательность работает с моментами времени, которые все также определяются как дата+ссылка.

(19) дата+ссылка - только в рамках 1 документа.

(20) Дата+ссылка в пределах любых типов. Ссылка для 1С = Тип+ИД. Согласно (5) сначала будут упорядочены типы и уже в пределах типов - ссылки. Таким образом документы одного типа в пределах одной секунды всегда будут стоять на позиции выше (ниже) чем у другого типа.

+(21) Т.е. *согласно (6)

(21) ну так и какой тогда момент времени, если сначала в пределах 1 секунды прошёл  приход по документу "Возврат из переработки" и в ту-же секунду но после прошёл  приход из "Поступление", а сортировка по типу ставит "Поступление" перед "Возвратом из переработки"!

(23) ПН будет стоять перед Возвратом. Селяви. Чего спорить - возьми проверь

(24) вот именно и пофиг что по факту в другом порядке было...

(25) Увы ...это то "малое зло", на которое пришлось пойти разработчикам.

(26) да это блин, понятно...