Endless loop on EWB Check In Method

Hi all,
has anyone encountered anything similar to this issue, this system logic error is stopping Check In on EWB for this particular part -ONLY- when attached any material to its BOM, i have tried adding different material i.e parts, deleting the part rev completely and create a new one with the same method and different, with no luck, just wonder if any one knows the reason before raising an official ticket with Epicor.

I ran into this once before and I believe I got a fix from Epicor, but my memory is a little fuzzy. I believe the problem was related to trailing white spaces or case sensitive records. Is this part related to legacy data from an older version of Epicor? Say 9 or 8?

Yes, it moved over from E9 to E10 with no transactions whatsoever in 10 yet,

Did you upgrade the database, from 9.05.702A, or did you DMT the data over?

yes exactly, upgraded from 9.05.702 not using DMT at all, company has not purchased this modul yet, if you can direct me to the right table then i will update the small letter if exist, i have checked Part, Partdtl, PartBOM, PartMtl, PartOper as well as ECC set

That may be a needle in the haystack type situation. Start with support and see if they have a fix. Only other tables I can suggest is PartRev, PartBOO, PartOpDtl, PartPlant, PartWhse, and probably even many more that I’m missing.

i have checked all of those as well no luck, it seems that there is no escape from going on Epicor Support Ancient waiting list :tired_face:

Did you try deleting the Rev and starting over?

And you said only for this Parent, but with ANY material. How about with no material (just an operation)?

Can you expand the tree so we can see the rest of the parts in that material?

Where (which node(s)) would you expect to see more materials listed under?

Under here.

image

Oh… I assumed that wasn’t a Mfg’d part. The OP said “…when attached any material to its BOM…” So I figured they’d try it with the simplest material (i.e. single, non-mfg’d part) added .

1 Like

I was too, but when I see that triangle, I see there is something in there.

1 Like

To me it looks like its an Endless Loop data reference… your ECOPart is 86610473… it has a Mtl of 86610473 unless thats 86610473BODY and even if its not that, it may be another ECOPart within the ECO simply causing a circular loop.

It may be even an Epicor bug where it does this

MaterialRow.Part.Contains(ECOPart.PartNum); // which of course would yield true because 86610473 is indeed contained in the MtlPartNum… so it could even be an Epicor Bug. Where they are using .Contains instead of .Equals

We can test this easily… make another 2 parts that have the same Starting Numbers.

the other thing is, sometimes their checks aren’t limited to the current ECO. (they should be, but they aren’t) We’ve had problems when we’ve had to change the UOM on newly created parts, and if they were in an old ECO group, we had to check them out under the old ECO to fix it.

1 Like

@A.Baeisa - I assume you’ve run the

Actions -> Revision -> Validate Bill

before trying to check it in?

good morning @ckrusen
yes i did, no luck, if i remove all material Part will check in as normal.

it is a manufactured part guys, we add any child part to its parent this way i.e. not using assembly functionality, it is working fine with all other parts.

@hkeric.wci,
i have tried and removed this child part completely and added a different one, the result is that any added material to this ECCOMtl will cause this issue

i have deleted the revision entirely to eliminate this possibility