Feature/integrate reports

[sfount]

A proposed structure for integrating PDF document reports into BHIMA. This pull request also proposes a framework for the conceptually complex issue of reporting.

Primarily an Income vs. Expense report document was developed allowing the user to compare the variance on multiple fiscal years as well as demonstrate the report structure.

The proposed report structure is as follows:

• Client Reports - This is anything that requires a snapshot of the database as it currently stands, there are many of these currently (sale records, cash records, etc.).
• Document Reports - Formal reports that are compiled as PDF files, archived and made available to the user at any time.
• Dashboards - Similar to a client report however with the aim of formatting the data using graphs and interactive components
• ?CSV/Excel Export

Grouping all of BHIMAs reports into these categories will simplify both UI/UX for users as well as finalising a schema for future report development. Using the proposed API will also allow report documents to easily be added given the report data. In this pull request this is demonstrated with the sale records page.

There are a number of design decisions that can be discussed and altered before the pull request is merged with the development branch.

Report Document Integration

• [x] Report document archive page (user interface)
• [x] Report service to handle server communication - cache and make report data available
• [x] Report generation modal structure (Initial development - design to be adjusted with feedback). Allow the generation of reports anywhere BHIMA requires it
• [x] Saving PDF document with reference in archive database, indexes available through GET
• [x] Standardised configuration (client) -> server options object -> templating options object

General Report Architecture

• [x] Model reports in the database (currently settup as hardcoded routes etc.)
• [x] Link client/server/database reports based on database _'reportkey'
• [x] Legacy reports build with document prototype 'depreciated' but supported until they can be upgraded

Reports

• [x] Income vs. Expense - Example of formal document report, configuration options allow the user to adjust title, headings and most importantly select two fiscal years to compare variance. All reports generated are indexed and saved for future use.
• [x] Chart of Accounts - Demonstrating another formal document report
• [x] Patient Invoices - Example of hybrid report, this report is primarily used as client side reference module to lookup daily sales and print receipts. This report demonstrates the ability to generate a formal report document given the same data (using the familiar document creation modal, anywhere in BHIMA). This can be used anywhere that may require a formal list/ state to be printed - for example auditing, invoice reports for conventions, shareholders interest etc.
• [x] Proposed demonstration report client side generation modals
• [x] Proposed demonstration report server side data + templating resources
• [ ] Tests for entire report integration process; client -> server -> database

Proposed discussions/ implementation before merged - these can be ignored if any not deemed required

• [ ] Proposed design (GitHub) issue for how to generically select accounts for a report to be built around, this could be something that shows up in many reports
• [ ] Proposed design fully defining the limited set of configuration options that should be implemented, letterhead, dates, headings etc.
• [ ] Modelling income and expense accounts separately (proposal) - the current system can only tell these two groups apart based on _accountnumber, this involves plenty of hardcoded statements in contrast to the databases driven accounts.
• [ ] Report language and translation proposal (accounting for current client side translation resources)
• [ ] Finalised report table/ Headings design - this is the face of BHIMA so should be perfected and standardised across our reports
• [ ] Templating engine standardisation across emails/ PDF documents etc.

The current build introduces a file in server/models called dev.sql to compliment synt.sql - this isn't intended as the final Schema however it will allow the team to discuss (as we would on a white board) before committing it to the upgrade structure - this can be removed/ changed if it is decided against.

[jniles]

Classic "needs tests" alert. :). I'll give you a code review before noon.

[sfount]

Cheers @jniles. I'll be making a few changes today but nothing too significant.

As I've let this pull request span over such a long time I wasn't able to guarantee all of the changes made are good!

No rush on the code review but I'll aim to merge changes from the current development branch to make your life easier.

[jniles]

@sfount, sounds good. Then maybe I'll schedule it for after work tonight.

Yeah, I figured this will take a little while to get merged in. At bhima, we like to make PRs that change 40+ files at a time. :+1:

[sfount]

(42). To be fair this is an example a larger feature that a subteam would work on and then merge up into development. The primary difference being lack of sub team, tests or incremental merges rebasing.

[jniles]

@sfount, I haven't really given a technical review since massive parts of this are changing and rife with TODOs. There are some comments to help clarify some of the concepts here. A few general thoughts (and correct me if I misunderstood anything) follow:

1. I really like the idea of module states begin put in a factory. That will make things clean and semantic in the controllers. Awesome work at setting a good base for that in this PR.

2. I worry about using resolve in our routes for a number of reasons. The benefit is that the controller can be written entirely synchronously, and that is convenient. However, I worry that switching our router, updates to AngularJS's Routing API in the future, or other reasons may cause us much more harm in the long run than it might otherwise. Also, if we ever want to start moving in a component-directives direction, it's unclear how we'll use resolve. For example, I'm no clue how this world work:

   .when('/some/route', {
    template: '<patient-list>',
    resolve : someObject  // can I get this into the directive??
   });

   Obviously, all my concerns are purely theoretical, but I'd be interested in discussing it.

3. You have the loading indicator earmarked to become a directive. It looks like the entire modal interface could actually be a directive as well.
4. That's some real magic you have going on, dynamically templating in the controllers and aliases for the reports. Probably could use some better documentation, and perhaps an angular course for whoever tries to read it in the future. :)

Overall, this represents a lot of hard work, and is a great step in the right direction. With regards to your future design questions, my perspective is this:

1. I think we have already settled on making two different account types: 'income' and 'expense'. However, we might be able to somehow combine that with the account.classe field, or at least make the account.classe more sematic.
2. The limited set of configuration options can be discussed. I can't think of many more other than:
   1. Language
   2. Layout (landscape/portrait)
   3. (potentially) ornate/plain -- 'ornate' having the IMCK logo, bhima logo, etc in color and ready for a formal report; 'plain' would be easy on printer ink and have minimal whitespace.
   4. Date format
3. It would be super nice to have an isomorphic (or whatever the kids are calling it these days) translation library to share between the client and server. It's definitely worth doing investigation this for bhima's future.
4. After some initial hiccups I'm happy with dot, but could easily change. It would be nice to have the same syntax (and potentially the same templates!) between the client and the server. But one can dream.