× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




A few comments on Devin Bowen's missive.

however, 1-step is not necessarily the RECOMMENDED method.  Check with your
accountants - most do not like, do not recommend and will not allow 1-step
cycle counting because if something is MISKEYED, it takes another
adjustment to fix it.

And how is this different from any other transaction?  Most accountants can
deal with reality if you expain it slowly and carefully to them. Sorry, I
like to tease accountants, but this implication that accountants can't
figure out  the need for transactions to fix errors is beyond me.

The problem with 2-step is that it does not  cut down on keying errors.
Only once have I ever been in an environment where keying something twice
has resulted in fewer errors than keying once.  There every transaction was
entered twice by two different people, and only those transactions where
the entries were identical were posted. Expensive but drastically cuts
keying errors (Sadly, even this did not eliminate keying errors). However
2-step does not work this way.

With 2-step you get a chance to miskey when you enter the tag. Then you get
a chance to miskey when you enter the inventory transaction. Now if in two
step, you reviewed the entered transactions, then once review was complete,
posted the previously reviewed transaction. I would agree. But you don't.
The second go around does not post what you have already entered, IT GIVES
ANOTHER OPPORTUNITY TO SCREW UP.  If you transpose the second time, (or
re-enter the transposed figure that was entered earlier, guess what!  It
takes another adjustment to fix it. Obviously most accountants should not
like, should not recommend and will not allow 2-step cycle counting.

The exact same reports are available to find and fix keying errors.  I
would much rather check and see that we have entered the right numbers,
than tell management "Well I checked, and we planned to enter the right
number. Just look at this report!".

the people doing the counting will love 1-step

Yes, heaven forbid the people doing the job, should have any opinion about
how to do the job better. Silly to think they might know.

2-step . . . a little more work but there will be a lot less flip-flop
adjustments since transpositions and bad counts will be caught and
reconciled BEFORE inventory is actually adjusted!

And transpositions will still go into inventory. And bad counts will be
still be caught AFTER inventory is actually adjusted.

Well if you really want to have a lot less flip-flop adjustments, the
easiest way to achieve that goal is to forego cycle counting completely.
Physical Inventories forever! Though personally, I don't care how many
transactions it takes, my goal is accurate inventories.

Actually my recommendation is not that strong. When cycle counts produce a
lot of changes 1-step is better. Fewer opportunities for keying errors. You
only have to rekey mistakes, you do not have another opportunity to screw
up a count that was entered correctly the first time.

But when a program has been in place for a while and inventory accuracy is
where it belongs, there is not much of a difference. You should need to
enter very few INV500 transactions when you have successfully taken charge
of inventory accuracy. So if you have reached this nirvana, and you are
using 2-step, it is silly to change.

Harmon Zieske
Nexgen Software Technologies


+---
| 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
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.