By SamanthaF-Oracle on Sep 05, 2014
What has changed?
The Invoice Validation concurrent program is now equipped to spawn multiple child requests based on the Purchase Order matched invoice load and the newly seeded profile "AP:Maximum Invoice Validation Child Requests".
The user continues to submit a single Invoice validation program with his/her preferred parameters but internally the program groups the invoices matched to same Purchase Orders and ensures that each such group is processed by a single child request.
Whereas for invoices that are not matched to any Purchase Orders, the system distributes these invoices equally amongst the maximum number of child requests spawned (as per the value set by the user in the aforementioned profile).
Why the change?
1) The current invoice validation concurrent program was not scaling up for high volume of invoices.
2) If multiple requests of the invoice validation concurrent program are submitted and invoices matched to the same Purchase Orders are processed by two or more requests then there are possibilities of lock contention errors on PO_HEADERS_ALL in any of the requests that concurrently attempts to update the PO object.
3) To avoid conflicts, user had to wisely select the parameters at the time of submitting the concurrent program or have conflict domains defined that constrained the program to execute serially.
4) Submitting multiple requests of the program causes an overhead of reviewing multiple log files and outputs.
R12: New Functionality Invoice Validation Parallel Processing (Doc ID 1917614.1)
If you have any questions on this new functionality please use the community thread