Thanks for posting this issue, very interesting. I’m not sure how DHIS2 is giving you the annual figure that you’re getting - since you haven’t specified an aggregation, it’s quite possibly randomly supplied by the underlying Postgres database (if an order or aggregation isn’t specified, databases will return records in a random order, which can change every time additional values are inserted into the database table). But since all your data is stored in a single data element, regardless of whether or not it’s aggregated, your annual figure will always draw on both annual and quarterly data values. (In pivot tables, DHIS2 org units and periods work in a hierarchy - so analysis at district level will always draw on both a district and its child clinics etc, and analysis at annual level will always draw on both annual and quarterly/monthly figures.)
From a design perspective, I think an underlying factor is that you’re capturing two different data collections (quarterly data and externally-supplied annual data) into a single data element. This is a subjective design call, so it would be good to hear other experts’ perspectives on this too, but if you’re capturing two different versions of the same data, it sounds to me like you’d be much better served by having two versions of each of these data elements. You’d be able to much more clearly segregate them, you’d still be able to easily put them side-by-side into a single pivot table, and it would open up a lot of other possibilities (eg using the built-in aggregations, which could be useful for your quarterly figures).
I realise that I don’t have the full picture, and that there might be other business requirements or design considerations that have led you down this path, so I do understand if you’re tied to using a single data element for both data collections. But if not, then I would definitely consider splitting this out, as being able to use built-in aggregations could resolve the issue you’ve encountered above.