stock periodical inventory report missing

Registered by Ferdinand

To count the products usually one needs a piece of paper to go out into stock location and physically count what's THERE. No computer available.

Usually one or often 2 persons have to sign this "inventory" to testify the correctness.

Blueprint information

Not started
Needs approval
Series goal:
Milestone target:

Related branches



--- 20110125 philu
Here is a good stocktake/periodical inventory/physical inventory procedure (which doesn't necessarily the procedure done in OpenERP, at least not yet): I will use the term "stocktake" here, but it means the same as "physical inventory" or, in OpenERP's case, "Periodical Inventory".

1. Start the stocktake: make records for what stock will be counted.

2. Print the forms on which to record the counts. This step should be optional, as people may have hand-held computers and so not need to print the forms. This is the step that this spec wants done.

3. Freeze the stock counts: record a snapshot of all the current quantities on hand, and cease processing of sales and purchases and transfers, at least those steps that update stock quantities on hand.

4. Physically count the stock, recording the counts on the forms printed from step 2.

5. Unfreeze processing, i.e. sales and purchases are now allowed to resume normal operation.
The time between steps 3 and 5 should be as short as possible so as not to hold up the business.

6. Key in the data from step 4. This can be done some time after step 5; it does not matter.

7. Print off variance reports that show the difference between the quantity on hand as it was at step 3, and the counted quantity, and print of reports that show that all counts have been entered off the forms.

8. Update stock: generate stock adjustments, the adjustment quantity being the difference between the physical counted quantity from step 4, and the frozen quantity from step 3.

9. The stocktake is now finished.

So I suggest there be a report that should print out:

- the product and its description and barcode
- the location of the stock
- the current quantity on hand - optional
- a blank area in which to write the counted quantity on hand
- an area on each page to record who did the counting, and perhaps who checked it

---- 20110125 ferdinand
* freeze mentioned will not work for large installation, we should have a solution that allows shipping regardless if inentory is taken
*** as we have a calculated "inventoy" quantity we can compare this quantity against the counted and post differences against this instead against the current.

* in another installation an inventory take was triggered automatically if calculated real quantity = 0 (zero) - it's easy to count and to confirm.
* only those products without real inventoy take during a certain period must be handled as described above.
* products were classified in "inventory" categories which determine the frequency of inventory takes
** monthly
** quatery
** yearly
depending on the importance (value, possible maximum error) for the organization (and legal/fiscal requirements

---- 20110127 philu
1. I agree with fredinand's point labeled ***; this is what I meant. I agree with all the other points to, except the one about freezing, as discussed next.

2. Do you have a better method than the freeze method? If so, what is it? If it helps, here's an essay on the issues of counting stock: You're right about the freeze method being wrong; it should be that processing of sales orders can still proceed IN THE SYSTEM, but it's the PHYSICAL ACTIVITY in the warehouse that must be frozen, or must be accounted for manually, so that the physical counts are accurate. I'll explain in more detail:

Let's call the time that the system records the quantity on hand as Point A and the time that the physical count is recorded on paper as point B. Ideally, these would be the same point in time; in reality, they wouldn't be.

(Point C is the time that the physical count from point B is typed into the computer. You can have any reasonable amount of time between point B and C without any problem as you know the quantity on hand at point B, assuming of course that Point A = Point B or that the quantity on hand at A did not move until point B in time. Point C isn't a problem, but I've described it here just for completeness.)

Between Points A and B, any physical function that will affect the count of the physical stock has to be stopped or accounted for, so you must freeze your warehouse activity and do the counts then resume warehouse activity; this is reasonable.

Note that you can still process sales orders in the system, but you can't physically do those orders in the warehouse because that would corrupt your count, unless you capture that activity, as described here: If you don't freeze those warehouse functions while you do your count, then staff must write down, on some slip of paper, the quantity of stock that they removed or added, so that these can be factored into the physical counts later at point B, so that the stock at Point A can be calculated and used as the physical quantity counted.

Maybe there is an alternative approach: instead of making Point A in the computer match point B in physical reality, you make point B match point C, i.e. you must not do any updating of computer quantities on hand between the time the count was physically taken and the time it is entered into the computer.

Either way, you have to tell the computer what the physical stock at a particular point in time was, with enough accuracy that the computer can tell what sales or purchase or transfer orders were adjusted before or after it, accurately, i.e. if the stock count was recorded at 11:00am and a sales order was also shipped at 11:00am, we'd need some way to resolve that.
Also, we'd need to know of all orders actually shipped physically but not yet entered into the computer, or vice versa.

So I'm interested in your reply.

---- 20110127 ferdinand
I agree with your concerns about "freezing"
IMHO the last chapter points in the right direction, especially if electronic devices (scanner) are used to take inventory including a timestamp.
what I want to say is that the system should be designed to allow this, even if the comany is not using it. It must be up to the decision of the company how to handle this.


Work Items

This blueprint contains Public information 
Everyone can see this information.