Всем доброго дня!
Коллеги, не могу сообразить, нужно для каждой позиции номенклатуры найти последние 2 документа прихода. Прямым запросом один последний документ нахожу без проблем, а вот как найти второй, предыдущий )
Ничего путного в голову не приходит ) Видимо надо писать второй похожий запрос с такой же выборкой, но кроме данных из первого запроса

да ничего тут особо не придумаешь.
по одной позиции приходы могут быть вчера и позавчера
а по другой - через столетие в будущем и до рождества христова в прошлом.
вижу только брать все и уже затем перебирать.
два цикла по группировкам.

(1)ну весь период я ограничу, например двумя годами. Сложность выбрать для каждой позиции именно 2 прихода, а не один последний

Вот самое простое в 8ке. Но будет проблема если по одной номенклатуре в одну и ту же дату будет 2 документа

ВЫБРАТЬ
    ПоступлениеТоваровТовары.Ссылка КАК Ссылка,
    ПоступлениеТоваровТовары.Ссылка.Дата КАК Дата,
    ПоступлениеТоваровТовары.Номенклатура КАК Номенклатура
ПОМЕСТИТЬ втДокументы
ИЗ
    Документ.ПоступлениеТоваров.Товары КАК ПоступлениеТоваровТовары
ГДЕ
    ПоступлениеТоваровТовары.Номенклатура В(&МассивНоменклатуры)
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    втДокументы.Ссылка КАК Ссылка,
    МАКСИМУМ(втДокументы.Дата) КАК Дата,
    втДокументы.Номенклатура КАК Номенклатура
ПОМЕСТИТЬ втПервая
ИЗ
    втДокументы КАК втДокументы

СГРУППИРОВАТЬ ПО
    втДокументы.Ссылка,
    втДокументы.Номенклатура
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    втДокументы.Ссылка КАК Ссылка,
    МАКСИМУМ(втДокументы.Дата) КАК Дата,
    втДокументы.Номенклатура КАК Номенклатура
ПОМЕСТИТЬ втВторая
ИЗ
    втДокументы КАК втДокументы
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ втПервая КАК втПервая
        ПО (втДокументы.Ссылка = втПервая.Ссылка
                И втДокументы.Номенклатура = втПервая.Номенклатура
                И втДокументы.Дата <> втПервая.Дата)

СГРУППИРОВАТЬ ПО
    втДокументы.Ссылка,
    втДокументы.Номенклатура
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    втДокументы.Ссылка КАК Ссылка,
    втДокументы.Номенклатура КАК Номенклатура
ИЗ
    втДокументы КАК втДокументы
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ втПервая КАК втПервая
        ПО втДокументы.Ссылка = втПервая.Ссылка
            И втДокументы.Номенклатура = втПервая.Номенклатура
            И втДокументы.Дата = втПервая.Дата

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
    втДокументы.Ссылка,
    втДокументы.Номенклатура
ИЗ
    втДокументы КАК втДокументы
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ втВторая КАК втВторая
        ПО втДокументы.Ссылка = втВторая.Ссылка
            И втДокументы.Номенклатура = втВторая.Номенклатура
            И втДокументы.Дата = втВторая.Дата


(0) Наступите песне на горло - сделайте стандартным запросом
Группировка Номенклатура;
Группировка Приход;

При обходе группировки (не забудьте обратное направление указать) Приход после второй записи Прервать
;-)

(4) угу - если номенклатура сотни тысяч и приходов столько же - из горла вместо песни предсмертный хрип

(5) А может номенклатура 100 и 10 приходов :-)  Автор темы все условия не озвучил

(6) В первой строке звучит "прямой запрос" - явно номенклатура > 100

(0) Можно же SQL функцией сделать, в которую передавать ИД номенклатуры. И там уже не так важен размер запроса.
Если получаешь SQL функцией, то можно добавить реквизит для исключения ИдДокумента
что-то вроде
function [dbo].[ПолучитьДокументПоследнийПриходТовараКромеДокумента] (@Товар char(9), notiddoc  char(9))
..
where
    dt.SP195 = @Товар
    and j.closed = 1
    and dh.iddoc <> @notiddoc
..
Тогда уже в основном запросе в 1с
dbo.ПолучитьДокументПоследнийПриходТовараКромеДокумента(@Товар,'') - будет первый приход
dbo.ПолучитьДокументПоследнийПриходТовараКромеДокумента(@Товар,dbo.ПолучитьДокументПоследнийПриходТовараКромеДокумента(@Товар,'') )  - будет второй приход

