Clean core no SAP: o que é, níveis A a D e o que fazer com o código Z

Clean core é o nome que a SAP dá a um ERP mantido o mais próximo possível do padrão, em release atual, com extensões e integrações compatíveis com a nuvem, dados de boa qualidade e processos bem desenhados. O conceito não proíbe código próprio. Ele exige que cada extensão fique separada do código da SAP e dependa de interfaces que a SAP se compromete a manter estáveis, e mede essa dependência em quatro níveis, de A a D.

O que é permitido muda por edição. Na SAP S/4HANA Cloud Public Edition, o desenvolvimento usa ABAP Cloud e só o nível A é aceito. Na SAP S/4HANA Cloud Private Edition e no SAP S/4HANA on-premise, o ABAP clássico continua disponível, o clean core é recomendação da SAP e o direito de modificar o padrão depende do contrato assinado. Por isso o inventário do código Z precisa ficar pronto antes da escolha da edição.

A comparação completa das edições está em SAP S/4HANA: o que é, e as responsabilidades de um contrato de nuvem da SAP, em RISE with SAP.

O que a SAP chama de clean core

No curso Managing Clean Core for SAP Cloud ERP, a SAP define clean core como um ERP atualizado, nos releases mais recentes, com extensões e integrações compatíveis com a nuvem, boa qualidade de dados primários e bom desenho de processos. O conceito tem cinco dimensões: processos de negócio, extensibilidade, dados, integração e operações.

Na extensibilidade, o princípio é desacoplar as extensões do padrão, com dois apoios: usar APIs liberadas e seguir o modelo de extensibilidade do S/4HANA Cloud. O mesmo curso afirma que a abordagem não significa evitar customização. O ganho declarado é o upgrade: quanto menos a extensão depende de objeto interno da SAP, menos ela quebra quando o release muda.

ABAP Cloud e ABAP clássico: onde cada um vale

ABAP Cloud é o modelo de desenvolvimento ABAP da SAP para a nuvem, que acessa apenas APIs liberadas e pontos de extensão. ABAP clássico é o desenvolvimento ABAP sem essa restrição, o modelo em que foi escrito o código Z do ECC. A tabela mostra onde a SAP oferece cada um, conforme o ABAP Cloud FAQ da SAP, em outubro de 2026.

Produto	ABAP Cloud	ABAP clássico
SAP BTP ABAP environment	Todos os releases, obrigatório	Não se aplica
SAP S/4HANA Cloud Public Edition	Desde o release 2208 para novos clientes, obrigatório	Sem ABAP clássico irrestrito
SAP S/4HANA Cloud Private Edition	Desde o release 2022, recomendado	Disponível
SAP S/4HANA on-premise	Desde o release 2022, recomendado	Disponível

Na Private Edition e no on-premise, a SAP recomenda ABAP Cloud sempre que possível e mantém a extensibilidade clássica disponível e suportada. Extensões aderentes ao clean core também podem ser construídas em ABAP clássico, desde que sigam as regras dos níveis.

Tipos de extensão e níveis A a D são classificações diferentes

A primeira classificação diz onde e com que ferramenta a extensão é construída. A segunda diz de quais objetos da SAP ela depende.

As três formas de extensão

• Extensão key user (key user extensibility): extensões simples, feitas por usuários-chave com ferramentas low-code ou no-code dentro do próprio ERP, como campos e lógicas nos pontos liberados.
• Extensão developer (developer extensibility): extensões que pedem código, feitas por desenvolvedores dentro do próprio ERP, em ABAP Cloud.
• Extensão lado a lado (side-by-side extensibility): aplicações construídas e executadas fora do núcleo, no SAP Business Technology Platform (SAP BTP), que conversam com o ERP por interfaces liberadas.

As duas primeiras rodam no próprio ERP (on-stack). A SAP prefere a extensão lado a lado e reconhece que casos como a implementação de uma BAdI exigem código local.

Os níveis A, B, C e D

A tabela traz a definição e os exemplos de cada nível no material de treinamento da SAP, em outubro de 2026.

