Skip to main content

Hi,
I am looking for suggestions on how to handle the classification of the same physical part for different use cases.  We are looking to classify as part as:

  1. For production
  2. For Warranty
  3. For Repair
  4. For Maintenance

We have thought about the following options, but was hoping for any other suggestions:

  1. Use of condition codes on the part
  2. Use of Availability Codes on the part
  3. Create duplicate part numbers with a prefix/suffix

Additionally, the business is looking to serialize some parts, but not in inventory.  Which would preclude the first two options above.  Option #3 is possible, but would require additional steps when we are looking to convert parts from one class to another. (either a count in/count out or a unidirectional flow of shop orders)

 

Are there any other ways to handle this situation? 

I think it depends on why this classification is important. If the part should have different inventory value and be planned differently (by MRP etc.) I believe different part numbers is the best option (with pre- or suffix). If it is more for an informational purpose I think condition codes would be the best option.


Hi Bjorn,

thank you for your response.  They parts will definitely be planned differently.  Additionally, a part that is classified as repair only or warranty only, may be a partially used part.  
Just for clarification, I know that we can setup customer orders and shop orders specific to condition codes, but MRP will not consider them? 

 

If we use pre- or suffix - what would you suggest would be the best way to convert parts from one classification to another?

Counting in and out isn’t the best option (in my opinion), and using shop orders would only allow us to convert in one direction. Trying to convert the opposite way on a shop order would create a circular reference error. 


@RajenGandhi Correct. MRP will not plan on condition codes. And the part can only have one standard cost per part number and not per condition code. So typically that sets the limitations for the condition code usages (and it also requires parts to be either lot and/or serial tracked).

Hard to say what the best way of converting between different classifications are. It would depend on what the background of the re-classification is I guess. I mean, what happens which makes you taking the decision to re-classify a part?


Thank you for the insight on the condition codes.


I think there would be two potential reasons for re-classification:

  1. the demand of a part in a different area of the business.  Ie. Production needs a part and we have some in the maintenance and don’t want to wait to order more for production. This would mean that parts could move back and forth between classifications.
  2. the return / replacement of a part already delivered to a customer - the old part would go back into inventory as a production part but then be reclassified for a different use case. In this scenario parts would only move in one direction of classification.  

 


Would (4) Sites be feasible, one for Production, one for Warranty, etc.?


In addition to @matt.watters suggestion, I would think about Project Inventory. MRP will handle this out of the box and you can reallocate as needed. If parts are used I would set a condition code or new part number.


@matt.watters  interesting suggestion - I think we may be able to do that for certain scenarios. 

I have a feeling this will be a combination of different options. 

@mmoss project inventory is also another option - I have looked into projects a bit, and it seems to have a lot of basic data setup, which has been the roadblock to date. 


@RajenGandhi please reference this post from last year on the topic of benefits of multi-site for additional insight.

 


Would (4) Sites be feasible, one for Production, one for Warranty, etc.?

This would also help in setting up a warranty/service organization, typically they are steered differently. Made the suggestion as well once to a customer. That resonated quiet well with their requirements.

 


Reply