@Björn Hultgren Thank you for the explanation. We currently do not have this enabled for our Inventory Parts. Is this functionality typically turned on? I would think that if you frequently over run production, you would want to enable this so the operation qty is accurate on succeeding operations?
@Björn Hultgren We currently have our work centers set to automatically receive on the last operation step. Would manually receiving the Shop Order increase the Lot Size to match the completed qtys on the operation steps?
Thank you @william.klotz !
UPDATE - The access needed is “ADMINISTRATOR” from the System Privileges tab in Permission Sets.
@matt.watters ha, well duh, thank you sir!
@IRituma Thank you very much for the clarification!
@IRituma Thank you for the clarification, I understand the Cost Set calculation now. The last item I am unsure of is the Cost Set Est Mtrl Cost field. What would this be used for if you’re using the Estimated Material Cost from the Inventory Part record?
@IRituma I have followed the process you’ve outlined, however, the Cost Set 3 value is still identical to the current cost (found in Cost Set 1). It has not updated to the $2 that I’ve indicated on the Part Cost.
@AsankaGaru Thank you! That was it!
After review, there were discrepancies as the Est module pulls existing SFPP prices, not cost of existing PNs.
@Björn Hultgren Thank you for the recommendation, I will add it
@Björn Hultgren Thank you very much for the clarification. It seems very odd that you cannot control that, as it can lead to very inaccurate inventory levels if a simple transactional error is made. I had hoped there was a similar feature to prevent over report. Either way, thank you for the explanation!
We were able to resolve this issue by performing a Calculate Resource Capacity on those individuals.
@Mathias Dahl Haha yes, i should have known!
UPDATE - I discovered what the issue was. We had a custom Event Action written that was attempting to send an email. When I disabled that, it stopped the error.
It appears to be impacting any user that attempts to reject an approval step when it is under Document Management > Document Revision It will return the same error and input that user’s email address.
@Mathias Dahl Yes, the user does have the person connected to it.
@majose Excellent!!! Thank you for the follow-up!
UPDATE - the case has been closed as we have not been able to replicate the issue. Not sure what the culprit was, but will have to reopen case if it occurs again.
@Björn Hultgren Thank you for checking! I’ve just opened a case with IFS. Will report back the result of the case.
@Björn Hultgren I thought that same thing. As I was reading through the help, it seemed to indicate that this was done intentionally by IFS: This seems to make no sense though, as the field is an LOV and the Scrap Part does not behave in this manner. This system behavior would lend itself to continual errors as employees keyed incorrect data in.Regardless, I will open a case with IFS to see. Thank you!
@majose I will. Thank you!
We have also enabled Lot Batch tracking, and the lots in the system are not using numerical.
Hi, yes, you are correct! The part is using a prototype structure with the “P” in the revision number. I have opened a case with IFS support.
@Björn Hultgren Thank you very much! I completely missed that checkbox!
Already have an account? Login
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
