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

21.07.09

Разработка - Запросы

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

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

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

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

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

Итак, имеем:

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

Наполнение:

  • Сотрудник Иванов И.И.
  • Сотрудник Петров П.П.
  • Сотрудник Сидоров С.С.
  • Запись регистра накопления: Сотрудник Иванов И.И., Руководитель Петров П.П., период 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

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


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


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

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

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

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

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

См. также

SALE! 20%

Infostart Toolkit: Инструменты разработчика 1С 8.3 на управляемых формах

Инструментарий разработчика Роли и права Запросы СКД Платформа 1С v8.3 Управляемые формы Запросы Система компоновки данных Конфигурации 1cv8 Платные (руб)

Набор инструментов программиста и специалиста 1С для всех конфигураций на управляемых формах. В состав входят инструменты: Консоль запросов, Консоль СКД, Консоль кода, Редактор объекта, Анализ прав доступа, Метаданные, Поиск ссылок, Сравнение объектов, Все функции, Подписки на события и др. Редактор запросов и кода с раскраской и контекстной подсказкой. Доработанный конструктор запросов тонкого клиента. Продукт хорошо оптимизирован и обладает самым широким функционалом среди всех инструментов, представленных на рынке.

13000 10400 руб.

02.09.2020    122170    670    389    

714

Для чего используют конструкцию запроса "ГДЕ ЛОЖЬ" в СКД на примере конфигурации 1С:ERP

Запросы СКД Платформа 1С v8.3 Запросы Система компоновки данных 1С:ERP Управление предприятием 2 Бесплатно (free)

В типовых конфигурациях разработчики компании 1С иногда используют в отчетах, построенных на СКД, такую конструкцию, как "ГДЕ ЛОЖЬ". Такая конструкция говорит о том, что данные в запросе не будут получены совсем. Для чего же нужен тогда запрос?

13.02.2024    5746    KawaNoNeko    23    

23

Набор-объект для СКД по тексту или запросу

Запросы СКД Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Абонемент ($m)

Есть список полей в виде текста, или запрос - закидываем в набор СКД.

1 стартмани

31.01.2024    2000    2    Yashazz    0    

29

Запрос 1С copilot

Инструментарий разработчика Запросы Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Абонемент ($m)

Пишем на человеческом языке, что нам надо, и получаем текст запроса на языке 1С. Используются большие языковые модели (LLM GPT) от OpenAI или Яндекс на выбор.

5 стартмани

15.01.2024    6285    31    mkalimulin    25    

50

PrintWizard: поддержка представлений ЗУП в конструкторе

Инструментарий разработчика Запросы Платформа 1С v8.3 Бесплатно (free)

Одной из интересных задач, стоящих в процессе разработки, была поддержка механизма представлений в ЗУП. Но не просто возможность исполнения запросов с ними. Основная проблема была в том, чтобы с ними было удобно работать, а именно: создавать, модифицировать и отлаживать. Кратко о том, что в итоге получилось...

14.12.2023    1742    vandalsvq    7    

29

Объектная модель запроса "Схема запроса" 2

Запросы Платформа 1С v8.3 Запросы Конфигурации 1cv8 Бесплатно (free)

Далеко уже не новый тип данных "Схема запроса". Статья о том, как использовать его "попроще". Примеры создания текста запроса с нуля и изменение имеющегося запроса.

06.12.2023    5388    user1923546    26    

43

Начните уже использовать хранилище запросов

HighLoad оптимизация Запросы

Очень немногие из тех, кто занимается поддержкой MS SQL, работают с хранилищем запросов. А ведь хранилище запросов – это очень удобный, мощный и, главное, бесплатный инструмент, позволяющий быстро найти и локализовать проблему производительности и потребления ресурсов запросами. В статье расскажем о том, как использовать хранилище запросов в MS SQL и какие плюсы и минусы у него есть.

11.10.2023    16186    skovpin_sa    14    

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

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

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

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

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

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

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

