Thanks @tschumilas and @Rachel
I understand that these reports don’t meet your specific instance needs in a single report. The conscious design decision here was to create general reports that would be accessible and understandable by all instances to use to support their users.
I specifically wanted to avoid creating a bespoke FR report and a bespoke CA report and in turn create both the precedent and demand for bespoke reports for every instance going forward.
In line with the goals of the Reports Project the idea is that we can create different ways for users to access the data. The UI should solve the majority of cases, though often not perfectly. The API can be used to better solve and metabase for creating bespoke reports.
If you are both saying that these reports won’t be useful then perhaps we need to stop this work here.
Some options:
- Instead focus on building a reports tool that gives users much more flexibility. We can expect this to be a multiyear project.
- Update the Sales reports to better include tax information (note we have to choose between line items, tax and fees - this is a three dimensional matrix and we are mapping to 1 dimension)
- Build bespoke in-app reports for each instance that needs new reports
- Think about how to use the API to better meet specific instance needs with integrations. This could mean continuing down this path. It might mean better enabling bespoke reports to be accessed via the UI.
- Someone else has a go at bringing these requirements together to see if they find a better way to cut this up.
- We wait for there to be space in the design pipe and get a real designer on this work.