cancel
Showing results for 
Search instead for 
Did you mean: 

Erros frequentes NFe desde Out/2011 (215, 217 e 204)

Former Member
0 Kudos

Boa tarde pessoal,

Desde outubro/2011 estamos cum uma certa frequência em 2 tipos de rejeição no GRC. São eles:

1) Lote com erro 215 Rejeição: Falha no schema XML + 71 - Rejeitado pelo Processamento da Nota Fiscal Eletrônica

Este erro não está na nota, somente no lote. Geralmente ocorre quando a nota possui algum problema de cadastro. No entanto pelo erro 215 não constar na nota e sim no lote, este status não volta para o GRC deixando a nota na engrenagem.

O procedimento que temos utilizado hoje é a "consulta de status"... uma vez feito isso, a nota volta com status 217 - NF-e não consta na base da SEFAZ. Aí este status sim, retorna para o R/3, permitindo ação sobre esta nota.

Dúvida: o status 215 não deveria estar além do lote, também na nota e retornar automaticamente para o SAP sem ação manual?

2) Nota Rejeitada com erro 204 Rejeição: Duplicidade NFE + 71 - Rejeitado pelo Processamento da Nota Fiscal Eletrônica

O erro de duplicidade ocorre em ambiente Produtivo e na primeira tentativa de envio a SEFAZ o que não justifica a duplicidade. Nesta situação a nota fica autorizada na SEFAZ, porém na engrenagem no R/3 e somente quando clicamos no botão consulta de status, ela equaliza todos os ambientes com a autorização da nota e status 100 - Autorização de Uso.

Dúvida: porque isso ocorre? O status de autorização não é o que já deveria ser o preenchido, ao invés do 204?

Existem notas recentes para ambas as situações? Estamos no SP 20 do GRC e no SP 31 do R/3 versão 4.7 e a empresa optou por não utilizar o validador do GRC.

Desde já muito obrigada pela ajuda!

Atenciosamente. Luciana.

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

Boa tarde.

Quanto ao item 1, sei que algumas SEFAZ (BA, talvez MT, não lembro....) quando recebem XML com falha de schema rejeitam o LOTE ao invés da nota. Também concordo que esta errado. Já tentei questionar a SEFAZ porém a resposta deles é que não podemos enviar nota com falha no schema.

Confirme o erro de schema em: http://www.sefaz.rs.gov.br/NFE/NFE-VAL.aspx

Se o validador do GRC não "pegou", abra um chamado na SAP.

Mas ví que você optou por não usar o validador, neste caso imagino que terá que fazer a validação que o GRC faz no SAP R/3 (na criação da nota).

obs.: A não ser que meu ambiente esteja desatualizado, quando isto ocorre (rejeição do lote e não da nota), acho que o status realmente não volta para o SAP R/3 - abra um chamado conforme orientação do Henrique

At.,

Bernardo Braga

Edited by: Bernardo Tavares Braga on Dec 13, 2011 6:16 PM

Former Member
0 Kudos

Olá Henrique e Bernardo, tudo bem?

Obrigada pelos retornos. Quanto ao uso do validador GRC, este cliente foi um dos primeiros a implementar a NFe SAP e há alguns anos atrás o validador não tinha uma versão muito amigável. Sendo assim, eles consideravam que o validador mais atrapalhava do que ajudava. Hoje como a solução está mais madura e depois de abordar este assunto com vocês, entendo que vale eles testarem os erros 215 com o validador ativo em QAS por exemplo para comprovar a eficácia do mesmo.

Quanto ao erro 204, identifiquei que todas as notas são AM. Sendo assim, pode ser um problema na SEFAZ, certo?

Vou entrar em contato com eles.

Muito obrigada pela ajuda por enquanto.

Former Member
0 Kudos

Lembrando sempre que o validador não apenas valida a nota, mas trata ela também (como remover caracteres especiais).

Acho que a não utilização do validador é um risco muito alto.

Se achar que o validador esta com algum problema ou falta alguma validação, só abrir um chamado na SAP relatanto o ocorrido. Caso realmente tenha algo errado ou faltando, uma nota de correção será liberada.

