CRM Руководитель - Форум

Добрый день!

Нужны консолидированные данные по типу сводных таблиц - т.е. чтобы группировать строки (записывать в одну с суммированием, например) - из нескольких "одноименных" и потом полученные данные использовать далее.

Для чего нужно:

Например, формирование сводной ведомости з/п.

Если есть сущность Виды работ, где собственно имеются отдельные записи за каждый день, там, естественно числовые поля - Суммы.

Есть отдельная сущность Ведомости, где можно создать "собирающую" запись за период и подключить через связанные записи туда записи из Видов работ, которые подходят по периоду (по полю Дата).

НО так подключаются все строки записей. А там (в сущности Виды работ), например, есть поле выпадающий список, который выводит "тип работы" - те. некое постоянное значение из глобального списка.

Обобщенная схема такая:

Ведомость №1 за период 01.08.21 - 07.08.21

- Механообработка от 01.08.21 / 3 ч / 100 руб
- Механообработка от 01.08.21 / 2 ч / 80 руб
- Механообработка от 02.08.21 / 3 ч / 100 руб
- Покраска от 03.08.21 / 4 ч / 200 руб
- Покраска от 04.08.21 / 5 ч / 250 руб
- Покраска от 05.08.21 / 2 ч / 100 руб

Итого по ведомости (100+80+100+200+250+100) / 830 руб.



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

Ведомость №1 за период 01.08.21 - 07.08.21

- Механообработка / 8 ч / 280 руб
- Покраска / 1 ч / 550 руб

Итого по ведомости/ 830 руб.

Т.е. чтобы список отдельных записей "преобразовывался" в некий сводный список записей в специальной "сводной" сущности. А определяющим (группирующим) элементом выступали, например, "опциональные" поля (выпадающие списки, радио, поле Сущность) - т.е. чтобы можно было "объединить" по признаку.

Ну и данная информация, естественно, записывалась в БД, чтобы можно было полученные данные дальше использовать в аналитике. При этом, обновление можно сделать не динамическим, а, например. через автоматизацию (если так будет проще), ну или как выйдет.

Надеюсь, идею донес понятно, думаю, такие сводные сущности модернизируют работу с аналитикой и позволят работать с уже посчитанными "промежуточными" данными, уменьшат объемы выходных данных (записей-то меньше станет). Может даже в какой-то мере заменят стандартные сводные таблицы, с которыми ничего сделать нельзя, кроме использования в отчетах.

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

ну если очень надо, то похожее делал так:
как и описано все данные связываем через связанные записи или поле сущность
далее делаем отдельное поле SQL формула
и в нее тексом формируем и группируем данные как душе удобно через group_concat и concat и на выходе получем большую ячейку в которой данные вида как хочешь.
Минус - данные в ячейке представлены как одна большая строка, в последующем обращении к ней надо делать преобразование ее в массив! Да Геморно, но в итоге получаем что есть.
По хорошему было бы класно, как я и говорил ранее, просто сделать отчет с возможностью обрабатывать данные из нескольких сущностей, а так же возможность оперировать данными из внутри отчета (обращатся к данным отчета внутри отчета: те если отчет считает сумму для значения, то возможность далее оперировать этой суммой в отчете!)

Ну вот хотелось бы именно "официальной" надстройкой, а не "через костыли" ))

Как идея/мысль - в экселе (новые версии) есть такой инструмент как Power Query. Там есть опция Группирование данных по признакам

http://joxi.ru/p27jv77HnnwjWm

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

- Механообработка / 8 ч / 280 руб (сводная/группирующая/родительская запись по полю, где значение "Механообработка") А ниже - "дочерние/связанные" записи, из которых сформирована эта "сводная" запись.

- - Механообработка от 01.08.21 / 3 ч / 100 руб
- - Механообработка от 01.08.21 / 2 ч / 80 руб
- - Механообработка от 02.08.21 / 3 ч / 100 руб

