SO_NEW_DOCUMENT_ATT_SEND_API1 — Classic SAPoffice function module for sending mail with attachments
SO_NEW_DOCUMENT_ATT_SEND_API1 sends an internal SAPoffice document or external email, with one or more attachments, through the classic Business Communication Service layer. It is the pre-BCS, function-module style send API, still present and callable on S/4HANA, but SAP's own direction has moved to the object-oriented CL_BCS class for new development.
This page covers what SO_NEW_DOCUMENT_ATT_SEND_API1 actually does when called from custom ABAP, its parameters and exceptions, and the operational traps that make background jobs report success while no mail is ever delivered. It also addresses its clean-core status on S/4HANA and who is responsible when a send silently fails.
Published 16 Sept 2026· 1,138 words
What it does
SO_NEW_DOCUMENT_ATT_SEND_API1 creates a SAPoffice document, attaches binary or text content to it, and hands it to the send mechanism, either as an internal SAP-to-SAP message or as an external email routed through SAPconnect. The 'API1' suffix marks it as one of the small set of SO_* modules that were explicitly released as a supported customer interface, unlike most of the internal SO_* helper modules in the same function groups. It predates the object-oriented Business Communication Service (CL_BCS) introduced later and is still widely found in custom reports that generate a spreadsheet, PDF, or text file and mail it out at the end of a batch job. It does not itself guarantee delivery; it only creates and queues the document for the send infrastructure.
Parameters
- DOCUMENT_DATA (type SODOCCHGI1) - header data for the document: subject/title, sensitivity, document type; mandatory.
- PUT_IN_OUTBOX - optional flag; when set, the document is written to the sender's SAPoffice outbox instead of being handed to the send job, useful for testing without risking a real email.
- COMMIT_WORK - optional flag controlling whether the function module issues its own commit; leave blank when the call sits inside a larger business LUW managed by the caller.
- SENDER_ADDRESS and SENDER_ADDRESS_TYPE - optional override of the sending address, used to send as a generic mailbox rather than the calling user.
- RECEIVERS (structure SOOS1, passed as a table) - one row per recipient with address, address type (external SMTP, internal SAP user, distribution list) and copy/blind-copy indicators.
- PACKING_LIST (SOPCKLSTI1) - describes how the content tables map onto body text versus attachments, including document type and line ranges for each part.
- OBJECT_HEADER, CONTENTS_TXT - line tables for the plain text body.
- CONTENTS_HEX / CONTENTS_BIN - line tables carrying binary attachment content.
- SENT_TO_ALL (exporting) - flag indicating whether every receiver in the list was accepted.
- NEW_OBJECT_ID (exporting) - the SAPoffice object id of the document that was created, needed if the caller wants to track the message later in SOST or SBWP.
Exceptions
- TOO_MANY_RECEIVERS - the RECEIVERS table exceeds the internal limit for a single call; nothing is sent to anyone, not even a partial list.
- DOCUMENT_NOT_SENT - the generic failure, and the one most often swallowed with EXCEPTIONS OTHERS = 0; usually traces back to a packing list entry that does not correctly describe the body or attachment content, or to a zero-length content table.
- DOCUMENT_TYPE_NOT_EXIST - the document type code referenced in the packing list or document data is not a valid SAPoffice type; typically a typo in the type string passed by the caller.
- OPERATION_NO_AUTHORIZATION - the calling user lacks send authorization in SAPoffice; the job or transaction appears to run cleanly but no message leaves the system.
- PARAMETER_ERROR - the packing list offsets and line counts do not match the actual content tables; common when attachment size is computed by hand instead of derived from the actual line count.
- ENQUEUE_ERROR - a lock is held on the target SAPoffice folder or document, often from a competing parallel batch job; retrying immediately in a tight loop tends to reproduce the same lock instead of clearing it.
How to call it safely
Call it synchronously and check SY-SUBRC immediately after the call; a non-zero return corresponds to one of the named exceptions and must be resolved into a message rather than ignored, since the module does not return a BAPI-style return table. After a clean return, do not assume the mail has left the system: creating the SAPoffice document only queues it, and actual transmission for external addresses depends on the SAPconnect send job being scheduled and running. Confirm delivery status in the send request monitor rather than trusting the function module's return code alone. Leave COMMIT_WORK blank when the call is part of a larger update, and let the enclosing transaction issue the commit so a rollback elsewhere does not leave a half-sent message.
ECC vs S/4HANA
SO_NEW_DOCUMENT_ATT_SEND_API1 still exists and runs unchanged on S/4HANA; it has not been withdrawn or blocked. SAP's own architectural direction for outbound mail, however, has been the object-oriented Business Communication Service through the CL_BCS class, which the classic function module effectively wraps under the hood in newer releases. Under clean-core guidance, new custom developments on S/4HANA are generally steered away from calling this function module directly, in favor of CL_BCS or standard output management channels that use BCS internally. There is no dedicated Fiori app or successor identifier for it; it remains a technical, non-released-for-Fiori building block.
Common pitfalls
- Omitting the packing list entry for the body text itself, not just the attachment, which produces DOCUMENT_NOT_SENT with no obvious cause in the log.
- Passing attachment content as raw character data instead of converting binary content into the hex line format first, which corrupts PDF or Excel attachments on arrival.
- Assuming the call sends the mail immediately; without a running SAPconnect send job the message sits in the queue indefinitely and the calling program has already logged success.
- Looping the call once per recipient in a mass mailing without managing locks, which surfaces as intermittent ENQUEUE_ERROR under load and tempts developers into blind retries that produce duplicate sends.
- Treating COMMIT_WORK = X as mandatory out of habit, which forces a premature commit inside a larger transaction and breaks the atomicity the calling program was relying on.
Whose problem this is
The Basis or technical operations team owns the SAPconnect configuration and the background send job that actually moves queued messages out of the system; without that job running correctly, no call to this function module results in a delivered email. The ABAP developer owns correctness of the packing list, content tables, and receiver list passed into the call. The functional or business team owns the decision of who should receive the message and under what condition, which is frequently the actual root cause when 'nothing arrived' turns out to mean the wrong or empty receiver list.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-function-modules/so-new-document-att-send-api1ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.