Update Associated Assembly of a part automatically

オフライン

When we update a part, for instance we change models, we want the same part in all the associated assemblies to be updated automatically.

Current process
• Look up part to be updated 
•  Click on Views and select where used (this is the list of assemblies the part currently exists in)
• Update any details impacted by the change (AML, AVL, and Goals), new part and price
• After save, we must go into each assembly and review where used
• Update by locking, saving and unlocking, then into each assembly here.

We have to follow this process to update each assembly it touches until we get to the Building assembly as that is our very top.

Instead of going to each assembly and updating the part, we want this to happen automatically.

Parents
  • Hi Barnali,

    This should be possible by configuring the RelationshipType behavior which you can find more details about in the Just Ask Innovator help menu inside the client.

    It sounds like you'd want to make sure all of these relationships to your Part are configured to be Float relationships, so that they always point to the most recent version. However, this should be the default behavior set on most of these standard relationships. I ran a quick test in my environment by creating a very simple assembly called Parent with a single part in the BOM called Child, and I can confirm that they changes I made to Child were automatically visible when I went back to look at the Parent.

    Chris


    Christopher Gillis

    Aras Labs Software Engineer

  • Hi Christopher,

    I checked and the relationship types are configured to float. Is this related to  part lifecycle map, workflows or Item types?

    Thanks,

    Barnali

  • Hi Barnali,

    I wouldn't think that this is related to the Life Cycle or Workflow.

    Would you be able to provide some steps to repeat this issue? I'm curious what specific piece(s) of information are needing to be manually changed after the part is updated.

    Chris

  • Hi Chris,

    I update (change model no) a part Say Part A, the state changes from released to preliminary. Then Click on Views --> Where Used, go to the assemblies where this part A is used. It shows the part A as released in the assembly. Unlock, update and lock the part A in the assembly so that the state changes to preliminary. After updating all assemblies, I change the Part A from preliminary to released.

    I would want this process to be automated so that I need not go to each assembly and update the part and change its state to preliminary. Ideally, when I change Part A, the changes and the state of Part A should reflect automatically in all the assemblies where it is used.

    Thanks,

    Barnali

  • Hi Barnali,

    Ah. I see what the problem is now. You were correct. This is indeed related to the Life Cycle Map. :) 

    Each state in Life Cycle also has a behavior associated with it. I believe what you were seeing was that the parent assembly was in the Released state which gave it the Fixed behavior. Because of this, when you updated the child part, the parent remained pointing to the last released version of that part.

    In order to achieve what you're looking for, you'll need to edit each state in the Part's Life Cycle Map to have the Float behavior instead.

    Chris

  • Hi Chris,

    Thanks ! This worked but with this change I ran into another problem. 

    I changed all states in Life Cycle to Float and repeated the same steps as mentioned above. This is what happened:

    Opened a Part Say Part A to edit. Clicked on Views --> Where Used. It shows 10 assemblies where it is used. I update (change model no) the part, the state changes from released to preliminary. Clicked on Views --> Where Used. Now it shows just 2 assemblies instead of 10. In these 2 assemblies, the part's state is preliminary though.

    Thanks,

    Barnali

  • This might be caused by changing the Life Cycle State for already existing items. I think once those assemblies are versioned and have their life cycles restarted, the changes should catch up to them.

    I'm curious as to why it's just for those two assemblies though. Is there anything about those two assemblies that are different from the other 8? Perhaps they're in a different state?

    Chris

  • What I see now is in the other 8 assemblies, this part's state is still released and only the assemblies where the part's state is preliminary shows up under View-->where used. 

    Is there anything which I am missing due to which the part in only some assemblies is changing states?

  • I misread your last comment. :) I think the logic still holds though. The item behavior is likely set when the Part enters a state. Because the parts in your system were already in the state when it was still Fixed, they still have the Fixed behavior set on them. Once these Parts move to a new state or are versioned and have their life cycles reset, the new Float behavior should catch up to them. 

    I'll do a quick test in my environment to see if it's possible to do a one-time update for these existing Parts, so you don't have to wait for them to be versioned.

  • Hi Chris,

    Another input which might help here:

    I see in the 8 assemblies, the part's version is the previous version say A. while the part's current version is B.

    Thanks,

    Barnali

Reply Children
  • Hi Barnali,

    It looks like this behavior is set on the relationship items themselves. I set up a similar situation in a local instance I have here where I put a parent part into the 'Released' state and then changed the behavior on the actual life cycle state afterwards. Even with the behavior on the state changed, the behavior on the Part BOM relationship item was still Fixed. After I created a new version of this parent Part and released it again, this corrected itself and the behavior of the relationship item changed to Float as expected.

    There's a few options for you to consider here.

    1. Continue to manually make the changes until all of the assembly Parts are versioned again
    2. Put each assembly Part through a revision just to get it to pick up the new behavior
    3. Use a one-time SQL query to set the behavior of these existing relationships to Float

    While we don't typically recommend using SQL as it bypasses the Aras permission model, it works for these kinds of one-time edits to correct data and Option 3 is likely your best bet. Just be sure to take a backup of the database before you run the query in case there are any unintended side affects of making the change this way. As you're working with multiple relationships (BOM, AML, AVL), you'll also need to make sure the query changes each of these. As an example, the query for the Part BOM relationship would look something like below. You should just be able to change the bolded part to the name of each relationship.

    update innovator.part_bom set behavior = 'float' where source_id in (select id from innovator.part where is_current = '1') -- is_current is necessary to keep this change only to the most recent version of each assembly part

    Lastly, I just want to re-emphasize that this should be considered a one-time fix to get the existing data in-line with the behavior you have now set.

    Chris

  • Hi Chris,

    When a child part's version is changed with a released state, the parent part still shows the previous version of the child and hence the parent part does not show up under Views--> where used. When I superseded the parent part's state, it shows up under Views--> where used of the child part.

    Is there a way where when a child part is moved to preliminary to released state, the parent part is automatically superseded?

    Thanks,

    Barnali

  • Hi Barnali,

    Is this after correcting the data for the existing items as I described in my previous answer? This is different from the behavior I'm seeing in my environment. Here's what I'm seeing after I set the behavior of the Released Life Cycle State to Float.

    1. Initial setup
      1. Parent A.1 is in the Released State and is related to Child A.1 in the Preliminary state
    2. I run the Manual Release action to release Child A.1
      1. Parent A.1 now indicates that it's related to Child A.1 in the Released state
      2. Similarly, I can find Parent A.1 in the Where Used of Child A.1
    3. I run the Create New Revision action to create Child B.2 in the Preliminary state
      1. Parent A.1 now indicates that's related to Child B.2 in the Preliminary state
      2. Similarly, I can find Parent A.1 in the Where Used of Child B.2

    There isn't an OOTB way to achieve the automatic superseding of the parent part, but I think that might be fixing a symptom and not the underlying cause.

    Chris