Re: Cycle Count System Development

We are 6101 MM and have never done traditional cycle counting.  I guess it 
depends on your goals and needs, but minimizing dollar variances, which is 
the goal of cycle counting, doesn't necessarily best serve a manufacturing 
facilty.  A missing ten cent shipper can just as easily stop production as a 
missing large dollar component.  And chasing round the entire warehouse or 
warehouses, in our case, in search of certain high dollar parts is just plain 
inefficient.  We also have customer owned components for custom jobs valued 
at zero dollars.  So, what we have always done are mini-inventories arranged 
to count every /location/ quarterly.  This scheme together with a great deal 
of zeal and discipline from our warehouse staff has served to keep our 
location accuracies in the 98-99%  range for many years.  It is efficient  
because we count whole levels of given aisles.  When discrepancies are 
discovered, instead of the easy adjustment the causes are researched and 
transactions are done that should have been done to begin with so that Shop 
Orders, other locations, etc, are kept in balance.  The last resort is a 
'Y' (Cycle Count) transaction.

One of our cost accountants assigns the rows and levels to be counted each day 
and is in charge of reconciliation.  We have a report that prints out a count 
sheet for each aisle-level and another that prints the reconciliation sheet.  
We also have open location reports that can be physically compared with the 
racks easily without machinery.  All locations are bar-coded as are all 
components and finished goods.  We use RF guns for put-away and pulling for 
production.  No back flushing.  Everything is lot controlled and finished 
goods are quality controlled as well.

Vince Rowe
MIS
Marietta Corp.
Cortland, NY



On Thursday 25 March 2004 05:02 pm, Alister Wm Macintyre wrote:
> We are 405 CD mixed mode, modified, and our cycle counts are all ****
> mucked up.
>
> There are two different methods for cycle counting in the BPCS
> documentation, but actually there is more going on there than meets the
> documented eye.  You might want to look at the Cycle Counting documentation
> in the BPCSDOC file for starters, to familiarize yourself with the official
> party line, before getting into nuances of undocumented exceptions.
>
> The challenge here is that for ERP to work right, the PEOPLE have to do a
> LOT of things right, but some people expect BPCS to do the work, and that
> aint gonna work with cycle counting.  You have to comprehend what the ****
> is going on, and have a set of business rules that all your people gonna
> adhere to.
>
> Check your transaction effects and reason codes ... You can use a unique
> transaction and reason for reporting your cycle counting, then if all your
> work force consistent with the plan, you can then use inventory history to
> find the last time you did specific transaction with specific reason.
>
> Check your transaction effects ... do you want date of last activity
> updated just because you found some obsolete parts in your physical
> inventory ... in other words we have not REALLY used this part in 3 years,
> but it shows up as last activity last month because that was our last
> physical inventory.
>
> There is an ABC code in BPCS item some place, where you can set some rules
> for the system to tell you which items to count based on most heavily used
> and how long since last cycle counted.  I suspect that is what you are
> being told does not work satisfactorily.
>
> We have items that we run out of (in actuality) when BPCS says there's
> plenty. The items that sort of thing happens to are those I think ought to
> be cycle counted frequently after we get the new in, to see if we are
> consuming more than BPCS being told about.
> Likewise, I think the items, that show up in physical inventory with bad
> variances, should be flagged for more frequent cycle counting, to see if
> the problem leading up to physical is still going on.
>
> You can create your own report ... show what proportion of the total
> inventory action on some item is due to use in actual production, purchase,
> sales and what proportion is due to the on-hand being fixed with an
> adjustment.  Those items with high proportion of adjustments, would be the
> ones you want to audit.  We had some that were 100% adjustments, the last
> time I ran these "proportionality" reports, which has been some time since
> I was looking into this.
>
> Unfortunately, transferring inventory from one place to another is recorded
> in 405 CD as an adjustment, so this makes report design a bit challenging.
>
> You do not have to use BPCS to determine which items ought to be cycle
> counted. You can send BPCS reports to a PC spread sheet and have your own
> set of rules to determine on what basis items should be cycle counted.
> This PC spread sheet might include all the reasons I cited above why some
> items might be in need of more frequent cycle counting.
>
> -
> Al Macintyre  http://www.ryze.com/go/Al9Mac
> Find BPCS Documentation Suppliers
> http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html
> BPCS/400 Computer Janitor at http://www.globalwiretechnologies.com/
>
> >We are on v 6.04 mixed mode, heavily modified.  Has anyone been able to
> >develop a cycle count program that actually tracks the last time an item
> >was cycle counted and when the item is due to be cycle counted?  My IT
> >department tells me cycle counting in Bpcs doesn't work and it may work in
> >a newer release.  This is too critical to our operation to ignore.
> >
> >Thanks,
> >Brenda Engel
> >574-254-4015 ext. 109
>
> _______________________________________________
> This is the SSA's BPCS ERP System (BPCS-L) mailing list
> To post a message email: BPCS-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/bpcs-l
> or email: BPCS-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/bpcs-l.