Hi,

This mail should be relevant to all super users and report designers
using DHIS 2.


---------- Forwarded message ----------
From: DHIS 2 <[EMAIL PROTECTED]>
Date: Fri, May 23, 2008 at 1:35 AM
Subject: [DHIS2-Trac] #323: Croostab table creator: need to specify
which month is the reporting month when using relative periods
To:
Cc: [EMAIL PROTECTED]


#323: Croostab table creator: need to specify which month is the reporting month
when using relative periods
-----------------------+----------------------------------------------------
 Reporter:  olati      |       Owner:  larshelg
   Type:  Defect     |      Status:  new
 Priority:  Major      |   Milestone:  2.0
Component:  Data Mart  |    Keywords:
-----------------------+----------------------------------------------------
 First some background information on this new module:

 In the new table creator module its possible to design crosstabulated data
 mart tables with lots of flexibility. Basically any kind of combination of
 orgunit,indicator (or data element) and period is possible to specify as
 column headers. This functionality is very useful when designing reports
 in other applications like e.g. the BIRT report designer when you need to
 put a specific indicator in a specific position on the report, or need an
 indicator value for the last quarter together with a value for the report
 month and last 12 months etc. User-defined crosstabulated data basically
 gives you full control and flexibility over your report design.


 You can check out the live demo at http://www.hisp.info:8090 to see the
 user interface of this new module called "Report table creator", but need
 to install the latest code of DHIS 2 locally to actually get access to the
 created tables for further testing and use.


 In my example I want to create a new table that has 10 feedback indicators
 for the reporting month + a total of the last three months for the same 10
 indicators. This means a table of 21 columns, the first column for orgunit
 (not crosstabulated but listed row by row), and then the next 20 columns
 for the crosstabulated 10 indicators X 2 periods. E.g. column heading 2 is
 "BCG <1 reporting month" and column 3 is "BCG < 1 last 3 months", column 4
 is "ANC 1st visit cov reporting month" and column 5 is "ANC 1st visit cov
 last 3 months" etc.. for all the selected indicators. Each row will then
 contain an orgunit name and then the 20 values for the indicator+period
 combinations for that same orgunit.


 In the user interface you can freely specify what you want to
 crosstabulate (orgunits, periods, indicators, data elements) and then
 select which orgunits, indicators and periods that should go into the new
 table. For periods you can either pick fixed periods (e.g. January 2008 or
 Q3 2007) from the list of available periods or you can select so called
 relative periods which are much more useful when you are designing routine
 reports that are going to be again e.g. every month or quarter. The
 available relative periods in this early release of the module is
 "Reporting month", "Last 3 moths", "Last 6 months", "Last 9 months", and
 "Last 12 months".

 My specific request in this ticket concerns how these relative periods are
 selected. The Last 3/6/9/12 periods are calculated totals relative to the
 reporting month, but the user cannot define what is the reporting month,
 that is my main concern. Currently the reporting month seems to be the
 current month (when the table is generated), but that is not always what
 the user wants as, first of all the reporting month is often the previous
 month as data cannot be reported before it is collected. And sometimes it
 might be even older months as data might have been reported late or have
 been modified. I suggest a small addition to the user interface for
 selection of relative periods to include a selection box where the user
 can specify exactly which month is the reporting month of the table
 (report) that is to be generated. Every month (or whenever) the user can
 then regenerate the same table simply by opening up the same table design,
 there change the reporting month and then re-generate the table. For
 readability and easier use of this table the table itself should include
 information of what is the reporting month. I suggest to add another
 column at the end called reporting month which contains the name of the
 reporting month selected by the user. This will be duplicated for each
 row, but considering the amount of data that these tables can potentially
 hold I find this small addition almost irrelevant when it comes to table
 size.


 For later releases, a more sophisticated solution could be to let the user
 define that the reporting month is the previous month (CURRENT_MONTH-1)
 (as data is reported the month after) which could be useful when we start
 to support automated generation of these report tables every month as part
 of a strategy towards a more automated data mart generation (which is
 planned for).

--
Ticket URL: <http://www.hisp.info/dhis2/ticket/323>
DHIS 2 <http://www.hisp.info/dhis2/>
District Health Information Software 2


--
best regards,
Ola Hodne Titlestad
HISP
University of Oslo



-- 
best regards,
Ola Hodne Titlestad
HISP
University of Oslo
_______________________________________________
Dhis-users mailing list
[email protected]
http://www.hisp.info/mailman/listinfo/dhis-users

Reply via email to