This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

DEVELOPERS FORUM - Nonlinear multi BOM problem concerning spare-part catalogue relations

fli - Thursday, October 7, 2010 4:47 AM:

Hi Everyone,


I am participating a pilot project for an international company.

I have a challenge solving spare-part catalogue relations.

I have attached a document (one page) describing the problem with datamodel, workflow and a possible solution. (next post)

I would very much like some feedback and/or a more elegance solution.
 
Regards,
Christoffer



PeterSchroer - Thursday, October 7, 2010 8:05 AM:

Hi Christoffer,

I did not see the data model picture yet,  so I can only make some guesses.       Are you using the Structure Browser to navigate the multi-level BOM,  or are you using the Community Soluition for the Multi-BOM tab?         Structure Browser can normally follow any relationships,  standard or custom,  shoudl not be a problem.      Multi-BOM uses a  SQL Stored procedure to query the deep BOM   (SQL procedure for fast performance -- so that BOM with like 250,000 parts is loaded quickly).       If you add a custom relationship,    you will need to change this SQL Procedure.     

I am also curious how you are modeling spare-parts.   Many companies are facing the same problem,  and maybe we can create a nice common solution.

Good luck,

Peter



fli - Friday, October 8, 2010 6:35 AM:

Normal 0 false false false EN-GB X-NONE X-NONE MicrosoftInternetExplorer4

Peter,
Thanks for your response.
Yes lets create a nice solution.
 
A Plate is never edited nor its items.
Problem:
When deleting or replacing a part in the multilevel-part BOM the PPI relation is not updated, making the referenced spare part wrong.
 
I had some trouble uploading to the site therefore the missing data pic. But here it is.

 
Thanks for a great program
Christoffer


fli - Friday, October 8, 2010 9:26 AM:

Normal 0 false false false EN-GB X-NONE X-NONE MicrosoftInternetExplorer4

Relations and revisions.
Is there a relation item for each revision and generation or how is this controlled.
Is it like this ?
If float :
Day 1
Part A v.1 – Part BOM X – Part B v.1
Day 2
Part A v.1 – Part BOM Y – Part B v.2
 
If it is like this :
If float :
Day 1
Part A v.1 – Part BOM X – Part B v.1
Day 2     Part B is visionated.
Part A v.1 – Part BOM X – Part B v.2    and    Part A v.1 – Part BOM Y -- Part B v.1
 
 
Is it then possible to relate the spare-part to the Part BOM X
and then in the grid show it’s related item ?
Then what happens when a part on the 4. Level is represented on the PPI and we replace the part on the 2. Level. Will the relationship not be intact and the PPI unchanged ?   causing an incorrect plate.
Do we need a method that triggers on Part “delete/replace”  and deletes every relation item in the plate that is similar to a relation found in the segment that has been replaced or deleted ?
Is the problem best solved by using some smart workflows ?
 


PeterSchroer - Tuesday, October 12, 2010 7:33 AM:

Hi Christoffer,

Sorry for the delay,   traveling to Denmark this week.     About your question of Float behavior,    the first example is the standard solution.   The relationship "floats" to the new version of Part B.     It is also possible to have the 2nd senario,  where instead of the relationship "floating" we create a new Relationship instance.   You can imagine that there must be properties of the relationship (usually called Effectivity) that define when the Relationship is considered in the configuration.    If you need this second behavior,  this is development work we are doing with Xerox.    It will become a new standard solution in the core framework,  but today we can also give you the working add-on package.

I think the design you have started with the Plate as a new Relationship and new itemType is correct.   The behavior is different from other Part items, so a new itemType is a good idea.    We have also done a solution using Classification --   for Parts and Variants,   we use the same Relationship Type,  but the server has different behaviors depending on the Classification of the related item.      I can share this idea with you also.

Peter.