If the dates are different it will pick the most recent one. But if the dates are the same, then it goes by the most recently checked back out. I have parts with multiple revisions and different dates. And the one with the most recent date is what got picked every time.
Epicor should have included the Rev as a key in the PartCost tables.
1 Like
I think they went with the assumption that you should be using one revision at a time, so it’s simpler to not have even more things to worry about. I can see the argument both ways though.
@Will79 - Check out this thread about checking parts in and out every night. Seems they had to do something to make sure the desired rev was being used … 
I agree that the vast majority usually only has one rev approved at a time. Especially for your own products. But if you’re a job shop, you may have customers that want to buy their prior rev, or have two revs active for a while.
But I think the argument would be that if you need to store that much different stuff, cost, methods, etc. Why not just make them different part numbers? There already is a substitution mechanism in place to show which parts can sub for others.
3 Likes
We are a print company and we use revisions for the same part but may be a different shape,a s an example. For our stock products, there is usually only two revisions, as those are very standard. And one of those revisions we disable before we run Cost Roll up. But there are a few that have three, with one being disabled. So, this info really helps me understand Epicor more and now I can make recommendations on how we do things going forward.
1 Like