OpenERP features required from the product

Software Bahmni
1

Hi, In last product roadmap discussion we had agreed that current development team should pick up 1 or 2 features in openerp category to get exposed to that part of the product but we couldn’t arrive to a consensus as to what feature in the openerp category should be picked up. The feature, of course has to be productish. I am starting this thread so we come up with some options for such type of feature. Here are a few options i think :

  1. Ability to sync all orders/orderables to openerp

Currently we sync only drug, lab (test and panel) and radiology orders. This is hardcoded. Refer code here . Can we make it generic to support any/all orderables? We can probably use concept_attributes to allow implementers to mark which concepts are to be synced. The usecase to sync other orders like surgeries and procedures is common and people struggle to do it using the radiology workaround (we don’t even have it documented anywhere) and its painful as well. We have multiple talk threads asking about this and this one is the latest in that list.

  1. Ability to sync obs to openerp

We currently only support syncing certain orders and do not sync any obs. There have been asks in the community for ability to sync certain obs like Registration fees to openerp which seems like a common usecase. We could support syncing obs against specific concept marked by implementer. We can again use concept_attribute for this i think.

  1. Ability to see certain generic erp data like patient outstanding amount, latest quotation amount in EMR

This is the one that i had suggested last time around and we had a brief debate on this. @angshuonline i am not sure what the contention on this was. Was it that this can be done using existing features or was it that this feature is not generic at all? Even though it’s achievable using existing features, it seems that none of the implementers so far has had enough capacity/capability to have developed this even after looking at the partial example you developed. Doing it via the product route i see the following benefits : it gets done, with standard UI, with documentation usable by many who need it. If it’s about generic, we could only pick up fields from erp that are standard like patients total outstanding amount, current visit’s outstanding amount. We could also push implementationish stuff if there is to default config as this could be something on the BMI generation lines i think which we have in default config and documented on wiki.

What do you think of these options and what could be other such generic features?

4 Likes
2

Further discussions on this is required.

3

Hi @ramashish, I looked at that thread. In that you are furthering the hardcoding that exists by adding support for one more specific order/encounter type, whereas here i am suggesting removal of the hardcoding for specific order types.

1 Like
4

That can be handled by processing concepts under “All Orderables” in a similar manner.

When I tried to create a new order type by setting it in order_type table and attaching the concept class (order_type_class_map) as mentioned here I get error in Angular code. I will look into the same and try to make it applicable for all orderables.

5

When I try to set order_type and map it to concept class so that it appears in “Orders” under “Consultation” as shown in the image (List of Consultants), I get error while saving the order.

image
image1202×402 40.9 KB
I am investigating it further.