- Покраска / 1 ч / 550 руб (-//- "Покраска)

- - Покраска от 03.08.21 / 4 ч / 200 руб
- - Покраска от 04.08.21 / 5 ч / 250 руб
- - Покраска от 05.08.21 / 2 ч / 100 руб

Может тут реализовать через поле Связанные записи - при этом на основе полей-признаков будет формироваться "родительская" запись и к ней прикрепляться соответствующие записи для подсчета/группирования.

Может как-то сделать через автоматизацию - на примере "связать записи по MySQL запросу". Только тут результатом должна быть автоматически сформированная "сводная" запись, а уже к ней подключены - связанные.

ну можно и так) но надо просто понять как автоматика должна вбирать в себя данные - все равно что то вносить руками придется!!
о идея можно в каждой сущности с отчетом сделать допполе отчет(ссылка на сущность) которая будет являтся сущностью отчета - вот и будет собственно связь))

я обычно в обратную сторону делаю, т. е. выбираю основной сущностью ту в которой больше всего данных изначально и уже в ней делаю допполя которые вбирают в себя через sql запросы разные данные и уже отчет строю на основе этой сущности.
минус решени - много лишних полей, sql запросы иногда доходяд до 2х страниц а4))) но это работает (и имхо это единственный вариант работы с отчетами((()

и потом полученные данные использовать далее

Что бы потом данные использовать далее, нужно создавать отдельную сущность и там создавать свои запросы. Данные в запросам можно группировать как угодно.

Например, создаем запись Механообработка от 01.08.21. Дату "01.08.21" вводим поле ввода и затем в sql запросе используем для расчетов. В результате получаем число, которое можно далее использовать в формулах.

в других системах конфигураторах таких костылей делать не надо) например dataexpress для вдохновения можно использовать))

Что бы потом данные использовать далее, нужно создавать отдельную сущность и там создавать свои запросы. Данные в запросам можно группировать как угодно.

Ну я ж вроде так и описал во 2-м посте: создается специальная "промежуточная/сводная/родительская" сущность, в которую и группируются по признакам (для начала хотя бы по одному признаку, т.к. многоуровневая группировка по нескольким полям скорее всего потребует несколько вложенных промежуточных сущностей, хотя могу ошибаться) - записи, может через поле "связанные записи", чтобы не дублировать информацию, а просто связать в группу. Ну или с копированием/дублированием, если так будет нужно, первичных записей, чтобы их группировать потом.

Или я не так понял?

В данном случае сущность выступает в качестве отчета. Каждая запись это отдельный отчет за определенную дату. Значения из записи можно использовать в дальнейших формулах, что и требовалось.
В чем сложность?

support писал(а): 26 авг 2021, 10:01 В данном случае сущность выступает в качестве отчета. Каждая запись это отдельный отчет за определенную дату. Значения из записи можно использовать в дальнейших формулах, что и требовалось.
В чем сложность?

Нужно как-то автоматически сгруппировать по полю, где стоит "тип работы" - Механообработка и Покраска. В данный текущий момент (в примере видно), что имеется 2 группирующих значения - это собственно Механообработка и Покраска. Но это я вижу "глазами". А нужно, чтобы система сама определила/вычислила сколько получается группирующих ("сводных") значений из "выборки" первичных записей - в результате создала столько записей, сколько было вычислено этих группирующих значений.

Т.е. завтра-послезавтра, например, среди записей появилась еще информация (работа) "Шлифовка" (помимо тех 2-х) в нескольких записях. То в группе сводной сущности должно быть уже 3 сводных записи:

Механообработка
Покраска
Шлифовка

Т.е. дата тут не обязательный параметр, это просто как ограничение диапазона выборки я указал. Группирующее поле-признак - в моем примере - это именно поле "Тип работы". И еще раз повторюсь: не я сам вручную должен увидев записи, создать именно 3 группирующие/сводные, а система: "проанализировав" в данной выборке записи - согласно настроек группирующего поля - автоматически сформировать/добавить именно 3 (в данный момент) сводные записи. Надеюсь понятно пояснил)) Так можно на данный момент сделать, без доработок?