Skip to main content

Hi Community,

This is for IFS 9 Enterprise Explorer 

 

Currently on the manual supplier invoice screen, when copying unmatched PO receipts from a referenced PO, users are able to manually override a tolerance check while matching PO receipts per line (please see the attached image). We would like to disable this functionality, and abort the process once the tolerance has been exceeded. We don’t want the user to be able to save the supplier invoice at all once the tolerance has been exceeded.

 

Is there any way to anyones knowledge that we can accomplish this? 

We were considering creating a custom event to check the tolerance again at the time of the manual supplier invoice creation, but if we could do something at the point this pop up appears that would be preferable.

 

Any other suggestions to solve this issue are also welcome.

 

Thank you

Hi, 

Long long ago … far far away, I found an option in security (database objects) that stopped a users ability to continue with an OK.   Since then, I have been unable to search for the database objects in security in our R&D reference environments.  So, I can’t send image or even proof that it still exists. 

It did exist 95% certain of that, but I can’t find previous emails showing how to fix, nor can I search and find it.  So… I believe the option still exists in security / database objects, at least nobody has told me the option no longer exists.    

Sorry I could not find the actual object,  I tried. 

Best regards, 

Thomas

Hi @Edwards ,

There is no facility to prevent a user to post the invoice when it is over the set up tolerance.
This particular concern has been in discussion for quite a while now. IFS Product Development team’s advice is to prevent potential bypassing through a custom event, or by performing required changes through user's base profile so they would not have subsequent access to change the value in order level.

We cannot restrict/hide related database columns using a permission set as well, but we can revoke access to method calls that the user invokes while using “Over Delivery Tolerance”. But this would not be the solution as the same method can be used in another process.

It is possible however to have extra steps to have the posting being authorized. You can use “Posting Proposal” functionality. It will require posting authorization regardless of the tolerance.

There is a Community Idea created for this same concern:
 


You can upvote and add your comments to the thread to support the idea, so that IFS Product Development team can consider it for a future release.

Hope this helps.

Kind regards,
Dinushi

I ended up taking the custom event route. As it still allows users to match POs as long as it falls within tolerance it seems like a workable approach for now. Thank you for the replies and suggestions.

 

Lavon

Hi @Edwards ,

There is no facility to prevent a user to post the invoice when it is over the set up tolerance.
This particular concern has been in discussion for quite a while now. IFS Product Development team’s advice is to prevent potential bypassing through a custom event, or by performing required changes through user's base profile so they would not have subsequent access to change the value in order level.

We cannot restrict/hide related database columns using a permission set as well, but we can revoke access to method calls that the user invokes while using “Over Delivery Tolerance”. But this would not be the solution as the same method can be used in another process.

It is possible however to have extra steps to have the posting being authorized. You can use “Posting Proposal” functionality. It will require posting authorization regardless of the tolerance.

There is a Community Idea created for this same concern:
 


You can upvote and add your comments to the thread to support the idea, so that IFS Product Development team can consider it for a future release.

Hope this helps.

Kind regards,
Dinushi

Hello,

Glad if you could mark this as the best answer if it answered your question.
Thanks!

Kind regards,
Dinushi

Terms & ConditionsCookie settings