Итак , п.1 или п.2 ?
11. ZyZer 252 17.07.09 11:35 Сейчас в теме
(10) О том, как исполняется в файловом варианте - не знаю, но у движка MSSQL вроде как хватает сообразительности пойти по 2 варианту. Подцепитесь профайлером и посмотрите план исполнения запроса.
13. Ish_2 1104 17.07.09 11:39 Сейчас в теме
(11) Спасибо за совет. Но подождем ответа автора для для файлового и SQL вариантов.
14. Ivon 673 17.07.09 11:41 Сейчас в теме
(10). Честно говоря не знаю, да и абсолютно нет разницы для конечного результата.
18. Ish_2 1104 17.07.09 16:33 Сейчас в теме
(14) Конечно нет разницы для конечного результата.
Разница будет во времени исполнения . По п. 1 оно может быть очень значительным.
Чтобы исключить п.1 и не надеяться на оптимизатор запроса при файловом
или SQL-варианте в указанном тексте лучше применить временную таблицу или вложенный запрос.
Насколько мне известно , "1с" не публиковала описание оптимизатора запроса в файловом варианте.
20. Ivon 673 17.07.09 17:56 Сейчас в теме
(18).Ну, как вариант, можно сделать вначале выборку нужных данных во вложенном запросе. Так будет явно понятно в какой последовательности происходит выборка, но приведенный тобой запрос (10) все-равно является неверным для задачи, так как выдает неправильный результат, поэтому какой смысл его использовать?...
21. Ish_2 1104 17.07.09 19:03 Сейчас в теме
(20) Пример взят из описания текущей темы . И в последующем примере запроса в описании темы - та же ошибка при построении запроса.

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

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

http://infostart.ru/blogs/1179/
25. Ivon 673 20.07.09 13:20 Сейчас в теме
(23). Вообще-то статья была на тему составления запроса для получения правильного результата, а не о оптимизации и скорости выполнения запросов. Думаю, что дальше развивать полемику на эту тему нет смысла. Для этого скорее всего и была создана тема, ссылку на которую ты указал.
62. AlexO 135 28.01.24 11:01 Сейчас в теме
(10) в 1С вроде как раз всегда идут по самому длинному и неоптимальному пути - сначала выборка по левому соединению по виртуальной таблице, потом - по условию из секции ГДЕ (п.1).
Поэтому и рекомендуют, если уж выбираете из виртуальной таблицы - то все условия по-максимуму писать в параметрах виртуальной таблицы.
12. Magister 134 17.07.09 11:37 Сейчас в теме
Я давно уже про это читал на Мисте:
http://www.kb.mista.ru/article.php?id=92
--
А какой собственно выигрыш при использовании временных таблиц? Мне например они как-то не по душе, вложенные запросы понятнее.
15. ZyZer 252 17.07.09 11:42 Сейчас в теме
(12) Ну про вложенные запросы - это на вкус и цвет, как говорится, но мне удобнее видеть выборки отдельно. Да и если выборки сложные и требующие частого вычисления одного и того-же в нескольких запросах - менеджер временных таблиц может здраво ускорить выборки.
Spacer; afanasko; +2 Ответить
63. AlexO 135 28.01.24 11:05 Сейчас в теме
(15)
Ну про вложенные запросы - это на вкус и цвет, как говорится

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

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

про это и говорить нечего, понятно, что получить данные один раз, и потом использовать готовую выборку - ровно в два раза быстрее, чем получать их два раза (каждый раз по вложенному запросу).
17. afanasko 35 17.07.09 16:06 Сейчас в теме
(12)
Во временных таблицах можно строить индекс по колонкам.
64. AlexO 135 28.01.24 11:07 Сейчас в теме
(12)
вложенные запросы понятнее.