(0) Что-то мне подсказывает, что если ты находишь один последний документ, то найти любое количество последних не составит труда.
Приведи текст твоего запроса, и я покажу тебе, куда там TOP 2 вставить :))

(9)
    ТекстПодЗапроса = "
    |SELECT
    |    MAX(Ном.Id + " + ИдВремени + ") AS НомДатаВремяIddoc,
    |    Ном.Id  AS [Номенклатура]
        |FROM
    |" + Журнал + "                        AS Jr,
    |   $Документ.ПоступлениеТоваров       AS Док,
    |   $ДокументСтроки.ПоступлениеТоваров AS ДокТЧ,
    |   $Справочник.Материалы              AS Ном,
    |   $Справочник.Контрагенты            AS Контр
    |WHERE
    |   (Jr.IdDoc              = Док.IdDoc)    AND
    |   (Док.IdDoc             = ДокТЧ.IdDoc)  AND
    |   ($Док.Служебный        = 0)            AND
    |   ($Док.ТипДокумента     = 0)            AND
    |   ($Док.Контрагент       = Контр.Id)     AND
    |   (RIGHT($ДокТЧ.Товар,9) = Ном.Id)       AND
    |   ($ДокТЧ.Цена          > 0.00)          AND
    |   ($Контр.ТипПоставщика <> 1)            AND      
        |"   +  УсловиеDate + " AND " + УсловиеClosed + УсловиеТовар + ТекстМФФильтра + "
    |GROUP BY
    |  Ном.Id";

    ТекстЗапроса = "
    |SELECT  Посл.Номенклатура        AS [Номенклатура  $Справочник.Материалы],
    |     CAST(($ДокТЧ.Цена)       AS Numeric(15,2)) AS ЦенаПрихода,
        |        $Док.Контрагент          AS [Контрагент       $Справочник.Контрагенты],
        |        Jr.IdDoc                 AS [ДокументПрихода  $Документ],
        |        Jr.IdDocDef              AS  ДокументПрихода_вид,
    |     Посл.НомДатаВремяIddoc    
        |FROM    " + Журнал + "  AS Jr
        |INNER JOIN        
    |   $Документ.ПоступлениеТоваров AS Док ON (Jr.IdDoc  = Док.IdDoc)
        |INNER JOIN        
    |   $ДокументСтроки.ПоступлениеТоваров AS ДокТЧ ON (Jr.IdDoc  = ДокТЧ.IdDoc)
    |INNER JOIN (" + ТекстПодЗапроса + ") Посл
    |      ON (Jr.IdDoc          = RIGHT(Посл.НомДатаВремяIddoc,9)) AND
    |      (RIGH($ДокТЧ.Товар,9) = Посл.Номенклатура)    
    |ORDER BY Посл.Номенклатура
    |";

Ном.Id из MAX() можно убрать, это я сейчас пытался свести первый запрос к одному параметру выборки

В идеале, для одного обхода достаточно двухмерной нумерации вместо одномерного идентификатора: i - номенклатура, j - док
Тогда после только одного обхода сразу можно получить для каждой i номенклатуры известные уже N-й и (N-1)-й доки.

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

(12)Что такое обходы ? Обходы чего ?

А вообще-то менеджерам лучше свою работу делать, а не придумывать работу для программиста. Один дворник может загрузить работой по оптимизации взмахов метлы десяток НИИ

(13)Если бы писались, то было бы все иначе. Это цены материалов для цеха. И озадачили именно тем, что нужны две последние цены прихода, чтобы их сравнить
(15)Это типа для снабжения. Хотя в целом я не очень уверен в полезности этой информации

Может просто тупо все выбрать, да отсортировать )) а там уже бери хоть 2, хоть 10 приходов

