Clean core en SAP: qué es, niveles A a D y qué hacer con el código Z

Clean core es el nombre que SAP da a un ERP que se mantiene lo más cerca posible del estándar: en un release vigente, con extensiones e integraciones compatibles con la nube, datos de buena calidad y procesos bien diseñados. El concepto no prohíbe el código propio. Exige que cada extensión quede separada del código de SAP y dependa de interfaces que SAP se compromete a mantener estables, y mide esa dependencia en cuatro niveles, de A a D.

Lo que está permitido cambia según la edición. En SAP S/4HANA Cloud Public Edition, la nube pública, el desarrollo usa ABAP Cloud y solo se acepta el nivel A. En SAP S/4HANA Cloud Private Edition, la nube privada, y en SAP S/4HANA on-premise, el ABAP clásico sigue disponible, clean core es una recomendación de SAP y el derecho a modificar el estándar depende del contrato firmado. Por eso el inventario del código Z tiene que estar listo antes de elegir la edición.

La comparación completa de las ediciones está en qué es SAP S/4HANA, y las responsabilidades de un contrato de nube de SAP, en RISE with SAP.

Qué llama SAP clean core

En el curso Managing Clean Core for SAP Cloud ERP, SAP define clean core como un ERP actualizado, en los releases más recientes, con extensiones e integraciones compatibles con la nube, buena calidad de datos primarios y buen diseño de procesos. El concepto tiene cinco dimensiones: procesos de negocio, extensibilidad, datos, integración y operaciones.

En extensibilidad, el principio es desacoplar las extensiones del estándar, con dos apoyos: usar APIs liberadas y seguir el modelo de extensibilidad de SAP S/4HANA Cloud. El mismo curso afirma que el enfoque no significa evitar la personalización. El beneficio declarado es el upgrade: cuanto menos depende una extensión de objetos internos de SAP, menos se rompe cuando cambia el release.

ABAP Cloud y ABAP clásico: dónde aplica cada uno

ABAP Cloud es el modelo de desarrollo ABAP de SAP para la nube, que accede solo a APIs liberadas y a puntos de extensión. ABAP clásico es el desarrollo ABAP sin esa restricción, el modelo en que se escribió el código Z de un sistema ECC. La tabla muestra dónde ofrece SAP cada uno, según el ABAP Cloud FAQ de SAP consultado en octubre de 2026.

Producto	ABAP Cloud	ABAP clásico
SAP BTP ABAP environment	Todos los releases, obligatorio	No aplica
SAP S/4HANA Cloud Public Edition	Desde el release 2208 para clientes nuevos, obligatorio	Sin ABAP clásico irrestricto
SAP S/4HANA Cloud Private Edition	Desde el release 2022, recomendado	Disponible
SAP S/4HANA on-premise	Desde el release 2022, recomendado	Disponible

En Private Edition y on-premise, SAP recomienda usar ABAP Cloud siempre que sea posible y mantiene la extensibilidad clásica disponible y soportada. También se pueden construir extensiones alineadas con clean core en ABAP clásico, siempre que sigan las reglas de los niveles.

Tipos de extensión y niveles A a D son clasificaciones distintas

La primera clasificación dice dónde se construye la extensión y con qué herramienta. La segunda dice de qué objetos de SAP depende.

Las tres formas de extensión

• Extensibilidad de usuario clave (key user extensibility): extensiones simples, hechas por usuarios clave con herramientas low-code o no-code dentro del propio ERP, como campos y lógica en los puntos liberados.
• Extensibilidad de desarrollador (developer extensibility): extensiones que requieren código, hechas por desarrolladores dentro del propio ERP, en ABAP Cloud.
• Extensibilidad lado a lado (side-by-side extensibility): aplicaciones construidas y ejecutadas fuera del núcleo, en SAP Business Technology Platform (SAP BTP), que se comunican con el ERP por interfaces liberadas.

Las dos primeras se ejecutan en el propio ERP (on-stack). SAP prefiere la extensión lado a lado y reconoce que casos como la implementación de una BAdI exigen código local.

Los niveles A, B, C y D

La tabla recoge la definición y los ejemplos de cada nivel en el material de formación de SAP consultado en octubre de 2026.

Nivel	Qué usa la extensión	Ejemplos que cita SAP	Valoración de SAP
A	Solo APIs liberadas y puntos de extensión, con contrato de estabilidad	Extensión on-stack en ABAP Cloud o con herramientas de usuario clave; aplicación lado a lado en SAP BTP	Enfoque preferido y único nivel aceptado en Public Edition
B	APIs clásicas que SAP considera estables aunque no estén liberadas	Un wrapper alrededor de una BAPI como BAPI_PO_CREATE1; ALV clásico	También preferido en Private Edition y on-premise
C	Objetos internos de SAP, sin garantía de compatibilidad	Uso directo de módulos de función y clases internos; lectura de tablas SAP no destinadas a uso externo	Riesgo gestionable; SAP publica un changelog para anticipar cambios incompatibles
D	Objetos y técnicas no recomendados	Modificaciones, enhancements implícitos y escritura no soportada en tablas SAP	Mayor riesgo y deuda técnica; no se considera clean

