I feel your pain Craig. We have 65,000 (and growing) Part master records (less than 20,000 are purchased - so remainder all have rev controlled MoMs). I wouldn't trade it for uncontrolled 'on the fly engineering'.
Yes: Job details can be appended selectively using 'get details' actions. The only limit is once an Op Dtl is reported in process, your ability to edit it is limited at best. The same for Material details: If a part is issued, you can't just delete the part from the job details and replace it with something else. (You would have to return it to stock and then make your edits.)
That is true (in virtually ANY system) whether engineering makes the changes at the part/rev/method (and production control adjusts the job details to suit the ECO) or if engineers are given direct job detail editing access.
I honestly see no benefit from not retaining the systemic seperation of engineers WB and job entry. ECO workflow can then provide the mechanism for notification of the need for changes, and a response after completion of those changes.
If you are 'cornered', and simply MUST give engineering direct job detail editing access, do yourself a favor and roll out a customization of Job Entry (accessible only to engineers via their enabled menus) that has greatly pared down capabilities. Example: Perhaps no Op Dtil tab (unless your engineers know equipment availability & capabilties better than your planner/schedulers) as your email seemed to suggest it was more a BOM editing need than a full MoM editing need.... Hide all Job Date and scheduling code editing controls. Hide (Job) qty editing controls. Perhaps hide Firm, Release controls. Point the simplified customized version of job entry to an appropriately deactivated customized Scheduler submittal form, etc., (and, if possible, do the same for traveler printing).
This isn't as daunting as it might sound as it is simply a matter of entering customization mode, selecting a screen control object (or a group containing multiple objects) and setting the Visible attribute to False in the attribute display pane. Everything is still there, the user just can't access it (making it easy to 'undo' if you are overzealous at hidng controls). Just remember to save as a new named customization (and export to XML for a secondary backup).
Either way (using the system seperation of roles paradigms and corresponding applications as designed - or deploying multiple role specific customizations) will work.
Just be aware that installing dot level upgrades sometimes requires review (if the initial methods used no longer work as a result of control object or db structure changes) and re-enabling of customizations. It is not quite as painless as epicor sales might have led your company to believe.
Good luck!
Rob Brown
Craig Weiss <cweiss@...> wrote:
Thank you very much for your perspective on the situation. I tend to
agree with you. However, Epicor really sold my company on the ability
to do on the fly engineering (I started shortly before
implementation, so I missed all the sales pitches and planning.). We
migrated from Manfact, and had over 40,000 parts in our partmaster.
Epicor sold everyone here on the big benefit of not having to create
parts in the partmaster, unless we intend to use them frequently, or
stock them. On the upside, our partmaster contains roughly 8,000
parts now.
I have one question on your suggestion. What process would you use to
update the BOM on a job if it were already being manufactured (i.e.
materials received, labor entered)? Does a get details update the BOM
in this situation?
Thanks again for all the information,
Craig
--- In vantage@yahoogroups.com, Robert Brown <robertb_versa@...>
wrote:
and "Scheduling" (and execution) activities. That is the whole point
of Rev control check in/out approved/unapproved ECO group actions in
Engineer's WB.
most - environments) - but it does force a relatively strict,
repetitive, secure process (that can made somewhat more digestable if
you set up ECO process flows to insure communication/reply workflow).
environment and changes are often requested by customers (and out of
the loop engineers) even as a product is being packed for shipment.
fulfillment changes?
change that culture of thought).
offer.
Looking for last minute shopping deals? Find them fast with Yahoo! Search.
[Non-text portions of this message have been removed]
Yes: Job details can be appended selectively using 'get details' actions. The only limit is once an Op Dtl is reported in process, your ability to edit it is limited at best. The same for Material details: If a part is issued, you can't just delete the part from the job details and replace it with something else. (You would have to return it to stock and then make your edits.)
That is true (in virtually ANY system) whether engineering makes the changes at the part/rev/method (and production control adjusts the job details to suit the ECO) or if engineers are given direct job detail editing access.
I honestly see no benefit from not retaining the systemic seperation of engineers WB and job entry. ECO workflow can then provide the mechanism for notification of the need for changes, and a response after completion of those changes.
If you are 'cornered', and simply MUST give engineering direct job detail editing access, do yourself a favor and roll out a customization of Job Entry (accessible only to engineers via their enabled menus) that has greatly pared down capabilities. Example: Perhaps no Op Dtil tab (unless your engineers know equipment availability & capabilties better than your planner/schedulers) as your email seemed to suggest it was more a BOM editing need than a full MoM editing need.... Hide all Job Date and scheduling code editing controls. Hide (Job) qty editing controls. Perhaps hide Firm, Release controls. Point the simplified customized version of job entry to an appropriately deactivated customized Scheduler submittal form, etc., (and, if possible, do the same for traveler printing).
This isn't as daunting as it might sound as it is simply a matter of entering customization mode, selecting a screen control object (or a group containing multiple objects) and setting the Visible attribute to False in the attribute display pane. Everything is still there, the user just can't access it (making it easy to 'undo' if you are overzealous at hidng controls). Just remember to save as a new named customization (and export to XML for a secondary backup).
Either way (using the system seperation of roles paradigms and corresponding applications as designed - or deploying multiple role specific customizations) will work.
Just be aware that installing dot level upgrades sometimes requires review (if the initial methods used no longer work as a result of control object or db structure changes) and re-enabling of customizations. It is not quite as painless as epicor sales might have led your company to believe.
Good luck!
Rob Brown
Craig Weiss <cweiss@...> wrote:
Thank you very much for your perspective on the situation. I tend to
agree with you. However, Epicor really sold my company on the ability
to do on the fly engineering (I started shortly before
implementation, so I missed all the sales pitches and planning.). We
migrated from Manfact, and had over 40,000 parts in our partmaster.
Epicor sold everyone here on the big benefit of not having to create
parts in the partmaster, unless we intend to use them frequently, or
stock them. On the upside, our partmaster contains roughly 8,000
parts now.
I have one question on your suggestion. What process would you use to
update the BOM on a job if it were already being manufactured (i.e.
materials received, labor entered)? Does a get details update the BOM
in this situation?
Thanks again for all the information,
Craig
--- In vantage@yahoogroups.com, Robert Brown <robertb_versa@...>
wrote:
>8.03 is to completely seperate "Engineering" activities
> Personal observation only: Epicor's intended paradigm in Vantage
and "Scheduling" (and execution) activities. That is the whole point
of Rev control check in/out approved/unapproved ECO group actions in
Engineer's WB.
>Materials in a Job directly when you really look at it.
> There is no time savings to be gained by having an Engineer edit
>annoying (as I think it is more intrusive than needed for many - even
> I personally find the ECO group part check out process somewhat
most - environments) - but it does force a relatively strict,
repetitive, secure process (that can made somewhat more digestable if
you set up ECO process flows to insure communication/reply workflow).
>numbering. I've had a few years experience in that type of
> Even in your ETO environment, I assume you use some kind of part
environment and changes are often requested by customers (and out of
the loop engineers) even as a product is being packed for shipment.
> * -traceability of these inevitable post order acceptance/pre order
> Wouldn't using ECO groups & Part Revisions give you better
fulfillment changes?
>Epicor?)
> (What are you really gaining by 'fighting city hall': a.k.a.
>*just*in*case* - but they rarely do (and it is a management issue to
> I know everyone thinks they need access to everything
change that culture of thought).
>selected by your company), I don't really have any work arounds to
> Other than adapting to the Epicor process (otherwise - why was it
offer.
>builds most
> Rob Brown
>
>
> Craig Weiss <cweiss@...> wrote:
> We are primarily a custom manufacturer, so engineering
> BOMs on the job directly. Once they are done, they notify ProdIf
> Control, and Prod Control adds operations and schedules the job.
>
> In our test environment, I set up process security for bo.jobentry
> for method changejobheadjobengineered. It gives an access denied
> error message to anyone who is not in prodcontrol that try's to
> engineer or unengineer the job, but it changes it in ayway. Am I
> missing something?
> Craig
> --- In vantage@yahoogroups.com, Robert Brown <robertb_versa@>
> wrote:
> >
> > Who else besides production control needs ANY editing access to
> Jobs? (Engineers?... Perhaps to create custom details on the fly?
> so, that can be handled by having engineering create the customMoMs
> under a Part number Rev in Engineers WB.)grey
> >
> > Everyone else should really only need read access via Job Tracker.
> >
> > Rob Brown
> >
> >
> >
> > Craig Weiss <cweiss@> wrote:
> > We are trying to set it up so that only Production
> Control can engineer
> > and release jobs. I used Field security to give the prod control
> group
> > access to those 2 fields. However, now everyone else just sees
> > boxes. I wanted everyone else to see job status, but not be ableto
> > change it. Is there a simple way to accomplish this? I assume IMobile.
> could
> > do it through a BPM, but I haven't used that functionality yet.
> > Thanks,
> > Craig Weiss
> > Peerless Mfg Co
> >
> >
> >
> >
> >
> >
> > ---------------------------------
> > Be a better friend, newshound, and know-it-all with Yahoo!
> Try it now.Search.
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>
>
>
>
> ---------------------------------
> Looking for last minute shopping deals? Find them fast with Yahoo!
>---------------------------------
> [Non-text portions of this message have been removed]
>
Looking for last minute shopping deals? Find them fast with Yahoo! Search.
[Non-text portions of this message have been removed]