(10) как-то излишне сложно
Проще надо быть. Примерно так


    ТекстЗапроса = "
    |SELECT TOP 2
    |    Посл.Номенклатура        AS [Номенклатура  $Справочник.Материалы],
    |    CAST(($ДокТЧ.Цена)       AS Numeric(15,2)) AS ЦенаПрихода,
    |    $Док.Контрагент          AS [Контрагент       $Справочник.Контрагенты],
    |    Jr.IdDoc                 AS [ДокументПрихода  $Документ],
    |    Jr.IdDocDef              AS  ДокументПрихода_вид,
    |    Посл.НомДатаВремяIddoc    
    |FROM
    |    "+Журнал+"  AS Jr
    |    INNER JOIN $Документ.ПоступлениеТоваров AS Док ON (Jr.IdDoc  = Док.IdDoc)
    |    INNER JOIN $ДокументСтроки.ПоступлениеТоваров AS ДокТЧ ON (Jr.IdDoc  = ДокТЧ.IdDoc)
    |    INNER JOIN (" + ТекстПодЗапроса + ") Посл ON
    |        (Jr.IdDoc          = RIGHT(Посл.НомДатаВремяIddoc,9)) AND
    |        (RIGH($ДокТЧ.Товар,9) = Посл.Номенклатура)
    |
    |    LEFT JOIN $Справочник.Материалы AS Ном ON Ном.Id = RIGHT($ДокТЧ.Товар,9) AND Left($ДокТЧ.Товар, 4) = $ВидСправочника36.Материалы
    |    LEFT JOIN $Справочник.Контрагенты AS Контр ON Контр.Id = $Док.Контрагент
    |
    |
    |WHERE
    |   (Jr.IdDoc              = Док.IdDoc)    AND
    |   (Док.IdDoc             = ДокТЧ.IdDoc)  AND
    |   ($Док.Служебный        = 0)            AND
    |   ($Док.ТипДокумента     = 0)            AND
    |   ($ДокТЧ.Цена          > 0.00)          AND
    |   ($Контр.ТипПоставщика <> 1)            AND
    |    "+УсловиеDate + " AND " + УсловиеClosed + УсловиеТовар + ТекстМФФильтра+"
    |
    |ORDER BY
    |    Jr.Date_Time_IDDoc Desc
    |";

Только надо учитывать тот факт, что выборка с такими условиями будет читать всю табличку $ДокументСтроки.ПоступлениеТоваров, и если там строк много, то может получиться неприятно.

(14) Не помню, мы в 7-ке же табличные части доков поступления обходим, не регистры?
А коли так, то матрица нумерации сложится так: (уникальный код номенклатуры, просто номер позиции по времени дока)

Для первого дока по времени (***, 1), для второго (***, 2) и т.д до конца периода выборки.

(18) + ошибочка... подзапрос "INNER JOIN (" + ТекстПодЗапроса + ") ..." надо убрать, он не нужен

(18)а в чем проще то ?)) ТекстПодзапроса остался прежним? а он же выбирает один приход для каждого материала

я пробовал с TOP 2 и ORDER BY, но у меня ничего не вышло. Отбирались всего две позиции для всей номенклатуры.

(22) Проще для понимания. Так то принципиально ничего не изменилось.
Ну и подзапрос там не нужен, я его удалить забыл.

(24)так у меня вернется всего 2 прихода, а мне надо 2 прихода для каждого материала

(16) В том то и дело что тут нужно сравнивать цены этих приходов и сравнивать их будут с учетом каких то факторов. Цена прихода которая вчера и 2 года назад это 2 разных цены. Цена прихода за партию 10 кг и 20 тн тоже будут отличаться. Опять же если перебираешь документы то Документ поступления товаров может быть с признаком возврат и там будут стоять цена по который ты продавал, хотя для материалов это обычно не критично. К документу поступления может быть привязан документ затраты на поступления где пописаны транспортные и прочие затраты которые для дешевых материалов могут превышать цену самих материалов.
Очень часто что если последняя цена закупки равна текущей цене закупки то искать еще одну цену закупки просто не надо, что значительно сокращает список товаров по которым нужно искать 2 цену.

(25) что-то я не внимательно задачу прочитал.
В такой постановке запросом получить нужную выборку врядли получится. Только постобработкой.

(28)Потому то у меня и был подзапрос. Можно результаты выборки последних цен выкинуть во временную таблицу или временный справочник сделать и затем выбрать снова последние цены, но исключая сохраненные. Но возиться неохота ради этой задачи. Итак день почти убил. Я лучше выберу все, а затем смогу показать хоть 2 прихода, хоть 22. Думаю, что это будет малополезным. Типа хотят видеть динамику последних цен закупа, чтобы цены снижались )

Таки можно и запросом. С использованием OVER
схема такая:

select
    *
