A bug was detected during the check of A03-1 PAV form. Indicators on column “Taxa de Cobertura” are not working. As you can see yellow box contains incorrect values, it should be (“Total” / “Grupo Alvos”) * 100 The bug refers to version 2.16 at the server for development copy of production server http://197.249.4.189:8082
The same does not happen at the server dedicated to development copy of historical server based on 2.13 version ( http://197.249.4.189:8080 ) , as you can see in the picture below.
A third check at server dedicated to quality control copy of production server but based on version 2.13 ( http://197.249.4.189:8086/ ) shows incorrect values, as you can see in the picture below 
These observations lead to the deduction that the problem is not related to the version, but to the organization units tree. Servers 8082 and 8086 are configured with the new organization units schema while server 8080 retains the old organization units schema.
The issue could be related to the migration of data from historical server to production server, some data where bound to the old organization units schema, they probably do not recognize the new organization schema, therefore were lost in some way. We need to investigate.
This is what Luis says (he seems to think it’s not org unit related)
Analysis of the issue of the EPI report , it was found that the
it derives from the application of SISMA -746 change where we were
requested by Health Programme that for all forms of VAP
( A03-1 , A03-2 ) , the field ” Target Group / Target ” should be an indicator ,
which over time could be calculated in% set.
This application has been implemented in SISMA and later
was canceled by the MOH ( in the words of Mr. Amisse who stood after
be formalized but did not and kept ) and has not been in
however made the roll -back to previous version. Even today
situation will be resolved in Production and Gulam respond to this
email with that statement .
So it seems as it was cancelled we should be able to use the version in the historical data 2.16 instance. It should not be a lot of work to revert the form, but we do not have access to the server. Only Critical can do this. As far as I know.
We can try it on our development server, you and Pascal should have access.
I see, but we need to replicate the solution in our server 8082. As far as I understand it is a simple change in formula. I did it with no results. What’s wrong?
best thing to do would be to get a dump of the production server (MDOH) metadata (once the fix has been made) and restore this to our server in mOASIS. We need to have a regular process to move metadata from the MISAU server to the mOASIS aserver to keep them in sync.
Just for a formula? It seem to much work. Moreover we are copying a solution not replicating it. We need a process of know-how transfer which is not guaranteed by a simple dump. I tried to modify the formula, I need somebody else to do it in order to validate the issue. I ask a dump to Gulam.
Forgot to write that there is a development work ongoing, therefore we cannot proceed with a simple restore otherwise we loose the current work, the SIS-C03 A (BES) Epidemiological bulletin is being produced for further use in MMOH server.
We should use one server for production (a copy of what is in MISAU), and another for development. i.e. dev should be for development, and staging for testing, and production should be an exact copy of what is on the MISAU server. But yes, we cannot overwrite our instance with metadata if there is work in progress. It’s on a different form/database so maybe it won’t matter if development proceeds on an instance that contains the bug. Once that dev is finished, those forms/datasets should get moved to staging/prod, and dev should be restored from prod again.
We have four servers for this purpose, the exact copy should be the quality server based on production server http://197.249.4.189:8086/ but at the moment is still on version 2.13, we should do the migration here.