Approvals Critical Field - Orders Still Requiring Approval

KKJ70

Well Known Member
We have our procurement approval critical fields set to only Extended Cost AEXP, Sub Type, Pymt Terms, Account Number and Sub Ledger - these are the fields to trigger the approval process again.

Orders are still being sent through for approval again if any of the delivery dates are changed. I have checked and double/tripled check the setup and the dates are not selected for the critical fields.

Is there something else, somewhere else that needs to be addressed?

~Kelli
 
A change to one or more of the following fields will cause an order that is at an approved status to go back through the approval process.

Extended Cost (AEXP)
Account Number (AID)
Subledger (SBL)
Subledger Type (SBLT)
Landed Cost (PDP5)
Promised Delivery Date (PDDJ)
Requested Date (DRQJ)
Payment Terms (PTC)
Discount Factor (DSPR)
Project Business Unit (OMCU)


Thanks,
Matt
 
Thanks for the quick response, Matt!
Making sure I understand:

Regardless to how the fields below are setup in approval critical fields, the system will still send an order thru for approval, if any of the below fields are changed, correct?
-

[ QUOTE ]
A change to one or more of the following fields will cause an order that is at an approved status to go back through the approval process.
-
Extended Cost (AEXP)
Account Number (AID)
Subledger (SBL)
Subledger Type (SBLT)
Landed Cost (PDP5)
Promised Delivery Date (PDDJ)
Requested Date (DRQJ)
Payment Terms (PTC)
Discount Factor (DSPR)
Project Business Unit (OMCU)


Thanks,
Matt

[/ QUOTE ]
 
Is processing option #4(Reapprove Changed Lines) on the Approvals tab in P4310 set to '2'?
Is the Approval Field Constants table (F43080) table populated?

If either of the above is not true than P4310 will default to checking for the fields mentioned in my earlier post.

Thanks,
Matt
 
P4310 Processing Option Approvals, #4, is set to 2.

The F43080 table is populated. See attached file for SQL query of F43080.

Thanks.
~Kelli

[ QUOTE ]
Is processing option #4(Reapprove Changed Lines) on the Approvals tab in P4310 set to '2'?
Is the Approval Field Constants table (F43080) table populated?

If either of the above is not true than P4310 will default to checking for the fields mentioned in my earlier post.

Thanks,
Matt

[/ QUOTE ]
 

Attachments

  • 157252-F43080.xls
    19 KB · Views: 197
<font color="blue">I have made some progress.
smirk.gif
The Override Next Status in P4310, Defaults, was set to blank. I revised that and it will now allow the date changes and not go through the reapproval process.

BUT

If the date is changed while it is awaiting approval, at 230 status, it changes the Next Status to the Override value - bypassing approval.
frown.gif


- Is the only way to address changes during approvals is with the Approval Hold Code?

- I understand a separate process must be performed to release it from hold once it is approved. Is it possible to code the process to release it from hold automatically when the status advances out of approval?

~Kelli</font>

[ QUOTE ]
P4310 Processing Option Approvals, #4, is set to 2.

The F43080 table is populated. See attached file for SQL query of F43080.

Thanks.
~Kelli

[ QUOTE ]
Is processing option #4(Reapprove Changed Lines) on the Approvals tab in P4310 set to '2'?
Is the Approval Field Constants table (F43080) table populated?

If either of the above is not true than P4310 will default to checking for the fields mentioned in my earlier post.

Thanks,
Matt

[/ QUOTE ]

[/ QUOTE ]
 
You should refer to doc id 625683.1 on the Oracle support website. It explains this very well.
The Override Next Status processing option sets the status for the system to override the next status on all lines in the purchase order. If both the Override Next Status processing option and Approvals processing options are populated in one version of Purchase Order Entry (P4310), the Override Next Status functionality will be used, and Approval Processing will not occur.
Approvals processing options include the Approved and Pending Approval Statuses. This set of processing options allows the system to determine whether the lines on the order will be set to the Approved status or the Pending Approval status.
When approval processing is activated the system should determine what the correct next status should be based on the approval logic.

Thanks,
Matt
 
Success!!!! Finally.
smile.gif