from
    (
    select
        ROW_NUMBER() over (PARTITION BY ТЧ.Номенклатура ORDER BY жДок.Date_Time_IDDoc) нДок,
        ТЧ.Номенклатура,
        жДок.Date_Time_IDDoc
    from
        докТЧРеализация ТЧ
        left join ЖурналДокументов жДок ON жДок.идДок9 = ТЧ.идДок9
    ) ТЧ2
where
    ТЧ2.нДок <= 2

результат примерно такой
1         9       201610038T6W8W  DOD6  
2         9       201610055E03GW  DP3L  
1        4A       2016100367B9KW  DO50  
2        4A       201610038T6W8W  DOD6  
1        5X       201610059HRO3K  DPI9  
2        5X       20161007AO2374  DQIU  
1        60       2016100367B9KW  DO50  
2        60       20161003729T1C  DO7N  
1        66       20161021A54PVK  DVF8  
2        66       201610246TASY8  DVNF  
1        8Q       20161005A284G0  DPJK  
2        8Q       201610277W4WQO  DX93  
1        HP       201610035SGI1C  DO36  
2        HP       20161003729T1C  DO7N  
1        IL       2016100450R79C  DONO  
2        IL       201610128K2BJK  DRYY  
1        IM       2016100450R79C  DONO  
2        IM       2016100476BZDS  DOSV  
1        IN       2016100450R79C  DONO  
2        IN       2016100476BZDS  DOSV

(29)возьму на заметку, спасибо огромное

а еслитупо?
Регистр
ОбратныйПорядок
УстановитьФильтр
ВыбратьДвижения
?

(32)я уже доделываю с полной выборкой, осталось печатную форму сделать )) там дел то. Пошел по ложному пути
Стереотип мышления.
Недавно выезжаю со стоянки утром. Надо выехать направо на дорогу Д1, потом через 200 м снова направо на дорогу Д2. На выезде направо авария, проехать никак. Поэтому еду закоулками, выезжаю сразу на Д2. И какие то мгновения размышляю, где лучше развернуться, чтобы вернуться назад и снова выехать на дорогу Д2, на которой уже нахожусь. Это пипец. Стало даже страшно ))) Но помутнение было кратковременным и поехал прямо ))

Всем спасибо! все отлично получилось )) Надо просто правильно ходить, не всегда прямо ))

а вообще если задача в (16) стоит то можно не удалять общепринятым в среде 1с образом гланды
а именно при поступлении второго прихода делать необходимую проверку и сохранять нужный результат проверки.
чтобы получать его мгновенно а не перелопачивая полбазы каждый раз когда подобное потребуется.

(135)Что значит при поступлении второго прихода? Приходов по каждой позиции много. В отчете нужны 2 последних.  А завтра может 3 или более попросят. На 11 ГБ файловой база работает вполне шустро.

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

(37)Там тоже будет геморрой, надо как то определять, что приход последний, бывший последний делать предпоследним. Я не вижу профита. Задача решилась, прямым запросом все выбираю, загрузка. в индексированную таблицу и все чудесно. И могу показать хоть 2 прихода, хоть все, выделяя цветом приходы, которые дороже предыдущего.  
В принципе я согласен, что бывает полезно использовать Ваш подход - готовить данные заранее, а потом только доставать готовое

(37) Поступления вводит девочка низшего звена бухгалтерии, не будет она ждать, пока финансовый аналитик рассмотрит цены.
(38) Только так и будет эргономично: один запрос, а далее работа с готовой таблицей номенклатура - поступление. Выбирай хоть предпоследнее, хоть все нечётные, хоть десятое снизу, хоть по заданной группе номенклатуры.

(27) почему "вряд ли получится"?
что-то вроде этого:
SELECT  
    ДваПрихода.Номенклатура  [Номенклатура $Справочник.Номенклатура],    
    ДваПрихода.Позиция [Позиция],
    Журнал.iddoc [ДокументПоступление $Документ.ПоступлениеТоваров],
    $ДокТЧ.Цена [ЦенаПоступления],    
    $Док.Контрагент [Поставщик $Справочник.Контрагенты]    
                 
