BAPI_CUSTOMERRETURN_CREATE — Creating Customer Returns via BAPI

BAPI_CUSTOMERRETURN_CREATE creates a sales document of the returns category, the object VA01 produces when the returns order type is selected instead of a standard order type. It sits at the front of the reverse logistics leg of order to cash: a return order is created first, then a return delivery is posted against it, goods come back into inventory, and a credit memo settles the customer account. The BAPI accepts the same shape of data as a standard sales order create call - header attributes, item lines with materials and quantities, partner data, and schedule lines - plus a reason for return at item level and, where relevant, a reference back to the original sales order or billing document being returned against.

The interface mirrors the standard sales order create BAPI structure closely, since a return order is still a sales document at the table level.

The BAPI does not commit the database on its own. It builds the return order inside the current LUW and hands back a document number in SALESDOCUMENT if processing reached that point, but nothing is durable until the caller issues an explicit commit. Programs that call the BAPI and move straight to the next step without committing will see a document number that later resolves to nothing in the sales document tables, because the update was rolled back at the end of the session. This is the most common cause of the phantom document number complaint: the interface log shows a return order number, the functional user cannot find it in the transaction, and the two teams waste time comparing logs before someone notices the missing commit call.

RETURN is a table, not a flag, and it has to be read as one. The common failure is checking only whether the table is empty and treating a non-empty SALESDOCUMENT as proof of success - but SALESDOCUMENT can be populated even when RETURN contains error-level entries, because the field gets set before the final consistency check runs in some code paths. The correct read loops over RETURN and treats any line with type E or A as a failure regardless of what SALESDOCUMENT holds, surfaces type W lines as warnings that need functional review rather than silent suppression, and only trusts SALESDOCUMENT as final once no E or A line exists and a commit has actually been issued. A second, quieter bug shows up with multi-item calls: one item fails on a reason-for-return validation while the others succeed, and the interface logs the whole call as a single pass or fail instead of checking which item number each RETURN entry references.

BAPI_CUSTOMERRETURN_CREATE continues to work on S/4HANA because it sits on top of the same sales document creation logic that VA01 uses, and that logic has not been withdrawn. There is no confirmed, widely adopted released API that has formally replaced it for returns creation specifically, unlike some other O2C objects that have modern equivalents. Teams building new integrations should still check whether a released API for sales document creation covers the returns scenario before defaulting to this BAPI, but as of current practice it remains the standard call for programmatic returns creation.

Most failures trace back to configuration gaps rather than the BAPI itself, but they surface as interface errors first.

Configuration issues - order type, item category, reason for return, copy control, partner determination - are functional territory and need the full RETURN table plus the input payload to diagnose. Missing commits and lazy RETURN parsing that produce false-positive success logs are developer territory. Functional teams should hand over the raw RETURN table content, not a summary, when escalating an interface failure to development.

The mirrored transaction is VA01/VA02 with a returns order type, and the underlying tables are VBAK and VBAP. The closest sibling is the standard sales order create BAPI, since both build the same document category with a different order type. Downstream, a return delivery and credit memo creation BAPI typically follow once the return order exists.