Is there any way to allow the POHeader custom fields to be edited after the PO has been approved?
Our Purchasing department wants to have the ability to edit a custom date field to enter the date a confirmation email was received, but they don’t want to have to un-approve the PO, change the field, then re-approve.
The simplest way to do this is to use an UBAQ and unapprove then change and re-approve in the background. It works around Epicor and gives the user a quick way to update a lot of POs.
This thread goes over the process. @danbedwards shared his baq there. I have done this with code also.
Greg,
Thanks for the quick response and great suggestion! While that is definitely a great way of doing it, our staff are already going into the PO to add the PromiseDate and potentially memos on the PO, so it doesn’t make sense for them to go into a separate dashboard and update the custom date field. Some fields are editable even after the PO is approved, is there really no way that this can be done on custom fields too?
We do all of that in the UBAQ. There is almost always a way with a customization, but it depends on how many tricks you would have to do to make it happen. You could use a callcontext field on the screen and then do the same unapprove/change/approve in a bpm. There may be other ways to make a read only field editable, but I do not do a lot of customizations.
Thanks for the follow up. I’ll keep this in mind and see if that is something that our staff would be interested in doing.
I have done this a few times - against my will - in the customization. Basically it can be an unbound field that appears when the PO is in read only and then behind the scenes you can toggle the po approval, pass this value through the call context, and toggle the approve flag again.
That does work - just looking if I missed a step in the document. What version of Epicor are you doing this on?
10.1.400.20 and going to 10.2.400.8
Hi Al,
We’re in 10.1.600.20. I also have an updateable dashboard for date maintenance field updates that works with Dans suggestion of:
Before Base
1 - Set Approve = false
2 - Set ApprovalStatus = “U”
3 - Set ReadyToPrint = false
After Base
Do the opposite of above.
It was created in 2017 and my memory is a bit spotty on it. One thing I recall as important with it was that I only brought “approved” POs in for the date maintenance. I have this noted in comments in the code and I wonder if bringing or updating unapproved caused an error. Are you only bringing in dataset and trying to edit PO releases on approved POs?
Also, are you an authorized buyer for all buyers who have purchase orders?
Nancy
10.1.400 is the issue - I believe this is different and I am looking back at my previous versions. I know from 10.1.600 on works the way I published. @A.Baeisa I will post version for 10.1.400
There is a field called Promise Date on both the header and release that remains updateable even after approval. That is what we use to track ETAs.
Vinay Kamboj
The thread started out as updating custom fields - not promise date. Promise date was just mentioned as being able to do it one way but head to a dashboard to do the other fields.
Usd
An outside the box method would be to use a child UD table connected to the POHeader table, to hold the date value. Not as clean as adding a field right to the POHeader table, but may get around the “Read only” aspect of Approved PO’s.
Good morning @Nancy_Hoyt, and @danbedwards,
Thanks for your replies guys, i have put a condition to carry on Dan BPM design only if PO approved, as well as not using adding new record nor update multiple rows, as i want this to run after each single row update and alert users at each line if there is a problem rather than error out at later stage of updating many rows plus i know this will require a different modification approach to add to the uBAQ/BPM, also i am aware of the authorised buyers and limit restrictions, and i am not violating any of these BO logics, so may be it is my Epicor version 10.1.400.20 as Dan suggested, i will do it in the new version 10.2.400.8 and let you know.
Many thanks again for both of you
Al
Thanks @ckrusen,
yes i use this method sometimes to avoid such issues, but the problem here is that there is already UD field in PORel and it has been used and users want what is contains, so to do this i need to move everything in it to the linked child UD table/filed, that is why i wanted to try Dan easier solution first.
Something I have done in the past is make that field editable, then store the value in BPMContextData along with a flag indicating that it needs to be updated. Then add a BPM that will test that flag, update the value on the record (outside of the Epicor Business Logic.) and clear the flag. I did that on the Time Approval screen to allow them to update a comment field while all the other data is readonly.