(
SELECT  $Док.Номенклатура  [Номенклатура],
     MAX(Журн.DateTimeIddoc) [Позиция]
FROM
    _1journ AS  Журнал
INNER JOIN    $Документ.ПоступлениеТоваров AS Док
    ON Журнал.IdDoc  = Док.IdDoc
INNER JOIN  $ДокументСтроки.ПоступлениеТоваров AS ДокТЧ
    ON Док.IdDoc  = ДокТЧ.IdDoc
INNER JOIN $ДокументСтроки.ПоступлениеТоваров AS ВыбранныйДок
    ON $ВыбранныйДок.Номенклатура  = $ДокТЧ.Номенклатура
WHERE
    Журн.DateTimeIddoc > :НачДата
    and ВыбранныйДок.iddoc = :ВыбранныйДок
    and ВыбранныйДок.iddoc <> Док.iddoc
GROUP BY
    $Док.Номенклатура

UNION ALL

SELECT  $Док.Номенклатура  [Номенклатура],
     MAX(Журн.DateTimeIddoc) [Позиция]
FROM
    _1journ AS  Журнал
INNER JOIN    $Документ.ПоступлениеТоваров AS Док
    ON Журнал.IdDoc  = Док.IdDoc
INNER JOIN  $ДокументСтроки.ПоступлениеТоваров AS ДокТЧ
    ON Док.IdDoc  = ДокТЧ.IdDoc
INNER JOIN $ДокументСтроки.ПоступлениеТоваров AS ВыбранныйДок
    ON $ВыбранныйДок.Номенклатура  = $ДокТЧ.Номенклатура
LEFT JOIN
    (
    SELECT  $Док.Номенклатура  [Номенклатура],
             MAX(Журн.DateTimeIddoc) [Позиция]
    FROM
        _1journ AS  Журнал
    INNER JOIN    $Документ.ПоступлениеТоваров AS Док
        ON Журнал.IdDoc  = Док.IdDoc
    INNER JOIN  $ДокументСтроки.ПоступлениеТоваров AS ДокТЧ
        ON Док.IdDoc  = ДокТЧ.IdDoc
    INNER JOIN $ДокументСтроки.ПоступлениеТоваров AS ВыбранныйДок
        ON $ВыбранныйДок.Номенклатура  = $ДокТЧ.Номенклатура
    WHERE
        Журн.DateTimeIddoc > :НачДата
        and ВыбранныйДок.iddoc = :ВыбранныйДок
        and ВыбранныйДок.iddoc <> Док.iddoc
    GROUP BY
        $Док.Номенклатура
    ) AS ПервыеДокументы
    ON ПервыеДокументы.Номенклатура = $ДокТЧ.Номенклатура and ПервыеДокументы.Позиция = Журн.DateTimeIddoc
WHERE
    Журн.DateTimeIddoc > :НачДата
    and ВыбранныйДок.iddoc = :ВыбранныйДок
    and ВыбранныйДок.iddoc <> Док.iddoc
    and ПервыеДокументы.Номенклатура is NULL
GROUP BY
    $Док.Номенклатура
) AS ДваПрихода
INNER JOIN    _1journ AS  Журнал
    ON    Журнал.datetimeiddoc = ДваПрихода.Позиция
INNER JOIN    $Документ.ПоступлениеТоваров AS Док
    ON Журнал.IdDoc  = Док.IdDoc
INNER JOIN  $ДокументСтроки.ПоступлениеТоваров AS ДокТЧ
    ON Док.IdDoc  = ДокТЧ.IdDoc

(39) Тогда это проще будет сделать через периодический реквизит "ЦенаПоступления" в справочнике "Номенклатура" и в модуле проведения приходной накладной делать УстановитьРеквизитСправочника(). Все последние цены товара можно оперативно получить вместе с документами.
Если есть предубеждение к периодическим реквизитам - то можно через подчиненный номенклатуре справочник с реквизитами "цена" и "документ", а в наименование, например, пихать позицию документа, чтобы выборку можно было сделать в порядке/обратном порядке документов. Создавать/изменять элементы справочника при проведении, удалять в ОбработкаУдаленияПроведения(). Правда, для УРБД, если есть, не будет работать нормально.
Но думаю, что если решение запросом уже найдено и оно довольно быстрое - то оно лучшее.

(41) не надо злоупотреблять периодичкой в 7.7
рассчитывать каждый раз тоже не надо - это архитектурно неверное решение.
все что может быть рассчитано один раз и далее повторно использовано - должно быть именно так и реализовано.
поэтому Гена в (39) извини но ты неправ в данном случае.
девочка на приходе не знает ничего и знать не должна.
но в момент когда она нажимает на кнопку "провести" в приходе
выполняется запрос по остаткам на последний документ - мы имеем все предыдущие цены.
в текущем документе у нас все текущие цены.
сравниваем и сохраняем результаты - в отдельный регистр например. из которого можно выдернуть что угодно в любой момент.
не получая все документы от начала времен.

