Вычисление ресурсов на верхних уровнях группировки
Неоднократно сталкивался с ситуацией, что некоторые поля отчета имеют смысл только на некотором уровне группировки, а на уровне детальных записей - нет.
Я нашел два решения для такой ситуации. Оба используют функцию СКД ВычислитьВыражениеСГруппировкойМассив.
В первом варианте данные получаю с помощью функцию общего модуля (если требуются какие-то сложные расчеты), но мне не нравится производительность этого варианта. Эту функцию отчет дергает очень много раз, а в функции наверняка будет запрос.
Во втором варианте данные получаю запросом набора данных, а потом агрегатной функцией максимум или минимум вычисляю в функции СКД ВычислитьВыражениеСГруппировкойМассив требуемое значение, предполагая, что для всех строк группировки значения будут совпадать, т.к в запросе использовалось левое соединение с условием по полю этой группировки. На уровне детальных записей отключил автополе и вручную добавил только нужные поля, чтобы замаскировать не имеющие смысла на этом уровне данные.
Я подготовил базу с рафинированным примером для того, чтобы можно было поэкспериментировать на ней и найти решение лучше. Ищу варианты решения без изменения архитектуры самой базы, но предложения по архитектуре интересны для общего развития.
Отчет должен выглядеть следующим образом:
Я нашел два решения для такой ситуации. Оба используют функцию СКД ВычислитьВыражениеСГруппировкойМассив.
В первом варианте данные получаю с помощью функцию общего модуля (если требуются какие-то сложные расчеты), но мне не нравится производительность этого варианта. Эту функцию отчет дергает очень много раз, а в функции наверняка будет запрос.
Во втором варианте данные получаю запросом набора данных, а потом агрегатной функцией максимум или минимум вычисляю в функции СКД ВычислитьВыражениеСГруппировкойМассив требуемое значение, предполагая, что для всех строк группировки значения будут совпадать, т.к в запросе использовалось левое соединение с условием по полю этой группировки. На уровне детальных записей отключил автополе и вручную добавил только нужные поля, чтобы замаскировать не имеющие смысла на этом уровне данные.
Я подготовил базу с рафинированным примером для того, чтобы можно было поэкспериментировать на ней и найти решение лучше. Ищу варианты решения без изменения архитектуры самой базы, но предложения по архитектуре интересны для общего развития.
Отчет должен выглядеть следующим образом:
Прикрепленные файлы:
База с режимом совместимости 8.3.10.dt
По теме из базы знаний
Найденные решения
(12) Ан, нет. Действительно, скопировал отчет, а исправлять стал Ваш. И при этом допустил ошибку. Извините еще раз за путаницу.
Вновь прикладываю пример. Смотреть нужно "агрегатную функцию".
Вновь прикладываю пример. Смотреть нужно "агрегатную функцию".
Прикрепленные файлы:
ВопросИнфостарт.dt
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(6)Эту статью видел, и как видно из тестовой базы так и сделал. Ищу альтернативные варианты. Мало ли, вдруг можно воспользоваться разными наборами данных или еще чем.
Мне не нравится вариант с использованием функции общего модуля. Если там сложные расчеты, и много строк в отчете, то она вызывается очень много раз и отчет сильно тормозит. Но иногда без этого варианта не обойтись.
В этом случае подошел бы следующий вариант оптимизации - мы заранее рассчитываем данные по всем строкам, а потом соединяем их с результатом на требуемом уровне группировки. Но как реализовать это на СКД я не знаю и вряд ли это возможно. Предлагаю устроить мозговой штурм и накидать самых разных и даже диких вариантов решения.
Мне не нравится вариант с использованием функции общего модуля. Если там сложные расчеты, и много строк в отчете, то она вызывается очень много раз и отчет сильно тормозит. Но иногда без этого варианта не обойтись.
В этом случае подошел бы следующий вариант оптимизации - мы заранее рассчитываем данные по всем строкам, а потом соединяем их с результатом на требуемом уровне группировки. Но как реализовать это на СКД я не знаю и вряд ли это возможно. Предлагаю устроить мозговой штурм и накидать самых разных и даже диких вариантов решения.
(1) На мой взгляд Вы, как и многие другие специалисты, решают проблему не с того края. Начинать нужно было с наборов данных, тогда и выражения ресурсов будут заметно проще.
Смотрите. Основная проблема это то, что СКД считает сумму кредита в разрезе контрагента и документа, тогда как в действительности у Вас она относится только к контрагенту. В подобных случаях следует соединять таблицы не левым соединением в одном запросе, а создавать 2 набора данных и связывать их с помощью СКД. Тогда и показатели таких наборов данных СКД будет рассчитывать по разному: где-то в разрезе контрагента и документа, а где-то - только в разрезе контрагента.
Рекомендую хорошо разобраться в вопросе, когда применяется соединение в запросе, а когда - соединение в СКД, т.к. на первый взгляд похожие механизмы на самом деле решают разные задачи.
Во вложении пример.
Смотрите. Основная проблема это то, что СКД считает сумму кредита в разрезе контрагента и документа, тогда как в действительности у Вас она относится только к контрагенту. В подобных случаях следует соединять таблицы не левым соединением в одном запросе, а создавать 2 набора данных и связывать их с помощью СКД. Тогда и показатели таких наборов данных СКД будет рассчитывать по разному: где-то в разрезе контрагента и документа, а где-то - только в разрезе контрагента.
Рекомендую хорошо разобраться в вопросе, когда применяется соединение в запросе, а когда - соединение в СКД, т.к. на первый взгляд похожие механизмы на самом деле решают разные задачи.
Во вложении пример.
Прикрепленные файлы:
ВопросИнфостарт.dt
(12) Ан, нет. Действительно, скопировал отчет, а исправлять стал Ваш. И при этом допустил ошибку. Извините еще раз за путаницу.
Вновь прикладываю пример. Смотреть нужно "агрегатную функцию".
Вновь прикладываю пример. Смотреть нужно "агрегатную функцию".
Прикрепленные файлы:
ВопросИнфостарт.dt
(14)Да, действительно то что нужно. Но не совсем понимаю как это решение работает. Точнее не понимаю, как работает соединение наборов данных. Как в параметр МассивКонтрагентов попадают нужные нам значения для корректной связи? Что лучше почитать, чтобы разобраться в связи наборов данных?
(15) Параметр заполняет сама СКД, его трогать не нужно. Вероятнее всего сначала исполняется запрос первого набора данных, готовится массив значений (контрагентов), присваивается параметру, и с этим параметром выполняется запрос второго набора. Т.о. мы оптимизируем работу СКД, т.к. без использования параметра выбирались бы все данные регистра кредитов, а нам могут потребоваться записи лишь по некоторым контрагентам. Аналогичный кстати финт можно провернуть и для поля "Год", создав для него свой параметр.
Как видите, агрегатные функции очень просты: используется лишь "Сумма". И действительно СКД просто суммирует значения поля годовых кредитов, но берет при этом их из второго набора, где нет документов, только контрагент. Оттого и суммы во всех группировках корректные. В т.ч. можно не отключать вывод полей кредита и процента на уровне детальных записей - там тоже будут корректные значения.
К сожалению, с ходу не смогу порекомендовать хорошую литературу для освоения связей в СКД. В моем случае это была книга Хрусталевой "Разработка сложных отчетов", кое-какие 1С-овские веббинары и опыт проб и ошибок. Надеюсь кто-то из сообщества Инфостарт Вам порекомендует что-то более конкретное.
Как видите, агрегатные функции очень просты: используется лишь "Сумма". И действительно СКД просто суммирует значения поля годовых кредитов, но берет при этом их из второго набора, где нет документов, только контрагент. Оттого и суммы во всех группировках корректные. В т.ч. можно не отключать вывод полей кредита и процента на уровне детальных записей - там тоже будут корректные значения.
К сожалению, с ходу не смогу порекомендовать хорошую литературу для освоения связей в СКД. В моем случае это была книга Хрусталевой "Разработка сложных отчетов", кое-какие 1С-овские веббинары и опыт проб и ошибок. Надеюсь кто-то из сообщества Инфостарт Вам порекомендует что-то более конкретное.
Если формула вычисления одна и та же для всех уровней группировки, то тут вариантов вижу несколько:
1. Убрать автополе в полях на нужном уровне группировки, вытащить все поля, кроме ненужных ресурсов.
2. Использовать макет для группировки.
3. Втупую - условное оформление (это вряд ли производительно будет).
1. Убрать автополе в полях на нужном уровне группировки, вытащить все поля, кроме ненужных ресурсов.
2. Использовать макет для группировки.
3. Втупую - условное оформление (это вряд ли производительно будет).
Даже 8.3.10 поставил. Все равно это не критично для вопроса.
Прикрепленные файлы:
База с режимом совместимости 8.3.10.dt
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот