ima-worldhealth / bhima-1.x Goto Github PK

As we approach the point of re-designing permission and routes, an important redesign goal is should be to modularize the architecture of the server posting journal code. Current statistics are:

The journal.js file is already set up for easy modularization. It exports a central router that calls a given function based on the url parameters. I propose the following redesign:

Folder Structure

- routes
  - journal
    - core.js         # contains the router export
    - coreutils.js   # contains utility functions common to each route (getTransactionId(), validUser(), ...)
    - engines       # contains the posting logic for each route in an individual file.
        - purchase.js
        - sale.js
        - cash.js
        - caution.js
# ...

In this model, core.js contains the map from URLs => engine and passes the parameters to each function. Ideally, the code would be incredibly generic and use promises. An idea looks like this:

module.exports = function router (db /*, dependencies */) {
  var utils, map;

  utils = require('./coreutils');

  map = {
    'purchase' : require('./engines/purchase')(db, utils),
    'sale' : require('./engines/sale')(db, utils)
    // etc ...
  };

  return function () {
    var args, table;
    args = Array.prototype.slice.call(arguments);
    table = args.unshift();   // get the first argument
    return (!!map[table]) ? map[table](args) : q.reject('No route for table : ' + table);
  };
};

This model can then handle any engines added later. The only change is to add a line into the map.

Each engine then is responsible to doing checks to see if the data is properly set up. The engine should also contain a rollback function, in case of failure.

Opinions? Thoughts?

We need, the new module for paying employee