SAP evalúa la extensión por la tecnología de nivel más bajo que utiliza: en el ejemplo del curso, una clase ABAP con dos APIs liberadas y una API clásica es nivel B. El Cloudification Repository, que SAP mantiene en GitHub, lista las APIs liberadas y las clásicas, y el ABAP Test Cockpit (ATC) ejecuta las verificaciones de código.

El tipo no determina el nivel. Una extensión de desarrollador en Private Edition puede ser A, B, C o D según lo que llame el código.

Qué acepta cada edición: modificaciones, add-ons y código Z

La tabla compara los tres despliegues de S/4HANA en cuanto a lo que el cliente puede hacer en el código. Las fuentes son la documentación de SAP y el suplemento contractual de Private Edition en su versión v7-2026. La edición vigente en octubre de 2026 es la v.10-2026, que se diferencia de la anterior por el cargo de continuidad de infraestructura de la cláusula 3.8 y mantiene las reglas de extensión.

Tema	Public Edition	Private Edition	On-premise
Modificación de objetos SAP	No permitida	Derecho previsto solo para las ofertas que nombra la cláusula 3.4.3 del suplemento; no permitida a quien también contrata SAP extended services	Capacidad técnica disponible; SAP recomienda clean core
Add-ons	Los add-ons clásicos de ECC no se pueden instalar	Add-on ABAP del cliente, add-on provisto por SAP y add-on certificado; con SAP extended services, solo los dos últimos	Sujeto a la compatibilidad con el release
Código Z en ABAP clásico	No aceptado	Aceptado; instalación, gestión, soporte y pruebas quedan a cargo del cliente	Aceptado

El límite contractual de Private Edition está en las definiciones del suplemento. Add-on es el desarrollo que agrega funcionalidad nueva e independiente sin modificar funcionalidad existente de SAP. Modification es el cambio del código fuente o de los metadatos entregados, y también cualquier otro desarrollo que personalice, amplíe o cambie funcionalidad existente. La definición es amplia, y el derecho a desarrollar Modifications aparece solo para las ofertas RISE with SAP S/4HANA Cloud, private edition enumeradas en la cláusula 3.4.3.

El mismo documento excluye del SLA los add-ons ABAP del cliente y obliga al cliente a ejecutar las verificaciones de simplificación y de incompatibilidad en cada upgrade. El suplemento tiene versiones: rige la versión referenciada en el pedido (Order Form), y el nombre de la oferta contratada debe compararse con la lista de la cláusula. Las demás diferencias entre las dos nubes están en SAP Cloud ERP público y privado.

Cómo inventariar el código Z antes de un proyecto RISE o de conversión

Los pasos siguientes salen del Conversion Guide de SAP S/4HANA 2025, actualizado el 07/10/2026, y del curso Practicing Clean Core Extensibility for SAP S/4HANA Cloud.

1. Medir el uso real en producción. SAP indica el ABAP Call Monitor (transacción SCMON) o Usage and Procedure Logging (UPL), sin ejecutar ambos a la vez, durante 6 a 18 meses, con al menos un cierre anual. La transacción SUSG agrega y conserva los datos de SCMON, que se borran al poco tiempo.
2. Ejecutar SAP Readiness Check al inicio de la planificación. Identifica los ítems de simplificación relevantes, hace un análisis de alto nivel del código a medida y verifica la compatibilidad de los add-ons.
3. Analizar el código frente a las simplificaciones de S/4HANA. La herramienta Custom Code Migration, disponible como app SAP Fiori, y el ATC listan dónde el código Z deja de ser compatible con el alcance y la estructura de datos de S/4HANA. SAP advierte que las verificaciones no identifican todos los casos, y la prueba en el destino sigue siendo necesaria.
4. Retirar lo que no se usa. La app Custom Code Migration cruza el análisis con las estadísticas de uso y genera una orden de transporte de borrado, que el Software Update Manager consume durante la conversión.
5. Revisar modificaciones, copias y enhancements. Las transacciones SPDD, SPAU y SPAU_ENH y la herramienta clone finder localizan modificaciones directas, clones de objetos SAP, enhancements implícitos y sobrescrituras de métodos. SAP orienta tratar ese código como candidato al retiro.
6. Clasificar lo que queda por los niveles A a D. Cada objeto recibe un destino: retirarlo, reescribirlo en ABAP Cloud o llevarlo al nivel más alto posible. Cuando falta una API liberada, SAP señala envolver el objeto en un wrapper propio o pedir la liberación por el canal SAP Influence.
7. Adaptar después de la conversión técnica. Las modificaciones y los enhancements se ajustan con SPDD, SPAU y SPAU_ENH, y los hallazgos de simplificación se corrigen con el ATC en la variante S4HANA_READINESS.

