How to manage one-to-many Mfr/MfrPN to Vendor/VendorPN?

This may be particular to the electronics industry, where the designer specifies a part by Mfr/MfrPN, but the part is purchased from a distributor or re-seller, many of whom will sell the same part and a purchasing decision for Vendor/VendorPN is based on price and stock on hand.

I am using a recent Tryton docker image, and have activated modules Product, Production and Purchase (and of course their dependencies), but do not see a mapping from Supplier to OEM. Am I missing something? Is there a module I need to activate?

Many thanks,
Dale

Fwiw, this is an example of how Vendor/VendorPN and Mfr/MfrPN were managed in Parts&Vendors (a long gone Windows app).

You can add suppliers on both product and their variant.

So I think you have to look at “Product” → “Products” or “Product” → “Products” → “Variant”. Both have a tab “Suppliers” where you can add the information. You can also use “Product” → “Products” → “Suppliers” to add the information.

Just to mention, you have to have the checkbox “purchasable” checked to see the tab.

1 Like

Thanks @edbo. Do you know if the Supplier paradigm extends to having suppliers for suppliers? If so, I could define a convention that a 2nd-level supplier is the original manufacturer.

Also, am I correct to understand that all Product may be sold? In a multi-level hierarchical BOM there may be many sub-assemblies that exist only for the convenience of the production process, and will never be sold. However, it seems “list price” is required data for all Products and I have been assigning $1 to product which will not be sold. Is this the correct procedure?

No a supplier is whom you purchase goods or service.

No only product with “salable” box checked can be sold.

