BAPI_PRODORDCONF_CREATE_TT — Mass confirmation BAPI for production and process orders
BAPI_PRODORDCONF_CREATE_TT posts one or more time-ticket style confirmations against production or process order operations, mirroring CO11N or CO15, including yield, scrap, actual dates and optional automatic goods movements. It processes each confirmation record in the input table independently, so RETURN must be read per record, and it does not commit the database itself; the caller must issue an explicit commit after checking for errors.
This page covers what BAPI_PRODORDCONF_CREATE_TT actually posts, which parameters carry the confirmation data and goods movement overrides, and why lazy RETURN parsing is the single most common source of silent failures in confirmation interfaces. It also separates the functional and technical ownership of confirmation errors so incident handling does not stall on finger-pointing.
Published 16 Sept 2026· 1,140 words
What it does
BAPI_PRODORDCONF_CREATE_TT creates confirmations against operations of production orders and process orders, mirroring what a user does in CO11N for a single time-ticket confirmation or in CO15 for order-level confirmation. It accepts a table of confirmation records rather than a single record, so it is the interface of choice for collective confirmation scenarios such as automated shop-floor feedback, PDC/MES integration, or mass upload of a shift's output. Each record posts an actual quantity confirmed (yield), scrap quantity, actual work and activity data, and optionally the confirmation type (partial or final). Depending on the control key on the routing operation and the order type customization, the confirmation can trigger automatic backflush of components, automatic goods receipt of the yield, and automatic activity or wage postings without any separate goods movement call.
Important parameters
- TESTRUN - simulation flag; when set, the BAPI validates and returns messages exactly as a real call would but performs no database update.
- Confirmation data table - one row per operation confirmation, carrying order number, operation and suboperation number, confirmed yield quantity, scrap quantity, confirmed activity values, actual start and finish dates/times, work center, and confirmation type; commonly referred to as the time ticket table in SAP documentation, though the exact structure name should be verified against the interface signature before coding.
- Goods movement override table - used when the interface needs to specify component consumption or by-product receipt manually instead of relying on the automatic backflush derived from the order and BOM; if omitted, the system applies whatever backflush logic is configured on the components.
- RETURN - standard return table, one entry per message raised during processing, carrying message type, message class and number, message text, and a reference back to the input record it belongs to.
Commit behaviour
The BAPI does not commit the database on its own. Like the vast majority of BAPIs in the confirmation and order-processing family, it performs the update work-process side changes and leaves the commit to the caller, who must issue an explicit database commit after inspecting RETURN for errors. If the caller forgets, the confirmation records appear to process without error inside the same logical unit of work, but nothing is written to the confirmation tables once that LUW ends; a subsequent read of the order will show it unconfirmed. This is a frequent cause of the report that the interface ran clean but the order status never changed, and it is almost always a missing commit rather than a BAPI defect.
Return handling
RETURN is the entire contract of this BAPI and it is structured per input record, not per call. Because the interface is collective, one bad order number in a batch of fifty does not abort the other forty-nine; each confirmation record is evaluated on its own, so checking only whether RETURN is empty, or checking only the first row, produces false positives on partial batches. Every row must be matched back to the input record it belongs to using the reference field carried in RETURN, logged individually, and only records with no error or abort message should be treated as posted. A message of type A (abort) is a different signal from type E (error): an abort means the surrounding processing cannot safely continue and the caller should not commit any part of that unit, while an isolated error on one record usually leaves the rest of the batch postable. Interfaces that swallow the distinction and commit unconditionally after seeing 'no hard error' end up with silently missing confirmations, silently skipped goods movements, or, worse, a commit issued after an abort that leaves inconsistent postings behind.
ECC vs S/4HANA
This BAPI remains valid and in active use on S/4HANA for classic order-based confirmation scenarios; the underlying confirmation data model built around order and operation confirmations has not been replaced. Some newer manufacturing scenarios expose confirmation through Fiori apps and manufacturing-oriented APIs aimed at shop floor and MES integration, but those sit on top of the same confirmation logic rather than superseding this BAPI outright. For custom point-to-point interfaces and data migration work, it is still the standard call; there is no officially documented successor that fully replaces its collective processing behavior.
Common pitfalls
- Order is already technically complete or the operation is already fully confirmed - the BAPI raises an error on that record, but interfaces that retry the whole batch blindly loop forever on the same rejected line.
- Control key on the routing operation does not permit automatic goods movement, or the component is batch- or special-stock managed - the confirmation itself posts successfully while the goods movement fails, and that failure often surfaces only as a warning-level message that a superficial RETURN check does not flag.
- Two interface calls confirm the same operation in parallel - both can succeed at the BAPI level because the order's status buffer has not yet caught up, producing a double confirmation that only shows up later in a quantity reconciliation.
- Posting date on the confirmation record falls outside the open fiscal period for the relevant movement type - this sometimes only errors at commit time rather than at the BAPI call, so a test-run pass gives false confidence.
- Confirmation posted against an operation whose predecessor operation has not been confirmed, in a routing with sequencing dependencies - accepted by the BAPI but flagged later during order settlement or variance analysis.
Whose problem this is
The interface loop, RETURN parsing, and commit sequencing are a developer problem. Whether a confirmation should trigger backflush, which control key governs the operation, and whether the order status legitimately blocks confirmation are functional configuration questions. When a confirmation 'disappears', functional needs to confirm order number, operation, and expected component movement; development needs to hand over the full RETURN log for that record, not a summary.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-bapis/bapi-prodordconf-create-ttERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.