Ordering & Stock Tracking of Consumables

Hi,

I am wondering if anyone uses OVPMS to manage consumables stock (i.e. items that are not billed to customers) and how you make this work?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: Ordering & Stock Tracking of Consumables

We have a setup where a) invoice line items are grouped (and ordered) by product-type; b) there is a specific product type 'No Charge' which is set (in the product type) as 'Detail on Invoice' = false; c) the invoiceitems.jrxml is set to not print any No Charge stuff.

So any non-chargable consumables can be happily entered as one enters the invoice line items so that their usage is tracked but the customer never sees them on the invoice.

Regards, Tim G

Re: Ordering & Stock Tracking of Consumables

Hi Tim,

Thanks for that. I guess I am thinking about this in a different way.

Lets take the example of swabs. We use heaps of swabs, order them from the same place each time. We don't charge out swabs as this is impractical. In fact I don't even really want swabs appearing on the product list when people are invoiceing is it would be a distraction and we would need to have hundreds of items in the product list that people don't charge out. This would lead to confusion and charging errors.

So basically I can't seem to have swabs in OVPMS for ordering purposes without them and all their related consumables (from ET tubes through to ultrasound gel) also being there. Thus creating a product list from hell when vets are charging out. It also begs the question of how to track levels of this stock and add this into the system to allow automatic ordering if we wanted to achieve that.

Re: Ordering & Stock Tracking of Consumables

OK- we have a couple of requirements: a) the stuff has to get 'used' - but as automatically as possible; b) the stuff has to get hidden as much as possible.

Can I suggest that a) can be addressed using product templates - so for an example, calling up the xyz operation as an invoice line item magically expands to multiple items including 6 swabs and two pairs of gloves etc.. b) can be addressed by appropriate naming in choices.  For example if all the junk stuff (like swabs) is named with a leading underscore (eg _Swab) then these will be 'out of sight' down the back end of the product list.

This combined with the 'No Charge' product type should do the trick.

 

Of course there is the alternative - don't track usage of these types of items (ie don't invoice them in order to have their usage recorded). Instead, do as follows:

  1. create a stock location 'Consumable Usage' not linked to any practice location (see the 2nd last bullet point in http://www.openvpms.org/documentation/csh/1.7/concepts/stockControl)
  2. on order day, look in the xxx parts bin in the store room to see how many xxx's are left - say 3
  3. look at the stock holding for part xxx - humm says 43 - hence have used 40
  4. enter a stock transfer to 'Consumables Usage' for 40 xxx's [you could just do an stock adjustment but doing the transfer leaves a better trace of the consumption - you just look at the qty in stock at the 'Consumables Usage' location]
  5. now run the order generation - the system will see that xxx's are low and will reorder

If you ever want to do a 'how much stock are we holding' report - be sure to omit the 'Consumable Usage' stock location - this contains what has been used, not what is on hand.

 

Hope this helps

Regards, Tim G

Re: Ordering & Stock Tracking of Consumables

Thanks Tim,

I think this is workable. Trying to see where things can go wrong to pre-empt problems... Where I can see holes in the system are:

- We still end up with a very large product list when invoicing and potential for selecting consumable items rather than items for invocing is high (esp when searching using a wildcard search).

- I love the idea of line item invoicing but it would make checking large invoices very difficult (if single template item expands into 5 different consumables we would end up with massive invoices for patients that are in hospital multiple days). It will be hard to check to make sure charges have been applied correctly. I don't think this is the way to go for us.

- The no tracking alternative would probably be the most workable option. Where I can see it going wrong is the maths (working out how many we have used). This is one step I am 100% sure will be stuffed up. So I guess using the stock adjustment option would be the way to go for us (i.e. just count how many are there).

Question - If we go the route of just using stock adjustments to note stock on hand (so the system can tell us if we need to re-order). Do we need to create a new stock location? Or is this a redundant step?

Also, what are your thoughts on the value of having a new product item "Consumables" that can as a default be hidden from visible invoicing/searching but can be used for ordering/stock adjustments, etc? To me this would solve a number of our issues with clutter. Potential error. It would allow for line item invoicing that doesn't clutter up invoices (that are visible to our staff), etc.

Re: Ordering & Stock Tracking of Consumables

Problems you raised:

a) large product list - putting aside any changes to the system, the trick of naming the consumables you want hidden as _Swab  etc will 'hide' them down the end of the product list, and you should be able to educate your staff not to put any item with a name starting with an underscore on an invoice.

