I have implemented a Stocktake suite as follows:

1. a Stocktake Export report that builds a spreadsheet that you can use to enter the stock counts - below are the first few lines of one where the product selection was 'RC %'

This is actually after the count was done - ie there were 17 of the first item and 1 of the 5th. [The ProdID's have a leading G(=goods=merchandise) so that the kettle program knows whether this is merchandise or medication.]

2. a Stock Movement report that you can use for checking movements between the time you ran off the above sheet and the time you actually counted the items. If there are any, you need to increase you Actual figure to include the quantity sold (or decrease if there was a delivery).

3. a Kettle job that processes the above csv file and generates an in-progress Stock Adjustment containing the necessary quantity updates.  Having done a quick check of the line items, you then Finalise the transaction to apply the adjustments.

Question:  Is this a reasonable way to run a stocktake? Note that it allows for the classic "slaves do the counting then logistics checks the data for any funnies (ie large discrepancies)".  It also allows you to do partial stocktakes - if there is no entry in the Actual column, the Kettle job assumes that you did not count that item.

Note that this post is here because I am considering initiating a project to replace the Kettle step with a built-into-OpenVPMS csv Import facility that will build the Stock Adjustment for you.

If this goes ahead, should there be an Export function to replace my Stocktake Export report? My feeling is No but others may think differently.

If we build a Stock Adjustment Import facility, should there also be a Stock Transfer Import facility? (This would allow one to generate/build spreadsheets to do mass transfers  - as well as doing simple movements of stock between stores, one could also use this to write off blocks of stock.)

I agree that one can build both Stock Adjustments and Transfers item by item, but data entry into a pre-prepared spreadsheet is a lot faster.

One final question: does anyone else see the need for a Stock Conversion facility.  This would be used to either convert N xxxx's into N yyyy's or (where you are breaking down boxes of stuff), N xxxx's into NxM yyyy's.  [In an earlier life, the last stock control system I wrote, achieved the conversion by transferring the from items (the xxxx's) to a 'Conversion-Out' pseudo store, and then transferring to items (the yyyy's) in from the 'Conversion-In' pseudo store.]   Again one can do this using back-to-back Stock transfers in the current system, but it would be nice to have an actual Stock Conversion facility - again with a csv file Import option.

Any comments appreciated.

Regards, Tim G