We are trying to create an update-able dashboard that will let us un-approve a PO, update the Promise and Due Dates, and then re-approve the PO. We currently have POHeader.Approve, POHeader.ApprovalStatus update-able to change the PO from Approved to Un-Approved. The problem is if I have a PO that is currently Approved, I then change the POHeader.Approve checkbox to false and the POHeader.ApprovalStatus to a “U”, click on save, click refresh on the dashboard, and then try to update the date fields, I get the following error, " The PO had been approved, changes are not allowed" I almost think because their is logic going on in the PO Entry screen when you Approve/UnApprove a PO that a update-able BAQ just can’t duplicate those same steps it appears and are dashboard may not be possible.
I believe you can achieve what you are after, UBAQ’s are kinda hammer like in their approach, they wont call out sequential methods like you were in a form…unless you customize your method calls within the UBAQ via code etc… Out of curiousity, have you tried to just unapprove, save, refresh the dashboard, make your other changes, save, refresh, then approve etc… not the work flow you’re after I’m sure but it would prove functionality. Be similar to the issues you’d have if you wanted to make changes to an engineered job through a UBAQ, you’d have to address the sequential steps of unreleasing and unengineering the job. You’d have to hijack the update method and insert your own logic, where there are certainly some pitfalls when you are talking about overriding base methods. You could try unapproving in preprocess, then basically update your changes in a post and then re-approve after that.
Won’t that workflow be kind of wonky through an updateable dashboard? Are you thinking you will unapprove the PO and update all the due dates through the same dashboard, then re-approve? Where I would see this becoming complicated would be when a PO has more than 1 line or 1 release. You would have to have some for Firsts in the code to undo the PO header (or C# that will uncheck all the approve checkboxes for each line) and then a for each to update all the due date/promise date on the PO Rel table (which you will also need to add).
Assuming only the due date is updated and the $$ doesn’t change it won’t need to go through approval again. This probably isn’t best practice and probably not epicor recommended, but you could write code in the updateable BAQ which just updates the porel table. It bypasses all the business logic but will allow you to update the dates without having to unapprove/reapprove. Super Epicor wizards please chime in regarding the magnitude of how bad an idea this can be.
We have a similar problem with large POs and our solution has been to put a C# button on the po summary tab with a Date field. You put a date in the field, click the button and it updates all open lines to the new due date. I’d be happy to share if you think that will help. Probably a better option than above.
Just some thoughts. Maybe if you explain how you want to update the dates from the dashboard more it will generate some additional ideas.
RBucek - Yes we have walked thru the steps you mention about unapproving/saving, refresh, etc. When we try to update the date fields, that’s when we get the ‘PO Had been approved’ error.
balmon - That’s the feeling that I get. Because inside of PO entry when you unapprove or approve a PO, it actually sets the approval for each PO Line and Release. Their is a second field named POHeader.ApprovalStatus that also changes from a “U” to a “A” which is a second field stating if it’s approved or not. The challenge has been trying to update the POHeader.Approve field and the POHeader.ApprovalStatus fields at the same time and then go in and try to make the changes to the date fields. For some reason when we change the POHeader.Approve field, the POHeader.ApprovalStatus will not change, and I think this might be where the hang up is as it sees the line is unapproved but the approval status still shows it is approved, but that’s just my guess.
Basically we want a dashboard that shows all open POs. We then want to be able to update the promise date and the due dates for each release for each PO. Now if a PO is approved, we want the ability to un-approve that PO, go in and change the two date fields, and then re-approve the PO, no different then doing it inside of PO Entry. The main reason for the dashboard is to show us all of our open POs so that we can update a bunch of them by just going down the dashboard and selecting the POs, unlike PO entry when you can only load one PO at a time in the screen.
I had started a dashboard like this, but have not finished. I brought up the baq I made and tested and there are two ways in the baq to update the dates.
Do an advanced bpm processing only and update the fields. Code below.
Do a pre-processing bpm to unapproved and a post processing to reapprove. In the baq attached.
Greg
/* update PORel */
def var buyer as logical init false.
define variable InfoMsg as character init ‘’.
define variable Msg as character init ‘’.
For Each ttResults where ttResults.RowMod <> ‘’ on error undo, next:
For each PORel where PORel.Company = cur-comp and PORel.SysRowID = ttResults.PORel_SysRowID exclusive-lock.
For first PurAgent where PurAgent.Company = cur-comp and PurAgent.BuyerID = dcd-userid.
If PurAgent.InActive = true then next.
Buyer = true.
End.
If Buyer = false then Do.
InfoMsg = "Only Buyers can update".
{lib/PublishInfoMsg.i &InfoMsg = InfoMsg}.
End.
If Buyer = true then
PORel.CheckBox01 = ttResults.PORel_CheckBox01.
PORel.DueDate = ttResults.PORel_DueDate.
PORel.PromiseDt = ttResults.PORel_PromiseDt.
End.
I think we’ve accomplished PO updates you are trying via a UD table and code…( instead of a UBAQ).
I will look later & if I can collect the details will post them.
Also, do you have the DMT?
I remember using it to update PO’s… I think it required multiple templates.
i.e. to maintain a similar sequence to what Rob described previously.
I was thinking something very similar to what gpayne wrote up. I would write the first line a little different though, just to make sure it applies to all porel lines and not just one, and only open lines as well.
for each ttresults no-lock where ttresults.romod <> ""on error undo, next:
for each porel exclusive-lock where porel.company = cur-comp and porel.openline (not sure if that’s the right field name) = true and porel.ponum = ttresults.poheader_ponum.
something like that you should be able to update all the PO Rel lines to your new date by only changing it once in the dashboard. if you put that code in the update method, then I don’t think you even have to unapprove/re-approve it, in which case your code should check to make sure the PO is not pending.
How are you trying to do this? Posting the ABL code from the BPM, whether it was created in simple or advanced mode, will help. If you created it in simple mode, you can switch to advanced mode to look up the code that was created.
It sounds to me like there is some mixup in the processing order. For example, you tell it to change the approved, status, and date fields, but maybe the BPM is trying to do it all at once or change the date before approval instead. This can happen because of processing in the background with the objects. Calling the object methods can set up the temp tables, and it may be trying to write the temp table at the end.
It may be necessary to go into advanced mode and separate the BPMs into different BPMs (such as 3 pre-process BPMs), so that the objects are written in between each BPM and the processing in the background is not confused.
I would try to stay away from the UD table customizations if you can… this is what temporary tables are for, and things are much neater without two sets of tables and temporary talbes, not to mention processing time. The route this thread is going looks to be a better way, if it is ever solved.
It seems to me that this is a good direction, as it addresses the order of change. However, I would be wary about using code to alter the Approval Status directly; using a method is preferable for at least the approval step in this case. If you use tiered approvals, a PO with an amount higher than the buyer is authorized should go into a pending state and go through a more complex workflow. I’m not familiar with that workflow and it appears that this code does not consider it either.
We were able to accomplish this by writing a BPM that lived in the same BO and Method that the dashboard does to set the approval field to true or false. Only drawback is the users have to go through several steps to approve and un-approve the POs in the dashboard and update them. It is a tedious process and we aren’t sure if we are going to stay with it because it really isn’t saving us any time. Thanks for all of the help and suggestions.