According to the Grand caisse bugs document (https://docs.google.com/document/d/1_NG3ReAUpbbWcXlLwoZkyM7uBKxeLRG4uANk0kQSb5c/edit), I would try to fixe convention bug.
Thanks

I notice that :

1. We credit the cash and debit the client instead doing the contrary.
2. There is no recit after transaction
3. We need a type a head for selecting debtor
4. We need to catch error of dependencies missing such as exchange rate

Cheers.

I noticed an error when I save modified posting journal records (I think there is a problem with unparsed date, date must have Mysql fromat).
The posting from the journal to the general ledger works but messenger service print an error.

Our journal voucher module has always been strange. It is slow, almost to the point of not being able to use it. Here are some thoughts on refactoring the module so that we can ship journal controls soon.

UI/UX

The user interface is very scattered. We can select the currency first, before even writing the amount! We need design the page to formalize the set of operations. For example, first provide a reason for the voucher, then give the voucher a date, and then specify if it is to a particular debtor/creditor and what the transaction currency is. Finally, you can begin assigning accounts and balances.
currency is. Finally, you can begin assigning accounts and balances.

Additionally, the module look very much like sale, and tries to do very different things. For example, since we implement double entry accounting, you should not have the option of removing rows past the last two. You can currently delete all rows without any repercussions.

Bugs

Finally, the adding/removing of rows is very slow. This one is particularly strange, because I am not sure the root cause. It requires investigation

The module should be very clear (in the messages/titles) that you are affecting change on the posting journal. It's a serious, administrator module, not like sale which you afford to make mistakes to fix later.

Picking a debtor should automatically fill in "D" for debtor and the account number. Similarly with the creditor field. Currently, you can assign "C" to a debtor and a completely different account. Lots of mistakes are waiting to happen here.

Conclusions

This is a priority if the Congo team intends to install the posting journal and train the accountants soon. If we are rolling out payroll soon, this is an absolute necessity (in case bugs are discovered in the payroll process, you can still pay a creditor through a voucher note).

There is no controller folder

We need to be abble to reverse a service distribution operation if necessary.

Currently, we simply define out patient find directive's typeahead templates inline. This leaves a variety of maintainability and user experience problems. We should unify into a single template which is uniform across the entire application. We gain the ability to edit a single template and see the results throughout the app, as well as giving the user the same experience from page to page.

Reference : IMA-WorldHealth/bhima#58 (comment)

Addressing the patient registration/ visit process in BHIMA, the proposal is to combine the patient registration and patient visit modules, this would give the receptionist the following options when registering a patient :

• Patient is new to the hospital
  • Provide patient registration form
• Patient is returning, but has not been registered with BHIMA
  • Provide patient registration form
• Patient is returning and has been registered with BHIMA
  • Allow user to lookup patient using search / advanced search
  • Patients account is registered as visiting the Hospital

This would provide immediate benefits to the users :

• Simplification of the visit process, less modules and conceptually easier to learn
• Much more difficult to ignore / forget to log patient visits, all related tasks are in one place

Enabling accurate patient visit logging with provide valuable statistics to Hospital administration.

In addition to streamlining the process, it should be verified that all meta data is recorded correctly, from patient visits to the user registering and date of registration.

Edit - ensuring correctness of logging

According to the Grand caisse bugs document (https://docs.google.com/document/d/1_NG3ReAUpbbWcXlLwoZkyM7uBKxeLRG4uANk0kQSb5c/edit), I would try to fixe transfert bug first of all.
Thanks

We need a report printing a debtor history, one person can choose it

This is not a critical issue, since we don't officially support Firefox, but may become relevant in time. It seems that our API to interface with the browser storage engines through AppCache throws an InvalidStateError at startup in the application in the latest Firefox builds. If someone wants to learn more about storage engines in the browser, this seems like an excellent bug to try and fix. It would also be nice to use Firefox in the future for development.

Update
The v1 branch has been upgraded to using $localForage. However, this issue still persists in FF, which means the bug may be beyond the scope of our applicaiton. We should still investigate to find out what the root cause is.

Daily exchange rates are of critical importance for the financial aspects of the application to work. The current exchange rate setup has proven problematic for two reasons:

1. The module itself allows registering multiple exchange rates on the same day. This feature has not created any errors to date, but it is confusing from a usability perspective. It is also unclear which exchange rate might be used in the case of a posting journal query or otherwise.
2. The exchange rate service is not sensitive to the changes in exchange rate from the module, resulting in a complete refresh being required to load a fresh exchange rate.

Proposals

Many user interface crimes have been committed by this particular module. We need to fix them. The table with exchange rate details ought to include a timestamp of when the exchange rate was added, and must let the user edit the exchange rate for the current day. We should allow loading any number of exchange rates in the table, in the style of github's commit message select "view the last XX rates". Finally, better confirmation messages ought to be used.

With regards to the exchange rate service, we can avoid the mess by simply changing the way we refer to exchange rates - the functions reference shadow properties of the scope and do not change the parent properties. Some analysis needs to be done, and the code updated. Furthermore, there ought to be a unified API for accessing exchange rates, so that all reports can leverage the exchange rate service to provide on the fly calculate of exchange rates.

Thoughts?

I notice that : If a sale was not paid, it will be consumed many time in the patient distribution module.
Even if you pay it after, it will continues to be printed like an unconsumed sale.
But every thing is good if the sale was paid before be consumed.

According to the Grand caisse bugs document (https://docs.google.com/document/d/1_NG3ReAUpbbWcXlLwoZkyM7uBKxeLRG4uANk0kQSb5c/edit), I would try to fixe generic expense submodule bugs.
Thanks

There is some bugs in invoicing for purchase order

Thank you Jon for the pull request

However, I have a suggestion about balance account initialisation, I think those account (class 1,2,3,4,5) must keep there statut from one fiscal year to an other.

About the new issue, I think we need to change a little be our posting journal and general ledger interface, by introducing cost center and profit center. because now accounting is almost full in our system, we are writting in posting journal from purchase order to distribution.
I assign this task to you for more flexibility and let me know if you have a better idea.

@sfount , let me know when you will be free.

Good health to both of you.
Cheers

The payroll module will need report printing such as unpaid salaries, paid salaries ...
one of use can choose this issue.

I propose a new API for accessing locations.

Currently, we have routes /village/, /sector/, /location/:villageUuid, etc. These don't make a very good API. Rather, I propose we remap these fields so that we never call extra fields, and break them into a new module as follows:

Overview

All routes are GET requests to a path along the /location/ route. The paths are:

• /location/villages
• /location/village/:uuid
• /location/sectors
• /location/sector/:uuid
• /location/provinces
• /location/province/:uuid

Countries can be made using the regular connect.fetch() syntax.

Details

/location/villages returns a table of all villages, in this format:

/location/village/:uuid will return the same information, limited to where uuid is the village uuid.

/location/sectors returns a table of all sectors, in this format:

And so on for the rest.

Comments?

location-select directive has no way of setting default values. Editing of current entities requires setting current location values.

Current suggested option is to define a variable that the directive will $watch on the $scope, as soon as this variable is populated the directive will attempt to load this as the default village.

select-village - define method to be called on new location
origin-village default-village - optional parameter to define the default village, if no parameter is supplied this will default to the enterprises location. This variable should be available to the scope and will cause the directive to re-assign the default location every time it is updated

<div 
  location-select 
  default-village="employee.village" 
  select-village="updateLocation"
>

We need a report for all income from the grand caisse. Please one of us can choose this issue.

Currently BHIMA uses some hacked together JQuery and a separate page to manage logins. After reading this article, it seems we can do better by embedding our login into the application itself and having a global session manager on the client side and the server.

There are multiple advantages to doing this.

Hiding Content

We gain the ability to have user permissions and roles received from a server at initial login and stored in session data around the application. We can then imagine filtering content based on the user roles. Obviously, this is not the most secure way of doing things, but for convenience this would work well. i.e.:

<a class="btn btn-sm btn-default" ng-click="doMiscThing()"> I am a regular button </a>
<a class="btn btn-sm btn-default" ng-click="doHighLevelThing()" ng-if="session.user.role=='admin'"> I require admin privileges to see! </a>

Login Validation and Translation

See the examples below:


In addition, we can translate the login page, and let the user switch between languages

Better control of application state

By keeping this within the angular app, we can use the same error handling techniques as always. Furthermore, if we ever want to extend to support "offline" modes or the like, we can use the session scaffold already in place and simply extend it.

Thoughts?

According to the Grand caisse bugs document ( https://docs.google.com/document/d/1_NG3ReAUpbbWcXlLwoZkyM7uBKxeLRG4uANk0kQSb5c/edit ), I would try to fixe purchase order.

We should handle the direct payment situation, from the hospital to the supplier

The CSS in the navigation tree hides content if modules are opened to far. I do not plan on addressing this right away, which is why I am creating a new issue.

Can someone tackle this? It should be an easy fix. Maybe Bruce or Chris?

Keeping with our theme of re-factoring into smaller, reusable modules, the /report/ route(s) could benefit from some re-factoring. The route structure should mirror the folder structure and vice versa. For now, there is no pressing need to go deeper than one layer, unless someone can find a logical way of clustering reports.

- report
  - router.js
  - cash.js
  - stock.js
  - depot.js
  # etc ...

This may not be the best idea - there may be a better way grouping by financial versus stock and such, but this structure would decompress our files for now, making them easier to version and slightly more portable.

Thoughts?

We need a report of all expenses from the grand caisse. Please one od us can choose this issue.

Hello All,

Well, my initial attempts are formalizing error reporting were really bad. This needs another analysis and redesign, but much more research first. If anyone wants to propose a design, please post it below. I do not have any ideas for the moment.

Lors de l'enregistrement de l'employé tout se fait correctement mais le problème se trouve lorsqu'on clic sur éditer, on ne voit qu'une partie des infos de l'employé

The location UI is sub-optimal, from both a technical (code) perspective and a user experience perspective. Considering that this series of modules will be undergoing quite a bit of use (initially, but we can expect it to pretty much continually be adding villages), it is useful to consider a redesign.

I propose standardize all the pages into a single page. The new location management page will feature four prominent buttons:

• Add a village
• Add a sector
• Add a province
• Add a country

These will bring up forms to do the specified action. The main table of locations could be a SlickGrid, with filtering and sorting support. Additionally, by clicking any column (except village), a drop down will emerge with all possible values of that column. In this way, if someone decides that "Tshibata" is not in sector "kazumba", they can quickly change it without having to do multiple clicks. They do, however, have to click to save the changes.

Edit

Furthermore, we should support deleting locations, but only if there are no patients registered to that village. We can use a series of check boxes on the main location management page to select a row, then have a single delete button at the top of the grid.

I think this is the best time to begin writing some thing for reports : We need the cash flow report.
Please one of us can choose this issue.

We need also a report printing all patient group and their price list.

After merging noticed that the module register supplier does not work very well.

The stock distribution to a patient doesn't work correctly, I don't know why but I notice that :

• When you submit the button, the module throws an error
  • there are lines or line in consumption table but not in consumption_patient table

The number of leaves in our tree has exploded, particularly in the "admin" branch. Currently, we have this series of modules:

• Gestion des Services
• Gestion des Grades
• Gestion des taxes
• Gestion des rubriques
• Gestion des jours fériés
• Gestion des vacances
• Gestion des Périodes
• Configuration des rubriques
• Configuration des taxes
• Configuration des comptes

This is a lot of modules, and presumably many of them can go into the same configuration module. For example, Gestion des Employés could account for Gestion des Périodes, Gestion des vacances, Gestion des jour fériés, etc... Configuation des comptes could be inside of Enterprise management.

We have to think very carefully before simply adding more modules, because our users will take along time to find them, and will slow their use of the application down. We should think about how to restructure this setup for increase the useability of our application.

The payroll module will need report printing such as unpaid salaries, paid salaries ...
one of use can choose this issue.

@DedrickEnc , can you please remove the unused (stale) branches in the main repository? Pull requests sometimes try to merge with old branches, which creates problems for everyone.

These branches include:

• current
• projects
• db
• stock
• any other one you believe will no longer be maintained

Hello All,

This is a rather large bug. For some reason, the exchange_rate module sets the wrong exchange rate date on the database. To replicate, simply create an exchange rate and observe that the recorded rate is for the following day.

Additionally, exchange rate has often given problems with setting the rate for the whole module without refresh. This needs to be fixed before the next bhima release.

Please confirm this bug exists on your machines as well.

We need some polishing in service module and the module can not update a service.

Gentlemen,

Receipts are now a critical part of our infrastructure, and we cannot continue hacking them together any longer. Working with the module this morning was tragic, left me feeling like a lost and confused programmer who has never heard of encapsulation or modularity. These self confidence issues must end.

Proposed Design
Invoice.js becomes receipt.js, and is the main controller. Based on the $routeParams receipt type, we use ng-include to include the appropriate template. We can also easily define data required for each template, and have a standard way of validating and loading the data in reciept.js. Our folder structure suddenly changes from

- invoice
  - invoice.js
  - invoice.html

to

- receipt
  - receipt.js
  - receipt.html
  - receipt.cash.html
  - receipt.sale.html
  - receipt.purchase.html
# ...

It is my opinion that this will help us immensely going forward, and therefore should be a priority. Right now making invoice/receipts is a very sad state indeed, with many console.log()s trying to figure out what is going on.

For reference:

An other task we need to do. one person can choose it

Currently, connect does not support aliasing, though it was always planned to. The app stands to gain a lot by supporting aliasing fields from the clientside. Many smaller data routes have been moved to the server simply because of field naming collision (e.g. text is used generously throughout the app).

I propose we add aliasing to connect.js and parser.js. The API may look something like this:

query: {
  tables : {
    'journal' : {
      columns : ['uuid~id', 'account_id'] // alias uuid as id
    }
  }
};

This, of course, is a very rough API, but may work for our needs. Discussion?

Previously, we had a button that would recover a sale in case the user accidentally navigated away from the page. Now that we have added "services" to the page, we should use the same method to recover the service.

An acceptable pull request must do the following:

• Create a sale to an arbitrary service, with arbitrary number of items
• Navigate away from the sale page prior to submission
• Return to the sale page, click 'Recover Sale'
• The only remaining required action should be to submit. All fields should be successfully restored, including the 'Select a Service' field.

Erreur lors de l'insertion du Groupe Debitor de l'employee

We need to be abble to reverse a distribution if necessary

According to the Grand caisse bugs document ( https://docs.google.com/document/d/1_NG3ReAUpbbWcXlLwoZkyM7uBKxeLRG4uANk0kQSb5c/edit ), I would try to translate the generic income.

We should revisit the employee module and fix some problem, such as supplier code in employee entity seems unnecessary.

This system needs to support long term accounting, buy 👍

• creating new fiscal year,
• opening balance,
• keeping balance account state from a fiscal year to another,
• resetting income and expense account to zero from a fiscal year to an other

We need also some fixing in fiscal year module.

Jonathan I hope thing will be more flexible if you did it because you wrote this module.
Thank

Patient registration currently allows users to submit a patient without a year of birth, I think this demonstrates a few things:

• Patient registration requires better validation, submitted values should be checked before being shipped and required values enforced
• The patient registration module contains a lot of legacy code from previous version of BHIMA, this should updated and brought up to the current standard

There are also a number of bugs related to locations in patient registration, these should also be addressed.