Change Sales Part number to point to different Inventory Part
Can you Change Sales Part number to point to different Inventory Part? We want to keep the sales part number but it needs to point to a different Inventory part, is this possible or do we have to create a new sales part number? Transactions already exist. what are my options?
Thank you,
Page 1 / 1
“Can you Change Sales Part number to point to different Inventory Part?” Yes this is possible, You can also have multiple Sales Parts connected to one Inventory Part.
But you are not able to change existing parts. You will have to create a new sales part.
Hi,
You need to enter a new sales part when transactions exists and system wont let you to enter a new inventory part.
Also if you need to have same sales part for different inventory part in same site below error message will be given.
Regards,
Peshala.
Hi,
we still don’t understand why is not possible to change the inventory part in the sales part window.
In my company we need to change the inventory part due to a business change but we don’t want to create a new sales part (the sales part code is known by the customers and we have more than 20.000 parts).
We have changed the inventory part in our TEST environment by an SQL update and all the tests were fine without any issue.
Do you have any idea why IFS do this validation?
Research Engineering Form, Fit, and Function rules.
Governed by processes (like ISO) that would ensure you don’t over time represent one item as another item entirely, the inventory part used for an sales part becomes a unique relationship. You can have 10 different sales parts to represent one inventory part if you want to sell the same item in different ways to different markets. There is a one to many relationship designed to work in this manner in IFS and it follows normal engineering control requirements.
You can’t however have a singular sales part represent different underlying inventory parts directly over time. That allows the possibility of a part eventually not meaning the same thing over time which is a poor sales practice and an awful Engineering/Quality process for traceability reasons.
You could however, have a hierarchy like this:
Sales Part
Inventory Part A (acts as an assembly)
Inventory Part B (Inventory Part B is valid from 2015 to 2020)
Inventory Part C (Inventory Part C is valid from 2020 to Present)
This change at a structure level below the Inventory Part that is directly connected to the Sales Part could be managed through Engineering Change Orders to document the change, but there is no such change object between the Sales Part and matched Inventory Part, so unless you force a data change that violates these rules (not recommended), you cannot make this concept work with standard IFS. I would dare say you probably wouldn’t be able to make this switch with most major ERP software.
Research Engineering Form, Fit, and Function rules.
Governed by processes (like ISO) that would ensure you don’t over time represent one item as another item entirely, the inventory part used for an sales part becomes a unique relationship. You can have 10 different sales parts to represent one inventory part if you want to sell the same item in different ways to different markets. There is a one to many relationship designed to work in this manner in IFS and it follows normal engineering control requirements.
You can’t however have a singular sales part represent different underlying inventory parts directly over time. That allows the possibility of a part eventually not meaning the same thing over time which is a poor sales practice and an awful Engineering/Quality process for traceability reasons.
You could however, have a hierarchy like this:
Sales Part
Inventory Part A (acts as an assembly)
Inventory Part B (Inventory Part B is valid from 2015 to 2020)
Inventory Part C (Inventory Part C is valid from 2020 to Present)
This change at a structure level below the Inventory Part that is directly connected to the Sales Part could be managed through Engineering Change Orders to document the change, but there is no such change object between the Sales Part and matched Inventory Part, so unless you force a data change that violates these rules (not recommended), you cannot make this concept work with standard IFS. I would dare say you probably wouldn’t be able to make this switch with most major ERP software.
I used to work as a mechanical engineer for an aftermarket distributor of hydraulic seals. Every product had a generic sales part number that meant something to the customer, like an O-ring in a particular size made of a particular material in a particular hardness/Durometer. For these, your point stands. That part number MEANS something.
That same physical inventory part would also get sold under one or more OEM equivalent part numbers. In construction equipment, that one O-ring might get sold under different part numbers for Caterpillar, Komatsu, John Deere, Volvo, Hitachi, Case New Holland, etc. Those part numbers were intentionally meaningless because the OEMs didn't want our job to be easy.
Aftermarket development is tricky. Sometimes you'd buy parts books and get data out of them, and sometimes you'd buy the physical part. Maybe you made a mistake during the original development, or maybe the OEM made a revision to the product itself. At either rate, this conversion of an OEM part number to a generic part number was something we had to change... almost routinely.
We had to make this change with an UPDATE query against SALES_PART_TAB, taking care that no open transactions existed against it first. It was our ONE exception to never doing straight updates. Engineering always initiated the change for IT to carry out.
In that environment, kitting such numbers with one-line BOMs would have been a huge headache for an operation that closed about 700 orders a day, the majority of which shipped in the final two hours before the UPSnext day air cutoff.
Hmm, interesting. So you had to make that switch that would go against normal engineering development rules because you really had no control over the engineering side, you were just trying to keep the customer side smooth.
The key you mention then is when it was time to make this change, you couldn’t have any open transactions else you would create an update issue to existing orders.
Research Engineering Form, Fit, and Function rules.
Governed by processes (like ISO) that would ensure you don’t over time represent one item as another item entirely, the inventory part used for an sales part becomes a unique relationship. You can have 10 different sales parts to represent one inventory part if you want to sell the same item in different ways to different markets. There is a one to many relationship designed to work in this manner in IFS and it follows normal engineering control requirements.
You can’t however have a singular sales part represent different underlying inventory parts directly over time. That allows the possibility of a part eventually not meaning the same thing over time which is a poor sales practice and an awful Engineering/Quality process for traceability reasons.
You could however, have a hierarchy like this:
Sales Part
Inventory Part A (acts as an assembly)
Inventory Part B (Inventory Part B is valid from 2015 to 2020)
Inventory Part C (Inventory Part C is valid from 2020 to Present)
In my organization we call this a “grandparent” part in the overall hierarchy. It is the most customer specific version of a general product/part we offer.
This change at a structure level below the Inventory Part that is directly connected to the Sales Part could be managed through Engineering Change Orders to document the change, but there is no such change object between the Sales Part and matched Inventory Part, so unless you force a data change that violates these rules (not recommended), you cannot make this concept work with standard IFS. I would dare say you probably wouldn’t be able to make this switch with most major ERP software.
Changing Form/Fit/Function typically should create a new inventory part number (along with a new Sales Part Number), but not all organizations follow this to the letter. My organization uses a backwards compatibility test to help us assess whether we are violating Form/Fit/Function. If you could put Rev A and Rev B on the same shelf, and a customer could buy both units without consequence, then it should be ok to do the revision.