ABAP Conversion Exits: ALPHA, MATN1, CUNIT and Interface Boundaries

A conversion exit is a pair of function modules named CONVERSION_EXIT_<name>_INPUT and _OUTPUT attached to a data element/domain. INPUT converts an external representation into the internal form used by ABAP/database keys; OUTPUT converts internal values to user/external display form. ALPHA commonly adds/removes leading zeros; CUNIT/LUNIT resolve unit representations from unit customizing; ISOLA maps SAP and ISO language codes; MATN1 handles material-number formatting. The exit belongs to the field's DDIC semantics, so the correct conversion should come from metadata rather than a developer's guess about how a key looks.

Use conversion exits at boundaries where human/external representations meet internal SAP keys: file imports, custom selection screens, generic tools, legacy RFC payloads, or API wrappers whose contract explicitly uses internal format. Do not apply a conversion again if the consuming framework already performs DDIC conversion automatically. For modern OData/CDS/business APIs, inspect the external contract because the service may expose normalized external keys or typed units/languages without requiring manual function-module calls.

Conversion exits are part of the ABAP Dictionary/runtime presentation model. Dynpro selection screens, ALV, classic RFC/BAPI interfaces and generic field processing can invoke them automatically or explicitly. They are distinct from quantity conversion, currency conversion, tax calculation and business validation. Material-number extension in S/4HANA is a good example: code that manually pads to 18 characters can corrupt data, while MATNR-typed fields and the proper conversion logic adapt to the configured length.

An inbound CSV contains customer number '4711'. The target BAPI expects the internal KUNNR format. A developer concatenates six zeros and the interface works until a different key length or object type is used. A safer implementation derives the DDIC type or uses the ALPHA input conversion for the correct field, then passes the typed result. For material numbers, the team avoids generic ALPHA assumptions and uses MATNR typing/MATN1 semantics because extended material numbers have different rules.

Conversion exits remain common in S/4HANA classic ABAP, but modern APIs increasingly hide internal key representation behind released external contracts. Extended material numbers make correct typing especially important. ABAP Cloud code cannot freely call unreleased classic function modules, so use released conversion APIs or language/CDS capabilities where available while preserving the same boundary principle.

ABAP/integration developers own correct conversion at interface boundaries. Data-model owners define the DDIC type/routine. Functional teams confirm whether an external value is genuinely a key format issue versus invalid master data. Interface architects should document whether payload keys are internal SAP format or business/display format.

SE11 shows data elements/domains and assigned conversion routines. The function-module library contains CUNIT, LUNIT, ISOLA and MATN1 conversion pages. Material, unit and language table pages provide supporting context.

Production verification: Capture DDIC data element or domain, assigned conversion routine, source external value, internal value, target field type and length, and whether the consuming framework already performs conversion. This prevents double conversion and hard-coded assumptions such as universal ALPHA padding or fixed material-number length.

Operational readiness: For production readiness of ABAP Conversion Exits: ALPHA, MATN1, CUNIT and Interface Boundaries, add one reproducible test case with realistic data volume and boundary values, one negative test that proves the failure contract, and one operational check that a support developer can run without changing productive data. Record the exact program, class or function and any release-dependent API assumptions. Where the topic affects performance or transaction consistency, compare evidence before and after the change instead of relying on coding folklore or one sandbox execution.