|
Hi Dale, Not that I know of. They used to have an informal relationship, but that changed with MDCC being added from ISI. Kronos was/is OK. DCSI/Highjump has additional functionality that was the reason we chose it consistently over Kronos. Just a quick example was the ability to barcode pallets and split/pallets plus cross-docking and more. I've worked very closely with the paperless product resently, and am very impressed. High quality too. Kevin kdfox@xxxxxxxxxxxxx -----Original Message----- From: DaleGindlesperger@xxxxxxxxxxx [mailto:DaleGindlesperger@xxxxxxxxxxx] Sent: Tuesday, January 27, 2004 9:54 AM To: MAPICS ERP System Discussion Subject: RE: Move Transactions.... OK, I heard of DCSI. For me, in the early 90's, it was between DCSI and Kronos - I had picked Kronos. Worked well for me through the 90's, changed to MDCC (Paperless) in 2001, works even better. Does Highjump have a relationship with MAPICS as an "approved" partner? Dale Gindlesperger IT Manager/Special Projects Leader Fleetwood Folding Trailers, Inc. 258 Beacon Street Somerset, PA 15501 "Kevin Fox" <kdfox@dslextreme. To: "'MAPICS ERP System Discussion'" <mapics-l@xxxxxxxxxxxx> com> cc: Sent by: Subject: RE: Move Transactions.... mapics-l-bounces@m idrange.com 01/26/2004 10:35 PM Please respond to MAPICS ERP System Discussion Highjump used to be DCSI. As a user, I implemented them in the late 80s and they have only gotten better over time. As a consultant (I don't miss those days) in the 90's, I implemented at least a dozen sites, all successful. Kevin kdfox@xxxxxxxxxxxxx -----Original Message----- From: DaleGindlesperger@xxxxxxxxxxx [mailto:DaleGindlesperger@xxxxxxxxxxx] Sent: Monday, January 26, 2004 8:12 PM To: MAPICS ERP System Discussion Subject: RE: Move Transactions.... Interestingly enough, this is the 2nd mention of HighJump I heard today (other on a phone call), and I've never heard of it before. Is it a MAPICS add-on that I've missed hearing about or seeing at the MUC? Dale Gindlesperger IT Manager/Special Projects Leader Fleetwood Folding Trailers, Inc. 258 Beacon Street Somerset, PA 15501 Chris.Kosieracki@xxxxxxxxxxxx Sent by: To: mapics-l@xxxxxxxxxxxx mapics-l-bounces+dalegindlesperger=fft-inc.com@m cc: idrange.com Subject: RE: Move Transactions.... 01/26/2004 05:09 PM Please respond to MAPICS ERP System Discussion 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.
As an Amazon Associate we earn from qualifying purchases.
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.