Re: inventory reporting -- BPCS-L

> Subj:  Re: inventory reporting
>  From:        whdecair@countryfresh.com (Wendy DeCair)
>  
>  Hi
>  We are running version 6.002 BPCS CS.
>  My company produces milk and other just in time dairy products.  At any
>  given point in the day we may be taking orders and producing milk with 'no
>  inventory'.  The order program is from a third party vendor with an
>  interface written to affect inventories as items are ordered, then  picked
>  and then sold.
>  Here is the problem:  we have tried to do cycle counting but once an order
>  is ready to be picked it is immediately relieved from the BPCS inventory
>  total.  We may have the product in the cooler when the count was taken, but
>  by the time we get ready to key  in  the count, 400 transactions have
>  occured.  If you use one step cycle counting it doesn't total up all the
>  transactions for you and we only have a one hour window to get these keyed
>  into the system.  Our clerks don't have time to recalculate the count for
>  each and every item.  Has anyone used a different transaction or
>  modified/created a new cycle counting program?  What I think the cycle
>  counting should do is create an onhand balance at the time the cycle count
>  sheet was printed and let me work toward that balance not the balance at 
the
>  time I key the count in.
>  Any recommendations.  This is seriously hampering our efforts to expand our
>  use of BPCS.
>  
>  Wendy DeCair
>  Country Fresh Inc
>  Suiza Foods

I agree - we theoretically live in a world of continuous transactions that we 
want posted as real time as practical, but there can be lag entering the 
transactions to the computer, so when the cycle count document is printed, it 
does not show the actual transactions that took inventory out of the location 
but have not yet been entered into the computer, so you want to flag your 
cycle count cut-off when there is a real break in the inventory flow, like 
lunch time, or shift change, and have all transactions accurately reflect 
WHEN they occurred - not time of key in, but time stamp like the shift they 
occurred.

There might be a potential for modification of the physical inventory tag 
file - a tag is created for a particular warehouse location item & at time of 
creation the modification might plug in the actual on-hand, to some field, 
that the computer thinks is there.  When you key in what you think is really 
there when you did the count, you want a calculated change to inventory 
against the plugged in value, not what is there at the time the tag is keyed 
in.

A problem with this thinking is that it assumes all inventory float is in 
lock step off-set - are all inventory transaction types posted with the same 
kind of delay?  In our case we post all labor transactions in one batch for 
24 hour period, sometimes not until the next day, so inventory receipts are 
more timely, during the day.  Thus the flow of posting should be considered 
when selecting items to cycle count, possibly flagging items after the labor 
is updated, either before or after any shipments for the day, so you know 
whether or not they are a factor.  Perhaps the receiving clerk should launch 
the cycle count flag at a point in time that there is a break between 
deliveries.

Perhaps we need the act of printing the cycle counting tag to simultaneously 
write a zero comment transaction to the inventory history, so we can track 
what transactions get posted between the time the tag is printed & the time 
someone tries to key in what they counted.

Al
+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---