The beauty of assign your own P/N is control the device change (ex. die shrink parts with form fit function all the same, you use std p/n would be no change... you would not have traceability after the assembly, except date code at assembly). your own P/N you can add dash to control that- just in case the die shrink causes reliability variation... Change location of MFG is another... dash or OEM P/N will catch that. if you only use common MRP, you might missing some detail that is critical for end of life prediction for example. my 2 cents. (the data is so cheap, if you set up properly, few more link would save the day sometime down to the road). jk > June 1, 2016 > > Although I recognize that some OEMs assign their own unique part numbers > to > EEE parts but I am not in favor of doing this because it complicates > things > and makes it difficult if you are using the drawing or separate parts list > for a competitive bid situation. For example, if a semiconductor is being > purchased as JANTX XXXXXX per MIL-PRF-19500/XXX, with a detailed > description of the part in the drawing remarks column, this is normally > sufficient for ordering the part using the MRP electronic system. > However, > if only the OEMs P/N XXXXXX is listed, then this normally requires a > detailed drawing or parts card to capture the part ordering information. > Using an OEM number makes it difficult to search to determine if a suspect > counterfeit part may have been used on an assembly unless there is an > electronic method to translate the OEMs part number to the military > specification part number. I also believe that the practice may violate > standard drawing practices. Normally, per standard drawing practices, OEM > documents can be listed as references along with the base requirement. > As > example, Solder per J-STD-001 Class 3 [OEM XXXXX] where the OEM XXXXX is > the local OEM procedure that implements the soldering requirements. If > the > BOM includes both the OMs part numbers and the generic part numbers such > as > the military part numbers, this may be an acceptable practice. Normally, > detail or source control drawings for an EEE part are not needed unless > the > part cannot be purchased without invoking additional requirements via a > detail or source control drawing. > > On Wed, Jun 1, 2016 at 12:02 PM, Ken Barton <[log in to unmask]> > wrote: > >> Greetings TechNet gurus, >> >> Just arrived at my present employer charged with creating process for >> PCB/CCA libraries. We have a turnkey layout vendor, this relationship is >> somewhat problematic: Wrong footprints & component subs. We have >> absolutely >> no correlation with Orcad CIS & our MRP/ECAD system. All board >> components >> are using vendor PNs. So, I want to toss this out to all for a reality >> check: My experience over a wide range of OEMs I have worked for is to >> issue each component a "Company" 10 digit PN. All critical attributes >> will >> be entered & fall into CIS explorer. The MRP/ECAD we have has all >> capability for handling the mechanical AND electrical assy structures. >> As >> my employer is the first time I have seen vendor PNs go on EBOMs & >> released >> out into the wild, I've been informed that other huge companies have >> done >> the same. >> >> Am I just an old guy using the "We always do it this way, it works?" I >> am >> willing to hear the pros & cons, has anybody else been in the middle of >> this? >> >> Ken Barton >> Technical Designer, >> Vehicles & GSE/ >> Avionics HW >> >> Blue Origin, LLC >> 21218 76th Avenue S. >> Kent, WA 98032 >> (253) 437-5625 x625 >> [log in to unmask]<mailto:[log in to unmask]> >> >> >> >> ______________________________________________________________________ >> This email has been scanned by the Symantec Email Security.cloud >> service. >> For more information please contact helpdesk at x2960 or >> [log in to unmask] >> ______________________________________________________________________ >> > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please contact helpdesk at x2960 or [log in to unmask] > ______________________________________________________________________ > ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please contact helpdesk at x2960 or [log in to unmask] ______________________________________________________________________