Desenvolvimento ABAP e customização fiscal no SAP: só o recorte fiscal, dentro do Clean Core

Por onde ler, conforme o seu papel

Comece pelo bloco do seu papel ou siga os quatro blocos na ordem em que o trabalho acontece. Os minutos ao lado de cada seção são só uma estimativa de quanto leva ler.

Quando customizar e quando não customizar

A decisão de customizar é a de maior consequência do projeto fiscal, porque cada linha de código do cliente é uma linha que precisa ser testada, transportada, documentada e revisada a cada atualização de SAP Note e de leiaute. Por isso o critério abaixo é de exclusão: o ABAP só entra depois que as alternativas mais baratas de manter foram descartadas, na ordem em que aparecem.

Dois sinais ajudam a calibrar. O primeiro é a frequência de mudança: regra que muda toda vez que sai uma nota técnica pede produto ou configuração, não código. O segundo é a proximidade do núcleo: quanto mais perto de uma tabela ou de um programa do SAP o código precisa chegar, maior o risco, e mais forte deve ser a razão para customizar.

O que entra no recorte fiscal

Recorte fiscal significa que a extensão existe por uma razão fiscal e é validada contra uma regra fiscal. As categorias abaixo cobrem a maior parte do que é pedido em um ambiente SAP brasileiro. Cada uma tem um ponto de extensão típico, um risco típico e uma forma de teste.

Fora do recorte estão a arquitetura geral do projeto, as interfaces de infraestrutura, a plataforma e o desenvolvimento genérico sem finalidade fiscal. Para a camada de integração fiscal com a plataforma de integração do SAP, a página de integração fiscal com BTP e API trata do que cabe ali e do que continua com o integrador.

Nota fiscal no SAP e a família J_1BNF

1. 01

   O primeiro é que o leiaute das notas fiscais eletrônicas evolui por notas técnicas, e o SAP o acompanha criando campos nas estruturas existentes.

   Quem tem código que lê ou grava essas estruturas precisa saber que elas mudam por esse caminho.

2. 02

   O segundo é que o SAP oferece pontos de extensão específicos para a nota fiscal.

   Um artigo de base de conhecimento do SAP sobre o preenchimento do campo AFRMM (adicional de frete para a renovação da marinha mercante) na transação J1B1N cita duas opções de BAdI: CL_NFE_PRINT e J_1BNF_ADD_DATA (Fonte: SAP KBA 2730030). O artigo se refere a sistemas SAP ERP, de modo que, em cada ambiente, a existência e o comportamento do ponto devem ser confirmados antes do desenho.

3. 03

   O terceiro é que ler e gravar a nota diretamente nas tabelas é o caminho mais frágil.

   O caminho mais estável é usar as interfaces que o SAP publica para o objeto, e verificar se elas constam como liberadas para a sua edição do SAP. A mesma lógica de liberação aparece na seção sobre Clean Core mais abaixo.

• Complementar dado da nota. Preencher um campo adicional que o leiaute exige e o padrão não preenche, com a regra definida pelo Fiscal e com o valor de origem documentado.
• Corrigir comportamento pontual. Ajustar um caso que o padrão trata de forma genérica, como uma natureza de operação específica, desde que o ponto de extensão seja publicado.
• Ler a nota para conferência. Montar relatório que cruza a nota, o lançamento e a escrituração, lendo por interface estável e não por tabela copiada.
• Reprocessar com trilha. Reabrir um documento rejeitado, corrigir o dado de origem e reenviar, com registro de quem fez e por quê.

Cálculo e determinação de imposto: onde mexer com cuidado

1. 01

   Determinar um imposto é decidir, a cada item de cada documento, qual é a situação tributária, qual é a base, qual é a alíquota e qual é o tratamento especial aplicável.

   No SAP, isso acontece em camadas: dados mestres, parametrização, regras de determinação e, quando necessário, código. Cada camada acima da parametrização aumenta o custo de manter.

