Can you share the PRB? The restriction is equally unacceptable for cloud and on prem.
1 Like
PRB0307586
Development Task TASK7459797 added to support this case.
2 Likes
I believe that.
1 Like
That doesn’t mean they need to put the shackles on everyone. Fix their shitty cloud hosting.
1 Like
Well…
Thanks everyone for bringing attention to this and for the detailed examples. I wanted to share an update: this issue has been logged as Epic ERPS-300291, and Development officially accepted it yesterday. It’s now assigned to a developer and being actively worked.
To clarify, this isn’t something specific to Cloud or On-Prem environments… it’s simply a feature gap that was identified that needs to be addressed. The root cause isn’t tied to deployment or infrastructure differences.
I’ll continue to monitor progress and will provide updates as soon as there’s movement or a fix available. In the meantime, there’s no need to take additional action on your end… we’ve got it in hand.
Appreciate everyone’s patience while we get this resolved properly.
5 Likes
2 Likes
Thanks for the update @timshuwy
1 Like
I want to provide a quick update and also clarify my earlier post. After further review, the item I referenced (Epic ERPS-300291) has been rejected, and that’s the correct call. The decision to change this behavior was intentional.
Here’s why: the “MRP and Scheduling” logging option goes far beyond what’s practical for a normal daily MRP run. This level of detail creates a separate log file for every unfirm job and includes line-by-line scheduling activity. While that’s valuable for deep troubleshooting, it can generate thousands of files and consume excessive disk space — on both Cloud and On-Prem systems. It also slows MRP processing significantly.
The intent of this option has always been for on-demand use when you’re diagnosing a specific scheduling issue, not for routine or nightly MRP runs. For daily execution, the Basic or MRP logging levels provide all the necessary visibility without the performance or storage impact.
I apologize for my earlier message suggesting this was a bug being fixed. After revisiting the original design intent with the development team, it’s clear this was a purposeful change to align with how the feature was meant to be used.
Thanks to everyone who raised the question and shared feedback — it helped us make sure the reasoning is well understood and documented.
3 Likes
We rely on the logs it generates when MRP runs off hours. We frequently are going and pulling those logs to investigate scheduling issues. MRP takes hours to run. How does it make sense to have to rerun it and wait hours for logs you could already have? That’s a huge waste off time.
This frankly isn’t Epicor’s problem to worry about for on-prem customers. We’ve never had an issue with disk space. A competent sys admin should be able to manage that. If the Epicor cloud team can’t that shouldn’t be my problem as an on-prem customer.
5 Likes
2 Likes
Just looked because I didn’t think this was valid. For the last 2 years it’s only 6 GB of logs. 6 GB. And we have tens of thousands of MRP logs. And if I cared I would runs some script to delete them after some period of time. But I don’t. It’s such a small amount of space that it’s irrelevant to worry about.
2 Likes
I raised the case with Epicor and was told:
Development had confirmed that the MRP & Scheduling logging level is only meant for debugging job specific scheduling results. Hence they would not be enabling that option for scheduled MRP runs.
As this is an intended change done by development,this would not be considered as a bug.
Please let me know if you have any queries.
I received this 2025-11-10 13:59:42.
And Epicor want 10% more for license fees.
And Epicor want £4,000 to plan at Revision level.
@timshuwy - I fear your efforts to engage with the community and work with us (which is very much welcomed and well received) is being over shadowed by Corporate Greed and Corporate Ignorance.
1 Like
@timshuwy - these logs have been available for 15 years+.
I and many others rely on these logs.
I have scripts that interrogate the logs and flag issues on a daily basis.
I am also on-prem so should be given the option to log to this level.
3 Likes
They are only changing it because their cloud team can’t manage logs in the cloud. @aosemwengie1 can tell you all about the saga of trying to get them to delete logs to clear up some space.
3 Likes
1 Like
I also use the full export on UATs to ensure there are no issues. I don’t normally run with full logging, but it is necessary for upgrade testing. (I’m also on-premise, so maybe it’s not an issue?)
Any relation to my pegging log growing out of control, despite being set to overwrite?
I’m in the opposite camp - I actually run MRP immediately (not recurring), and I don’t want the excess data.
I do have a case in for this. CS0005189596
I have raised a new case with Epicor ref this issue.
When I run MRP and use Filter to select either 1 or many Parts and set logging level to MRP and Scheduling, Logs are created but the logs are blank.
This is a great enhancement.
3 Likes
Idea.
Create a function that runs at x time everyday.
Define within this function to run MRP with the appropriate settings and logging.
This would restore the functionality that Epicor have removed for their benefit and not the usergroups.
Would this work?
2 Likes