PO Req - By pass the approved status limitations.

Has anyone had any luck allowing saves to the PO Req Lines form even in approved status when cost has not changed? The PO Req Limit on the users form is stopping us from allowing buyers to make updates after Approved.

We would like users to be able to make changes to PO Req Lines for any status except Complete, unless it changes the PO Req Line Amount like Item, Qty, Cost. If that isn't' changed we would like the user to be able to save even if their req limit doesn't meet the criteria for changing to approved status. For example, if we need to update the Destination of the PO Req Line and it is in Approved Status. Or update the Vendor before Converting to PO.

We are in Syteline CSI 10 On-Prem.

0911060553270289.pdf

Find more posts tagged with

General Discussions

Accepted answers

All comments

Ryan Pukanski

We have customized the procurement side quite a bit. Currently, the limit checking, etc is all handled via a SQL trigger on preq_mst and preqitem_mst, so you would need to modify that coding. We edited the code so that stuff is editable as long as item, qty and cost do not change. You also have to change the form logic so that items in approved status have certain fields that are opened up for editing.

mtolliver

That sounds like exactly what I am trying to do. Do you mind sharing how you change the code to allow you to edit those fields?

Ryan Pukanski

There are two things you need to do. First for the form you would need to change the form script. Get the name of the component you need to edit and then find that name in the script. For example, the destination type is RefTypEdit and in the form script you can see code that determines if its enabled or not:

Secondly, you will need to edit/create your own trigger on the tables because thats where the approval logic comes in when you save. Check preqitem_mst_Iup. We added some code doing some compares.

Here is where the system checks the approval amount:

EXEC @Severity = dbo.MsgAppSp @Infobar OUTPUT, 'I=IsCompare'
, '@user_local.preqitem_limit'
, @UserLocalPreqitemLimit

We added a line of code so that if the status is A and the old status is A (aka no status change) then dont run the limit check.

IF @PreqitemStat = 'A' and @OldStat = 'A'

EXEC @Severity = dbo.MsgAppSp @Infobar OUTPUT, 'I=IsCompare'
, '@user_local.preqitem_limit'
, @UserLocalPreqitemLimit

Hopefully that gets you started on the right track.

Thanks
Ryan

UPD - dEPM-684- Mapping Enhancements.mp4

Ryan Pukanski

Sorry - Correction

IF @PreqitemStat <> 'A'

EXEC @Severity = dbo.MsgAppSp @Infobar OUTPUT, 'I=IsCompare'
, '@user_local.preqitem_limit'
, @UserLocalPreqitemLimit

This will tell the system that if the status is not A then you need to check the limit. Othewise, bypass the check.

mtolliver

Have you had any issues with uplifting your environment with your modified triggers? Our consultants are advising that we should not be modifying triggers to get the intended results, I am unaware of any other way to bypass the trigger to allow edits since it is not controlled in the form itself. What is your experience with working with Infor or doing uplifts and modifying the triggers?

Infor HRCM - Stay Prepared, Engaged, and Informed - HRCM v20.1 Web.pdf

Ryan Pukanski

Yup. Every uplift we use winmerge to compare new infor code to old and to merge the customizations in the trigger. We only have 3 modified triggers currently. And we only uplift twice a year so its not too much work for us. But we try to use the event system whenever we can.

Kind of hard to not modify the trigger when its the only source of business logic that you need to change...

Copyright © 2025 Infor. All rights reserved.