b) stock adjustments rather than transfers - yes I agree that it will be easier to say 'humm 3 left in the bin so adjust stock to 3' rather than 'humm 3 left, system says 41 so thats 41-3=38 used so transfer 38'. Note that tracking usage is not impossible - all we need is a report that prints the stock adjustments done within a specified period.  And no, if you go the stock adjustment route (rather than stock transfer) then you do not need the new dummy stock location. [In an earlier life, in the last stock control system I wrote (in Cobol) we called these 'pseudo' branches (as opposted to the real Canberra, Sydney, Melb etc branches) and we used them to write off stock.]

New product item type: I don't think that introducing a 'Consumables' type of product (to add to services, merchandise and medication) is the optimum solution to having a smaller product list to choose from for invoicing. [If for no other reason than I think that adding a new type of product would require significant changes to parts of the system.]

A better approach might be to directly address the problem - ie how to limit the number of product that one can charge for. We currently have the concept of de-activating things that are no longer in use. Conceptually we need a mechanism to limit the number of 'invoicable' products - ie the products that are displayed when you are searching for one.  One way to do this would be to introduce a level number for products (just like the level number we use to hide reports from those users who do not have a level sufficient to be able to see (and run) the report).  By default the product level is 0 - ie everyone can see it just like now.  Setting the product level to 5 means that only users with level 5 or more will be shown the product.

This facility would allow you to limit the list of products available to 'low level' users - but you (being boss with level 9) can see all. More logically, when you need to look at the whole set, you log in as 'Logistics Manager' who is level 9, by for normal use you login as Dr Bloggs, who being a level 1 person, sees none of the consumable stuff (which is set say at level 5).

This 'hide if product level> user level' feature would only operate for product search. It would not operate to hide a product on an invoice. Ie a level 6 product could only be invoiced by a level >= 6 person, but anyone looking at the invoce would see it. [This is the way de-activated products work - if I invoice xxx and then de-activate it, the invoice line item containing xxx is still there.]

Hope this helps.  Regards, Tim G

 

Re: Ordering & Stock Tracking of Consumables

I found another way to 'hide' products - ie have them not present on the list of products available for invoicing - use the species.

Do as follows:

  1. either choose the most uncommon species you have (I used Hedgehog - we have one customer with 2 of them), or invent a new species _Consumables
  2. for all consumable (or other) items that you do not want to appear on the product list, set their species to '_Consumables' [or Hedgehog ;-]

Now provided that you have a patient (who will have a species), the list of products available to be invoiced will not include any with their species set to _Consumables.

I do admit that this is a kludge - but it is a 'hide method' that can be used today.

 

Regards, Tim G

Re: Ordering & Stock Tracking of Consumables

Hi Tim,

Thanks for that. It seems a better method for the current point in time and is probably the way I will go once we start to use OVPMS for stock tracking and ordering.

I am not a programmer so I accept what you say about adding a "consumables" stock type as being difficult. It just disturbs my silly mind when I don't have a nice appropriate "Catagory" to put things in!

The user permissions idea seems a good way of controlling this.

Thanks,

Adrian

Re: Ordering & Stock Tracking of Consumables

Adrian - if you want the "suppress product if it's level is greater than user's" facility then a) we need Tim A to create a project for it and cost it; and b) you need to pay for it.  This is not a facility that EIAH needs (though I can see it being useful) and having pumped some $5400 into the OPV coffers for 6 different 1.7 features/improvements and many many hours into generating the Context Sensitive Help text, I will not be recommending that EIAH fund it.

Regards, Tim G

Re: Ordering & Stock Tracking of Consumables

Hi Tim,

Yes, understand that. We will need to chat about it on our end as likely we have greater priorities for our next funding contributions (the user preference project once finalised, auto-logout implementation and audit/medical records lockdown projects).

In the short term I will try the Hedgehog trick until we can fund a more elegant solution.

Syndicate content