RE: Move Transactions....

[Chris.Kosieracki@xxxxxxxxxxxx]

The scenario I described should work regardless of whether the first (or
other preceding) operation is finished before the next operation is started
as long as they enter the operation quantity that they completed and/or
scrapped when they do their OF transaction. Those quantities can be stored
and used for the validations at subsequent ops.

Or maybe I don't really understand the problem...

Contact me offline if you'd like to discuss details.


-----Original Message-----
From: mapics-l-bounces@xxxxxxxxxxxx [mailto:mapics-l-bounces@xxxxxxxxxxxx]
On Behalf Of LeLeux@xxxxxxxxxxxx
Sent: Monday, January 26, 2004 4:54 PM
To: MAPICS ERP System Discussion
Subject: RE: Move Transactions....

Thanks, but my problem is when they advance to the next operation(s) 
before the first is complete rather than letting the parts wait till the 
previous op is finished.

Supervisor intervention isn't practical, although you think it would 
be.....

I'm gonna re-tailor the test env to not have moves and see how that flows.

Thanks....I'll keep pondering.





Chris.Kosieracki@xxxxxxxxxxxx 
Sent by: mapics-l-bounces+leleux=shur-lok.com@xxxxxxxxxxxx
01/26/2004 02:09 PM
Please respond to
MAPICS ERP System Discussion <mapics-l@xxxxxxxxxxxx>


To
mapics-l@xxxxxxxxxxxx
cc

Subject
RE: Move Transactions....






Have you considered eliminating the MOVE transactions but instead
implementing all of your quantity validation processing within the 
HighJump
system? We have some customers that build in validations to compare
operation quantities to what was reported at the previous operation minus
scrap, etc. That way you're not bound by the order quantity but rather 
what
was completed at earlier ops. For the first op you could also require some
supervisory override to allow producing beyond the order quantity, if
desired.

-----Original Message-----
From: mapics-l-bounces@xxxxxxxxxxxx [mailto:mapics-l-bounces@xxxxxxxxxxxx]
On Behalf Of LeLeux@xxxxxxxxxxxx
Sent: Monday, January 26, 2004 3:24 PM
To: MAPICS ERP System Discussion
Subject: Move Transactions....

I'm gonna try one more time, can't believe I didn't get a single reply, 
not even a flame!
Maybe it was my subject choice.......so here it goes again, thanks in 
advance!




For as long as I can remember we have used MOVE operations following the 
CLOSE (Stat 40)
of an Operation.  This has worked well, but in part of the shop we are 
encountering some problems
related to work centers needing to start subsequent operations (more than 
just the next op sometimes)
and how to manage the MOVES, especially relating to what quantity to 
enter.

Ultimately I'd like to eliminate the MOVES, but the problem is that we 
perform some validation based
upon the move-in quantity compared to the Qty Complete to Date + Scrap to 
help ensure the close-out
quantity is accurate (+/- 12% margin) and this is where we are having the 
problem on the practice
performing MOVES before the previous operation is closed.

If your current operation is for 500 pieces, after you complete, say 100, 
move that quantity to the next
op, and to the next op when those are complete.  This results in 3 active 
operations (that's ok) but there
is real confusion as to what the practice should be on the quantity 
moved-in.  If they only move the
first 100, then the count is inaccurate, certainly for validation.  Also, 
if they estimate the complete
quantity then that could lead to validation errors.  Bear in mind we do 
incur scrap, which is why I don't
use the MO qty, plus some areas 'run out the bar' and exceed the MO qty 
significantly.

To summarize, I'm interested in what some of you are doing, perhaps I'm 
simply over-analyzing?
If you don't use the MOVE transaction, is the QTMVI field in MOROUT 
populated?  How do you
'start' the Op, get it to go from 10 to 20?  We do not allow clocking onto 

a stat 10 op via our
HighJump software and we like this validation to help guide the operators.


Thanks in advance for your opinions.
_______________________________________________
This is the MAPICS ERP System Discussion (MAPICS-L) mailing list
To post a message email: MAPICS-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/mapics-l
or email: MAPICS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/mapics-l.
_______________________________________________
This is the MAPICS ERP System Discussion (MAPICS-L) mailing list
To post a message email: MAPICS-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/mapics-l
or email: MAPICS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/mapics-l.


_______________________________________________
This is the MAPICS ERP System Discussion (MAPICS-L) mailing list
To post a message email: MAPICS-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/mapics-l
or email: MAPICS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/mapics-l.