(42) если доставать не из документов, а из регистра движений ТМЦ, который проиндексирован и по номенклатуре, и по докам - то запрос получится весьма быстрый. Насколько необходимо разменивать "расчет" на "запись и хранение" - зависит от частоты операций "анализа приходов".
Что касается "девочки на приходе" - Гена говорил о другом. Первичку вводит [дешевая] девочка-оператор, которая вообще не должна думать. ее задача обработать документы как есть (и без ошибок и в срок). а анализ цен, и принятие каких-то решений - задача для [более дорогого] финаналитика, финконтролера, или какого-то другого стража бюджета. И уже он должен  получать информацию о девиации цен, и принимать какие-то решения.

(43) так я о том и говорю - что переписанная логика работы документа и системы в целом вообще никак не касается девочки на приходе.
она вводит ровно те же данные ровно те же кнопки жмет.
и понятия не имеет какие запросы к каким регистрам производятся и какие движения куда пишутся.

(42) Зачем тогда вообще нужны запросы по документам? Давайте тогда по любому чиху заведём свои регистры.
Видел как-то 90-й счёт, куда ГБ упросила впендюрить кучу субконто: и контрагентов, и номенклатуру и ещё что-то.

(45) это "дешевый" с точки зрения ресурсов системы вариант выполнить хотелку с 2 последними приходами.
когда мы получаем результат не дергая все данные из всей базы.
а крохотным запросом при каждом приходе получаем нужное и пишем в готовом к использованию виде.
откуда при необходимости опять же будет мгновенное получение по нужным отборам не перелопачивая всю базу.

(46) Да это понятно. Просто стоит ли игра свеч. Сегодня им цены подавай, завтра почасовой учёт прибыли/убытка от каждой продажи.
Как показывает практика, если финдира вовремя не тормозить - программа распухнет от его хотелок )

(46) но увеличивает скорость записи, т.е. время блокировки. а читать можно без блокировки.
кроме того, "регистр приходов" - это подмножество правильно индексированного регистра движений. (это я намекаю на то, что если понадобится получать "две последних цены расходов" - ты тоже будешь делать отдельный регистр?)
ну и ко всему этому вопрос - нужно ли "мгновенное получение", как часто оно нужно, и какова его реальная стоимость

Мне кажется, что здесь не тот случай, когда надо писать при провендении в специальный "регистр". При полной выборке движений постобработка данных минимальная и быстрая. Гена абсолютно прав, что завтра может понадобиться 3.5 прихода разных оттенков серого или еще что-нибудь подобное. Сейчас могут смотреть произвольное число приходов. Бывают случаи, когда выборка сложная, тогда можно "агрегат" куда-то писать, но это редко. А здесь пихать сложность в проведение ради отчета, который может еще и не очень нужен - сомнительное занятие

Кстати, вы никогда не замечали, что при начале работы с новой средней фирмой - сразу начинает нарезать круги финдир со своими эксель-табличками и ласково так просить их реализовать в программе 1с? )
Стоит дать слабину, и брюки превращаются... тьфу! Конфа превращается... превращается конфа...

Помню войну на одной фирме между ГБ и финдиром, как раз на 7-ке. Финик пробил у программиста на 90-х свои статьи доходов и расходов под свой анализ. Девчата из бухгалтерии понятия не имели какой элемент выбирать нового справочник и заводили каждый раз новый, вроде "оплата за гостиницу Пупкину". Финаналитикам потом приходилось всё перебивать, а это перепроведение доков задним числом, отчего съезжал напрочь БУ. Вот ГБ и материла финика, а тот кричал в ответ, что все её бабы дуры )

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

(49) попробуй, плз, (40) по времени по сравнению с постобработкой. Интересно на реальных данных (на выборке из регистра (40) будет, кстати, быстрее, чем по документам)
и да, база файловая, временные таблицы низзя?
и еще, на "произвольное количество" запрос нужен? Если да, то дай структуру регистра движения остатков (можно прямо из dds, с индексами)
(3) не работает. для 10 номенклатур выбирает 526 строк.

(41) лучше через регистр накопления