2. 02

   A regra de bolso é empurrar a decisão para a camada mais baixa e mais legível.

   Uma tabela de decisão que o analista fiscal consegue ler e corrigir vale mais do que uma condição escondida em um método. O SAP tem para isso o BRFplus (Business Rule Framework plus), definido na documentação oficial como uma interface de programação e de usuário para especificar e processar regras de negócio, que permite modelar regras de forma intuitiva e reutilizá-las em aplicações diferentes (Fonte: SAP Help Portal, BRFplus). A mesma documentação descreve funções, expressões, entradas (contexto) e saídas (resultado), e recursos como simulação, rastreamento, transporte e exportação.

3. 03

   A consequência para o fiscal é concreta.

   Com uma regra modelada em BRFplus, a pergunta do auditor, por que este item saiu com esta situação tributária, pode ser respondida por rastreamento e simulação em vez de leitura de código. É uma vantagem que só existe se a regra estiver, de fato, modelada, e se o BRFplus fizer parte da solução fiscal do seu ambiente, o que deve ser confirmado caso a caso.

A reforma tributária reforça esse cuidado. Com a chegada de novos tributos e de novos campos nos documentos, regras de determinação que hoje são simples tendem a ganhar dimensões novas, e é nesse cenário que uma extensão mal posicionada se torna um problema de manutenção. A página sobre a reforma tributária com CBS e IBS explica o calendário e o que muda; aqui o ponto é que cada ajuste de cálculo em código precisa de um dono e de um plano de revisão a cada ato novo.

Validação de campos e dados: barrar cedo custa menos

A rejeição de um documento pela SEFAZ chega depois da emissão, com mensagem técnica e com tempo perdido. A validação de campo, feita antes, evita esse retorno. É um dos usos mais saudáveis do ABAP fiscal, porque o código é curto, a regra é objetiva e o benefício é visível.

• Formato. Tamanho, composição e dígito de verificação de identificadores como CNPJ, inscrição e NCM, conferidos antes do documento ser gravado.
• Coerência entre campos. Combinações que não podem coexistir, como uma natureza de operação incompatível com o tipo de parceiro ou um código de situação tributária sem a base correspondente.
• Completude para o leiaute. Campos que o leiaute vigente exige em determinada condição e que o processo de origem costuma deixar em branco.
• Compatibilidade com o dado mestre. Divergência entre o que o documento traz e o que o cadastro do material ou do parceiro afirma, que sinaliza erro de um dos lados.

1. 01

   Primeiro, a mensagem deve dizer ao usuário o que corrigir, em português claro, e não repetir o código técnico.

2. 02

   Segundo, a validação deve distinguir erro que bloqueia de alerta que informa, porque bloquear demais cria o hábito de contornar.

3. 03

   Terceiro, a regra deve estar escrita em uma frase que o Fiscal assina: se o Fiscal não reconhece a frase, o código está validando outra coisa.

Conferência de SPED e de DF-e: o relatório que o analista usa

Programas de conferência são a categoria de ABAP fiscal que mais se aproxima do trabalho diário do analista. Eles não emitem nem escrituram: leem o que o ERP tem, comparam e mostram a diferença. A página sobre SPED detalha cada obrigação acessória, e a de documentos fiscais eletrônicos detalha o ciclo do documento. A conferência fica entre as duas.

ABAP e Clean Core: o que o SAP publica

1. 01

   Usuário-chave (in-app)

   Para necessidades simples, como acrescentar um campo, o SAP indica as ferramentas de usuário-chave. As necessidades mais complexas devem usar as ferramentas ABAP de desenvolvimento (Fonte: ABAP Cloud FAQ).

2. 02

   On-stack com ABAP Cloud

   Código do cliente dentro do S/4HANA, acoplado ao processo, usando só objetos liberados. O SAP o recomenda para cenários fortemente acoplados (Fonte: ABAP Cloud FAQ).

3. 03

   Lado a lado na BTP

   Aplicação separada, que conversa com o ERP por interface. Indicada quando o ciclo de vida da extensão não deve depender do ciclo do núcleo (Fonte: SAP News Center).

