Logging changes to Forecast.ConsumedQty field

Hi all!

We have enabled the change log on the Forecast table (on all fields). It properly logs new records and all changes users make in the Forecast menu to forecasted quantities and the inactive checkbox. But it does not log changes to the ConsumedQty field (again, it’s included in the log!). This field cannot be edited directly by users, instead it’s updated by the MRP/Generate Suggestions process. Any idea why this does not trigger the change log? Any ideas how one could enable change logs to this field?

The reason I am asking is that the ‘rock stars’ in our sales department sometimes move sales order dates that consumed forecast. Of course they don’t tell their ‘roadies’ in plannering and purchasing, and this then can cause issues. Monitoring the ConsumedQty field through the change log might be a step to support them.

Best regards from Germany,
Thomas

If the change log is having issues, have you thought of sending an email or writing to a UD table instead when your sales people are moving order dates around? This might be the easiest solution if the change log is having unexpected behaviour.

Sending emails when moving SO dates would have been solution #2 in my list but I’d like to avoid this. Reason is, that this might trigger false alerts when our sales team is reshuffling their orders (happening way too often). This would send emails if e.g. one SO being moved out of a forecast period but may not catch if then another SO for the same part will again consume the forecast. Someone checking may get confused. Instead of emulating the business logic I’d prefer to have the system calculate the consumed qty and me just piggyback on that.

Re: the UD table idea, can you explain what you mean to do here? I am the admin for quite some time now, but still feel that I just dipped by feet in the customization pool. Never worked with UD tables, only saw someone doing magic with them at various Insights classes :astonished:

You’re able to create new rows (either through widgets or custom code) in a UD table (e.g. UD01) and some people will use this as a logging method.

I could see this also being the case for change logs. How have you setup your change logs?

I think this statement tells your story. A Change Log (I’ve always assumed) is triggered by a User action. The log then records the change and the User responsible.

As you stated, ConsumedQty is not a field that can be edited directly by users. Its not a USER changing the value, it is the MRP engine. Its basically a calculated field.

If you want alerts when the value changes, you may be able to do this with a BPM on the Forecast BO.

Or, potentially create a BAQ / Report that queries the Forecast table (and whatever else you need) on a regular schedule. You could schedule that report to run after MRP runs on your desired frequency. That report could then be emailed out via Advanced Print Routing, etc. Daily, weekly, monthly… I don’t know what frequency your users would appreciate receiving forecast updates, That’s up to you and your organization.

If you want to keep RECORDS of the value changing, than, yes, I agree that you’d probably have to tap into a UD table.

1 Like

Thank you Eric and Dave for your answers!

To Eric’s question re: logging: Not sure, how this was done but I think a consultant enabled logging on the Forecast table for us (before my time). It’s working on most fields users can change via the menu but not on the system calculated ConsumedQty field…

I think, I will try the BAQ report solution. There is the PrevReqDate on the OrderRel table that offers some history to employ here, i.e. checking if the PrevReqDate was within a forecast period and the (current) Req being out of that forecast period. If so, I will show my team all results where the forecast ConsumedQty related to the PrevReqDate is greater than zero, so they can check (the report then would need to run after our nightly MRP). However, this is some kind of reverse engineering and anticipating on what the system may or may not do. But after a quick check I see only a few such cases in our system. and this way, I can push back some responsibility back to the data owners :wink:

Again, thanks for your replies. This helped me a lot!

1 Like

Own It GIFs - Find & Share on GIPHY

Hi Thomas, we use Epicor in Germany as well and we have some specific german things and would like to know your experience about it, maybe we can learn from each other or work together on some processes to improve it on EPicor? Can we get in touch? I tryed to find you on Linkedin, without success. Best regards Erika Krauter