(53) Я, к стыду своему, не силён в восьмерочных терминах, в семерке - регистр остатков и регистр оборотов. И оба не совсем удобны для хранения/получения сведений о последних ценах прихода. Плюс при добавлении каких-то измерений/ресурсов/реквизитов надо или лезть напрямую в таблицы или шаманить с технологическим перепроведением, что очень неудобно.
Периодические реквизиты хранятся в одной таблице, поэтому сильно её задействовать не комильфо.
Поэтому как вариант (аналог регистра сведений в 8, да?) можно использовать отдельный или подчиненный справочник - реализовать быстро, первоначально заполнить просто, информацию можно записать/получить быстро, места много не займёт.

(52) Мне такой запрос на практике не нужен, но тем не менее интересно было бы взглянуть.
Предположим, что регистр простой  (Номенклатура, Документ; Количество). И проиндексирован так, как тебе надо, невзирая на правила 1С.

Идея в (40) понятна (собственно, была высказана ещё в (8)), но как-то очень уж по-китайски.

(52)время будет, я попробую. База у меня файловая, 11 гигов. А временные таблицы есть - INTO DBF <имя файла>, редко но пользуюсь. Но здесь неохота, потому что базу собираюсь в SQL затащить, а там еще и другие перемены маячат ) По скорости не измерял, но визуально быстрее, чем просто последние цены. Выборка же очень простая. Индексированная таблица тоже шустро работает

(52) Сорян. Не проверял. Лишнее поле было.
Вот правильное:

ВЫБРАТЬ
    ПоступлениеТоваровТовары.Ссылка КАК Ссылка,
    ПоступлениеТоваровТовары.Ссылка.Дата КАК Дата,
    ПоступлениеТоваровТовары.Номенклатура КАК Номенклатура
ПОМЕСТИТЬ втДокументы
ИЗ
    Документ.ПоступлениеТоваров.Товары КАК ПоступлениеТоваровТовары
ГДЕ
    ПоступлениеТоваровТовары.Номенклатура В(&МассивНоменклатуры)
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    МАКСИМУМ(втДокументы.Дата) КАК Дата,
    втДокументы.Номенклатура КАК Номенклатура
ПОМЕСТИТЬ втПервая
ИЗ
    втДокументы КАК втДокументы

СГРУППИРОВАТЬ ПО
    втДокументы.Номенклатура
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    МАКСИМУМ(втДокументы.Дата) КАК Дата,
    втДокументы.Номенклатура КАК Номенклатура
ПОМЕСТИТЬ втВторая
ИЗ
    втДокументы КАК втДокументы
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ втПервая КАК втПервая
        ПО (втДокументы.Номенклатура = втПервая.Номенклатура)
            И (втДокументы.Дата <> втПервая.Дата)

СГРУППИРОВАТЬ ПО
    втДокументы.Номенклатура
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    втДокументы.Ссылка КАК Ссылка,
    втДокументы.Номенклатура КАК Номенклатура
ИЗ
    втДокументы КАК втДокументы
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ втПервая КАК втПервая
        ПО (втДокументы.Номенклатура = втПервая.Номенклатура)
            И (втДокументы.Дата = втПервая.Дата)

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
    втДокументы.Ссылка,
    втДокументы.Номенклатура
ИЗ
    втДокументы КАК втДокументы
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ втВторая КАК втВторая
        ПО втДокументы.Номенклатура = втВторая.Номенклатура
            И втДокументы.Дата = втВторая.Дата

УПОРЯДОЧИТЬ ПО
    Номенклатура,
    Ссылка УБЫВ


(55) 1.Ну, по-китайски потому, что без временных таблиц. с временными слегка короче.
2. клюшек сейчас под рукой нет, вот на снеговике  по документам. По регистру, в принципе, ровно то же самое - там в зависимости от быстройобработкиДвижений либо привязываешься к datetimeiddoc, либо сам его делаешь

ВЫБРАТЬ
    ПриобретениеТоваровУслугТовары.Ссылка КАК Ссылка,
    ПриобретениеТоваровУслугТовары.Номенклатура КАК Номенклатура,
    ПриобретениеТоваровУслуг.Дата КАК Дата,
    1 КАК сч
