1. Dipod 14 13.05.19 17:32 Сейчас в теме

Вычисление ресурсов на верхних уровнях группировки

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

Я нашел два решения для такой ситуации. Оба используют функцию СКД ВычислитьВыражениеСГруппировкойМассив.

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

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

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

Отчет должен выглядеть следующим образом:

Прикрепленные файлы:
База с режимом совместимости 8.3.10.dt
Вознаграждение за ответ
Показать полностью
Найденные решения
14. dhurricane 14.05.19 10:50 Сейчас в теме +2 $m
(12) Ан, нет. Действительно, скопировал отчет, а исправлять стал Ваш. И при этом допустил ошибку. Извините еще раз за путаницу.

Вновь прикладываю пример. Смотреть нужно "агрегатную функцию".
Прикрепленные файлы:
ВопросИнфостарт.dt
Остальные ответы
Избранное Подписка Сортировка: Древо
6. user-z99999 18 14.05.19 09:27 Сейчас в теме
(1)
1С СКД: Суммирование значений на различных уровнях группировок
http://blagin.ru/1s-skd-summirovanie-znachenij-na-razlichnyx-urovnyax-gruppirovok/
8. Dipod 14 14.05.19 09:36 Сейчас в теме
(6)Эту статью видел, и как видно из тестовой базы так и сделал. Ищу альтернативные варианты. Мало ли, вдруг можно воспользоваться разными наборами данных или еще чем.

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

В этом случае подошел бы следующий вариант оптимизации - мы заранее рассчитываем данные по всем строкам, а потом соединяем их с результатом на требуемом уровне группировки. Но как реализовать это на СКД я не знаю и вряд ли это возможно. Предлагаю устроить мозговой штурм и накидать самых разных и даже диких вариантов решения.
9. dhurricane 14.05.19 09:48 Сейчас в теме +1 $m
(1) На мой взгляд Вы, как и многие другие специалисты, решают проблему не с того края. Начинать нужно было с наборов данных, тогда и выражения ресурсов будут заметно проще.

Смотрите. Основная проблема это то, что СКД считает сумму кредита в разрезе контрагента и документа, тогда как в действительности у Вас она относится только к контрагенту. В подобных случаях следует соединять таблицы не левым соединением в одном запросе, а создавать 2 набора данных и связывать их с помощью СКД. Тогда и показатели таких наборов данных СКД будет рассчитывать по разному: где-то в разрезе контрагента и документа, а где-то - только в разрезе контрагента.

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

Во вложении пример.
Прикрепленные файлы:
ВопросИнфостарт.dt
10. Dipod 14 14.05.19 10:19 Сейчас в теме
(9)Вот примерно такой вариант решения я искал. Только у вас этот отчет не выдал требуемый результат. Вы исправили наборы данных в отчете под названием "агрегатная функция", а проверяли, вероятно по отчету соединение.
11. dhurricane 14.05.19 10:20 Сейчас в теме
(10) Нет, я ничего не трогал в отчете "агрегатная функция". Я его скопировал, назвал "соединение" и доработал новый.

UPD. Отчет "соединение" и есть мой пример, который я хотел Вам показать.
12. Dipod 14 14.05.19 10:33 Сейчас в теме
(11)В отчете соединение я не увидел никаких изменений по сравнению с моим. А вот в отчете агрегатная функция есть изменения и он не выдает требуемый результат.
13. dhurricane 14.05.19 10:42 Сейчас в теме
(12) Ой. Я кажется вместо выгрузки решения повторно загрузил Вашу базу, извините. Секунду...
14. dhurricane 14.05.19 10:50 Сейчас в теме +2 $m
(12) Ан, нет. Действительно, скопировал отчет, а исправлять стал Ваш. И при этом допустил ошибку. Извините еще раз за путаницу.

Вновь прикладываю пример. Смотреть нужно "агрегатную функцию".
Прикрепленные файлы:
ВопросИнфостарт.dt
15. Dipod 14 14.05.19 11:13 Сейчас в теме
(14)Да, действительно то что нужно. Но не совсем понимаю как это решение работает. Точнее не понимаю, как работает соединение наборов данных. Как в параметр МассивКонтрагентов попадают нужные нам значения для корректной связи? Что лучше почитать, чтобы разобраться в связи наборов данных?
16. dhurricane 14.05.19 11:28 Сейчас в теме
(15) Параметр заполняет сама СКД, его трогать не нужно. Вероятнее всего сначала исполняется запрос первого набора данных, готовится массив значений (контрагентов), присваивается параметру, и с этим параметром выполняется запрос второго набора. Т.о. мы оптимизируем работу СКД, т.к. без использования параметра выбирались бы все данные регистра кредитов, а нам могут потребоваться записи лишь по некоторым контрагентам. Аналогичный кстати финт можно провернуть и для поля "Год", создав для него свой параметр.

Как видите, агрегатные функции очень просты: используется лишь "Сумма". И действительно СКД просто суммирует значения поля годовых кредитов, но берет при этом их из второго набора, где нет документов, только контрагент. Оттого и суммы во всех группировках корректные. В т.ч. можно не отключать вывод полей кредита и процента на уровне детальных записей - там тоже будут корректные значения.

К сожалению, с ходу не смогу порекомендовать хорошую литературу для освоения связей в СКД. В моем случае это была книга Хрусталевой "Разработка сложных отчетов", кое-какие 1С-овские веббинары и опыт проб и ошибок. Надеюсь кто-то из сообщества Инфостарт Вам порекомендует что-то более конкретное.
2. laperuz 33 14.05.19 05:42 Сейчас в теме
Если формула вычисления одна и та же для всех уровней группировки, то тут вариантов вижу несколько:
1. Убрать автополе в полях на нужном уровне группировки, вытащить все поля, кроме ненужных ресурсов.
2. Использовать макет для группировки.
3. Втупую - условное оформление (это вряд ли производительно будет).
3. ZergKRSK 126 14.05.19 05:48 Сейчас в теме
Нужно предупреждать что платформа нужна не ниже чем 8.3.14
alex-l19041; +1 Ответить
5. Dipod 14 14.05.19 09:26 Сейчас в теме
(3)Сейчас включу режим совместимости с 8.3.12 Этого хватит?
4. toypaul 64 14.05.19 08:22 Сейчас в теме
Хорошо когда есть база. Плохо когда для нее нужен такой релиз :)
Поэтому и ответов мало
7. Dipod 14 14.05.19 09:28 Сейчас в теме
Даже 8.3.10 поставил. Все равно это не критично для вопроса.
Прикрепленные файлы:
База с режимом совместимости 8.3.10.dt
17. Dipod 14 14.05.19 11:53 Сейчас в теме
Если у кого есть еще варианты решений, кроме найденного - пишите.
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Руководитель отдела внедрения 1С
Новосибирск
зарплата от 60 000 руб. до 160 000 руб.
Полный день

Ведущий программист 1С
Москва
зарплата от 120 000 руб. до 150 000 руб.
Полный день

Программист 1С
Самара
зарплата от 50 000 руб. до 100 000 руб.
По совместительству


Ведущий программист 1С
Сочи
зарплата от 82 500 руб. до 99 000 руб.
Полный день