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

выбрать первые 3 упорядочить по период убыв

(0) А цены у тебя где? В регистре сведений?

(0) тебе просто три последние цены из поступлений , или цены на дату трех поступлений?

(1) а если несколько позиций одновременно?

Да, есть массив товаров, нужны три последних цены (чтобы узнать среднюю).
Ну, например, есть РН Закупки.

+(4) и по разной цене?

(4),
Конечно, так и будет.
(6) ну, тут не принципиально)

(5) Тогда напрашивается отбор по виду регистратора и как в (1).

Пока сделал только дерево с номенклатурой и всеми приходами.... надо оставить только три прихода..

(8)Это понятно. А дальше?

Конечно, можно обойти Дерево, но это как-то убого. Неужели через запрос никак...

Точнее, надо выбрать три последних прихода (в список), а потом вибирать из регистра по вхождению регистратора в этот список. Как-то так.

(12)
"Точнее, надо выбрать три последних прихода (в список)," и как их выбрать? Конечно, связать потом по ссылке проблем нет....

(13) Ну, я так понимаю, что как в (1), только запрос по документам.

(14)Ну он и выведет мне три строчки. А у меня массив из ста позиций номенклатур.

Вот у меня и дилема теперь - то ли получить полную таблицу со всем приходами, то ли делать 100 запросов по каждой номенклатуре как в (1)

(15) Тогда я не понимаю, чего ты хочешь. В (0) ты сказал "получить цену номенклатуры", теперь говоришь про массив из ста позиций.

(16) А, вон ты о чём, ну так и фильтруй запрос по регистру накоплений по вхождению номенклатуры в этот массив.

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

+(18) И да, надо получать все приходы кучей.

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

Классная задачка.
Первая покупка 3 года назад.
Вторая - 2 года назад.
Третья сегодня.
Цена то классная будет.

Запрос с тремя уровнями вложенностями

С начала получаешь партию с максимальной датой Дата1

На втором уровне с максимаьлной датой но меньше дата1 - дата2

На тертьем уровне максимльной датой но меньше дата 3

(23) вот, наконец-то первая здравая идея)
Но если вложенность захотят задавать руками.. например, 5 последних партий..

(22)Да не - там все четко, приходы каждую неделю, хотим узнать среднюю "нормативную" стоимость

(25) Ну так и выбирай все данные, просто за последнюю неделю.

(25) на некоторые позиции по две недели)))

(27) Значит за две недели.

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

Если нужна средняя, почему не получить среднюю? Зачем эти 3-5 цифирек? Пользователю - полюбоваться? Программисту - побаловаться?

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

(30)дык, мне и не нужны эти циферки - нужна одна - средее арифметическое. Но как я его получу без этих циферок??

(32) Одна цифра сильно упрощает дело.

(33) Ок, подкинь идею, пока пытаюсь сделать как в (23)

(24) тогда только использовать способ номер по порядку

Например как в
v8: Номер по порядку в консоли запросов

(34) Номер по порядку


ВЫБРАТЬ
   Вложение.Номенклатура КАК Номенклатура,
   Вложение.Цена / Вложение.Делитель КАК Среднее
ИЗ
   (ВЫБРАТЬ
       Закупки.Номенклатура КАК Номенклатура,
       СУММА(Закупки.Стоимость / Закупки.Количество) КАК Цена,
       СУММА(1) КАК Делитель
   ИЗ
       РегистрНакопления.Закупки КАК Закупки
   ГДЕ
       Закупки.Номенклатура В(&СписокНоменклатуры)
   
   СГРУППИРОВАТЬ ПО
       Закупки.Номенклатура) КАК Вложение


(0) Ищи мою ветку "Срез предпоследних" месяц назад была. Идея решения - там.

+(37) только сперва упорядочить по дате документа и добавить такую штуку в таблицу Вложение
ИМЕЮЩИЕ
   СУММА(1)  < 4

должно взлететь.

зачем???

(37) было к (34) с учетом (32)

(39) не... неправильно

да ваще чушь, а если было 4,5,6 ... приходов - среднего не будет? )))

(37) ему среднее n последних надо

(44) внимательно (41) или сразу (32)

тут только номером по порядку. в FAQ-ах по SQL расписано.

(44) да, так и надо.

(47) n чему равно?

n - параметр

47 был вопрос

(48) В ТЗ - или 3 или 5. В идеале - чтобы можно было задавать. Заказчик сам не знает, какая глубина n ему нужна.

тогда посложнее

чуть чуть)

(37) крутяк. Не понял, правда, пока как работает, но попробую прикрутить.

(54), блин, здесь я про (35) номер по порядку писал

и что ты в результате наваял, хвались

(37)сюда кол-во поступлений не привязать....

(56) разбираюсь еще

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

(59) а как 5 например отрезать?

еще и через параметр

(60) Этот запрос во временную таблицу или во вложенный запрос. Кому как нравится

и что дальше то делать

если ТС не потренироваться в хитрых запросах а реальная задача то на мой взгляд самое оптимальное динамически сделать текст запроса и не ипать моск

