ima-worldhealth / bhima-1.x Goto Github PK
View Code? Open in Web Editor NEWA hospital information system for developing countries.
License: GNU General Public License v2.0
A hospital information system for developing countries.
License: GNU General Public License v2.0
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:
File | Length |
---|---|
journal.js |
1825 |
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 :
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.
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.
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.
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 :
This would provide immediate benefits to the users :
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:
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:
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.
/location/villages
returns a table of all villages, in this format:
uuid | name | sector_name | province_name | country_name |
---|---|---|---|---|
e80f127a-2eba-46a5-93fa-fcf373fe5a9f | Bulungu | Ango | Bas Congo | Democratic Republic of the Congo |
/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:
uuid | name | province_name | country_name |
---|---|---|---|
e80f127a-2eba-46a5-93fa-fcf373fe5a9f | Ango | Bas Congo | Democratic Republic of the Congo |
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.
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>
See the examples below:
In addition, we can translate the login page, and let the user switch between languages
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.
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:
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.
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 :
The number of leaves in our tree has exploded, particularly in the "admin" branch. Currently, we have this series of modules:
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
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:
File | # of Lines |
---|---|
invoice.html |
1089 |
invoice.js |
852 |
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:
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 👍
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:
There are also a number of bugs related to locations in patient registration, these should also be addressed.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.