The missing segment was the 230 and 280 status codes must be setup for each status from the approval status. (which was a 2 line side note in the document suggested by 'pfd'
wink.gif
). Once those were added, dates and other areas not on our approval critical fields could be changed and not re-routed through the approval process.

Thanks for all your help.
tongue.gif
 
Has anyone experienced the following? When a line is cancelled on a multi line order the rest of the lines goes back to 230.

I managed to cancel the line without the rest of the lines going back through approval. which is fine. However, when I change the quantity on any line only that line goes to 230 not the rest of the lines. The objective is to cancel a line without invoking approvals again but when a price or quantity is changed all the lines needs to go through approval.

Any thoughts please?
 
Has anyone experienced the following? When a line is cancelled on a multi line order the rest of the lines goes back to 230.

I managed to cancel the line without the rest of the lines going back through approval. which is fine. However, when I change the quantity on any line only that line goes to 230 not the rest of the lines. The objective is to cancel a line without invoking approvals again but when a price or quantity is changed all the lines needs to go through approval.

Any thoughts please?

The functionality changed in release 8.9 and higher to keep all lines in synch upon a change. If you in a lower release than that, then that would be standard functionality to have only the single line update.

If you are in 8.9 or higher, then I would check the "Override Next Status" processing options on the Default tab to make sure that is not populated.
 
Thanks. Marcia. We are on 9.2. The override status is blank The critical fields in approval processing is set to 3.
The next status on the Order Revision tab is blank. I removed the last status in the P43080 ( Critical Fields) and made it blank. When I cancelled one line on a multi line order, all the other lines went to a next status of 230. When I entered a next status of 230 on the Order Revisions tab, only the first line was cancelled which is great, However when you make a change to a line on the order e.g. increasing the quantity, the next status stays at 280 or only that line would change to 230. I may have to create a separate version of P4310 that only purchasing can cancel lines.
 
You should refer to doc id 625683.1 on the Oracle support website. It explains this very well.
The Override Next Status processing option sets the status for the system to override the next status on all lines in the purchase order. If both the Override Next Status processing option and Approvals processing options are populated in one version of Purchase Order Entry (P4310), the Override Next Status functionality will be used, and Approval Processing will not occur.
Approvals processing options include the Approved and Pending Approval Statuses. This set of processing options allows the system to determine whether the lines on the order will be set to the Approved status or the Pending Approval status.
When approval processing is activated the system should determine what the correct next status should be based on the approval logic.

Thanks,
Matt

Hi Matt. I can't seem to access that doc id 625683.1. Is it possible to send it to me?

Thanks.
 
Hi Mark,

How can I set up P4310 not to send the order back to approval process if I cancel one line? ( More on the requisition side) or if I change the amount of a line to be less than the original amount, I do not want to restart the approval process
 
Success!!!! Finally.
smile.gif

The missing segment was the 230 and 280 status codes must be setup for each status from the approval status. (which was a 2 line side note in the document suggested by 'pfd'
wink.gif
). Once those were added, dates and other areas not on our approval critical fields could be changed and not re-routed through the approval process.

Thanks for all your help.
tongue.gif
Hi, I want JDE not to send the approved order to re-approve process again when promised delivery date is changed. How can I do this? Thanks in advance
 
Debe consultar el documento ID 625683.1 en el sitio web de soporte de Oracle. Explica esto muy bien.
La opción de proceso Anular estado siguiente establece el estado para que el sistema anule el estado siguiente en todas las líneas de la orden de compra. Si tanto la opción de procesamiento Anular estado siguiente como las opciones de procesamiento de Aprobaciones se completan en una versión de Registro de órdenes de compra (P4310), se utilizará la funcionalidad Anular estado siguiente y no se producirá el procesamiento de aprobación.
Las opciones de procesamiento de aprobaciones incluyen los estados Aprobado y Pendiente de aprobación. Este conjunto de opciones de proceso permite al sistema determinar si las líneas del pedido se establecerán en el estado Aprobado o Pendiente de aprobación.
Cuando se activa el procesamiento de aprobación, el sistema debe determinar cuál debe ser el siguiente estado correcto en función de la lógica de aprobación.

Gracias,
Mate
Hola Matt, estaba interesado en ver el documento ID 625683.1 pero no puedo encontrarlo. ¿Ese número de identificación es correcto?
 
Back
Top