gifts2017

Выборка в запросе из периодического регистра сведений данных на дату из строки запроса

Опубликовал Ivon (Ivon) в раздел Программирование - Практика программирования

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

В данной статье я расскажу и приведу пример, каким образом, используя вложенные запросы, можно решить данную проблему.

Для написания статьи я создал простенькую конфигурацию и слегка заполнил данными.

Итак, имеем:

  • документ "Договор" с реквизитами "Сумма" и "Сотрудник";
  • справочник "Сотрудники" с ФИО сотрудника; 
  • регистр накопления периодический в пределах секунды "Руководители" с измерением "Сотрудник" типа Справочник.Сотрудники и ресурсом "Руководитель" типа Справочник.Сотрудники.

Наполнение:

  • Сотрудник Иванов И.И.
  • Сотрудник Петров П.П.
  • Сотрудник Сидоров С.С.
  • Запись регистра накопления: Сотрудник Иванов И.И., Руководитель Петров П.П., период 15.06.2009 00:00:00
  • Запись регистра накопления: Сотрудник Иванов И.И., Руководитель Сидоров С.С., период 15.05.2009 00:00:00
  • Договор № 1 от 05.06.2009 12:00:00, сумма 200, сотрудник Иванов И.И.
  • Договор № 2 от 20.06.2009 12:00:00, сумма 300, сотрудник Иванов И.И.

Необходимо сделать отчет за период с 01.06.2009 00:00:00 по 01.07.2009 00:00:00 в котором отразить на какую сумму договора каждый из руководителей заключил с помощью своих сотрудников. И сделать отчет нужно обязательно в компановщике, а значит данные должны быть выданы 1 запросом.

В голову сразу приходит следующий запрос:


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

СГРУППИРОВАТЬ ПО
    РуководителиСрезПоследних.Руководитель,
    Договор.Ссылка


Скажу честно, аналогичный запрос сразу же был представлен и мной. Но что же получается в итоге:

Руководитель Договор 000000001 от 05.06.2009 12:00:00 Договор 000000002 от 20.06.2009 12:00:00 Итого
Сумма Сумма Сумма
Петров П.П. 200,00 300,00 500,00
Итого 200,00 300,00

500,00

А по документам первый договор был заключен под руководством Сидорова и премию по этому договору он не получит. А значит наш отчет выдал совсем не то, что есть на самом деле.

Что делать? Все очень просто. Забыть про СрезПоследних(). Именно этот механизм, во многих случаях облегчающий написание запросов, сейчас играет не в нашу пользу. А вот вложенные запросы, которыми не всегда любят пользоваться программисты, могут сделать достаточно много. В моей практике были запросы до 10 вложенностей. Как результат - очень быстрое построение отчета одним большим (огромным) запросом. Всегда есть минус - такие запросы очень сложно переделывать. Но вернемся к теме. Для начала нам необходимо получить всех руководителей, период записи которых меньше или равен дате договора. Потом все поля, кроме периода сделать группировочными, а период взять максимальный. После этого зная сотрудника и период записи можно сделать соединение и получить руководителя на дату договора.

На практике наш новый запрос выглядит вот так:


ВЫБРАТЬ
    ВложенныйЗапрос.Ссылка КАК Договор,
    ВложенныйЗапрос.Сумма,
    Руководители.Руководитель