It is required for now but you can just set 0 for cases it does not make sense. We are working on improving the situation: Crash if list_price is None (#10244) · Issues · Tryton / Tryton · GitLab

Thanks @ced for clarifying. Does this mean the facility does not exist for managing the Mfr/MfrPN to Supplier/SupplierCode using available modules?

For my use case, engineering specifies the Mfr/MfrPN (often several, as second sources or alternates) and purchasing is free to chose Supplier based on price and availability for planned production schedule.

It would be most convenient if the MfrPNs could be managed in Tryton instead of a seperate db or spreadsheet. Can you make any suggestions for how this might be accomplished?

Thanks, Dale

What is the meaning of “Mfr/MfrPN”?

1 Like

I don’t really understand the Mfr/MfrPN phrase. But when I look at your screenshot from your application, I see a list of possible suppliers right?

So for example you added an 74HC04 as a product. That part can be bought from (I made it all up):

  • digikey → name “Inverter 74HC04HT (hex)”, code from digikey 123456
  • farnell → name “74HCT04 HEX inverter”, code from farnell 543231
  • mouser → name “Hex inv 74HC04”, code from mouser 9487345

In Tryton you add those three suppliers to the product with the name, code and leadtime. You can also add the different prices based on quantity.

If you want to say that the 74HC04 should be from the Fairchild brand or Texas Instruments, you can add that information with a special module like GitHub - NaN-tic/trytond-product_brand or GitHub - NaN-tic/trytond-product_manufacturer

1 Like

Thank you @edbo! :grinning:

This is exactly what I mean! :slight_smile: I suspect the product_manufacturer module will be the one I need.

I apologose for not being more clear. By Mfr/MfrPN, I mean the original manufacturer and their part number. E.g. STMicroelectronics M74HC04YTTR, Texas Instruments CD74HC04MT and ON Semiconductor MM74HC04MTCX are likely all acceptable alternates for a “generic” 74HC04. However, generally manufacturers do not sell parts directly, they sell through distributors, such as Digi-Key, Arrow, Future, Mouser, etc, and the same part can often be purchased from more than one distributor (supplier). Engineering often only specifies one Mfr/MfrPN - the one used to build the prototype. Later though, it is not uncommon for the original source to either not be available, or not competitive vs equivalent parts from other manufactures. This leads to having approved alternates that can be selected from depending on the situation.

For me this looks like a product template with multiple variants which have many suppliers if the parts are not considered as the same at the stock level.
For now the production module can define BoM using only product variant, but it will be a good improvement to allow to define with a template and later let the system or the user choose a corresponding variant.

Thankyou @ced and @pokoli for your help. I will describe the general use case in case you can recommend a more optimal solution than the NaN-tic trytond-product_manufacturer module.

In high-tech electronic product manufacturing, especially printed circuit board assemblies, the designer (“engineering”) typically provides a BOM for manufacturing with a purchase specification for each product on the BOM. At a high level, the road to the customer is often an iterative process, starting with product prototype 1, 2, 3… (which are not sold), then an official product release, and later product revision 1, 2, 3… to correct defects and or make product improvements.

In the electronics industry (and I expect others also), products used as raw materials are typically not purchased from their manufacturer but rather from a distributor or re-seller, and the same part is often available from more than one supplier. Each supplier generally has their own part number for purchasing, and it does not matter which supplier the part is purchased from, so long as the manufacturer’s part number specified by engineering is respected. This provides flexibility in purchasing and reduces support effort needed from engineering.

For example, engineering may specify an STMicroelectronics M74HC04YTTR (a “74HC04”-type hex inverter integrated circuit in a 14-TSSOP package). The purchaser can select the Supplier from avaiale supplies, such as Digi-Key, Arrow, Future, Mouser… based on price, availability, strategic partnership, etc., without going back to engineering for approval.

Although engineering will often initially specify only one source for a particular product on a BOM (e.g. the STM M74HC04YTTR), there can be other manufacturers that make a generally equivalent part (e.g. Texas Instruments CD74HC04MT and ON Semiconductor MM74HC04MTCX). As time passes it is not uncommon for the original source to become unavailable and for engineering to specify additional parts as alternates for purchasing (i.e. the TI and ON Semi parts). Note generally only engineering is qualified to determine if an alternate part is truly alternate though, as very specific characteristics of the design may need to be considered, even to the point of building a special prototype to test and evaluate a potential alternate.

Am I making sense? Generally this is managed by engineering and purchasing in a many-to-many type of table associated with each raw material product, engineering provides Manufacturers and Manufacturer Part Numbers, and purchasing or supply-chain provides Suppliers and Supplier Part Numbers (possibly with approval work flows in the management tool).

Thanks for the help,
Dale

I do not see why you can not use the manufacturer name as the name of the product as it seems to be the way you distinct different alternative parts.

@ced, are you proposing to use e.g. “IC Hex-Inverter STMicroelectronics M74HC04YTTR” as the name of the product, instead of a generic name e.g. “IC Hex-Inverter 74HC04 14-TSSOP”, and then add Suppliers for the STMicroelectronics M74HC04YTTR as well as Texas Instruments CD74HC04MT and ON Semiconductor MM74HC04MTCX? To me, this lacks clarity as the product name implies the STM part is the preferred part, when in fact the three are equivalent and no individual preference or superiority should be implied. Also I see potential maintenance confusion should the STM part be discontinued. Do I understand you correctly? Could you provide a detailed example?

I’m lost with your requirements. Sometimes you said that parts are equivalent and sometimes you said there are not. So there is no solution.

I apologise, I think I lost clarity with too much detail. My comment was only that with alternates there should be no implied preference or superiority by including the initial alternate in the product name.

I should mention in case it makes a difference that by definition alternates are not stocked separately. E.g. there is only one stock location for a “2K Ohm 0805 1% resistor”, and the stock location could contain resistors from multiple manufacturers (and their suppliers). If the products are not true alternates, they of course must then be managed distinctly, and using the “not exactly alternate” will require a revision to the BOM (or if only temporary, it may be documented as a process change and not a BOM change).

I am intrigued by your earlier suggestion to use product variants, but I do not understand the limitation of the current implementation you described.

Can you clarify?

With your last statement, clearly variants are not a way to go because they are considered as different from each others.

Also I think the Nan-tic module will not solve the problem as it provides only a single manufacturer name per product.

So finally this looks like a need to store different “names” for a product. So why not use an identifier record (without type) for each manufacturer name? This will be a simple solution with the standard module only.
Otherwise I would advise to create a simple custom module that add a One2Many to a model that store a Many2One to a party as manufacturer and a translated Char for the name.

Thank you Cedric, I very much appreciate your help as I am sure your time is very limited - and I fear I have given too much detail again.

If I understand your reference, this statement was intended only to illustrate a special case.

E.g. using an 0603 package resistor on a circuit board designed for an 0805 resistor. The two are not true alternates, and would not be documented as such for purchasing, although might still be done temporarily (until the correct part was available) with appropriate care and attention if the business situation was dire.

I appreciate your proposal, especially because it uses the standard module only, but I’m not sure I understand exactly what you mean by “identifier record (without type)”? Is this the same as a Product record? Can you give an example and which view it would be created from?

Once again I’m lost. In the system it is not possible to have something that is the same and not the same.

Hello Dale,

You are making things a bit more complicated here ;-). I fully understand what you mean but there are also people who are not working in that business. So let keep simple and straight and focus first on the products and how to get a flow in it which fits your needs.

I think that the idea of @ced is not a bad idea at all. It gives much more flexibility then the modules I mentioned.

You can find the identifiers at a tab in the “Product” → “Products” → “Variants” form. You can add multiple identifiers, however the type is limited at the moment. When this is the way to go, you can extend the list yourself with a custom module.

In short will give this you the possibility to add multiple identifiers to the product. So you can use a general name for your product, add different identifiers which shows the brand and product type. And you add all the possible distributors (suppliers) to the list of suppliers like I mentioned before. To visualize it a bit more:

Product name: IC Hex-Inverter 74HC04 14-TSSOP
Product identifiers:

  • no type, STMicroelectronics M74HC04YTTR
  • no type, Texas Instruments CD74HC04MT
  • no type, ON Semiconductor MM74HC04MTCX

Product Supplier:

  • Farnell with the details
  • DigiKey with the details
  • Distrelec with the details
  • Mouser with the details

The “no type” can be replaced in the future with your own type in your custom module which can be something like “Alternative numbers” or whatever comes to mind.

I would stay away from this sort of edge cases first and first see if the general idea will fit in the default Tryton.

Thank you @edbo, this is sooo fantastic! Thank you also @ced. :slight_smile: I will create the part and add to a BOM in my demo system, and then work through the actual purchasing and receiving process.