надеюсь, через 15 лет вы все-таки поняли, чем плохи вложенные запросы, и что они уж точно не понятнее и нагляднее временных таблиц.
16. Alien_RS_Forever 432 17.07.09 13:56 Сейчас в теме
За идею - плюс. Помню, сам парился на эту тему и решил проблему аналогичным способом )) будет полезна многим
Istur; hame1e00n; +2 Ответить
19. erem 424 17.07.09 17:26 Сейчас в теме
в Укр. типовом ЗУП полно таких конструкций. Метод действительно давно уже используется - "Срез последних на разные периоды", а плюс за описание для молодежи...
24. lsp71 20.07.09 12:45 Сейчас в теме
+ за просвещение самоучек (тоже была такая проблема).
26. ninch 51 21.07.09 05:53 Сейчас в теме
Особо еще не разобрался в тонкостях, но были такие же ситуации, возможно тогда бы такое решение мне бы и помогло:))) Спасибо за ликбез
27. DoReMi 21.07.09 09:49 Сейчас в теме
Несколько странным кажется, что люди не умеют пользоваться поиском и поисковыми машинами.
Потрачено время на то, что уже придумано другими людьми гораздо раньше. Я бы не знал куда спрятаться от стыда.
29. Ivon 673 21.07.09 10:06 Сейчас в теме
(27). Не надо обалдевать от собственной крутости. Бывает, что просто не видишь даже вариантов решения вопроса. Как в фильме: видишь суслика? Нет. А ведь он есть. Кто-то (как ты, например) посещал немеряно курсов и знает про 1С все (ну или думает, что знает), а кто-то нигде не учился. Я например, до 1С программировал на 3 языках: Perl, VB и C#. А СрезПоследних так забивает голову, что сразу и не найдешь решение, если не вспомнишь былую практику или, как в твоем случае, курсы.
EugeneR1c; Yuri_T; DAnry; +3 Ответить
30. DoReMi 21.07.09 10:47 Сейчас в теме
(29) про курсы анекдот какой-то, я слесарь-сборщик радиоаппаратуры и консерваториев не кончал, однако когда проблема встала с необходимостью получения данных в запросе на дату документа - нашел на мисте описалово метода и стал пользоваться, и это не моя крутость, а ваша пафосность в представлении этого баяна немного меня зацепила.
31. Ivon 673 21.07.09 13:05 Сейчас в теме
(30). Ну, никто же не мешал тебе сделать статью здесь. Я разместил статью потому, что дошел до этого своим умом, когда знакомые считали это сложноразрешимым. Более того, некоторое время сам думал, что это нереально сделать в одном запросе. Я же не написал, что это открытие века.
32. DoReMi 21.07.09 17:54 Сейчас в теме
(31) Ндя... А просто погуглить "запрос срез последних на дату документа"?
43. hren 19.05.10 02:46 Сейчас в теме
(32) из-за таких как ты, все запросы в гугл отправляют тебя на страницу, где советуют обратно поискать в гугле
Yuri_T; Designer1C; Spacer; Valerich; +4 Ответить
45. DoReMi 19.05.10 07:09 Сейчас в теме
(43) и (44) вам почти год понадобился чтобы найти решение в гугле? :) вот ссылка http://kb.mista.ru/article.php?id=92 первая редакция от 16.02.06
иначе я не вижу причин, чтобы разводить флейм в теме, которая стара как мир.
46. Valerich 1633 19.05.10 07:16 Сейчас в теме
(45) я не рассуждаю о свежести темы. Просто (43) прав в принципе безотносительно темы. Очень часто ищешь информацию (ЛЮБУЮ), а натыкаешся только на своеты погуглить, спросить яндекс и т.п., что не ускоряет поиск нужной информации, потому как эти советы гораздо свежее по времени самой информации.
Будет гораздо уважительнее ко всем, в т.ч. и новичкам, если пишешь про баян, то сразу дай ссылку на этот баян.

