Erro 297 - (Rejeição: Assinatura difere do calculado)

[former_member182577]

Pessoal, boa tarde!

Estou com algumas NF-e's que foram rejeitadas com o erro 297. Alguém já passou por isso antes?

Tentamos reenviar as NF-e's algumas vezes mas o erro retorna.

Agradeço qualquer ajuda.

Renato

[Former Member · Accepted solution]

Sim. Tive esse problema agora com 2 notas enviadas para SEFAZ BA.

O problema era o ' no campo Cidade (xMun) do destinatário. Foi cadastrado no SAP como: DIAS D'AVILA.

Depois da analise da SEFAZ BA, a resposta foi:

Prezada XXX,

Conforme Manual de Integração Contribuinte item 5.3, todos os textos de um documento XML passam por uma análise do u201Cparseru201D específico da linguagem. Alguns caracteres afetam o funcionamento deste u201Cparseru201D, não podendo aparecer no texto de uma forma não controlada.

Os caracteres que afetam o u201Cparseru201D são:

u2022 > (sinal de maior),

u2022 < (sinal de menor),

u2022 & (e-comercial),

u2022 u201C (aspas),

u2022 u2018 (sinal de apóstrofe).

Alguns destes caracteres podem aparecer especialmente no campo de Razão Social, Endereço e Informação Adicional. Para resolver esses casos, é recomendável o uso de uma seqüência de u201Cescapeu201D em substituição ao caractere que causa o problema.

Ex. a denominação: DIAS & DIAS LTDA deve ser informada como: DIAS &amp ; DIAS LTDA no XML para não afetar o funcionamento do "parser".

Verifique no preenchimento da nota a existência de um desses caracteres acima citados, realize as correções devidas e transmita a nota.

Por exemplo, segue trecho do XML enviado por vocês onde está sendo utilizado caractere especial:

(ai mostra o XML nosso com o sinal de apóstofre no campo cidade (xMun) do destinatário.

obs1: O mensagem de erro da SEFAZ não tem nada a ver...rs.

obs2: Aparentemente nem todos campos são removidos os caracteres especiais (chamado?).

obs3: O validador não valida este tipo de problema? Caracter especial em campos?

At.,

Bernardo Tavares Braga

Edited by: BERNARDO TAVARES BRAGA on Feb 2, 2010 5:05 PM

Edited by: BERNARDO TAVARES BRAGA on Feb 2, 2010 5:06 PM

[henrique_pinto · Accepted solution]

Bernardo,

Curiosidade: o mesmo XML dá erro no validador da SEFAZ RS?

As vezes, algumas SEFAZ tem interpretacoes proprias de algumas frases do manual, e acabam implementando manualmente algumas restricoes que o proprio padrao XML aceita.

Abs,

Henrique.

[Former Member · Accepted solution]

Henrique, o mesmo XML não da erro no validador da SEFAZ RS...por isso que enviamos para a SEFAZ BA analisar pois não conseguimos encontrar nenhum problema.

Não sabia que não podia ter ' em NENHUM campo....rs.

At.,

Bernardo Tavares Braga

[henrique_pinto · Accepted solution]

Esse eh o ponto. De fato, nenhum parser "de mercado" escapa o apostrofo pra &apos, assim como nenhum validador de schema XML "de mercado" requer q esse caractere seja escapado (em geral, soh olham &amp, &quote, etc).

Se eles querem isso, e se estao fazendo isso, entao desenvolveram "na mao".

Abs,

Henrique.

[Former Member · Accepted solution]

Vejam respota POSITIVA da SEFAZ BA que recebi agora:

Prezados,

Realizamos alguns melhorias quanto o tratamento de caracteres especias no XML da NF-e não sendo mais necessário realizar ajustes no sistema que utilizam para emissão de notas. Por gentileza, retransmitam as notas que apresentaram a rejeição.

Atenciosamente,

XXXXXXXXX

Secretaria da Fazenda do Estado da Bahia

Analista de Suporte - SGF/DTI/GEAUS

At.,

Bernardo Tavares Braga

[former_member182577]

Boa tarde!

O problema aconteceu foi na BA também.

Mas antes de verificar as dicas passadas por vocês decidimos reenviar as NF's novamente e para a nossa surpresa elas foram Autorizadas.

Só que por algum motivo o Status na J1B3N continua como "Aguard Resposta".

Renato

[former_member182114]

Bom dia Renato,

Isto me leva a pensar em três situações:

1) A Sefaz por problemas temporários respondeu com esta rejeição de forma errônea.

2) O XML gerado pela segunda vez foi diferente do gerado na primeira vez. Isto pode acontecer se nos métodos da BAdI CL_NFE_PRINT (FILL_HEADER e FILL_ITEM) não foram considerada a possibilidade de reenvio. Explicando melhor, às vezes os desenvolvedores pegam tudo de memória da transação que está gerando a nota, e não lembram de programar o reenvio onde não tem mais a transação original e deve-se pegar do banco de dados.

Obs.: Para o item 2 quando o cliente implementa o decouple só precisa pegar do banco de dados.

Verifique na SXI_MONITOR se os XML's gerados nas duas transmissões são iguais.

Atenciosamente, Fernando Da Ró

[henrique_pinto]

Fernando,

qual a 3a situacao?

Abs,

Henrique.

[former_member182114]

Rss Henrique,

A "terceira" situação eu tinha pensado e tirei, seria se o 297 foi entregue no lote e não na própria nota, então o 297 poderia estar em outra nota... E a rejeição se espalhou...

Risquei esta possibilidade pois o 297 é por NF-e (a não ser que tenha Sefaz inventando...)

@Bernardo,

Ótima notícia, que bom que eles também estão trabalhando para melhorar o produto deles.

Atenciosamente, Fernando Da Rós

Edited by: Fernando Ros on Feb 2, 2010 8:51 PM

[former_member182114]

Bom dia Renato / Bernardo,

Isto acontece bastante pois o usuário faz (ctrl + C e ctrl + V) de winword e cola no R/3, então no seu D'AVILA este apóstrofo não é um apóstrofo apenas, é um caracter especial.

Implemente a SAP Note 1391981 que elimina complementa qualquer caracter especial, inclusive LF, CR, TAB....

Atenciosamente, Fernando Da Ró