4. 04

   ABAP clássico com governança

   Nas edições Private Edition e on-premise, também é possível construir extensões compatíveis com o Clean Core usando ABAP clássico, dentro das regras de nível e das verificações do ATC (Fonte: ABAP Cloud FAQ).

Os níveis A a D aplicados ao fiscal

O SAP evoluiu o seu modelo de três camadas para um conceito de níveis de Clean Core, com quatro níveis (A, B, C e D) segundo a integridade arquitetural, a estabilidade nas atualizações e o alinhamento com os princípios do Clean Core (Fonte: SAP News Center). Os cartões abaixo resumem a definição do SAP e acrescentam a leitura fiscal da DFSpro.

A utilidade dessa classificação para o Fiscal é de vocabulário. Em vez de discutir se uma extensão é boa ou ruim, a equipe passa a dizer em que nível ela está e o que seria preciso para subir. Um inventário das extensões fiscais do ambiente, cada uma com nível, dono e data de revisão, é um artefato de governança simples e muito útil, e pode nascer de um Diagnóstico Fiscal SAP.

ATC e testes: o que impede a regressão

Transporte e rastreabilidade

Uma extensão fiscal só é confiável se for possível dizer, para qualquer data, qual versão do código estava ativa em produção e quem a aprovou. É o que o fluxo de transporte do SAP permite quando é usado com disciplina.

• Uma ordem de transporte por mudança com sentido fiscal completo, com descrição que cita a regra e o chamado de origem, e nunca uma ordem genérica que mistura assuntos.
• Liberação do transporte só depois do ATC sem pendências e do teste de homologação aprovado pelo Fiscal.
• Registro, no chamado, de quem pediu, quem definiu a regra, quem desenvolveu, quem testou e quem aprovou, com datas.
• Evidência de teste anexada ao chamado: casos, resultados e capturas do que foi conferido.
• Janela de transporte para produção alinhada ao calendário fiscal, evitando mudar regra no meio de um fechamento.
• Plano de retorno descrito antes da mudança: como reverter e o que fazer com os documentos gerados no intervalo.

A rastreabilidade tem uma finalidade que vai além da auditoria técnica. Quando uma autuação ou uma divergência pergunta por que um imposto foi calculado de determinada forma em determinado mês, a resposta precisa aparecer em minutos, com a regra, a versão e a aprovação. É o que transforma uma customização em um ativo defensável, e não em um risco escondido.

Documentação que sobrevive à equipe

A documentação de uma extensão fiscal tem três leitores: o fiscal que precisa entender a regra, o técnico que precisa mantê-la e o auditor que precisa confiar nela. Um único documento curto, com seções fixas, atende aos três.

• Regra em uma frase. O que a extensão faz, em linguagem fiscal, assinada pelo responsável da regra.
• Base normativa. O ato, o artigo ou a nota técnica que fundamenta a regra, com link, e a data da última conferência.
• Ponto de extensão e nível. Onde o código está plugado, em que nível de Clean Core se enquadra e por quê.
• Entradas, saídas e exceções. Quais dados lê, o que devolve, o que acontece quando o dado falta.
• Casos de teste. A lista de casos aprovados pelo Fiscal, com o resultado esperado de cada um.
• Dono e revisão. Quem responde fiscalmente, quem responde tecnicamente e quando a regra volta a ser revisada.

Manutenção em SAP Notes e mudanças de leiaute

Extensão fiscal não é um projeto que termina. O ambiente em que ela vive muda por ao menos três caminhos, e cada um precisa de uma rotina.

Um modelo de operação contínuo ajuda a não deixar essa rotina para a véspera do problema. A página sobre o AMS Fiscal descreve como esse acompanhamento consultivo pode ser organizado, e a de migração para o S/4HANA trata do momento em que o inventário de extensões é decisivo.

Exemplo ilustrativo de código e de teste

Os trechos abaixo são exemplos curtos e fictícios, escritos só para mostrar o formato de uma validação pequena e o caso de teste que a acompanha. Não representam código de nenhum cliente, não foram feitos para uso em produção e não substituem a análise do ponto de extensão do seu ambiente.