Los caminos de transición y lo que cada uno arrastra están en migración de ECC a SAP S/4HANA.

Clean core en SAP PM: órdenes, avisos de mantenimiento, confirmaciones y mediciones

En mantenimiento, la pregunta práctica es qué interfaz usa cada programa Z o integración para leer y grabar órdenes de mantenimiento, avisos de mantenimiento, confirmaciones y mediciones. La tabla lista las APIs que SAP documenta para Public Edition, consultadas en octubre de 2026. En Private Edition, on-premise y ECC, la disponibilidad debe verificarse en el release del sistema.

Objeto	API	Protocolo	Operaciones documentadas	Escenario de comunicación
Orden de mantenimiento	API_MAINTENANCEORDER_0002	OData V2	Lectura y creación; cambios según la tabla de operaciones de SAP	SAP_COM_0397
Aviso de mantenimiento	API_MAINTNOTIFICATION	OData V2	GET, POST y PATCH	SAP_COM_0397
Confirmación de operación	API_MAINTORDERCONFIRMATION	OData V2	GET, POST, batch y anulación	SAP_COM_0398
Punto de medida	API_MEASURINGPOINT	OData V4	GET, POST y PUT	SAP_COM_0395
Documento de medición	API_MEASUREMENTDOCUMENT	OData V4	GET, POST y PUT; sin borrado	SAP_COM_0398

Public Edition también tiene BAPIs liberadas para escenarios determinados. La tabla oficial de interfaces RFC incluye BAPI_ALM_ORDER_MAINTAIN y BAPI_ALM_ORDER_GET_DETAIL para órdenes y la familia BAPI_ALM_CONF para confirmaciones (SAP_COM_0344), y la familia BAPI_ALM_NOTIF para avisos (SAP_COM_0322). Como la tabla todavía vincula esas interfaces con scope items obsoletos (BH1, BH2 y BJ2), figurar en ella no garantiza la activación en un tenant nuevo ni autoriza a llamar otra BAPI.

Un programa Z de mantenimiento se puede leer por niveles:

• Una aplicación en SAP BTP que crea órdenes por API_MAINTENANCEORDER_0002 usa una interfaz liberada y queda en el nivel A, en la edición y el release donde la API está liberada.
• Una extensión en ABAP clásico que llama una BAPI de orden o de confirmación queda en el nivel B si SAP clasifica esa BAPI como API clásica, lo que se consulta en el Cloudification Repository.
• Un reporte Z que lee directamente tablas SAP no destinadas a uso externo queda en el nivel C.
• Una validación en un enhancement implícito, una modificación de un programa estándar o una escritura directa en una tabla SAP quedan en el nivel D.

El punto de medida es un dato maestro y el documento de medición es la lectura registrada, cada uno con su API.

Errores frecuentes al interpretar clean core

Plantear la decisión como código Z sí o no

El modelo de SAP no divide el sistema entre código estándar y código Z. Un objeto Z que solo llama APIs liberadas es nivel A; otro, con una escritura directa en una tabla SAP, es nivel D. La pregunta útil para el inventario es de qué objeto SAP depende cada programa Z.

Suponer que Private Edition lo permite todo

La capacidad técnica existe, y el derecho contractual es más estrecho. El suplemento v7-2026 concede el derecho a modificar solo a las ofertas que nombra y deja las pruebas a cargo del cliente. La clasificación por niveles tampoco funciona como licencia: describe dependencias del código y no autoriza a cambiar el estándar.

Las soluciones de terceros sobre SAP PM entran en el mismo inventario

La aplicación de campo, la herramienta de planificación y las integraciones también dependen de objetos de SAP PM. Conviene pedir al proveedor el objeto, la operación, la API o BAPI exacta, la edición y el release validados, el escenario de comunicación, el componente instalado en SAP y quién sostiene la prueba en cada upgrade. PM RUN es la plataforma de ejecución, movilidad y planificación de mantenimiento que funciona sobre SAP PM sin reemplazar a SAP, y usa SAP PM en ECC 6.0 o en S/4HANA, on-premise o en la nube. La página de gestión de activos en SAP describe lo que cubre la plataforma.