Erro de assinatura no GRC NFE em NFe com tags de retirada/entrega

Publicado por:Renan Correa 01 de November de 2021
Compartilhe:
01 de November de 2021

Erro de Assinatura no GRC NFE por causa do nome do parceiro no endereço de retirada

Essa semana tive um erro muito atípico no GRC, tanto que resolvi até fazer um post sobre isso. Gastei um tempinho debugando para entender o que estava passando no sistema.

Até me sinto velho quando falo de GRC NFE, toda empresa com SAP hoje podia estar usando NF-e na nuvem com custo menor, monitoramento automatizado e sem stress com atualizações, mas tem muita empresa que gosta de gastar mais e dar manutenção no sistema por conta… eu acho…

Basicamente estava recebendo uma rejeição 225 (falha de schema) numa nota específica.

Olhando a nota não achei nada de errado visualmente e quando passava no validador da SEFAZ RS então a história estava mais estranha, o validador dava erro de assinatura inválida:

Ein Bild, das Text enthält.

Automatisch generierte Beschreibung

Tem um código de rejeição 297 específico para assinatura inválida, mas o porque o governo não devolveu ele não sei e nem tenho idéia do porquê.

Mas então que treta é essa que tá acontecendo?

Análise do B.O.

Para assinatura ficar inválida a causa mais provável é que o XML tenha sido alterado depois de assinado.

Então peguei a NF rejeitada, enviei novamente e no /H fui até o método no GRC NFE onde o sistema passa os dados para serem assinados.

Função do ERP que chama o GRC e passa as estruturas para montar a NFE

Seguindo para o que dá pra fazer, abri o parâmetro do XML no debuggger, peguei o conteúdo e comparei com o XML da NFE rejeitada que eu já tinha.

E não é que tinha uma diferença mesmo?

A Tag X_NOME dentro do grupo de parceiros de retirada tinha um ESPAÇO em branco no primeiro caractere e depois da assinatura esse espaço em branco não existia mais.

Tá mas o que é que causa esse problema do espaço em branco? Essa tags X_NOME não podem começar por brancos, isso causa erro de estrutura do XML.

Exemplo inválido:

<xNome> S4CN Consultoria ILIMITADA</xNome>

Exemplo válido:

<xNome>S4CN Consultoria ILIMITADA</xNome>

Então sobre duas opções:

1-Esse espaço em branco deveria ser removido antes de assinar o XML e não está sendo por algum motivo.

2-Esse espaço em branco não deveria ser removido depois de assinar o XML e deixar o governo rejeitar por falha no schema devido ao espaço em branco.

O GRC tem uma lógica de mapeamentos dos dados das tabelas internas transferidas via RFC que passa por uma classe que faz ajuste como remover caracteres inválidos, retirar espaçoes em branco e também validar se o conteúdo de uma tag é válido ou não.

Classe/Método no GRC NFE onde as validações são executadas

Essas regras ficam na tabela /XNFE/XMLVALID.

Dei um “confere” na tabela e, NÃO ACREDITO, X_NOME dentro do grupo retirada ( e também do grupo entrega ) não tinha nenhuma regra estabelecida.

Hmmmm… Isso é a causa do problema….

Ein Bild, das Tisch enthält.

Automatisch generierte Beschreibung

Se tivesse uma entrada ali com o “No Spaces” marcado para essa tag, aquele espaço em branco seria removido antes da assinatura.

OK.

É Um problema super específico, precisa ter um parceiro com espaço em branco no primeiro dígito do master data e esse parceiro precisar ser local de retirada ou de entrega na nota.

OK.

Mas aconteceu, não é hipotético.

E agora José, como que posso resolver esse galho?

Solução do B.O.

Eu criei uma entrada nova na tabela das validações especificamente para o campo X_NOME do grupo retirada.  

Isso funciona, mas não é definitivo porque essa não é uma tabela de customizing e é sobrescrita em upgrade de SP. A solução definitiva é criar uma validação customizada no SPRO na opção ‘NF-e: Maintain Validation Rules’ usando a view /XNFE/V_XMLVALCN. Essa é uma opção para configurar regras de customização para as validações no GRC NFE.

Moral da história: Criando entradas adicionais de validação no GRC o erro não acontece, mas se criar os parceiros no ERP sem espaços em branco no primeiro dígito, isso também ajuda ;D

Valeu Gurizada,

Renan Correa

OBS:

Para quem ficou curioso sobre remover o espaço depois da assinatura eu não debuguei o processo até o fim, mas suponho que seja algo na proxy do cenário do lote que remove o dito cujo do espaço em branco. Olhando na proxy tem uma expressão regular na qual o espaço em branco no primeiro dígito não se enquadraria.

Quer ficar ligado nas novidades de localização? Entra no grupo da S4CN no Telegram e segue a gente no canal do Youtube

Mais infos sobre a localização Brasil no ERP, direto da sap, vocês podem conferir no SAP community na tag de S/4HANA logistics for Brazil

Outros posts sobre Localização você pode conferir filtrando pela categoria NFE/CTE ou Localização BR Geral.

Subscribe
Notify of
guest
1 Comentário
Oldest
Newest Most Voted
Inline Feedbacks
Ver Todos Comentarios
Vinícius Ferrari
Vinícius Ferrari
2 meses atrás

Parabéns pelo post Renan!

Esses dias por coincidência também me deparei com o mesmo erro 225. O motivo era também um caractere especial (#) no campo nº do endereço do cliente do grupo Entrega no XML. Como o cadastro estava errado, antes de assinar, o sistema considerava o caractere especial, ex: #2135, mas depois que a assinatura foi feita, o sistema apagava o # e portanto, a SEFAZ retornava o erro 225.
O NF-e foi cancelada, o cadastro foi corrigido e um novo documento foi criado!

1
0
Deixa tua opinião aí!x
()
x