Does anyone know how the Previous Due Date field in the PO Rel table works? Would like to use the field to record the original Due Date of the PO if any changes are made to the Due Date.
Previous Due Date PO Release
Userlevel 2
I did a simple test in our Pilot environment. I picked an open PO and using either SSMS or a BAQ, I noted the PORel.DueDate field, PORel.PreviousDueDate and PORel.ReqChgDate field. I had to unapprove the PO, then I could change the PORel.DueDate. Saved and queried the PORel table again. The DueDate changed as expected, the PreviousDueDate remained NULL. However, I did notice that the ReqChgDate field was changed to the previous DueDate. Per the data dictionary for ReqChgDate field, “When the Due Date is changed, this is the previous DueDate. (originally was "Requested pending date change")”
If I change the DueDate field again, the ReqChgDate field updated to last DueDate field.
Hope this helps.
Userlevel 2
Isn’t what you are trying to do the same as what Epicor does with the ReqChgDate field? When you change the PO Release due date from say, 2/3/2022 to 2/10/22, Epicor is copying 2/3/2020 to the ReqChgDate field. The ReqChgDate field is populated is the previous DueDate field.
As time permits I will look at your BPM.
Userlevel 2
Isn’t what you are trying to do the same as what Epicor does with the ReqChgDate field? When you change the PO Release due date from say, 2/3/2022 to 2/10/22, Epicor is copying 2/3/2020 to the ReqChgDate field. The ReqChgDate field is populated is the previous DueDate field.
As time permits I will look at your BPM.
Yes and no in answer to your question. The ReqChgDate will be updated every time the Due Date is changed. We only want it to copy the original Due Date into the Previous Due Date field no matter how many times the actual Due Date is updated. It is a way to measure our suppliers on their performance.
Hi Daniel. I understand. I can get a BPM to write to the previous date field but, the trick is capturing the due date before the user changes it. If I Set the ttPORel.PreviousDueDate field of the changed row to the ttPORel.DueDate, it will copy the changed Due Date and not the original one. (Used a Show Message box as the first step in the BPM to see what the fields are, tt duedate, tt reqchgdate tt previousduedate)
Condition;
The ttPORel.RowMod field of the changed row is equal to the “U” expression.
And the ttPORel.DueDate field has been changed from any to another.
And the ttPORelPreviousDueDate field of the changed row is equal to the null expression.
Action;
Set the ttPORel.PreviousDueDate field of the changed row to the ttPORel.DueDate field.
the above copies the changed due date and not the original due date. Not what you need.
If the PORel.DueDate had never changed, we could Set the ttPORel.PreviousDueDate field of the changed row to the ttPORel.ReqChgDate field. This would capture the original due date that was written to the ReqChgDate field. Of course this won’t work if there is already data in the PORel.ReqChgDate field from a previous change to the due date field.
A completely different approach might be to create a UD field on PORel table, OriginalDueDate. Then a BPM could be written for when a new PORel is added, Set the ttPORel.OriginalDueDate field of the added row to the ttPORel.DueDate field.
This would give you a field that won’t change with the change of the Due Date. Then using the above condition and action, change the action from
Set the ttPORel.PreviousDueDate field of the changed row to the ttPORel.DueDate field.
to
Set the ttPORel.PreviousDueDate field of the changed row to the ttPORel.OriginalDueDate field.
Maybe someone else can come up with an easier way.
Userlevel 2
You know what i think you are right with the UD field. Looking back i think i had to do something similar in a previous company i was in. It was similar to what they wanted but could not get the Previous Due Date field to work.
Reply
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.