dhis2-devs team mailing list archive

[Thuy Nguyen <thuy.hispvietnam@xxxxxxxxx>]

Dear Johan,
Thank you for your suggestions. Please scroll down to see my mail



On Tue, Dec 7, 2010 at 1:59 AM, <johansa@xxxxxxxxxx> wrote:

> Dear Thuy,
>
> I'm not very familiar with the requirements in Sri Lanka, but I have a few
> general comments. First, the categories and combinations should be used
> when we want to aggregate them into a data element that is a natural total
> of these categories. For stock, this is usually not the case, as we do not
> want to add start balance, received, issued, and monthly requirement (in
> this case).


About the total meaning of categories and categories options. I got the
lesson from my mistake in Vietnam. So I didn't want to repeat again by
explanation people here. But again because of the instant benefit of
category data elements such as the defaul entry form will generate
automatically with good form which DHIS provided. And the shorting of
creating data elements,... So the person who do this project decided to use
categories for this report as well as other reports for equipments like
beds, tables,... I knew it is wrong for the meaning of categories which
developers in DHIS wish to use. But I don't know serious reason for defense
on this. That's why I consult you to know what will happen in the future
when data base become huge if we use category options like this for data
elements? Is it affecting to retrieving information later?

The total will be meaningless. The average monthly requirement
> would probably also be a semipermanent data element I think.
>

Tihs averate number is calculated like this. it will get total values of 12
months issued in the year and devise to 12. Some places they get total of
last 3 months and devise to 3. Some places use total of last 6 months and
devise to 6. This is according to each place prediction for their
requirements to get the items.

And when the data base in very start state, there is not value of last
months. But the requirement need to be generated.

That's why I put more element for average, users will enter the values they
want according to their requirements. This average require and depend on the
size of each place's stock, will generate min require quantity, max require
quantity.


>
> Second, regarding the parent/child/grandchild totals, I think it should be
> possible to set aggregation start levels, meaning you could use the same
> data element definitions for all levels without running into double/triple
> counting. But others would need to fill in about this.
>

I don't understand much about this. Please give more suggestions.


>
> Aside from this, I would recommend some changes to the form attached, if
> possible. If these forms are not final, I would recommend adding some
> aggregate information on stock outs, such as days out of stock. But if
> this is generally not a problem, then the few instances can be derived
> from the other data elements.
>
> Regards,
> Johan
>
> Thuy