Nível	O que a extensão usa	Exemplos citados pela SAP	Avaliação da SAP
A	Somente APIs liberadas e pontos de extensão, com contrato de estabilidade	Extensão on-stack em ABAP Cloud ou com ferramentas key user; aplicação lado a lado no SAP BTP	Abordagem preferida e único nível aceito na Public Edition
B	APIs clássicas, que a SAP considera estáveis embora não sejam liberadas	Wrapper em torno de uma BAPI, como a BAPI_PO_CREATE1; ALV clássico	Também preferida na Private Edition e no on-premise
C	Objetos internos da SAP, sem garantia de compatibilidade	Uso direto de módulos de função e classes internos; leitura de tabelas SAP não destinadas a uso externo	Risco administrável; a SAP publica um changelog para antecipar mudanças incompatíveis
D	Objetos e técnicas não recomendados	Modificações, enhancements implícitos e gravação não suportada em tabelas SAP	Maior risco e dívida técnica; não é considerado clean

A SAP avalia a extensão pela tecnologia de nível mais baixo que ela usa: no exemplo do curso, uma classe ABAP com duas APIs liberadas e uma API clássica é nível B. O Cloudification Repository, que a SAP mantém no GitHub, lista as APIs liberadas e as clássicas, e o ABAP Test Cockpit (ATC) aplica as verificações de código.

O tipo não determina o nível. Uma extensão developer na Private Edition pode ser A, B, C ou D, conforme o que o código chama.

O que cada edição aceita: modificação, add-on e código Z

A tabela compara as três implantações do S/4HANA quanto ao que o cliente pode fazer no código. As fontes são a documentação da SAP e o suplemento contratual da Private Edition na versão v.10-2026, vigente em outubro de 2026.

Tema	Public Edition	Private Edition	On-premise
Modificação de objeto SAP	Não permitida	Direito previsto só para as ofertas que a cláusula 3.4.3 do suplemento nomeia; vedada a quem também assina o SAP extended services	Capacidade técnica disponível; a SAP recomenda clean core
Add-on	Add-on clássico do ECC não é instalável	Add-on ABAP do cliente, add-on fornecido pela SAP e add-on certificado; com SAP extended services, só os dois últimos	Sujeito à compatibilidade com o release
Código Z em ABAP clássico	Não aceito	Aceito; instalação, gestão, suporte e testes ficam com o cliente	Aceito

O limite contratual da Private Edition está nas definições do suplemento. Add-on é o desenvolvimento que acrescenta funcionalidade nova e independente, sem modificar funcionalidade existente da SAP. Modification é a alteração do código-fonte ou dos metadados entregues e também qualquer desenvolvimento que customize, estenda ou altere funcionalidade existente. A definição é ampla, e o direito de desenvolver Modifications aparece apenas para as ofertas RISE with SAP S/4HANA Cloud, private edition listadas na cláusula 3.4.3.

O mesmo documento tira os add-ons ABAP do cliente do SLA e manda o cliente executar as verificações de simplificação e de incompatibilidade a cada upgrade. O suplemento é versionado: vale a versão referenciada no pedido de compra (Order Form), e o nome da oferta contratada precisa ser conferido contra a lista da cláusula. As demais diferenças entre as duas nuvens estão em SAP Cloud ERP público e privado.

Como inventariar o código Z antes de um projeto RISE ou de conversão

Os passos abaixo estão no Conversion Guide do SAP S/4HANA 2025, atualizado em 07/10/2026, e no curso Practicing Clean Core Extensibility for SAP S/4HANA Cloud.

1. Medir o uso real em produção. A SAP indica o ABAP Call Monitor (transação SCMON) ou o Usage and Procedure Logging (UPL), sem rodar os dois ao mesmo tempo, por 6 a 18 meses, com ao menos um fechamento anual no período. A transação SUSG agrega e guarda os dados do SCMON, que são apagados em pouco tempo.
2. Rodar o SAP Readiness Check no início do planejamento. Ele aponta os itens de simplificação relevantes, faz uma análise de alto nível do código customizado e verifica a compatibilidade dos add-ons.
3. Analisar o código contra as simplificações do S/4HANA. A ferramenta Custom Code Migration, disponível como app Fiori, e o ATC listam onde o código Z deixa de ser compatível com o escopo e a estrutura de dados do S/4HANA. A SAP avisa que as verificações ainda não identificam todos os casos, e o teste no sistema de destino continua necessário.
4. Retirar o que não é usado. O app Custom Code Migration cruza a análise com as estatísticas de uso e gera uma requisição de transporte de exclusão, que o Software Update Manager consome durante a conversão.
5. Revisar modificações, cópias e enhancements. As transações SPDD, SPAU e SPAU_ENH e a ferramenta clone finder localizam modificações diretas, clones de objetos SAP, enhancements implícitos e sobrescritas de métodos. A SAP orienta tratar esse código como candidato à remoção.
6. Classificar o que sobra pelos níveis A a D. Cada objeto recebe um destino: aposentar, reescrever em ABAP Cloud ou adaptar ao nível mais alto possível. Quando falta uma API liberada, a SAP indica encapsular o objeto em um wrapper próprio ou pedir a liberação pelo canal SAP Influence.
7. Adaptar depois da conversão técnica. Modificações e enhancements são ajustados com SPDD, SPAU e SPAU_ENH, e os achados de simplificação são corrigidos com o ATC na variante S4HANA_READINESS.

