# Concurrent request completes with Warning and an FDPSTP message > Source: https://netray.co/erp-help/ebs-concurrent-request-completed-warning-fdpstp > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer A concurrent request ending in Warning with a message mentioning FDPSTP means the underlying program's own completion status was not a clean Normal, and the post-processing step (FDPSTP) that handles printing/output is simply reporting that upstream condition. Always open the request log first - the real cause is almost always inside the program's own log, not in FDPSTP itself. ## Kind error ## System oracle-ebs ## Erp Oracle E-Business Suite (Concurrent Processing) ## Module Concurrent Processing ## Query Concurrent request completed with warning FDPSTP ## Alternate Queries - FDPSTP failed to load or run properly EBS - EBS concurrent request ends in warning fix - concurrent program completed with warning post processing ## Applies To Oracle E-Business Suite 11i, R12.1, R12.2 Concurrent Processing (FNDCPESR / FDPSTP) ## Steps ### Diagnose a Warning-status concurrent request **Items:** From 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. Check 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. For 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. For 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. If 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. Resubmit the request only after addressing the root cause found in the program log - simply resubmitting without a fix usually reproduces the same warning. ## Sections ### What FDPSTP actually does **Body:** FDPSTP is the standard post-processing routine EBS runs after a concurrent program's main executable finishes - it handles formatting and delivering the output (printing, saving to the output file, applying the layout template) and then rolls up a final completion status for the request based on what the executable itself reported plus whether post-processing succeeded. Because FDPSTP is the layer that sets the final visible status, a message referencing FDPSTP in the log is frequently just the messenger - the executable underneath it already completed with a warning-level condition, or with normal completion but zero rows/empty output, and FDPSTP is reporting that state rather than being the source of the problem itself. ### Distinguishing a real post-processing failure from an inherited warning **Body:** A genuine FDPSTP-layer failure looks different: printer errors, output file write permission issues on the concurrent manager's output directory, or a corrupted RTF/XML template for a BI Publisher-based report will show explicit printing or formatting errors in the log, separate from any data-processing messages from the executable itself. An inherited warning looks like the executable's own log lines describing a business condition (skipped records, validation failures, an intentional partial-success branch) followed by FDPSTP simply reflecting that status upward - read top to bottom rather than jumping straight to the last few lines of the log. **Code:** - SELECT request_id, phase_code, status_code, completion_text FROM fnd_concurrent_requests WHERE request_id = &request_id; ### Common executable-level causes behind the warning **Body:** For custom PL/SQL concurrent programs, a very common pattern is a developer explicitly setting a WARNING completion status when some but not all input records processed successfully, which is by design and should be resolved by fixing the flagged records, not by chasing FDPSTP. For Oracle Reports output, a data model that returns no rows for the given parameters is a frequent, easily overlooked cause - verify the report's parameters actually match data that exists before assuming there is a technical fault at all. ## 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. ## Ai Angle ERPray can read the full concurrent request log for a Warning-status request, separate the executable's own messages from the FDPSTP post-processing lines, and summarize in plain language whether the cause is a data condition, an intentional partial-success flag in custom code, or a genuine printer/output failure - saving the manual top-to-bottom log read every time a request ends in Warning. ## Faq ### Does a Warning-status request mean data was not processed at all? **Answer:** Not necessarily. Warning often means the program completed but flagged a non-fatal condition, such as some records skipped or validation exceptions logged, while most of the work still completed successfully. Check the log to see exactly what was and was not processed. ### Is FDPSTP itself ever the root cause? **Answer:** Yes, but less often than assumed - genuine FDPSTP-layer failures involve printer connectivity, output post-processor errors, or template/layout generation failures, which show distinct formatting or printing error text in the log rather than business-data messages. ### Can I safely ignore a recurring Warning status? **Answer:** Only if you have confirmed with the program owner that the Warning is an intentional, documented condition (common in custom PL/SQL programs for partial-success reporting). Otherwise treat every Warning as worth investigating in the log. ### Where do I check if the printer is the actual problem? **Answer:** System Administrator responsibility > Install > Printer, plus the specific printer's driver and style definitions; also confirm the concurrent manager's output directory has correct write permissions. ## Search terms concurrent request completed with warning, FDPSTP failed to load or run properly, EBS concurrent program warning status fix, fnd_concurrent_requests status query, EBS report zero rows warning, concurrent manager output printer error, set_completion_status warning custom program, Oracle EBS post processing failure --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json