If you've gone through DevResults training, you know that all pieces of data in DevResults need to have four characteristics defined:
It's easy to remember these words, but understanding the concepts they align to in the system will make it much easier to use DevResults. We've worked up a diagram to work through some of these concepts, and this page will walk you through a lot of them.
First, let's take a look at our DevResults Data Structures Diagram:
If this looks confusing to you, keep reading.
There are two basic ways to report data in DevResults (see the Entering Results Data section of the site for more info on both of these):
- Via Reporting Period
- Your site is configured with reporting periods, which can be whatever periods you choose (monthly, quarterly, annually, etc.), which have set start and end dates and set submission periods.
- You or your partners can only report data for the reporting period during its submission period.
- See Add a Reporting Period for steps on adding a reporting period to your site.
- Via Data Tables
- Spreadsheets containing individual records are entered into the system.
- You or your partners can add data to these tables at any time.
- These rows of data must contain a date; the system will automatically aggregate these individual records by reporting period.
DevResults tracks two types of geographies:
- Specific points on a map with GPS coordinates such as hospitals, schools, etc.
- Can be added at any time by following the steps in the Add a Location page
- Administrative Divisions
- Shapes or areas such as districts, provinces, states, etc. loaded into your site via kml file
- DevResults pre-loads your site with relevant shapes from http://gadm.org/
- Changes to administrative divisions can generally only be made by providing us with a new kml shapefile (see About KML Files and Add Map Overlays for more info)
Every indicator gets defined with a geographic reporting level; activities are also assigned to geographies. (Note the arrow and triangle from this box to the Indicator reporting level and Activity boxes.)
Indicators really are the "what" that you're reporting. They must be precisely defined so that results can be compared between locations, reporting periods, and activities. See Indicator Guidebook for best practices and more information.
Indicators may be configured with one or more disaggregations; disaggregations must have disaggregation values assigned to them.
Take a look at the whole diagram and pay attention to the arrows; it should be easy to tell that the Activity is really how everything gets tied together in DevResults. Consequently, most problems with being unable to enter data for a reporting period stem from problems assigning an indicator, a reporting period, or a geography to that activity.
In turn, all activities are assigned to an organization. Users are also assigned to an organization. For partners and partner managers, the system compares the user's organization to an activity's and will only show a user the activities for which the organization matches. See Activities and Organizations for more information on these topics.
Permissions are assigned to user groups (such as partner, user, manager, partner manager, owner); these permissions determine what a user can view and edit broadly system-wide. A partner user's organization determines which activities they can see, but their permissions determine which actions they can complete for activities. See Permissions Overview for further info on the permissioning process.