|
Eric, I would find out first why the client feels they need EPDM. Why? Because the integration with the rest of MAPICS is spotty, incomplete and of course buggy. If they have the staff and are willing to impose rigid discipline it can work. But forget about stocking or buying revisions, that was never implemented. Realize, unless they have fixed this, when you release an order if two lower level parts are both effective with different revisions order release will pick the first revision it sees. Also be aware that none of the third party applications have been made EPDM friendly (the biggest one is Paperless). So there is a safe path, hopefully one that agrees with their needs. Converting programs is nasty because of the multiple effective revision problem. Because effective date and revision are a matrix any queries other than very basic ones will have to be converted to programs. EPDM stable? Never, we still get smalltalk errors and had the aforementioned inability to delete items at client rev 30, now fixed in 33. It is far more stable than it was originally. Throw a big 400, big pc and lots of memory at it and you will minimize the issues. The green screen EPDM is pretty good if you get all the fixes to it but it does still not have some of the old inquiry functionality. Of course you do lose the ability to do green screen maintenance on item master and the manufacturing files. We have EPDM active in one of our 3 environments. One suggestion, since Revision is alpha, adopt a naming convention that sorts correctly. In an alpha field Rev 2 is higher than Rev 11, so adopt a convention of 0002 and 0011 if you need to see the highest level. Second suggestion, package changes and rev the highest level when the changes are implemented. It is not necessary but makes the output more correct, less ambiguous and far easier to understand. Third suggestion, because writing a BOM retrieval routine is a bitch use the built in program AMDPSR0R to do the retrieval. Note even with that we still need to filter the retrieved records for effectivity. Fourth suggestion, always allow operations to complete before starting a second operation. All EPDM updating is in batch and there are a few operations that require serialization that EPDM does not enforce. Good luck! Konrad -----Original Message----- From: Eric Wolf [mailto:eric_a_wolf@xxxxxxxxxxx] Sent: Tuesday, April 01, 2003 11:41 PM To: MAPICS-L@xxxxxxxxxxxx Subject: EPDM implementation / other application questions To the list, I am working with a client that is ready to implement EPDM. Could anyone who has already done this give me some feedback on what to look out for. How much work did it take to migrate custom programs and queries to use the new file structures - primarily the Items and BOMs? Is it a "slam-dunk" converting the programs? Just replace the files and field names or did adding Site and Rev complicate it just a bit. Is EPDM pretty stable? Are there any functions that do not exist in EPDM that did in "green" PDM? Application questions: AM/Plus - is it completed to the point that ALL AR, AP and GL functions can be done in the application - Cash Posting, AP Invoice entry and payments, GL Journal and Reporting? Can users be secured by Company? AM/AR, AM/AP, AM/GL - I was told that these applications can now be secured down to the company level in "green screen". Did I miss this announcement? COM/IM - Has anyone tried the Data Security on Warehouse or Company? How did that work for your company? If I am not secured for a warehouse, does it block me from Item Balance inquiries using that warehouse; or enter orders against that warehouse/company? All help would be greatly appreciated... Thanks in advance... Eric A. Wolf _______________________________________________ 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.
midrange.com
