0. ids79 4465 08.10.19 17:30 Сейчас в теме

Три способа создания одного отчета на СКД

СКД имеет столько возможностей, что часто приходится выбирать, каким образом строить отчет. Причем выбор не всегда очевидный. В статье рассмотрен пример построения отчета «Отрицательные остатки по товарам на момент проведения расходных документов» тремя разными способами. Приведены «За» и «Против» каждого варианта решения задачи.

Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо
1. VmvLer 08.10.19 17:57 Сейчас в теме
как возможности вариантов реализации - добротная инструкция

детали, в которых кроется сами знаете кто
1. запросы во всех трех вариантах похожи по логике, но различны по содержанию.
посему статистика сравнения по этой причине имеет статус НЕ факта, а скорее статус декорации "ну вот так получилось"
2. Расчет остатков методом нарастающего итога в запросе хорош в примерах и методичках всяких там курсов, но на биг-дате - вешалка.
3. Важно насколько "шусрый" сервер СУБД который выполняет запросы и насколько шустры сервера приложений, которые
принимают на обработку в СКД, то что выдал первый. Иногда первый отработал шутсряком, а вторые не могут "скушать".
Я хочу сказать, что размеры БД конечно имеют значение и результаты на биг-дате могут быть совсем иные.
...
n. при оптимизации запросов в каждом варианте результаты также могут стать иными.

В общем, как инструкция хорошо, как догма не-не-не - в нашем мире все относительно, как говорил классик.
narutouzumaki_13; ids79; acanta; +3 Ответить
2. wowik 621 08.10.19 17:59 Сейчас в теме
3. acanta 79 08.10.19 21:07 Сейчас в теме
Первый способ не всегда возможен. Например сумма более чем 20 полей превышает допустимую размерность длины формулы или колонки.
4. zqzq 17 09.10.19 08:45 Сейчас в теме
Способ второй – использование двух наборов данных -- это запрос в цикле, что замер производительности и показывает. Выполняется запрос основного набора, далее для каждой строки результата выполняется запрос подчиненного набора данных. На продуктиве такое лучше не делать. И обычно можно второй способ свести к первому.

Также автор лукавит в таблице сравнения, можно например и так написать:

Внутренние функции СКД
Необходимо время на написание и отладку схемы компоновки. Скорость создания отчета зависит от умения строить сложные отчеты СКД.

Расчет в запросе
Если есть навык написания подобных запросов, отчет строиться очень быстро.
5. Dach 285 09.10.19 10:01 Сейчас в теме
По сути, автор предлагает расчет нарастающего итога вынести на клиент и использовать для это ВычислитьВыражениеСГруппировкойМассив.
Это действительно будет работать. Но, во-первых, раз это клиент - скорость работы отчета будет зависеть и от параметров ПК клиента (ОЗУ, ЦП). А что, если это будет веб-клиент и запуск базы на планшете, к примеру?

Кроме того,

"После установки отбора по группировке «Склад» перестают корректно рассчитываться итоги по нижестоящим группировкам, и в отчет попадают лишние записи. Это связано со спецификой работы встроенных функций. Я склонен считать это ошибкой, возможно, это будет исправлено в будущих релизах."

- не согласен.

Это не ошибка. СКД делает ровно то, о чем Вы ее просите. Вы ей сказали "считай вот это поле вот так, с учетом вот таких вот отборов". Как работают все эти функции СКД? Система получает результат запроса в виде плоской таблицы, затем начинает группировать строки так, как ей сказали, при этом рассчитывая вычисляемые поля тоже так, как ей сказали и накладывая те отборы (часть отборов может транслироваться в сам запрос при этом), которые ей дали. Так что никакой ошибки тут нет и надеяться на исправления в следующих релизах незачем.
black_elephant; narutouzumaki_13; zqzq; ids79; +4 Ответить
10. ids79 4465 09.10.19 18:01 Сейчас в теме
(5)
По сути, автор предлагает расчет нарастающего итога вынести на клиент и использовать для это ВычислитьВыражениеСГруппировкойМассив

Почему Вы считаете, что расчет нарастающего итога будет выполнятся на клиенте, не понимаю...

(5)
Это не ошибка. СКД делает ровно то, о чем Вы ее просите.

Может и не ошибка, а "нюанс" - грань тонкая.
6. dhurricane 09.10.19 12:11 Сейчас в теме
Есть вопросы по второму способу.

Во-первых, Вы обращаете внимание читателя на флажки "Список параметров", однако в самом запросе используется условие на равенство аналитик, а не оператор "В". Мне не известно, СКД сама заменит "=" на "В", или же условие равенства так и останется?

Во-вторых, не могу сообразить, зачем связь со справочником ключей аналитики и условие сравнения с количеством прямо в запросе? Почему бы не получить остатки те, которые есть, а уже потом используя вычисляемые поля и отборы отфильтровать записи, где количество больше остатка?

