infor.com
concierge
infor u
developer portal
Home
Groups
VISUAL - Enterprise Customer Community
Part Numbers
peter-kimbark
We are a young company who is beginning the implementation of VISUAL. Right now we currently use a 2-3 letter prefix for all our part numbers followed by a 4 or 5 digit number (VLVxxxx = valve, RMxxxxx = Raw Material, WPxxxx = Water Pump, ELCxxxx = Electrical).
Using this format the only issue we have come across are oddball parts that don't seem to fit into any category which resulted in a "GENxxxx" (general) part number category and parts that can fall into multiple categories.
We are considering changing our part number system as we begin our new implementation and was wondering what others did.
We've considered going to a RM and P (purchased) format as well as going to a straight number system that (513456). In a straight number format would you recommend just beginning at your baseline, say 100000, and no matter what order you transferred your parts over just follow it in sequence?
If we stuck with our current format, how would you handle those oddball parts that don't fit into an existing category, are to unique to create a new category, or may fall into more than one category?
Find more posts tagged with
Comments
Legacy Contributor
We went with the serialized part numbers approach (random 5-digit numbers) for all the reasons you stated. There were too many parts that could go in different categories and it would cause more confusion than it would help things. And, as parts evolved, it would become even more confusing (parts we fabricated today, but started buying later....etc.).
We've found that defining those attributes in Part Maintenance (Commodity Code, UDF fields, etc.) worked really well and all can be edited as the part evolves. We also standardized how we defined the description which made the searches much easier.
cgibson
We use a mixture of methods, serialized and semi-intelligent items. Some of our items are customer specific as we do a lot of subcontracted manufacturing. For those parts we use a prefix for the customer, followed by their item number.
I have to agree with Jason, in that Commodity codes, product codes, UDF, and descriptions are better ways to structure the information about the item, as they can all be revised as needed. The only caution I would recommend would be dealing with parts that you are able to purchase or manufacture. Converting these parts can cause a bunch of accounting issues if not handled carefully. (Depending on your costing method) Feel free to contact me for additional information.
peter-kimbark
Thanks for the responses.
I think a serialized approach makes sense with the search capability of part descriptions, commodity codes and products codes. Our old (still current) system has horrible search function and no other ability to define or find information on parts.
On that same token, having only dealt with one system and the restrictions it has, I still feel I need that little push to know that doing it this way is not going to cause us issues down the road.
I'm assuming I'd be correct in saying that there is no need to worry that a sequence of 10001, 10002, 10003 and 10004 could very easily be a hydraulic fitting (10001) followed by fabricated part (10002) followed by a 3/8-16 Hex Nut (10003) followed by 2" steel pipe (10004) and it wouldn't matter.
Chris, we've ran into a few cases of converting parts from purchased to fabricated and vise versa. In the past we have tried to reuse the part number but during this process the idea has crossed my mind what if we left the purchased version and the fabricated version as two separate part numbers that were alternates of each other (another feature we do not have access to in our current system).
Legacy Contributor
Just to add my two cents worth in on Part numbering schemes: We use 8 digits with all numbers, such as 500-60715. The prefix identifies the larger category of parts, such as, 500 identifies hoses & fittings, 600 is electrical, etc. The last five are just sequential numbering. This helps when eyeballing a part# to easily recognize at least the category. We really don't have misc. parts or parts that would fit into different categories, but if we did, the commodity code could be used. From experience, stay away from alphabetic characters as they are more prone to typos and lower case vs. upper case.
The most helpful in a search is the description. We are still working on this, but since you are starting out, make sure you develop a logical nomenclature of how descriptions are to be entered and stick with it.
Last but not least, I would not recommend using two different part #s for same part. However, I do not know your specific circumstances, but this can cause a lot of confusion to the end users as to which one to use and under what circumstances.
Legacy Contributor
Ditto on avoiding configured part numbers. Use the field that are intended to help give info for the part and be used in searches and reports:
-->Part Description,
-->Product Code,
-->Commodity Code,
-->Fabricated/Purchased,
-->Consumable,
-->Tool/Fixture,
-->Planner User ID,
-->Buyer User ID,
-->User Defined Fields,
-->Customizable User Defined Fields
If you have a lot of options you want to search for, you could contact TrueFit Innovation about their Data Extender, which provides an entire table for part configuration at a reasonable cost. If you are running EPDM metadata that has the same information on the engineering side, you can integrate with packages such as QBuild's CADLink.
Important Links
Community Hubs
Discussion Forums
Groups
Community News
Popular Tags
ION Connect
ION Workflow
ION API Gateway
Syteline Development
CPQ Discussion Ask a Colleague
Infor Data Fabric
Infor Document Management (IDM)
LN Development
FAQs, How-To, and Best Practices
API Usage