Все супер, получилось через (35!!!)
(62)Проанализировал. Идея та же, что и в 35, но там просто не получается, т.к. нужна сортировка убыванию поступлений и (60)

Дальше там все очевидно. Главное - номер по порядку получить, чтобы потом на него условие накладывать.

сюда кинь, интересно

это (65)

(68)
Вот для Трех последних поступлений:

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

СГРУППИРОВАТЬ ПО
   ТабЗакупки.Номенклатура,
   ТабЗакупки.Номенклатура.Артикул,
   ТабЗакупки.Период
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
   Таб1.Артикул,
   Таб1.Номенклатура,
   Таб1.СтоимостьОборот,
   Таб1.КоличествоОборот,
   Таб1.Период,
   КОЛИЧЕСТВО(Таб11.Период) КАК Счетчик
ПОМЕСТИТЬ Итоговая
ИЗ
   Таб1 КАК Таб1
       ВНУТРЕННЕЕ СОЕДИНЕНИЕ Таб1 КАК Таб11
       ПО Таб1.Период >= Таб11.Период
           И Таб1.Номенклатура = Таб11.Номенклатура

СГРУППИРОВАТЬ ПО
   Таб1.Артикул,
   Таб1.Период,
   Таб1.Номенклатура,
   Таб1.СтоимостьОборот,
   Таб1.КоличествоОборот
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
   Итоговая.Артикул,
   Итоговая.Номенклатура,
   Итоговая.СтоимостьОборот,
   Итоговая.КоличествоОборот,
   Итоговая.Период,
   Итоговая.Счетчик
ИЗ
   Итоговая КАК Итоговая
ГДЕ
   Итоговая.Счетчик <= 3

работает там, где есть регистр Закупки

прикольно

Вроде, все зашибись получилось))))
А идея в (35) вообще для меня прорыв, после "Остатки по регистру на каждый день"

Интересно, почему я ее раньше за столько лет не нашел на мисте... наверное, искал "счетчик в запросе" - в итоге, ниче не нашел, кроме СКД

Щас доделаю еще одну временную табличку с средним арифметическим и вообще все будет зашибись)))

Вообще, конечно, работает не очень быстро
45 тысяч строк - 8 секунд

Номенклатура В ИЕРАРХИИ
вот это наверное просто В без "ИЕРАРХИИ"
и кстати выбирает первые n поступлений а не последние

ПО Таб1.Период >= Таб11.Период
на
ПО Таб1.Период <= Таб11.Период
поменять вроде, проверь

(77) да, точняк) как раз только что нашел и поправил. Херово соображаю уже, не сразу понял как сортировку поменять

(76) не, они любят выбирать каталоги....

ну тогда да

45 тысяч строк - 8 секунд

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

(81) не прокатит - некоторые позиции в 10 году последний раз закупались. Пусть лопатит.

Могу дать ссылку у меня есть платная ращработка готовая) как говорится лесапед уже давно изобретен

а говорил раз в неделю приход бывает) тогда конечно все придется брать

(84) к (82)

(84) как правило, да, даже чаще. Но состав прихода всегда разный.

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

я бы замутил на скд, глядишь - оно к нормальному sql запросу преобразует

(86) поэтому гарантий никто не даст, а отчет всегда должен правильно работать. Вне зависимости, когда закупили

Просто ситуация до боли знакома) когла нафинают с ценообразованием что то хитрить и придумывать - это надолго и всеръез. У меня контора все три года пыталась что то придумать новое.

(88) Вообще это обработка. Чтобы получить "нормативную" цену и по ней выбрать "примерно верную (+-15%)" из прайсов поставщиков. Дальше делается заказ.

(88) Да ладно, не умрут. Скорость выполнения приемлемая.

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

(93) Беру только ПТиУ. Разовые поставки - потом фильтр сделаю. А по уму тут надо СКО мутить.

Чтобы отбросить "нелепые" цены

ничего лучше чем ограничение по периоду и получение связки - минимум, средняя, максимум не будет.

например - последний месяц, последние три месяца, с начала года и тп

(97)
Согласен. В доп ТЗ допрут)))

(98) С другой стороны - там такой оборот, что все равно не будут ничего анализировать в момент заказа

Круто получилось. Прицепил это все дело к другому запросу, связал по номенклатуре. Правда, в запросе 825 строчек получилось, но бывают и побольше))))

(0) сортировать по дате последнего поступления и применить в запросе Первые 3

+(101) если я не прав, закритикуйте

(101) для списка позиций не прокатит. Только для одной

Решение в (69). Только знак на <= поменять надо

825! не, что-то не попадались побольше. Думаю, даже в ЗУПе меньше строчек в запросах

(105) ??? промахнулись?

сорри(((

(105) Ну, это вряд ли. Просто я предпочитаю все нужные данные по максимуму вытягивать запросом. Ненавижу циклы и "шерстить", как это это называют некоторые гомнокодеры))))))

Отмечусь