At.,

Bernardo Braga

henrique_pinto
Active Contributor
0 Kudos

Oi Luciana,

não deixe de abrir o chamado, pra entender o porquê de o 215 não estar voltando pro ERP.

Abs,

Henrique.

former_member182114
Active Contributor
0 Kudos

Bom dia Luciana,

Sobre o 215/225 (falha de esquema). Existem casos e existem casos, em princípio se tudo ocorre conforme esperado tanto a NF-e quanto o lote são atualizados, mas isto depende também das informações da resposta da Sefaz. Por exemplo, tem casos em que a Sefaz aceita o lote e na resposta do processamento diz que o esquema está inváido, porém não responde que nota foi rejeitada. O esperado no BATSR são respostas individualizadas do processamento autorizado/rejeitado de cada NF-e, provavelmente deve ser o motivo.

Obs1: Não acontece desta forma para todas as Sefazes, as que rejeitam falha de esquema no envio (interface BATCH) o GRC se atualiza e atualiza o ERP sem problemas.

Obs2: Salvo o passado, não existe sistema NFE produtivo com validador desligado com qualidade. Qualquer travessão (caracter especial do word) ou acentuação para algumas Sefazes (principalmente Sefaz MG) irá provocar rejeitação em 100% dos casos que acontecer.

Aproveitando que vocês vão revisar, coloque outro ponto na lista. Configuração de lote de vocês deve estar 1 NF-e por Lote.

Como você comentou, antigamente o validador deixava passar bastante coisa causando os 215/225 e bastava 1 nota com problema para rejeitar o lote inteiro, então é provável que a configuração de lote de vocês esteja 1 pra 1 por esta segurança necessária àquela época. Como você está com SP20 seguramente pode aumentar para 50 NF-es por lote, 500.000 tamanho e eliminar as configurações especificas por CNPJ (se houver) deixando apenas a linha default. Mexa apenas no tempo de espera para fechar o lote, este deve ser de acordo com o volume esperado. Poucas NF-es... 5 segundos... medio 20... muitos talvez 30/40... Isto vai fazer seu GRC/PI e processamento de NF-es "rodarem" suave.

Atenciosamente, Fernando Da Ró

former_member182114
Active Contributor
0 Kudos

Bom dia Luciana,

Assim que possível dê feedback à thread e encerre se solucionado.

Atenciosamente, Fernando Da Rós

-

-


Desculpe, agora que vi que não está como questão e sim como informação.

Edited by: Fernando Ros on Dec 22, 2011 5:27 AM

Former Member
0 Kudos

Olá Luciana,

Gostaria de saber se você tem alguma novidade sobre o Lote com erro 215 Rejeição: Falha no schema XML?

Aqui na empresa desligamos o validador somente para testar se as notas eram rejeitadas e processadas corretamente. Para SEFAZ SP e RS a nota foi rejeitada por falha no esquema e o status voltou normalmente para o R/3. Porém, a SEFAZ PE ao invés de rejeitar a nota ela rejeitou o lote e a nota voltou sem status e neste caso a nota não foi atualizada no R/3.

Baseado nisso, gostaria de saber se há alguma solução para este caso porque fiquei com receio de ocorrer o mesmo problema em produção. O validador não pegar algum campo/info faltante no xml e a SEFAZ PE rejeitar o lote e a informação não ser atualizada no R/3.

Desde já agradeço,

Juliano Costa

henrique_pinto
Active Contributor
0 Kudos

Caros,

Rejeição de esquema sempre foi por lote - isso foi até o principal motivador do desenvolvimento do validador.

Me causa estranheza dizer que em alguns casos é por nota.

As variações que podem ocorrer são:

- o 215/225 voltar no cStat cabeçalho do retConsReciNFe (interface BATSR)

- o 215/225 voltar no cStat do retEnviNFe (interface BATCH)

Esse segundo foi uma "novidade" que algumas SEFAZs (e.g. BA) trouxeram depois, e aí adaptamos o retorno da BATCH para alimentar o R/3 caso tivesse algo diferente de 103 (e acho q 999 tb). Mas o 1o sempre funcionou. Deixou de funcionar agora??

