TECHNET Archives

June 2016

TechNet@IPC.ORG

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Joyce Koo <[log in to unmask]>
Reply To:
TechNet E-Mail Forum <[log in to unmask]>, [log in to unmask]
Date:
Wed, 1 Jun 2016 16:08:07 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (106 lines)
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] 
______________________________________________________________________

ATOM RSS1 RSS2