Here’s the other option, if it’s truly so custom, then just build a make to order job, and just use parts on the fly and build the methods on the job.
2 Likes
There is another option we’ve been playing with. On the Part Maintenance screen, in the list of checkboxes on the right side of the window, is one called “Use Part Rev”. This is enabled in the application by default. Having that checkbox checked FORCES Epicor to select the most current revision (by effective date). If, however, you UNCHECK that checkbox, you can enter any approved revision you like in the Sales Order and it will stay there. You can even force (via BPM) all your parts to default to revision VT if you like, and as long as the checkbox is UNCHECKED it will hold.
2 Likes
@Ernie, I think they dont want to enter VT at order entry. They want it to populate.
If you generic Revision is VT with Effective date 3/1/2019, the who ever is creating the new revision needs to set the new revision effective date to 2/1/2019. Would that work
IF your Generic Revision is VT for all part numbers, a BPM to populate VT at the revision field/
1 Like
And I don’t mean to beat a dead horse, but you should let management know that you have the same number of “parts” you are just hiding them in revisions. If you need logical groupings, it would probably be better use product groups or grab an attributes field to put in the “part number” as you are using it, and then your new part numbers are what they are used to seeing as “revisions”. Then you can create search functions to find them easily. That way you aren’t trying to wrestle with Epicor since what Epicor views as a revision isn’t what you are using it as.
Anyways, just some ammo to use if you want to try to use the system as designed, because that usually works out better in the long run.
1 Like
Which method would be best to use for this?
Having a “base” part and then customized versions is what the Configurator module does best.
3 Likes
I agree with having individual part numbers as well. We are highly customized automation and most part numbers are unique to the fabricated part. Part numbers which tie to commercial items like circuit breakers are only unique if they have multiple manufacturers, because that makes it easier for us instead of maintaining multiple manufacturers for one part number in the system. More part numbers are not that bad. You need to convince them of this, then the customer can call back to get their part if they do.
Having multiple approved versions of a part number is best applied to when a customer buys a an item from you. Then changes it and now they regularly want to buy rev B. But occasionally still want to be able to buy rev A.
Currently, we have our Part that is the base as shown in the catalog. The revisions are for things like round holes vs square holes, sizes, shapes, etc.
From my testing, it looks like the most recent Effective date is used. But not one in the future.
For example: A part with following revs is entered on a SO:
The SO defaults to Rev 3, as it has the most recent Effective date that has not yet passed. While Rev 2 has a newer Efeective date, it is not yet 3/22/2019.
On the plus side, Effective date can be changed right in Part (no checkout or Eng Workbench required), as long as the revision is unchecked.
Since I don’t have the scheduler, I’d make a PowerShell script or batch file to run DMT via the command line, and schedule that task to run every day at 12:01 AM.
I did a test with DMT, thinking I just need two or three rows. The first to make the rev Inactive, the second to set the date and the third to make is active again.
But DMT seems to combine the lines into one update, and doesn’t work.
If I run DMT 3 times: 1) Make inactive, 2) Set Effective Date, and 3) Make Active
it works.
1 Like
When you say active, do you mean approved?
I am just running DMT for Effective date and it seems to be changing it correctly.
2 Likes
I assumed that wouldn’t work, as the Effective date field is disabled when Acitve is checked.
That’ll teach me to assume the locking was via the business object, and not the UI.
1 Like
DMT handles the approve/unnaprove. It does the same with engineering workbench stuff.
1 Like
yes.
I’ve had a few brain farts lately with mixing up “enabled”, “active”, “inactive”, “approved”, etc…
1 Like
Just find it odd that in the UI, the Effective Date for a rev can only be changed if the rev is not approved.
Can I change the part description of a closed sales order via DMT (without first re-openeing the order and line)?
I don’t think so. But you would have to try it. Effective date is something that is more like to need to be managed, so I think that’s why they programmed the logic to be able to handle it. You have to remember that DMT isn’t just a copy paste/excel tool. It’s trying to align with the Epicor BO logic, so different situations will have different solutions based on what’s trying to be accomplished.
1 Like