When a bill of materials refers to a parts list, and one of the parts contains other elements in the parts list, you have what is called an Assembly. I.e. it is a part that isn't elementary.
Where you are confused is that you are trying to see a two-step relationship as though it were a one-step relationship.
Make a new type of entry in your parts list. Call it an assembly. Give it a part number as though it had a unique existence.
Make an Assemblies table that is
tblAssembly
-- PartNo (PK)
-- ComponentPartNo (FK) - that points back to the parts table.
-- NumReqd
You have as many entries in this table as you need to describe the components in the assembly.
Now, to use this, you have to establish a relationship between the PartNo field in tblAssembly and your master parts table, but with the relationship being "all parts and any matching assemblies." THEN establish a second relationship between the Assembly's ComponentPartNo and the parts table.
When you want to expand on the part numbers, you have a parent-child relationship here. It appears to be cyclic, which in a way it is. So in queries or in the relationship diagram, you might have to add the parts table TWICE. (You can do that.) Then make the Part-to-Assembly relationship on the first copy and the Component-to-Part relationship on the second copy.
Now when you want a parts list that includes an assembly, you have to build a report/subreport case, where whenever you have an assembly you have to include the subreport.
If that seems to not give you just a flat-out parts list, you can use a UNION query here to your advantage. The examples for UNION queries in the Help files should be good enough to give you the basic idea.
For any bill of materials, the absolute list of parts is a union of all parts called out by number that AREN'T assemblies plus all parts referenced from the Assembly table for parts that ARE assemblies.
One trick I sometimes use is that I add a constant field in each segment of my UNION queries so I can identify whether the item came from table A, table B, table C, etc.
Now, things can get VERY nasty if you ever have the case that an assembly is itself an assembly. For now, let's cross that bridge if and when you come to it.
This is a conceptual discussion. Perhaps this is not what you want to implement. But you said you were having trouble getting your head around this problem. So if this provides only insight and no actual directions, at least I hope the insights are useful.