ИЗ
    (ВЫБРАТЬ

        Договор.Сумма КАК Сумма,
        Договор.Ссылка КАК Ссылка,
        МАКСИМУМ(Руководители.Период) КАК Период,
        Договор.Сотрудник КАК Сотрудник
    ИЗ
        Документ.Договор КАК Договор
            ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.Руководители КАК Руководители
            ПО Договор.Сотрудник = Руководители.Сотрудник
                И Договор.Дата >= Руководители.Период
    ГДЕ
        Договор.Дата МЕЖДУ &Дата1 И &Дата2

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


ZyZer (спасибо ему) подсказал вариант запроса с временной таблицей:


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

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

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


Смотрим результат:

Руководитель Договор 000000001 от 05.06.2009 12:00:00 Договор 000000002 от 20.06.2009 12:00:00 Итого
Сумма Сумма Сумма
Петров П.П.
  300,00 300,00
Сидоров С.С. 200,00   200,00
Итого 200,00 300,00 500,00

Вот теперь у нас все правильно.

Ну а если Вам необходимо вместо а-ля СрезПоследних сделать СрезПервых, просто в запросе меняем больше на меньше и максимум на минимум. Все просто.

Изучите данную базу и Вы поймете: не все полезно, что облегчает нашу жизнь.

Спасибо за внимание. И не забываем ставить плюсы.

Скачать файлы

Наименование Файл Версия Размер
База к статье 185
.1247749507 19,49Kb
25.09.09
185
.1247749507 19,49Kb Скачать

См. также

Подписаться Добавить вознаграждение
Комментарии
1. Maniac (Eugeneer) 16.07.09 21:00
В описании статьи я написал почему минус.
2. Сергей (DoReMi) 17.07.09 00:19
Жирный минус за баян изобретателю велосипеда. Лень искать клинописную табличку, в которой предками описан сей метод, но это было очень давно.
Плюс почему-то поставился, хотя за минус надо какой-то рейтинг набрать. Снять плюс тоже не вижу как. Поставил бы минус аффтарам движка и админам, тоже не вижу где это тут.
3. Ярослав Программист (ZyZer) 17.07.09 07:45
А почему именно вложенный запрос??? Почему не временная таблица? Это и отлаживать удобнее и более понятно для глаз. Честно говоря, вообще коробит, когда такие промежуточные запросы называют "ВложенныйЗапрос", неужели нельзя дать понятное наименование?
4. Ivon (Ivon) 17.07.09 09:48
(2). Я не изобретатель велосипеда. Просто не все учатся на курсах и читают нужные книги. Много самоучек с большим стажем работы и не факт, что они до этого дошли. Я показал как это решается. И я уверен, что найдутся те, кому это поможет в решении своей задачи. Я тоже самоучка и у меня нет сертификатов. На ресурсе я тоже вижу статьи и файлы, которые для меня не представляют ничего сложного и интересного, но тем не менее людям они помогают. И что, им тоже минусы?
(3). Ну я рассматривал вариант, когда все делается в одном запросе, а не в двух и более. Временная таблица подразумевает использование менеджера временных таблиц и программной обработки результата запроса и еще как минимум 1 запрос.
tinkerbell; DAnry; Pavel777777; IrinaL___; w-divin; hame1e00n; +6 Ответить
5. Ivon (Ivon) 17.07.09 09:50
(1). Спасибо за понимание.
zariciuc; +1 Ответить
6. Ярослав Программист (ZyZer) 17.07.09 10:24
Менеджер временных таблиц можно и не использовать - все организовать в одном запросе, например как-то так(как красиво вставить код в ответе не знаю):
ВЫБРАТЬ
Договор.Сумма КАК Сумма,
Договор.Ссылка КАК Ссылка,
МАКСИМУМ(Руководители.Период) КАК Период,
Договор.Сотрудник КАК Сотрудник
ПОМЕСТИТЬ РуководителиДоговоров
ИЗ
Документ.Договор КАК Договор
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.Руководители КАК Руководители
ПО Договор.Сотрудник = Руководители.Сотрудник
И Договор.Дата >= Руководители.Период
ГДЕ
Договор.Дата МЕЖДУ &Дата1 И &Дата2

СГРУППИРОВАТЬ ПО
Договор.Сумма,
Договор.Ссылка,
Договор.Сотрудник
;
ВЫБРАТЬ
РуководителиДоговоров.Ссылка КАК Договор,
РуководителиДоговоров.Сумма,
Руководители.Руководитель
ИЗ
РуководителиДоговоров КАК РуководителиДоговоров
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.Руководители КАК Руководители
ПО РуководителиДоговоров.Период = Руководители.Период
И РуководителиДоговоров.Сотрудник = Руководители.Сотрудник
DAnry; VikingKosmo; vladir; afk; Istur; artbear; mir-inoy; DoReMi; Flashback1979SE; agostev; Ivon; hame1e00n; +12 Ответить 1
7. Анатолий (hame1e00n) 17.07.09 10:29
Статья безусловно полезная, я думаю есть начинающие программисты на 1С, которые об этом не знают. В любом случае, именно подобные статьи и делают инфостарт таким ценным ресурсом - мы делимся опытом и сами чему-то учимся. Не пойму, зачем ставить минус, если ты знаешь об этом приеме.
Короче автору однозначно +
ivannn; Nelli_A86; Ivon; +3 Ответить 1
8. Ivon (Ivon) 17.07.09 10:54
(6). Согласен. Работает. Еще 1 вариант. Наберу рейтинг 30, поставлю +.
9. Ivon (Ivon) 17.07.09 11:10
10. Игорь Исхаков (Ish_2) 17.07.09 11:16
Рассмотрим первый пример из статьи :
***************************************
ВЫБРАТЬ
Договор.Ссылка КАК Договор,
СУММА(Договор.Сумма) КАК Сумма,
РуководителиСрезПоследних.Руководитель
ИЗ
Документ.Договор КАК Договор
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.Руководители.СрезПоследних(&Дата2, ) КАК РуководителиСрезПоследних
ПО Договор.Сотрудник = РуководителиСрезПоследних.Сотрудник
ГДЕ
Договор.Дата МЕЖДУ &Дата1 И &Дата2

СГРУППИРОВАТЬ ПО
РуководителиСрезПоследних.Руководитель,
Договор.Ссылка
******************************************

Язык запросов - язык декларативный , т.е. не определяющий последовательность действий при выполнении платформой запроса.

В какой последовательности ,на взгляд автор, будет происходить исполнение
запроса :

1. Вначале будет выполнено левое соединение всей (!) таблицы Договоров с регистром сведений и лишь потом фильтрация полученной промежуточной таблицы по условию
"ГДЕ
Договор.Дата МЕЖДУ &Дата1 И &Дата2"".

2. Или вначале будет фильтрация талицы Договоров по условию "ГДЕ ..."
и лишь затем левое соединение полученной промежуточной таблицы с регистром сведений.

Итак , п.1 или п.2 ?
11. Ярослав Программист (ZyZer) 17.07.09 11:35
(10) О том, как исполняется в файловом варианте - не знаю, но у движка MSSQL вроде как хватает сообразительности пойти по 2 варианту. Подцепитесь профайлером и посмотрите план исполнения запроса.
12. Misha ⁠ (Magister) 17.07.09 11:37
Я давно уже про это читал на Мисте:
http://www.kb.mista.ru/article.php?id=92
--
А какой собственно выигрыш при использовании временных таблиц? Мне например они как-то не по душе, вложенные запросы понятнее.
13. Игорь Исхаков (Ish_2) 17.07.09 11:39
(11) Спасибо за совет. Но подождем ответа автора для для файлового и SQL вариантов.
14. Ivon (Ivon) 17.07.09 11:41
(10). Честно говоря не знаю, да и абсолютно нет разницы для конечного результата.
15. Ярослав Программист (ZyZer) 17.07.09 11:42
(12) Ну про вложенные запросы - это на вкус и цвет, как говорится, но мне удобнее видеть выборки отдельно. Да и если выборки сложные и требующие частого вычисления одного и того-же в нескольких запросах - менеджер временных таблиц может здраво ускорить выборки.
Spacer; afanasko; +2 Ответить
16. Роман (srv7) 17.07.09 13:56
За идею - плюс. Помню, сам парился на эту тему и решил проблему аналогичным способом )) будет полезна многим
Istur; hame1e00n; +2 Ответить
17. Dmitry Afanasyev (afanasko) 17.07.09 16:06
(12)
Во временных таблицах можно строить индекс по колонкам.
18. Игорь Исхаков (Ish_2) 17.07.09 16:33
(14) Конечно нет разницы для конечного результата.
Разница будет во времени исполнения . По п. 1 оно может быть очень значительным.
Чтобы исключить п.1 и не надеяться на оптимизатор запроса при файловом
или SQL-варианте в указанном тексте лучше применить временную таблицу или вложенный запрос.
Насколько мне известно , "1с" не публиковала описание оптимизатора запроса в файловом варианте.
19. Sasha Erem (erem) 17.07.09 17:26
в Укр. типовом ЗУП полно таких конструкций. Метод действительно давно уже используется - "Срез последних на разные периоды", а плюс за описание для молодежи...
20. Ivon (Ivon) 17.07.09 17:56
(18).Ну, как вариант, можно сделать вначале выборку нужных данных во вложенном запросе. Так будет явно понятно в какой последовательности происходит выборка, но приведенный тобой запрос (10) все-равно является неверным для задачи, так как выдает неправильный результат, поэтому какой смысл его использовать?...
21. Игорь Исхаков (Ish_2) 17.07.09 19:03
(20) Пример взят из описания текущей темы . И в последующем примере запроса в описании темы - та же ошибка при построении запроса.

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