METHOD validar_ncm.
  " EXEMPLO ILUSTRATIVO E FICTÍCIO. Não usar em produção.
  rejeitado = abap_false.
  IF strlen( ncm ) <> 8 OR ncm CN '0123456789'.
    rejeitado = abap_true.
    mensagem  = |NCM { ncm } fora do formato de 8 dígitos|.
  ENDIF.
ENDMETHOD.

Repare no que o exemplo faz e no que ele evita. Faz uma só coisa, com entrada e saída claras. Não lê tabela do SAP, não grava nada e não depende de variável global. A mensagem diz o que está errado. O método cabe em uma tela e pode ser coberto por teste automatizado, e o ponto de extensão onde ele seria chamado é decisão separada, que depende do ambiente.

Item: material com NCM 12345678, natureza de operação X
Regra assinada pelo Fiscal: "para a natureza X, a NCM precisa existir na tabela Z"
Esperado: aceita
Item: material com NCM 1234
Esperado: rejeita com a mensagem "NCM 1234 fora do formato de 8 dígitos"

O caso de teste acima nasceu da regra, escrita em português pelo Fiscal, e não do código. Esse é o formato que se quer: a frase do Fiscal vira o teste, o teste vira o critério para aceitar o código.

Roteiro de uma extensão fiscal

O roteiro abaixo resume como uma extensão fiscal deve ser conduzida, do pedido à operação. Ele serve para quem contrata e para quem executa, e é o que a DFSpro usa como referência no recorte fiscal.

1. 01

   Pedido e regra

   O pedido é descrito em termos fiscais, com o cenário, o documento e o resultado esperado. O Fiscal escreve a regra em uma frase e aponta a base normativa.

2. 02

   Alternativas

   Passa-se pelo critério de quando não customizar: dado mestre, parametrização, produto, ponto de extensão publicado. O resultado fica registrado.

3. 03

   Desenho

   Escolhe-se o ponto de extensão, o nível de Clean Core pretendido e o desenho da interface. Define-se o dono fiscal e o dono técnico.

4. 04

   Casos de teste

   Os casos são escritos antes do código, com o Fiscal, incluindo os casos de borda e os casos em que a regra não deve agir.

5. 05

   Desenvolvimento

   O código é feito no menor tamanho possível, com ATC e testes unitários rodando durante o trabalho.

6. 06

   Homologação

   O Fiscal testa em ambiente de homologação com documentos representativos, e a aceitação é registrada.

7. 07

   Transporte e operação

   A ordem de transporte é liberada com a evidência anexa, em janela compatível com o calendário fiscal.

8. 08

   Revisão periódica

   A extensão entra no inventário, com nível, dono e data de revisão, e é revista a cada ato novo ou a cada atualização.

Erros que custam caro em ABAP fiscal

A maior parte desses erros tem a mesma raiz: tratar a customização como uma decisão técnica quando ela é, antes, uma decisão fiscal. Quando o Fiscal está na mesa desde o pedido, a maioria desaparece.

Como a DFSpro atua

A DFSpro é uma consultoria de Governança Fiscal SAP, de Curitiba, fundada em 2018, e atua na camada fiscal do projeto.

Para o que cabe à configuração e à determinação padronizada, a DFSpro também é Canal Autorizado do GUEPARDO Tax, produto da NTT DATA, e a decisão entre produto e código é parte do critério de quando customizar. Se a dúvida é o estado atual das suas extensões, o Diagnóstico Fiscal SAP é o ponto de partida.

Fontes oficiais com link

As afirmações sobre o modelo de extensão, o ABAP Cloud, o ATC, o BRFplus e os pontos de extensão da nota fiscal vêm de material publicado pelo SAP, listado abaixo. O critério de decisão e o roteiro são a orientação da DFSpro.

Comece pela regra em uma frase

Se você tem uma extensão fiscal pedida, ou um conjunto de extensões antigas que ninguém ousa mexer, o ponto de partida é o mesmo: escrever, em uma frase, a regra fiscal que o código executa. A conversa por contato é o canal para fazer isso junto com a DFSpro.