Within QlikView is an option to show sub-totals within a pivot on top or on bottom - which is also within the ajax client available. Therefore, you are right that it should be technically rather easy possible to implement this feature. I assume they skipped this property intentionally to keep the object and the available features simpler as within QlikView and I think within the most scenarios the on top version was the preferred one. Does anyone have made a feature-request for it?
By a straight-table I'm not so sure if sub-totals are technically possible because the virtual data-table on which the visual rendering is applied is AFAIK the same as by a bar- or line-chart ...
To answer a question with a question - why do you need the subtotals to be at the bottom? If you can provide a good reason (and ideally add it to the existing Idea threads I linked in a separate post), you'd have a better chance of perhaps getting Qlik to pick up the feature request. That said, I wouldn't hold my breath as Qlik doesn't seem inclined to add this option (personally, I don't miss it in the slightest, I've yet to encounter a use case for having them at the bottom, but of course your use cases may be different).
thanks for the links to the existing 'issues' / suggestion on this, going to add my support to them.
Re Why,
simply to have the option. Not all data sets work well with totals at the top. e.g. I want to have a monthly sales flow by day and week, subtotals at the top does not allow sequential viewing of the Month to date trend.
if you have a lot of users coming from Excel based reporting, and they are used to having totals / subtotals at the bottom, then the instant reaction is 'if we have a modern and supposedly market leading product why is this not an option'.
There absolutely will be different views to this but ultimately, its the user that has the requirement so having the option solves so many issues.
There is no neat way of doing this in Qliksense straight out the box. Which there ought to be. There's a "P&L Pivot" but that only allows for 1 level of hierarchy on the left (aka I can't click on Tax to find out what different types of taxes are being paid). There's also no subtotal feature, so it's kinda useless.
There's the standard Pivot Table. But I have gripes with that; for a start, there's no way to hide the search bars at the top left which take up real estate and are more of a distraction than a help. There's no way to do subtotals / partial sums.
Finally there's the Pivot Table in the Qlik Visualization Bundle. Probably the best, but still no Subtotals.
Why is it so hard to believe customers when they say this was useful in Qlikview and would be useful in Qliksense?
Don't ask me - I'd say "I just work here" but I don't even work here. That said, this thread is three years old and Qlik's actually working on replacing the existing Pivot at this point.
Admittedly, it's a little clunkier, but it's also more robust, and a classic P&L with requirements that go beyond the existing P&L object is somewhat niche. I'd love to see a more robust native solution to P&Ls myself, but I haven't seen any indication that this is something Qlik wants to work on, and subtotals-at-bottom wouldn't really help given that you still need to make room for the non-standard aggregation lines, such as GP%, OP%, etc.
IMO is the challenge not the pivot-chart as object else the needed dimensionalities within the data-model. If some values of the sub-category are revenue and some EBITDA and similar they just need to assigned to an appropriate main-category - and then all sub-totals are available.
Quite probably you will need more as two layer - to fetch also cost centers and accounts - and all kinds of other sub-groups. Also overlapping assignments are possible with logic like: The As-Of Table - Qlik Community - 1466130.
If you don't have a valid hierarchically grouping data-source you should ask for it and building the missing yourself in own tables. The grouping/matching work be done somewhere and the most hardest way is to attempt it within the UI - therefore include it within the data-model.