Подробнее прочитать про оптимальность и неоптимальность запроса
можно в статье Павла Чистова "Пакетные запросы" из рубрики "1с рекомендует".
22. Ivon (Ivon) 17.07.09 23:30
(21). Будет время - обязательно сделаю базу с количеством записей 20 000 на каждый объект конфигурации и проверю разницу времени выполнения запроса. На текущий момент могу сказать, что выполнение сложного запроса и построение отчета за 2 секунды целиком устраивает моих пользователей.
23. Игорь Исхаков (Ish_2) 17.07.09 23:46
(22) Чтобы картина была более полной , возможно будет интересно почитать
и сторонников противоположной точки зрения

http://infostart.ru/blogs/1179/
24. Сергей (lsp71) 20.07.09 12:45
+ за просвещение самоучек (тоже была такая проблема).
25. Ivon (Ivon) 20.07.09 13:20
(23). Вообще-то статья была на тему составления запроса для получения правильного результата, а не о оптимизации и скорости выполнения запросов. Думаю, что дальше развивать полемику на эту тему нет смысла. Для этого скорее всего и была создана тема, ссылку на которую ты указал.
26. ninch Иванов (ninch) 21.07.09 05:53
Особо еще не разобрался в тонкостях, но были такие же ситуации, возможно тогда бы такое решение мне бы и помогло:))) Спасибо за ликбез
27. Сергей (DoReMi) 21.07.09 09:49
Несколько странным кажется, что люди не умеют пользоваться поиском и поисковыми машинами.
Потрачено время на то, что уже придумано другими людьми гораздо раньше. Я бы не знал куда спрятаться от стыда.
28. Ivon (Ivon) 21.07.09 09:55
Добавил в статью вариант запроса с временной таблицей от ZyZer из поста 6.
29. Ivon (Ivon) 21.07.09 10:06
(27). Не надо обалдевать от собственной крутости. Бывает, что просто не видишь даже вариантов решения вопроса. Как в фильме: видишь суслика? Нет. А ведь он есть. Кто-то (как ты, например) посещал немеряно курсов и знает про 1С все (ну или думает, что знает), а кто-то нигде не учился. Я например, до 1С программировал на 3 языках: Perl, VB и C#. А СрезПоследних так забивает голову, что сразу и не найдешь решение, если не вспомнишь былую практику или, как в твоем случае, курсы.
30. Сергей (DoReMi) 21.07.09 10:47
(29) про курсы анекдот какой-то, я слесарь-сборщик радиоаппаратуры и консерваториев не кончал, однако когда проблема встала с необходимостью получения данных в запросе на дату документа - нашел на мисте описалово метода и стал пользоваться, и это не моя крутость, а ваша пафосность в представлении этого баяна немного меня зацепила.
31. Ivon (Ivon) 21.07.09 13:05
(30). Ну, никто же не мешал тебе сделать статью здесь. Я разместил статью потому, что дошел до этого своим умом, когда знакомые считали это сложноразрешимым. Более того, некоторое время сам думал, что это нереально сделать в одном запросе. Я же не написал, что это открытие века.
32. Сергей (DoReMi) 21.07.09 17:54
(31) Ндя... А просто погуглить "запрос срез последних на дату документа"?
33. Сергей (DoReMi) 21.07.09 17:57
Надо завязывать конечно с этим спором, я не размещаю статей, я не учусь на курсах, я просто прежде чем написать "я открыл Америку" пытаюсь найти информацию, не открывал ли кто-то её уже раньше. И вам советую. Во-1х экономит время сильно, во-2х не попадёте в глупое положение.
34. Ivon (Ivon) 22.07.09 13:08
(33). Во первых, я не писал, что "я открыл Америку", а во вторых, как показало время, статья оказалась полезной другим. А то, что статей не пишете - так это вам не в плюс. Знаниями и опытом надо делиться.
35. Александр Хомяк (logarifm) 27.10.09 19:33
Да но в этом методе есть и отрицательные стороны. На больших таблицах, будут тормоза. А еще если это связано с регистром накопления, а что если необходимо получать остатки на дату документов, а регистр к примеру партий товаров... Вот этот способ не сработает. То есть оно работать будет но ужастно долго!!!!!!
36. Ivon (Ivon) 28.10.09 10:55
(35). Естественно, запрос будет отрабатывать дольше. Но он будет работать и выдавать правильный (!) результат. Если у Вас есть решение лучше - пожалуйста, предложите. Во всяком случае это решение будет работать гораздо быстрее, чем если обрабатывать эти вещи не в запросе, а в коде.
37. Александр Хомяк (logarifm) 28.10.09 11:13
(36) Смотря для каких задач... Это хорошее решение и правильно что выложили его здесь... Просто не для всех оно подходит. Например мне необходимо было делать выборку по заказам покупателей и на момент заказа смотреть стоимость партии в регистре накопления "ПартииТоваров", вот этот вариант уже не подходит... Постоянный перерасчет регистра на всю номенклатуру...

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

