Not sure if this will apply to your situation exactly, but here's an illustration of what can happen with the Avg(Aggr()) combination that can cause unexpected results (and how the impacts may come from the data model).
If you set up Avg(Aggr()) expressions against a single table or a table with perfect keys, the calculations should yield expected results. And sometimes initial testing is done against a single table or a table with a perfect key, and it seems everything is working right. Then perhaps only later, if the perfect key of that table somehow changes to an imperfect key, calculations may be impacted in ways that might not be expected.
Once the fields involved in the Avg(Aggr()) calculation are joined to other tables with a non-Perfect key, the introduction of an entry for <NULL> potentially joins the denominator value list. It also depends on whether the actual field in the calculation is the keyfield and whether selections are applied or not.
- Perfect key - <NULL> NOT introduced in denominator
- Imperfect key - no selections applied - <NULL> introduced in denominator
- Imperfect key - selections in filtering field applied (key or non-key)
- all selections have entry in calculation field - <NULL> NOT introduced in denominator
- any selection has a null value in calculation field - <NULL> introduced in denominator
I know these scenarios may seem complicated, but identifying them has helped me manage the Avg(Aggr()) combinations, and maybe this will help you.
Avg_and_aggr.qvw 190.5 K