Does anyone know how to resolve this message? I see a ton of other jobs set up the exact same way in terms of the operation in this job. We are able to schedule other jobs with this same operation just fine.
Most likely on the bom the operation is configured to use an inactive resource or a resource group with no resources. If this is for existing jobs check for the same thing by querying table erp.resourcetimeused
I see that the resource groups are active and they have active resources under them.
Did you check the erp.resourcetimeused table - particularly for the jobassm.op you mentioned and confirm that there is nothing wrong with how that has been scheduled.
Also to confirm you are scheduling these jobs in the future ie they are not late.
@mcfreedombaby first off, love the username. Secondly, there is nothing in the table for the job that I am having issues with because it won’t schedule. Rows only get committed to resource time used if the job schedules without errors. I have a a ton of other jobs with the same operation and resources in it, yet they scheduled perfectly fine.
To get around the issue I had to delete one of the resource groups on the operation. The minute I deleted that one the issue disappeared. It is strange though because the one I deleted had no labor or burden cost on any of the resources so it must be in the operation solely for scheduling purposes. But even that doesn’t make sense because it is infinitely scheduled and we don’t pay much attention to the resource group load scheduling graphs… In any case, I am chalking this one up as unknown. I know that this was an engineered job and it looks like the assembly they are having trouble with was sourced from an older quote. Maybe something was strange with the operation.
I am not sure.
Only other thing I can think of is that there was no calendar assigned to the resource group you deleted or it maybe had a special calendar with no hours - we use one like that when we are retiring resources so as nothing gets scheduled to it.
User name is a legacy from being a DJ in rocks cubs in the UK in the early 90’s. At the time the “rave” scene was at it’s height and had lots of dj’s with stupid names. One drunken night my friend and I came up with comedy rave dj names - can’t remember what his was but this was mine. Came back to me when I started creating accounts for use on the internet - only downside is folks make assumptions about where you stand on various UK political issues.
@mcfreedombaby There is a calendar assigned to the resource group so it is not that either. I am not sure what it was.
That’s just how it goes.
Does the calendar have hours that you can schedule against. In the resource group are the resources machines or people?
@mcfreedombaby the calendar is a 23 hour calendar and the resource group has resources that use the resource group values. They are “Machining Workforce” resources so I guess you could say they are people.
Sorry I was a bit vague - are the resources linked to shop employee accounts - just wondering if the linked employee account may have been deactivated
I don’t see any linked employees either.
Was there a fix to this? We are now seeing this in our environment.
Thanks in advance
Sorry Matt, I don’t remember how we resolved this.
Ok, thanks for the update anyways Utah.
When i see this error it is usually one of three scenarios
1.Resource is inactive
2.there are multiple resources linked to the same operation (in the example look to see if there are more than one Opdtl listed)
3. There is a scheduling constraint
I have checked all three points and it seems like none of them are on this job. It’s in our TEST environment as well, as we are in the process of implementing Epicor, so there are no other jobs tying up resources. We can process MRP against the sub-assemblies
within the machine we’re having issues with. Just only when we run MRP against the full machine do we have the problem. Working with an external consultant and will start with Epicor support as well.
I ended up posting to several similar themed threads and I can only add to one so here’s the link:
Just posting here as this issue has taken us weeks to resolve. Our steps to fix were:
- Clearing the autoreceive checkbox in the method. Auto receive can be left for the top level part.
- Changing the Operation start to finish.
- Checking the Operation had a description.
I have a strong feeling that step 3 was the fix as this item exists:
The update to the above, at least in version 10.2.400.5, is that the field is now ECOOpr.OpDesc.
i had to develop a BPM to stop checking-in any part revisions if it has auto receive ticked.