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

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:

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.

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.

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….

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.