How to handle an item that is both purchased and manufactured
Occasionally, an item will cross between purchased and manufactured, depending on the scenario. DBA's recommendation to handle this would be to use two separate item numbers: one for the manufactured version and one for the purchased version. As far as MRP is concerned, you must make a definitive choice as to whether you will be using the manufactured part number or purchased part number in all of your active default BOM revisions. You can use the BOM - Component Replace to designate the part in all active revisions where the part is used.
You may choose to use essentially the same item code but just append an appropriate suffix to one or both (such as ITEMCODE-P for the purchased version). Each code should reflect, in the Stock Items screen, its associated M or P setting (M for the manufactured version and P for the purchased version).
Aside from this being the only way to handle this scenario in DBA, there is a benefit in costing and lead day scheduling. Each code will maintain its own inventory value, which can be helpful since, usually, the manufactured version will have a different costing impact than the purchased version.
When listing the item as a BOM component, just make sure to choose the most common version used by your company. So, for example, if the item is purchased 90% of the time (and manufactured the other 10%), it's more logical to list the purchased version in active BOMs. If you want to switch to your manufactured item instead of purchasing you can use the BOM - Component replace to swap out the M item code.
Lastly, as you might imagine, having two separate item codes, each containing quantities of the same exact item, can be problematic. So, you may consider the following solution for managing these separate item codes. Pick the item code which is the most common. In other words, figure out whether you would most likely be purchasing this item most of the time or if you would be manufacturing it most of the time. Then, for the least common method's item code, set the default receipt location to be some sort of "review" location (a location with a name that indicates it should be reviewed). Then, develop a company process to often review these locations, if quantities exist in them. During that review, the Stock Adjustments module could be used to "transfer" the quantities into the more common item code.
For example, I usually purchase red wagons. Occasionally, though, I'll build them. They are the exact same product, just different ways of obtaining them. So, I set up a REDWAGON-P item code and a REDWAGON-M item code. The REDWAGON-P item code gets received into a location where it is inventoried. The REDWAGON-M item code, though, has a default receipt location of 'NEED-STOCKADJ'. My company often reviews the 'NEED-STOCKADJ' location to see if there are any of these REDWAGON-M's in it. When there are, the Stock Adjustments screen is used to decrease those quantities (paying attention to the cost involved in that decrease). Then, still in the Stock Adjustments screen, an equal increase is performed against the REDWAGON-P item code *at the same cost that was involved in the decrease*. So, ultimately you're just moving the quantity (and cost) to the most common version of the item code.