ПОМЕСТИТЬ ВТ_сч
ИЗ
    Документ.ПриобретениеТоваровУслуг.Товары КАК ПриобретениеТоваровУслугТовары
        ЛЕВОЕ СОЕДИНЕНИЕ Документ.ПриобретениеТоваровУслуг КАК ПриобретениеТоваровУслуг
        ПО (ПриобретениеТоваровУслугТовары.Ссылка = ПриобретениеТоваровУслуг.Ссылка)
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ Документ.ПриобретениеТоваровУслуг.Товары КАК ПриобретениеТоваровТекущийДокумент
        ПО (ПриобретениеТоваровУслугТовары.Номенклатура = ПриобретениеТоваровТекущийДокумент.Номенклатура)
ГДЕ
    ПриобретениеТоваровУслуг.Дата > &НачДата
    И ПриобретениеТоваровУслуг.Ссылка <> ПриобретениеТоваровТекущийДокумент.Ссылка
    И ПриобретениеТоваровТекущийДокумент.Ссылка = &Ссылка

;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    ВТ_сч.Ссылка КАК Ссылка,
    ВТ_сч.Номенклатура КАК Номенклатура,
    ВТ_сч.Дата КАК Дата,
    СУММА(ВТ_сч.сч) КАК сч
ИЗ
    ВТ_сч КАК ВТ_сч
        ЛЕВОЕ СОЕДИНЕНИЕ ВТ_сч КАК ВТ_сч1
        ПО ВТ_сч.Дата <= ВТ_сч1.Дата
            И ВТ_сч.Номенклатура = ВТ_сч1.Номенклатура

СГРУППИРОВАТЬ ПО
    ВТ_сч.Ссылка,
    ВТ_сч.Номенклатура,
    ВТ_сч.Дата
ИМЕЮЩИЕ СУММА(ВТ_сч.сч) <= &КоличествоПоследних    
УПОРЯДОЧИТЬ ПО
    Номенклатура,
    Дата УБЫВ

(58) ага, понятно. Почему-то я про такой манёвр забываю всё время.

(59) блин, даже короче получилось. что-то вчера думал, что будет две временных.

(54) ну, в снеговике - это понятие, объединяющее (и разделяющееся на) остатки и обороты.
хранить а оборотном регистре удобнее, чем в справочнике,  потому, что имеешь автоматичексое удаление при распроведении/пометке удаления. а значение получать выборкой движений

(54) регистр сведений в 77 можно реализовать типа регистр без измерений, только с реквизитами

(61) Понятно. Хотя и работу со справочником можно спокойно запихнуть в ОбработкаПроведения() и ОбработкуУдаленияПроведения(), при этом не будет особых заморочек с первоначальным заполнением за предыдущие года. Но будут заморочки с УРБД.
Так что если прямые запросы, как в (58) у ТС заработает, то это будет лучшим решением. Хотя и (32) неплохо, если строк в документе в среднем немного, а то дёргать 100 раз рег.выбратьдвижения с наложеннным фильтром по товару и перебирать документы обратным порядком довольно тормозно может оказаться.
(62) Как много нам открытий чудных... С другой стороны - у меня компонента "БУ", там регистры недоступны вообще. Так что приходится искать другие способы реализации регистра сведений.

(63) а почему будут заморочки с УРБД? не вижу ни одной причины.
выборка движений в обратном порядке - не фильтруется по iddocdef, не фильтруется по виду движения (не в индексе), поэтому выбирается в dbf по тем полям, по которым может, дбф тянется на клиента, там доиндексируется, и уже по нему выборка ходит....
Ну а РС - это в любом случае табличка. И справочник ты можешь по нужным полям проиндексировать, и регистр п онужным реквизитам. Просто справочник - это "независимый РС", а регистр с толькореквизитами - "РС подчиненный регистратору"

(62) поправочка - без ресурсов
В измерении Номенклатура и вид цен
Ресурсы - пусто
Реквизиты цена

А далее
Прайс.УстановитьФильтр(Номенклатура,ТипЦен);
Прайс.ОбратныйПорядок(1);
Прайс.ВыбратьДвижения(,ДатаПрайса);
Если Прайс.ПолучитьДвижение()=1 Тогда    
   Результат=Прайс.Цена;
   //ДокументДвижения=Прайс.ТекущийДокумент();
Иначе
   Результат=0;
КонецЕсли;

(64) Заморочки с УРБД - это про реализацию задачи через справочник (дубли про одновременном проведении в двух разных базах). При реализации через регистр - такой заморочки, конечно, нет. Ну в общем выбор по решению задачи есть и зависит от умений, вкуса, конкретных параметров базы.