Sei tb que em algum momento as SEFAZs definiram que 215 era pra erro de esquema do lote, e 225 era da msg de consulta consReciNFe (ou vive-versa, nao recordo exatamente). Adaptamos o retorno do BATSR para só devolver o do erro de lote pro ERP - no caso de erro na msg de consulta, o lote é gravado com erro mas sem retorno (similar ao 999 a nível de lote), para possibilitar reenvio da msg de consulta de lote e/ou Status query individual por nota.

Abs,

Henrique.

Former Member
0 Kudos

Olá pessoal! Boa tarde, tudo bem?

No cliente para o qual eu presto consultoria, este erro do 215 que volta somente no lote, ocorre apenas com a SEFAZ AM.

Este cliente, por opção, nunca utilizou o validador do GRC, conforme mencionei no início do tópico que abri no fórum. Estamos negociando com eles a utilização, mas é um processo lento...

Bom, o último ponto de análise que efetuados foi a partir da pesquisa por notas já existentes para este problema. Encontrei a nota (SAP Note 1461745 - The retransmition of a status from GRC to ERP fail) que busca o status do lote e envia para o SAP quando a SEFAZ não o envia em nível de nota. Esta nota já encontra-se aplicada no ambiente que eu atendo e pedi a um ABAP para identificar então o porque no caso destas notas de Manaus o status não volta para o ERP. Após o debug foi identificado que esta nota através das funções /XNFE/ERP_STATUSUPDATE e /XNFE/UPDATE_ERP_STATUS chamam a J_1B_NFE_XML_IN_TAB e conseqüentemente a função J_1B_NFE_XML_IN para atualizar o status da nota no ERP.

Um dos parâmetros utilizados para atualização da nota é o da tabela /XNFE/NFEHD-DOCSTAT, que na situação que eu tenho da SEFAZ AM é u201CAu201D.

Dentro da função J 1BNFE_XML_IN no ERP há 2 notas aplicadas que separam o tratamento do campo docstat em duas direções:

Se o campo /XNFE/NFEHD-DOCSTAT que equivale ao campo msgtyp for igual a u2018123456789u2019 a nota será tratada pela J_1B_NFE_XML_IN. Se o campo for igual a A e B deverá ser tratada pela J_1B_NFE_SET_STATUS. (que é chamada pela J_1B_NFE_SET_STATUS_IN_BACKEND). É neste ponto que o erro ocorre, pois a nota da SEFAZ AM deveria ser tratada pela J_1B_NFE_SET_STATUS, porém não encontramos uma chamada no GRC que trate da mesma. A chamada é somente para a função J_1B_NFE_XML_IN_TAB e conseqüentemente para a função J_1B_NFE_XML_IN.

Bom, a partir disso, sugerimos ao cliente que abrisse o chamado na SAP. O usuário que autoriza a abertura do chamado encontra-se de férias e por isso ainda não conseguimos evoluir no assunto.

Juliano, se você identificar que esta análise se encaixa na situação que você possui e tiver autonomia para abrir o chamado na SAP, acho válido, pois todos nós saimos ganhando.

Neste momento, não tenho essa possibilidade, pois dependo do cliente.

Fernando, Henrique, se tiverem como contribuir, desde já, agradeço!

Abraços, Luciana.

henrique_pinto
Active Contributor
0 Kudos

Olá Luciana,

novamente, todo erro 215 é pro lote todo.

Você deve estar confundindo se ele volta no envio (BATCH) ou verificação (BATSR).

Quanto a sua análise, note que essas 2 funcoes que você citou só são utilizadas em tentativas de reenvio (via Monitor ou via Job); no caso da tentativa inicial de retorno ao ERP, quem é executada é a função /XNFE/RECEIVE_BATCH_DATA. Essa função chama o form update_nfehd, que por sua vez atualiza o DOCSTAT para 1, 2 ou 3, dependendo se foi autorizada, rejeitada ou denegada.

No seu caso, como o DOCSTAT ainda está como A, aparentemente essa função nao rodou, ou seja, o retorno do proxy da interface BATSR do PI pro GRC falhou por algum motivo. É isso que tem que ser avaliado.