Не спорю это не гуманно, но пришлось и так обходить!
38. Ivon (Ivon) 28.10.09 11:53
(37). А вы не пробовали сравнить скорость выполнения обработки кодом и сложным запросом? Я думаю, что на среднем компьютере сложный запрос будет выполняться быстрее, чем обработка кодом. Сейчас у меня отчет на запросе в 1642 строки отрабатывает порядка 20 секунд. Я даже не представляю, сколько он отрабатывал, если бы обработки были в коде. Ведь код обрабатывается на клиентской машине, а весь запрос на сервере, который гораздо производительнее клиентской машины.
39. Александр Хомяк (logarifm) 28.10.09 19:48
(38) Опять же спорно... Сделайте так как я говорю и вы увидите в чем прикол, структура хранения регистров сведений и регистров накоплений совершенно другая. И в запросе указывая дату расчета на каждый документ происходит постоянный перерасчет данных...

А насчет кодом у клиента, необязательно, можно клиенту отдать таблицу значений которая отработана на сервере (ну это касательно 8.2, хотя 8.1 можно построить на уровне серверных модулей схожее выполнение).
40. Александр Хомяк (logarifm) 28.10.09 19:53
И все же яне опровергаю вашу статью и ставлю +1. Я сам пользовался и не однократно срезом регистра сведений на "динамические даты" и это пролетало, а вот с регистром накоплений к примеру "Партии товаров" можете представить себе объемность данной таблицы, долго... Так как нету фильтра на номенклатуру в этом беда, он рассчитывает таблицу в целом.... Я просто поднял свою тему так как пришлось совершенно недавно с этим столкнуться: Поднимал этот вопрос на мисте

