Check in Error

[lmilesVSQKU]

Hi All,

I have an assembly that I did an initial release on. I then wanted to make an updated version with a few of the components deleted. I used the CAD plugin Project BOM to check out the released assembly, I then deleted items from the assembly.

I then attempt to checkin or save the assembly using the plugin, in which I select where the item will be saved.

I get a message saying  the parent assembly has an Ebom structure and do I want to add new item to Ebom structure.

I then click yes and get checkin  error with no message.  

I am not sure what I am doing wrong, I also don't know why when I click save it comes up with the option to select a location in the BOM. I thought I would just be updating the released assembly to a new version.

Any guidance would be much appreciated. Thanks.

Lewis

[mladen_vuk_autodesk]

Hello lmilesVSQKU, thank you for your response. To investigate why that error appeared on check-in, can you please log a support ticket for Upchain. We would need an error log from plugin side.

[FNmrodgers · Accepted solution]

Hi Lewis,

While I can't speak exactly for the Check-In error you're getting (hopefully the support ticket will be able to resolve that), I can give you some insight to the BOM location.  When an item gets moved to the released state it essentially becomes a snapshot in time of the BOM and all child components of said BOM.  Upon checking out a released item, the item goes into this sort of "interstitial" state between 'released' and 'development' until you check it back in.  When you go to check this new version back it, it's basically the same function as if you were creating a brand new item so Upchain wants to know where you'd like to store this.  I agree that it's a bit of a funky process, but once you've done it a couple times it becomes more of a second nature.

The one caveat I will mention with this is that because you are required to select a new location upon check in of a previously released item, you will need to be cautious about where that item lives in your top level BOM structure.  For example, if you have a BOM where everything is released and you check out a child component of the top-level item you will not be able to check that item directly back into the previously released top level item (because it's already been released and is a snapshot in time like I mentioned before).  If you want to modify something farther down in your BOM tree, it's best practice (at least from what I've found) to cascade your check-outs from the component that you want to modify up through every higher level assembly until you get to the top level.  Then, you can check your top level item or assembly back into your project and it will create a new version of the entire BOM rather than just your child component.  Hopefully that makes sense.  Thanks!

- Max

[SonicFlow]

---

@FNmrodgers 

The one caveat I will mention with this is that because you are required to select a new location upon check in of a previously released item, you will need to be cautious about where that item lives in your top level BOM structure.  For example, if you have a BOM where everything is released and you check out a child component of the top-level item you will not be able to check that item directly back into the previously released top level item (because it's already been released and is a snapshot in time like I mentioned before).  If you want to modify something farther down in your BOM tree, it's best practice (at least from what I've found) to cascade your check-outs from the component that you want to modify up through every higher level assembly until you get to the top level.  Then, you can check your top level item or assembly back into your project and it will create a new version of the entire BOM rather than just your child component. 

---

That was an interesting explanation, but it raised significant questions for me, as someone who doesn't currently have access to Upchain. I hope you have time to help me unpack that. 

"if you have a BOM where everything is released and you check out a child component of the top-level item you will not be able to check that item directly back into the previously released top level item"

What does not able to check the item back in to the parent really mean? You can't put it back in the same project as the parent? Or you can check-in, but the parent tries to ignore the newer version?  With CAD, I know it's going to use the versions of components that you have loaded.  I can't imagine it completely blocks check-in...?

"If you want to modify something farther down in your BOM tree, it's best practice (at least from what I've found) to cascade your check-outs from the component that you want to modify up through every higher level assembly until you get to the top level."

What you describe there is pretty much the opposite of a best practice when it comes to PDM and CAD. If the item number didn't change, the component should be interchangeable (so you can use either AB or AC in the assembly). Why would you need to go to the trouble of revising multiple assemblies (and drawings) if you change one bracket (but it still fits in the assembly)? 

If the child item number changed, then it would be required to update the subassembly where it is used (and sometimes, but often not, levels above that).

Thanks!

[FNmrodgers]

What does not able to check the item back in to the parent really mean? You can't put it back in the same project as the parent? Or you can check-in, but the parent tries to ignore the newer version?  With CAD, I know it's going to use the versions of components that you have loaded.  I can't imagine it completely blocks check-in...?

This means that if you have put a part into the 'released' state, the BOM for that item is fully locked in time.  You cannot go back and modify that BOM without pushing it into a new version.  Therefore, you cannot check a child item back into it's parent if the parent is not brought into the development state as well (as I'm referring to below).  You can still check the item into the project, but it may not cascade correctly into the multi-level BOM as you have it structured in your CAD platform.

What you describe there is pretty much the opposite of a best practice when it comes to PDM and CAD. If the item number didn't change, the component should be interchangeable (so you can use either AB or AC in the assembly). Why would you need to go to the trouble of revising multiple assemblies (and drawings) if you change one bracket (but it still fits in the assembly)? 

If the child item number changed, then it would be required to update the subassembly where it is used (and sometimes, but often not, levels above that).

You can set up your filters in the eBOM to accomplish different functionality if you are looking for something specific.  For example, the default eBOM filter is set to 'As Saved', but you can change it to 'Virtual Latest Released' which might accomplish more of what you're looking for.  With VLR, Upchain will look for the most recent revision of all items inside the BOM and use those versions of the item; however, with 'As Saved' it will only reference the revision that was used when the BOM was first released.  Based on how we use Upchain currently, this is why we typically check out everything upstream of the component being modified so that our BOM tab doesn't end up with a bunch of components and rather just a single top-level assembly BOM for each project.