We have part A, which when on a BOM or purchased, always should have part B. Is there a way in Epicor out of the box to flag this and have it alerted?
Is there a way to purchase what would look like a sub-assembly?
Part A
Sales Kits, CO-Parts, and Alternates do not seem to satisfy this and we don’t want to build anything custom if there is a defined process for this already.
We are on 10.1.600
there is no equivalent to Sales Kits in purchasing in any fashion unfortunately in 10.1 any version. I can’t speak to anything 10.2 and above.
We are scheduled to move to 10.2.300 in our test environment in the next few weeks. Hopefully the surprises we encounter are of the positive, feature adding kind 
Anyone with 10.2. see anything like this?
Shouldn’t that requirement be defined in your demand before it gets to purchasing?
It should be, yes, but sometimes it gets missed. There are a bunch of parts that have complex dependencies on each other.
What I am looking for is if there is a way to help users “remember” these parts are related, just like Epicor helps them remember that this part has been replaced with another one.
I know you said “out of the box” , but …
You could use a UD table with the PartNum’s of the two related parts as the key fields, with a record for each relationship.
You want to include a control so that Key1 always contains the first (alphanumerically) part and Key2 the related part. That way you don’t have “dup” records like:
Key1 Key2
WID-001 TTY-009
TTY-009 WID-001
Other fields could include who and when the relationship was created, last changed, expires, affects purchasing(Y/N), affects jobs(Y/N), etc…
Then make BPM’s that fire when a part is retrieved, and show a notice or something when that part has a related part.
We still want something out of the box but if we do go custom it will look a lot like this. Thanks for sharing how this could work!
In my opinion (take it or leave it), I doubt Epicor would make something like this out of the box. They will say that if they are required together, that demand should drive them to be together. The fix at the Purchasing level is fixing a symptom of demand not being created correctly. The root cause is to make sure the demand matches up.
I’m not saying that a solution like @ckrusen suggested may not help in your case, but if purchasing is not buying according to demand, then your inventory is not being adjusted correctly when those “this always goes with that” things get shipped. So for Epicor to program it like like this is them programming something that will intentionally drive inaccurate inventory.
So if it’s something you want, I would go ahead an do it with your own customization, because I doubt Epicor is going to.
The demand side of your logic makes sense and I can see where both you and hypothetically would come from.
Let’s look at the demand. Is it the place of the ERP system to help understand which parts are related to each other and may be needed? Let’s say I am in Engineering work bench and I add Material Card 10 which is Purchased Part A. How do I remember that I always need Purchased Part B?
Thanks for the discussion - it is helpful to bounce these ideas off of other people with more experience in Epicor than I have.
Make a phantom assembly?
One way to do that would be to make Part A and Part B and assembly (we’ll call it AB). Then instead of your engineers calling out for A or B, they call out for AB. You can use phantom BOM settings to flatten this on the job if you would rather not have extra levels.
For the ordering side, you would probably look at sales kits (I won’t be much help on those, I haven’t used them yet).
Or BPM’s to check for these, very similar to what @ckrusen suggested already. But I think it’s better to get that as close to the beginning of the process (hence the demand) as possible. So I would put that on the engineering side.
@ckrusen and @Banderson
I am hesitant to go down this route as the amount of different combinations would mean remembering which phantom/assemblies to add would potentially be even more burdensome than remembering the individual components as they are made up numbers. I agree this is the only functionality in Epicor that appears to support it.
On the Sales Kit side, I do not believe you can cut a Purchase Order for a Sales Kit…
Not the purchasing side, the customer order side (demand side). The salesman would sell the sales kit, the purchase orders would be for each part.
I understand what you mean now. Unfortunately we never sell these on their own, they are a sub-assembly 2 to 3 levels down from the top-level finished good we sell.
I agree that we need to get Engineering involved early on in the process and have the variations of these BOM’s prebuilt. Perhaps the Configurator will make sense here.
That’s right, then, you don’t need the sales kits.
Agreed. Just the “Sales Kit” functionality and how it recommends parts to go together is exactly the type of functionality we want - just on the BOM creation side.
Great discussion. Thanks again everyone.
If you don’t want to create the phantom BOM’s (And I agree they can be a pain) then I would recommend the BPM in engineering workbench to force engineering to make sure they are matched up correctly.
FWIW though, the phantom bom part number would be pretty much the same thing as getting the salesman to remember to use the sales kit number instead of the individual part numbers (I think 
). I really should dig into sales kits more to better understand how they work.
If the parts of the “purchasing” kit are from the same supplier, perhaps the supplier can set them up as “sales kits” on their end. 
It’s something we have discussed but so far there are so many variants that we haven’t gone there yet. Thanks!
I agree that if we are going to customize that Engineering Workbench is the best spot for it. Thanks again.