С уважением. Ничего личного.
44. Valerich 1633 19.05.10 03:38 Сейчас в теме
(32). Если уж советуешь погуглить, то приведи сразу ссылку, потому как (43) 100% прав
Designer1C; +1 Ответить
28. Ivon 673 21.07.09 09:55 Сейчас в теме
Добавил в статью вариант запроса с временной таблицей от ZyZer из поста 6.
33. DoReMi 21.07.09 17:57 Сейчас в теме
Надо завязывать конечно с этим спором, я не размещаю статей, я не учусь на курсах, я просто прежде чем написать "я открыл Америку" пытаюсь найти информацию, не открывал ли кто-то её уже раньше. И вам советую. Во-1х экономит время сильно, во-2х не попадёте в глупое положение.
34. Ivon 673 22.07.09 13:08 Сейчас в теме
(33). Во первых, я не писал, что "я открыл Америку", а во вторых, как показало время, статья оказалась полезной другим. А то, что статей не пишете - так это вам не в плюс. Знаниями и опытом надо делиться.
Yuri_T; w-divin; +2 Ответить
35. logarifm 1117 27.10.09 19:33 Сейчас в теме
Да но в этом методе есть и отрицательные стороны. На больших таблицах, будут тормоза. А еще если это связано с регистром накопления, а что если необходимо получать остатки на дату документов, а регистр к примеру партий товаров... Вот этот способ не сработает. То есть оно работать будет но ужастно долго!!!!!!
36. Ivon 673 28.10.09 10:55 Сейчас в теме
(35). Естественно, запрос будет отрабатывать дольше. Но он будет работать и выдавать правильный (!) результат. Если у Вас есть решение лучше - пожалуйста, предложите. Во всяком случае это решение будет работать гораздо быстрее, чем если обрабатывать эти вещи не в запросе, а в коде.
37. logarifm 1117 28.10.09 11:13 Сейчас в теме
(36) Смотря для каких задач... Это хорошее решение и правильно что выложили его здесь... Просто не для всех оно подходит. Например мне необходимо было делать выборку по заказам покупателей и на момент заказа смотреть стоимость партии в регистре накопления "ПартииТоваров", вот этот вариант уже не подходит... Постоянный перерасчет регистра на всю номенклатуру...

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

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

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

И выкладываю этот материал как примечание чтобы взять во внимание. Спсасибо за понимание, а автору плюс за труды!
41. Ivon 673 29.10.09 10:21 Сейчас в теме
(40) Честно говоря, я стараюсь не использовать внутренние механизмы типа "Срез". Механизм "Обороты" так же в последнее время в основном не вызывается, а вместо него пишется вложенный запрос. Как показала практика, самописные выборки гораздо гибче встроенных механизмов. С "Остатками" мне почти не приходится работать, но, думаю, если придется, можно и это реализовать.
42. kolpak_mp3 21 20.11.09 08:17 Сейчас в теме
Поражаюсь. Одна критика. Я вот вчера только узнал про вложенные запросы. Для начинающих полезная статья. Автору +
Yuri_T; hren; +2 Ответить
47. A_kryl 161 09.02.11 12:20 Сейчас в теме
Для начала нам необходимо получить всех руководителей, период записи которых меньше или равен дате договора. Потом все поля, кроме периода сделать группировочными, а период взять максимальный.

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

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

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

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

УПОРЯДОЧИТЬ ПО
ДатаПериод
51. nzrulez 29.04.21 10:18 Сейчас в теме
Придумал вариант. Не нужно никаких временных таблиц. Достаточно одного условия с вложенным запросом в условии левого соединения с регистром. Оно легко интегрируется в любой запрос.

Для данного случая будет так:

...
ИЗ
        Документ.Договор КАК Договор
            ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.Руководители КАК Руководители
            ПО Договор.Сотрудник = Руководители.Сотрудник

			И (Руководители.Период В
				(ВЫБРАТЬ ПЕРВЫЕ 1
					Руководители2.Период КАК Период
				ИЗ
					РегистрСведений.Руководители КАК Руководители2
				ГДЕ
					Руководители2.Период <= Договор.Дата
					И Руководители2.Сотрудник = Договор.Сотрудник
				УПОРЯДОЧИТЬ ПО
					Период УБЫВ))
