Reporting: separating gifts into two columns

tim_ingham

In OM, we sometimes understand that the income of a field should be separate into two classes:

[]Gifts intended to support a named individual[/]
[]Other income (general gifts, gifts for a specific purpose, and earned income)[/]
[/list:u]

Our report, "Total Gifts Through Field" has filters that separate gifts into two columns, based on this understanding.

The current logic in the report uses the names of gift motivation details, which it must not do, since these are user-editable names.

This separation of gifts into these two classes is specifically an OM thing, and other organisations that are potentially OpenPetra users may not see the value of using these particular classes for reporting. On the other hand, they may want to use three or more columns.

I need to remove the explicit references to the ASCII names of motivation details from all our reports, so our consensus (ie brief discussion here in the Carlisle office) is that we should add another field to our MotivationDetail table, to specify which column a particular MotivationDetail will report in.

The minimum requirement is to add another boolean flag, "worker" to mark those MotivationDetails that will be reported in the "Worker" column, but I would prefer to instead add an ASCII field, "ReportColumn" so that in the future our reports could be re-worked to display a variable number of columns. To fulfil the current OM requirement, we could then write "Worker, Field" into the UI as hard-coded values (in a drop-down or possibly from a check-box), but in the future we could allow configuration for n report columns.

This is a proposal to add a field to a database table, so I appreciate that it will have an impact on our database conversion, and sample database production.

pokorra

We have the same problem with special types, WORKER vs OMER.

I am wondering if we need to solve these problems in the database, or is it easier to add a configuration parameter, which we have to pass to the reports.
Otherwise all the tables and queries become again more complicated.

Also: for OM, you don't need to worry about other organisations. It is up to other organisations to make it work for them, and to invest into such a solution.
I think, OM should focus on getting it work for OM.

It would even work to have a separate branch with hardcoded values for OM, which I do for my customers.

We need to keep it simple.