И выкладываю этот материал как примечание чтобы взять во внимание. Спсасибо за понимание, а автору плюс за труды!
41. Ivon (Ivon) 29.10.09 10:21
(40) Честно говоря, я стараюсь не использовать внутренние механизмы типа "Срез". Механизм "Обороты" так же в последнее время в основном не вызывается, а вместо него пишется вложенный запрос. Как показала практика, самописные выборки гораздо гибче встроенных механизмов. С "Остатками" мне почти не приходится работать, но, думаю, если придется, можно и это реализовать.
42. kolpak_mp3 20.11.09 08:17
Поражаюсь. Одна критика. Я вот вчера только узнал про вложенные запросы. Для начинающих полезная статья. Автору +
43. hren hren (hren) 19.05.10 02:46
(32) из-за таких как ты, все запросы в гугл отправляют тебя на страницу, где советуют обратно поискать в гугле
Spacer; Valerich; +2 Ответить 3
44. Валерий Дубовой (Valerich) 19.05.10 03:38
(32). Если уж советуешь погуглить, то приведи сразу ссылку, потому как (43) 100% прав
45. Сергей (DoReMi) 19.05.10 07:09
(43) и (44) вам почти год понадобился чтобы найти решение в гугле? :) вот ссылка http://kb.mista.ru/article.php?id=92 первая редакция от 16.02.06
иначе я не вижу причин, чтобы разводить флейм в теме, которая стара как мир.
46. Валерий Дубовой (Valerich) 19.05.10 07:16
(45) я не рассуждаю о свежести темы. Просто (43) прав в принципе безотносительно темы. Очень часто ищешь информацию (ЛЮБУЮ), а натыкаешся только на своеты погуглить, спросить яндекс и т.п., что не ускоряет поиск нужной информации, потому как эти советы гораздо свежее по времени самой информации.
Будет гораздо уважительнее ко всем, в т.ч. и новичкам, если пишешь про баян, то сразу дай ссылку на этот баян.

