I talked my people into actually tracking what material we really do use. As such, I needed to adjust the QTY/Parent via DMT. That pretty much went over very, very well. However, yesterday I got some errors saying This Group is closed, and These parts are currently checked out. It was late so I went home as it’s not a big issue. This morning when I came in all I had left was the parts that are in closed Groups.
So, everyday at 4 the system manger checks out every part at 4PM. That explains all the This part is Checked out. But after the system manger is done, does it complete the adjustment automatically? Cause that is what it looks like? Also, how does the system agent work?
William which table are you trying to update via the DMT. Are you updating the quantity/parent on the bom for that part or updating usage for a part or something else?
Are you logging in to DMT as system manager? It should say whoever is logged in has it checked out.
You control what group the DMT uses by the ECO group. Open it up in engineering workbench to see if the group you are using is closed. If it is, re-open is and group approve/check in all. We have a group made specifically for DMT changes that stays open.
What automation are you running everyday at 4pm? I don’t really want to get into business practices, but adjusting your BOM everyday is a little excessive. If you really want to track usage, you should be manually issuing to jobs, and then make occasional adjustments to the BOM.
That’s a whole 'nother can of worms. (and unrelated right?) You’ll probably have to be more specific and someone who knows more than me will probably give you a better answer.
Apologies if you have already worked this out and I am assuming you are using E10. The process of updating the bill of materials via DMT sees the part checked out and then back in via the erp.eco… tables. Similarly checking the part out writes to this table. I would have thought this error would have prevented the erp.eco… tables being updated but if I understand you it could be that the this is just a warning and the erp.eco table is updated and when the part is checked back in the erp.partmtl table is updated with the new value.
I know for it to give us the right results we need to populate the fields below.
We also created a new Engineering workbench group called importer, which we use for updates/imports - this is in the ECOGRoupID - this makes it really easy to track what is going on and should also eliminate the group closed messages. Assuming you are using part revisions you should be able to find out when the part is being updated in the audit log on the part revision - at least then you should be able see when the update that seems to be happening is in fact happening - also useful to establish who in fact updated a record.
However if I remember correctly if the update of the bill of materials had any issues the part being updated stays checked out - in a mass update this is any parts with issue - but only those parts.
Also worth doing the same process a test db and querying the erp.eco… tables whilst this is running.
I am intrigued, and I am only asking to expand my knowledge, why are you checking out all parts each day and how many parts are you doing this for?
So I wrote a big response, but after reading the comments, I have one question. I saw we had one group name Import. It was last used when we went from Vantage to E10. I am assuming, I could of had the group as one group and then just updated all the parts through that one group, correct? Which makes sense. I was thinking parts were already in a particular group.
But on a side note: I tested in Test first and had no issues. That’s why I was curious when I had these issues in live. And we are not changing the parts manually daily. I am just changing them now so that way from here on out we can accurately look at what is going on. And if the system amanger is that big a can @Banderson, I’m staying away! LOL! I have enough to worry about.
Yes. You use an ECOgroup to check out part. The part doesn’t inherently have a group. Depending on how your company manages ECO’s, you might have a group tied to a specific group of changes. In our company, each person just has their own group that we use all of the time. If I work on it, it gets checked out to mine. If someone else works on it, it gets checked out to theirs. We also have one just for DMT’s. It’s just a way to manage changes. If the group is closed, in program, you can’t check out. For some reason DMT allows you to check out, but they get stuck. If the group is open, it should check it back in. (at least it does for me, but I’m usually changing comments, and production standards, not quantities very often, so maybe there is something to what James said earlier.)
That’s good. When you said “all” you had me worried.
Use one group and it should go much better. However as you have ran this previously it looks like you may have parts that are stuck in the eco tables as checked out - you can check by going into the engineering work bench as the user who is checking the part out - any ones that have a problem will list here - however if it is a lot then the screen may crash or take a while to come out.
The cleanest way to tidy this up is to load the files that you used into the dmt and do a delete via the dmt - this removes all changes. Fix the ecogroupid in the file and then redo the import. I know when I was testing the DMT process for our boms and routes way before go live, we had an import that had hundreds of errors and there was so much stuff stuck checked out that it to all intents and purposes it broke the engineering workbench until I backed everything out.
Well that explains a lot. But I’m still wondering why the parts that were checked out last night by today had the new qty/parent already. I went from a few hundred to 8 by morning. The engineering dept has checked it out and everything is good…so far. But that has me stumped a little bit.
If the part is already checked out to ECO Group specified in the import file then the import continues correctly.
If the part is already checked out to a different ECO Group to the one specified in the import file then you get the following error:
Table: ECORev Msg: This part is already checked out to group…
If you specify an ECO Group which is marked as closed then you will get the following error:
Table: ECOGroup Msg: The Group is closed.