...
Показать


Вложенное условие вернёт список с 1 записью максимально приближенной к дате договора.
GetNight; +1 Ответить
52. Ivon 673 29.04.21 15:14 Сейчас в теме
(51) Если результаты выборок будут большими, то для временных таблиц можно будет построить индексы, что существенно повысит производительность.
53. GetNight 46 26.11.21 07:24 Сейчас в теме
(51) пришёл когда-то к такому-же... очень лаконично получается и на самом деле универсальный с точки зрения внедрения в любое место запроса

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

ЛЕВОЕ СОЕДИНЕНИЕ
	РегистрСведений.ЦеныНоменклатуры КАК ЦеныСрез
     ПО ЦеныСрез.Номенклатура					  = ДокДвижения.Номенклатура
      И ЦеныСрез.ХарактеристикаНоменклатуры		= ДокДвижения.ХарактеристикаНоменклатуры
      И ЦеныСрез.ТипЦен							= ДокИнвентаризация.Склад.ТипЦенРозничнойТорговли
      И ЦеныСрез.Период В (ВЫБРАТЬ ПЕРВЫЕ 1 ЦеныПоследние.Период
      					   ИЗ РегистрСведений.ЦеныНоменклатуры КАК ЦеныПоследние
      					   ГДЕ ЦеныПоследние.Период					   <= ДокИнвентаризация.Дата
      					     И ЦеныПоследние.Номенклатура				  = ДокДвижения.Номенклатура
      						 И ЦеныПоследние.ХарактеристикаНоменклатуры	= ДокДвижения.ХарактеристикаНоменклатуры
      						 И ЦеныПоследние.ТипЦен						= ДокИнвентаризация.Склад.ТипЦенРозничнойТорговли
      					   УПОРЯДОЧИТЬ ПО ЦеныПоследние.Период УБЫВ)
Показать
54. Ivon 673 26.11.21 11:28 Сейчас в теме
(53) Вложенные таблицы начинают дико тормозить, когда надо работать с очень большим количеством строк в результате. Временные таблицы с индексами в данном случае гораздо производительнее. Кроме того, если вам надо работать с одним и тем же результатом выборки более одного раза, то вложенные таблицы придется вызывать нужное количество раз в каждом соединении, а значит это хранение нескольких копий результата по сути одной и той же выборки, соответственно одна и та же вложенная выборка так же должна быть вызвана нужное количество раз. Временные таблицы можно вызывать произвольное количество раз в запросе. Например:
Выбрать Контрагенты.Ссылка КАК Ссылка,
Контрагенты.ФизЮрЛицо КАК ФизЮр
ПОМЕСТИТЬ КонтрНерез
ИЗ Справочники.Контрагенты КАК Контрагенты
ГДЕ
Контрагенты.Нерезидент = Истина
;
Выбрать КонтрНерез.Ссылка КАК Ссылка
ПОМЕСТИТЬ НерезФиз
ИЗ КонтрНерез КАК КонтрНерез
ГДЕ
КонтрНерез.ФизЮр = ЗНАЧЕНИЕ(Перечисление.ЮрФизЛицо.ФизЛицо)
;
Выбрать КонтрНерез.Ссылка КАК Ссылка
ПОМЕСТИТЬ НерезЮр
ИЗ КонтрНерез КАК КонтрНерез
ГДЕ
КонтрНерез.ФизЮр = ЗНАЧЕНИЕ(Перечисление.ЮрФизЛицо.ЮрЛицо)
;
///////
///// Дальнейшая работа
///////
Показать