Os caminhos de transição e o que cada um carrega estão em migração do ECC para o SAP S/4HANA.

Clean core no SAP PM: ordens, notas, confirmações e medições

Em manutenção, a pergunta prática é qual interface cada programa Z ou integração usa para ler e gravar ordem, nota, confirmação e medição. A tabela lista as APIs que a SAP documenta para a Public Edition em outubro de 2026. Na Private Edition, no on-premise e no ECC, a disponibilidade precisa ser conferida no release do sistema.

Objeto	API	Protocolo	Operações documentadas	Cenário de comunicação
Ordem de manutenção	API_MAINTENANCEORDER_0002	OData V2	Leitura e criação; alterações conforme a tabela de operações da SAP	SAP_COM_0397
Nota de manutenção	API_MAINTNOTIFICATION	OData V2	GET, POST e PATCH	SAP_COM_0397
Confirmação de operação	API_MAINTORDERCONFIRMATION	OData V2	GET, POST, batch e cancelamento	SAP_COM_0398
Ponto de medição	API_MEASURINGPOINT	OData V4	GET, POST e PUT	SAP_COM_0395
Documento de medição	API_MEASUREMENTDOCUMENT	OData V4	GET, POST e PUT; sem exclusão	SAP_COM_0398

A Public Edition também tem BAPIs liberadas para cenários determinados. A tabela oficial de interfaces RFC lista a BAPI_ALM_ORDER_MAINTAIN e a BAPI_ALM_ORDER_GET_DETAIL para ordens e a família BAPI_ALM_CONF para confirmações (SAP_COM_0344), e a família BAPI_ALM_NOTIF para notas (SAP_COM_0322). Como a tabela ainda vincula essas interfaces a itens de escopo depreciados (BH1, BH2 e BJ2), constar nela não garante ativação em um tenant novo nem autoriza chamar outra BAPI.

Com isso, um programa Z de manutenção pode ser lido pelos níveis:

• Uma aplicação no SAP BTP que cria ordens pela API_MAINTENANCEORDER_0002 usa interface liberada e fica no nível A, na edição e no release em que a API está liberada.
• Uma extensão em ABAP clássico que chama uma BAPI de ordem ou de confirmação fica no nível B se a SAP classificar aquela BAPI como API clássica, o que se confere no Cloudification Repository.
• Um relatório Z que lê direto tabelas SAP não destinadas a uso externo fica no nível C.
• Uma validação em enhancement implícito, uma modificação em programa padrão ou uma gravação direta em tabela SAP ficam no nível D.

Na especificação, ponto de medição é cadastro e documento de medição é a leitura registrada, com APIs e cenários diferentes.

Erros comuns de interpretação do clean core

Tratar a decisão como Z sim ou Z não

O modelo da SAP não divide o sistema entre código padrão e código Z. Um objeto Z que só chama APIs liberadas é nível A; outro, com uma gravação direta em tabela SAP, é nível D. A pergunta útil para o inventário é de qual objeto SAP cada programa Z depende.

Supor que a Private Edition permite tudo

A capacidade técnica existe, e o direito contratual é mais estreito. O suplemento v.10-2026 dá o direito de modificar apenas às ofertas que nomeia e deixa os testes com o cliente. A classificação por níveis também não funciona como licença: ela descreve dependências do código e não autoriza alterar o padrão.

Soluções de terceiros sobre o SAP PM entram no mesmo inventário

Aplicativo de campo, ferramenta de planejamento e integração com outros sistemas também dependem de objetos do SAP PM. Para cada um, vale pedir ao fornecedor o objeto, a operação, a API ou BAPI exata, a edição e o release validados, o cenário de comunicação, o componente instalado no SAP e quem sustenta o teste a cada upgrade. A PM RUN é a plataforma de execução, mobilidade e planejamento de manutenção que roda sobre o SAP PM, sem substituir o SAP, e usa o SAP PM no ECC 6.0 ou no S/4HANA, on-premise ou em nuvem. A página de software de manutenção para SAP PM descreve o que a plataforma cobre.