Concurrent request completes with Warning and an FDPSTP message

Diagnose a Warning-status concurrent request

1. 1From Concurrent Requests, open the failing request and view the Log file first, not the Output - the log contains the actual program messages that caused the non-Normal completion.
2. 2Check whether the request's own executable (a PL/SQL procedure, a report, a Java concurrent program, or a host script) logged a warning-level condition, such as partial data processed, validation exceptions, or a non-fatal exception it deliberately trapped.
3. 3For Oracle Reports-based programs, confirm the report actually generated output - a report that produces zero rows or fails a data model query internally often surfaces only as a Warning at the request level.
4. 4For PL/SQL-based concurrent programs, check whether the procedure explicitly calls fnd_concurrent.set_completion_status with 'WARNING' - custom programs sometimes do this intentionally for partial-success conditions and the message is expected behavior, not a bug.
5. 5If the printer or output post-processing genuinely failed (for example, the assigned printer is offline or the output format failed to generate), check the printer definition under System Administrator > Install > Printer and the output post-processor log separately from the program log.
6. 6Resubmit the request only after addressing the root cause found in the program log - simply resubmitting without a fix usually reproduces the same warning.

Distinguishing a real post-processing failure from an inherited warning

SELECT request_id, phase_code, status_code, completion_text
FROM fnd_concurrent_requests
WHERE request_id = &request_id;

Common pitfalls

• !Treating every FDPSTP-mentioning warning as a printer or output problem without first reading the executable's own log messages.
• !Resubmitting the request repeatedly without addressing the underlying data or validation condition that caused the executable to set a Warning status.
• !Assuming Warning status always requires a fix - some custom programs intentionally use it to flag partial success and the message is expected, documented behavior.
• !Not checking whether the report or program simply returned zero rows for the given parameters, which is a data/parameter issue, not a system fault.
• !Overlooking printer configuration or output directory permissions when the log clearly shows a formatting/printing-stage failure rather than a data-stage one.