O retorno final de status de processamento de NF-e do GRC pro ERP deve ser sempre numero. O retorno de letras (A, B, C) é feito pelas RFCs de recebimento (/XNFE/NFE_CREATE, /XNFE/NFE_CANCEL e /XNFE/NFE_SKIP, respectivamente). Elas que chamam a J_1B_NFE_SET_STATUS_IN_BACKEND.

Abs,

Henrique.

Former Member
0 Kudos

Boa Tarde Senhores,

O Nosso sistema GRC do nada mudou o XML para a versão 1.0

Autualizamos o Sistema com a NT 004/2011 no Dia 1 de Dezembro. e temos Notas Validadas corretamente com o XML 2.0 até dia 6 de Dezembro, Após esta Data o sistema não valida as Notas e identifiquei o XML como 1.0.

Esse sistema é o Nosso QA. e na Produção o Sistema Funciona Normalmente com o 2.0.

Gostaria de alguma dica

Obrigado.

eduardohartmann
Contributor
0 Kudos

Boa tarde mcalgaroto,

Primeiramente, lembre de abrir nova thread para assunto novo...

Pode ser que alguém (ou alguma "coisa" hehehe) tenha alterado a configuração da versão do XML por filial, no SAP (não GRC).

Veja na tabela J_1BNFE_CUST3 como está a versão do XML para a(s) filial(is) - lembre de considerar a validade.

Abs,

Eduardo

eduardohartmann
Contributor
0 Kudos

Mais uma coisa: dependendo da forma como foi implementada a NF-e aí, pode ser que a configuração não esteja por filial, mas por Região, ou alguma outra forma... o mais comum é definir por filial.

Veja na SPRO:

Componentes válidos para várias aplicações -> Funções gerais de aplicação -> Nota fiscal -> Notas fiscais eletrônicas (NF-e) -> Atribuir versão XML a região

Também: Componentes válidos para várias aplicações -> Funções gerais de aplicação -> Nota fiscal -> Filial CNPJ -> Definir locais de negócio. Escolha a empresa, marque a filial e vá para "NF-e: configuração do sistema".

Ah, a configuração da versão por filial é por modelo de NF... mas creio que não esteja influenciando no seu caso. Porém, vale a pena confirmar

Indo mais além (caso o acima não aponte o problema), vá na função J_1B_NF_MAP_TO_XML, coloque break nas chamadas dos FORMs read_nfe_customizing3 e read_nfe_customizing1.

Se não for encontrado o ponto, pode ser que esteja sendo definida a versão na BAdI ou em algum enhancement - nunca vi alguém fazer isso, mas....

Abs,

Eduardo

Former Member
0 Kudos

Olá Eduardo

Agradeço a respostas.

Certamente verifiquei as informações J_1BNFE_CUST3 via Se16 porém as configuração está correta em 2.0.

E por região tambem.. tudo está 2.0 no ERP.

Alguma dica mais ?

att,

Maikel

eduardohartmann
Contributor
0 Kudos

Oi Maikel,

Você tentou o debug no envio da NF-e (J_1B_NF_MAP_TO_XML)?

Sds,

Eduardo

Former Member
0 Kudos

Olá Eduardo,

Tentarei essa solução, passarei a equipe ABAP.

Abraço e muito obrigado

henrique_pinto
Active Contributor
0 Kudos

Olá Luciana,

quanto ao 1, sim, o 215 deveria estar voltando pro ERP. Deve ser analisado o porque disso nao estar ocorrendo aí.

É SEFAZ-PR? É devolvido um numero de protocolo mesmo sendo rejeitado?

Abra um chamado no componente SLL-NFE. Contudo, nao entendo o porque de a empresa nao usar o validador. Qual o sentido/motivo??

Quanto ao 2, esse é o procedimento normal, na ocorrencia do 204, que deveria ser esporádico.

Se está acontecendo comumente, é possível que a SEFAZ esteja rejeitando na mensagem mas aprovando internamente, e daí qdo vc reenvia falha. Vale uma análise mais detalhada do que está acontecendo também.

Abs,

Henrique.