А если сюда еще и добавить создание индексов, то будет еще и быстрее работать, причем в некоторых случаях в десятки раз. Например, у меня один запрос на 1500+ строк отрабатывал порядка 4 минут, а после добавления индексов время сократилось до 15 секунд.
Кроме того, результат выборки во временные таблицу можно использовать в разных запросах. Достаточно в свойствах запроса указать менеджер временных таблиц.
МВТ = Новый МенеджерВременныхТаблиц();
Запрос1 = Новый Запрос("Выбрать Контрагенты.Ссылка КАК Ссылка,
|Контрагенты.ФизЮрЛицо КАК ФизЮр
|
|ПОМЕСТИТЬ КонтрНерез
|ИЗ Справочники.Контрагенты КАК Контрагенты
|
|ГДЕ
|Контрагенты.Нерезидент = Истина
|
|ИНДЕКСИРОВАТЬ ПО
|Ссылка,
|ФизЮр");

Запрос1.МенеджерВременныхТаблиц = МВТ;
Запрос1.Выполнить();

Запрос2 = Новый Запрос("Выбрать КонтрНерез.Ссылка КАК Ссылка
|ПОМЕСТИТЬ НерезФиз
|ИЗ КонтрНерез КАК КонтрНерез
|ГДЕ
|КонтрНерез.ФизЮр = ЗНАЧЕНИЕ(Перечисление.ЮрФизЛицо.ФизЛицо)");

Запрос2.МенеджерВременныхТаблиц = МВТ;
Запрос2.Выполнить();

Запрос3 = Новый Запрос("Выбрать КонтрНерез.Ссылка КАК Ссылка
|ПОМЕСТИТЬ НерезЮр
|ИЗ КонтрНерез КАК КонтрНерез
|ГДЕ
|КонтрНерез.ФизЮр = ЗНАЧЕНИЕ(Перечисление.ЮрФизЛицо.ЮрЛицо)");

Запрос3.МенеджерВременныхТаблиц = МВТ;
Запрос3.Выполнить();

ЗапросНерезФиз = Новый Запрос("Выбрать НерезФиз.Ссылка КАК Ссылка
|ИЗ НерезФиз КАК НерезФиз");

ЗапросНерезФиз.МенеджерВременныхТаблиц = МВТ;
РезультатФиз = ЗапросНерезФиз.Выполнить().Выбрать();

ЗапросНерезЮр = Новый Запрос("Выбрать НерезЮр.Ссылка КАК Ссылка
|ИЗ НерезЮр КАК НерезЮр");

ЗапросНерезЮр.МенеджерВременныхТаблиц = МВТ;
РезультатЮр = ЗапросНерезЮр.Выполнить().Выбрать();
Показать
55. GetNight 46 26.11.21 13:21 Сейчас в теме
(54) не могли бы дать свою интерпретацию приведённого мной запроса?
56. Ivon 673 26.11.21 16:51 Сейчас в теме
(55) У вас не полностью запрос приведен. Дайте полный текст, я переделаю под свой вариант.
57. GetNight 46 26.11.21 17:20 Сейчас в теме
(56) Это один из наборов данных в СКД (УПП, дописанная под себя)
текст запроса
58. Ivon 673 28.11.21 12:24 Сейчас в теме
(57) Примерно так:
Текст запроса
61. GetNight 46 29.12.21 08:38 Сейчас в теме
(58)
Примерно так:

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

{ГДЕ ДокИнвентаризация.Дата МЕЖДУ &НачалоПериода И &КонецПериода, ДокИнвентаризация.Склад = &Склад}


типа

{ГДЕ ИнвентаризацияТоваровНаСкладе.Дата МЕЖДУ &НачалоПериода И &КонецПериода, ИнвентаризацияТоваровНаСкладе.Склад = &Склад}


в обеих частях объединения или как?..
59. Tatitutu 3855 29.11.21 15:03 Сейчас в теме
Как так то 70 уже было или будет ?
Прикрепленные файлы:
GetNight; +1 Ответить
60. GetNight 46 30.11.21 15:59 Сейчас в теме
(59) это основатель направления)
Оставьте свое сообщение