С уважением. Ничего личного.
47. A_kryl К (A_kryl) 09.02.11 12:20
Для начала нам необходимо получить всех руководителей, период записи которых меньше или равен дате договора. Потом все поля, кроме периода сделать группировочными, а период взять максимальный.

Данная фраза не верна - нужно сделать группировку по всем измерениям регистра и по периоду - чтоб в выборке однозначно получить его ресурсы, и вообще относительно http://www.kb.mista.ru/article.php?id=92 пример не доделан, выборкой с группировкой мы находим конкретную запись, связываем по измерениям еще раз с регистром сведений и получаем ресурс(ы). А потом уже они выводятся в окончательный запрос. В качестве примера - регистр цен, если я сделаю группировку по ресурсу цена - никакой максимум не сработает, а так как в группировке участвуют все поля запроса :(
48. mailrum2004 08.05.12 11:11
Спасибо автору за пример использования хоть и известного, но полезного подхода в работе с периодическими регистрами сведений. Иногда помишь, что такое возможно, но не помнишь как. Такие статьи помогают отыскать забытые или потерянные знания.
Nelli_A86; +1 Ответить
49. Сергей Крайнов (ccserg) 29.08.15 21:55
(47) A_kryl,
видимо столкнулся с такой проблеммой , не работает максимум , не понимаю , как решить ?
у меня в запросе два регистра сведений соединяются по Периоду
50. Валера Мартиков (valeriy-vm) 14.12.15 16:17
Рабочий пример для ЗУП 2.5

ВЫБРАТЬ
СУММА(ВЫБОР
КОГДА РаботникиОрганизаций.ЗанимаемыхСтавок > 0
ТОГДА 1
ИНАЧЕ -1
КОНЕЦ) КАК Количество,
табПериодов.ДатаПериод КАК ДатаПериод
ИЗ
(ВЫБРАТЬ
КОНЕЦПЕРИОДА(КурсыВалют.Период, МЕСЯЦ) КАК ДатаПериод
ИЗ
РегистрСведений.КурсыВалют КАК КурсыВалют
ГДЕ
КурсыВалют.Период МЕЖДУ &НачПериода И &КонПериода

СГРУППИРОВАТЬ ПО
КОНЕЦПЕРИОДА(КурсыВалют.Период, МЕСЯЦ)) КАК табПериодов
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.РаботникиОрганизаций КАК РаботникиОрганизаций
ПО табПериодов.ДатаПериод >= РаботникиОрганизаций.Период
ГДЕ
НЕ РаботникиОрганизаций.ПричинаИзмененияСостояния = ЗНАЧЕНИЕ(Перечисление.ПричиныИзмененияСостояния.Перемещение)

СГРУППИРОВАТЬ ПО
табПериодов.ДатаПериод

УПОРЯДОЧИТЬ ПО
ДатаПериод