Развейте, пожалуйста, мои сомнения, но кажется, что запрос второго набора данных составлен некорректно. Использование флажка "Список параметров" должно было привести к оптимизации получения данных, выбирая их разом для порции записей из основного набора данных. Но из-за условий в запросе подчиненного набора этого могло не произойти, и сам запрос в итоге выполнялся для каждой строки основного набора. Отсюда и следует столь длительное формирование отчета.
ids79; deaddy64; GROOVY; +3 Ответить
11. ids79 4465 10.10.19 10:50 Сейчас в теме
(6)
Мне не известно, СКД сама заменит "=" на "В", или же условие равенства так и останется?

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

А зачем выбирать лишние записи? Номенклатуры может быть очень много и для каждого документа будут выбираются остатки по всем товарам...
13. dhurricane 10.10.19 11:07 Сейчас в теме
(11)
А зачем выбирать лишние записи
Как раз для того, чтобы выбирать данные порциями, а не для каждого значения параметра "Количество".

Тут еще остается, конечно, "темный" вопрос, связанный с параметром "Период". Помнится, на курсах по СКД Белоусов рассказывал, что флажок "Использовать список" также оптимизирует запрос и для параметра "Период", но каким именно образом не расшифровал. Моя догадка такая: СКД собирает из основной таблицы все значения периода и выполняет столько запросов подчиненного набора данных, сколько различных значений периода удалось собрать. Если это так, то в представленной Вами задачи такая оптимизация будет бесполезна - повторяющихся периодов практически нет, ведь мы выбираем в основном наборе все движения за указанный временной интервал.
16. ids79 4465 10.10.19 12:59 Сейчас в теме
(13)
Как раз для того, чтобы выбирать данные порциями, а не для каждого значения параметра "Количество".

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

(13)
флажок "Использовать список" также оптимизирует запрос и для параметра "Период"

Тоже слышал о такой оптимизации. Но как она точно работает нигде не нашел информации. Возможно, как Вы написали, возможно нет - загадка компании 1С.
17. dhurricane 10.10.19 14:36 Сейчас в теме
(16)
Если список, тогда отбор по количеству нужно переносить на уровень настроек компоновки.
Ну так о том я и толкую в первом своем сообщении. :)
7. VIA_1C 52 09.10.19 13:08 Сейчас в теме
Есть вопрос по второму подзапросу в первом способе:

ЛЕВОЕ СОЕДИНЕНИЕ ВТ_Документы КАК ДокументыДвижения


откуда вязалась ВТ_Документы ?
9. ids79 4465 09.10.19 17:40 Сейчас в теме
8. starik-2005 1981 09.10.19 15:28 Сейчас в теме
Четвертый способ - использование вложенных схем, пользовательских полей, ....
12. ids79 4465 10.10.19 10:54 Сейчас в теме
(8)Примерчик не напишете?
18. starik-2005 1981 11.10.19 13:12 Сейчас в теме
(12) вложенные схемы? Ну вот есть у вас отчет, например, по разным группам доходов и расходов, собираемый из разных мест. Можно городить кучу объединений, а можно сделать несколько вложенных схем и их скомпоновать в один макет. Собсно, ничего сложного...
19. leosoft 143 14.10.19 09:17 Сейчас в теме
(18) Может статью набросаете? Интересно было бы посмотреть.
14. kosmo0 91 10.10.19 11:59 Сейчас в теме
Необходимость знания большого количества нюансов лично для меня отталкивает варианты использования всех возможностей СКД. Если браться за СКД раз в полгода, то лучше использовать более простой, но зато "железный" вариант (чтобы не пошел отчет в "пешее эротическое путешествие" при применении какого-нибудь отбора). Ну а если постоянно заниматься СКД и владеть всеми нюансами на кончиках пальцев - тогда да, раз-два - отчет готов и он оптимален.
15. ids79 4465 10.10.19 12:51 Сейчас в теме
20. 7OH 32 15.10.19 14:28 Сейчас в теме
А в 3-м способе менять группировки местами можно будет ?
21. ids79 4465 15.10.19 18:09 Сейчас в теме
(20)Нет, структура жесткая. Иначе отчет нужно будет переделывать.
22. premierex 176 16.10.19 12:55 Сейчас в теме
(0) А индексация временных таблиц в 1-м и 3-м варианте разве не уменьшит время выполнения запроса? Или СКД самостоятельно индексирует временные таблицы?
23. ids79 4465 16.10.19 13:54 Сейчас в теме
(22)На счет индексации временных таблиц вопрос очень не однозначный. С одной стороны есть ускорение, но с другой стороны нужно время на создание самого индекса. Нужно пробовать, и смотреть что получается.
Я не пробовал.
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Программист 1С
Санкт-Петербург
зарплата от 80 000 руб. до 130 000 руб.
Полный день

Автор новостных обзоров на тему 1С и бухучета
Санкт-Петербург
По совместительству

Программист/Cтарший программист 1С
Москва
зарплата от 100 000 руб. до 250 000 руб.
Полный день

Программист 1С
Калининград
зарплата от 60 000 руб. до 80 000 руб.
Полный день

Руководитель проектов 1С
Санкт-Петербург
Полный день