cancel
Showing results for 
Search instead for 
Did you mean: 

Verificação de NF-e de entrada dispara proxy da versão errada

former_member182503
Active Contributor
0 Kudos

Pessoal,

estou fazendo alguns testes com o B2B de entrada e notei um possível BUG/Falha na minha customizing.

Quando envio uma NF-e na versão 2.0 para a interface NFB2B*, ele entra normalmente no GRC e grava na /XNFE/XMLIN. O problema é quando ele dispara a interface NFESC para verificação do status da mesma na SEFAZ. No caso, ao invés de chamar a interface do namespace 006 ele chama a do namespace 005a.

Olhando o código da função /XNFE/RECEIVE_INCOMING_B2B, depois de efetuar a gravação da NFE na /XNFE/XMLIN, ele chama o FM /XNFE/GET_XML_VERSION passando a UF, TIPO AMBIENTE e ELEMENT. Aqui nesse ponto, ele vai na tabela de customizing /XNFE/TSRV fazendo um SELECT SINGLE sem passar a chave completa da tabela (ok, se a função vai justamente pegar a versão do XML, que faz parte da chave primaria da tabela, não faria sentido ele usar a chave completa, mas...), pegando somente o PRIMEIRO registro encontrado.

No meu caso, tenho customizado na SPRO as duas versões de XML para verificação de status do servico, sendo 005a e 006.

Como eu imagino que seja possível utilizar as duas versões de XML em paralelo, considerando também que o customizing permite que eu insira registros para as duas versões nessa tabela, eu penso que isso reflete uma abordagem errada na forma de definir qual é a versão do XML da NF-e de entrada.

IMHO, deveria-se verificar a versão do XML da NF-e de entrada pelo próprio XML entrado(tem os atributos de versao) e não pelo que está na customizing do GRC. Identificada a versão do XML que entrou, aí sim verificaria no GRC se ele suporta essa versão e daria continuidade no processo caso suporte, gerando log de erro caso não suporte.

Alguém já passou por isso? É falha na minha customizing ou posso abrir chamado?

Grato,

José Nunes

Accepted Solutions (1)

Accepted Solutions (1)

henrique_pinto
Active Contributor

Jose,

tens toda razao, é bug msm.

Acredito que nao foi analisado pelo time de desenvolvimento, e confesso que passou da minha analise tb.

No caso, nao é nem pra ele ver a /XNFE/TSRV, isso era o comportamento qdo a TSRV era a mandante de versao.

Agora que ela soh serve pro service status check, teria que usar a versao do XML mesmo.

Abs,

Henrique.

former_member193386
Active Contributor
0 Kudos

Pq deveria usar a versao do XML ? se o cliente sempre trabalha com uma apenas? Não tem bug Henrique, vcs pensaram certo de maneira que o sistema trabalhe mais rapido, inclusive porque campos string em chave não são performáticos

Former Member
0 Kudos

Vou discordar... penso que deveria suportar trabalhar com as duas versões ou quantas mais vierem.

Abraço

Eduardo

former_member193386
Active Contributor
0 Kudos

em qual situacao Eduardo, conhece algum landscape dessa maneira para o GRC NFe? Uma empresa só transmite em um formato, estamos com uma unica excessao ultimamente devido ao formato 2.0 e que deve ser tratado de acordo com os ambientes em si, por exemplo, uma empresa nao vai estar trabalhando com testes de 2 formatos em homologacao por estado, alias, o SEFAZ nao recebe em mais de um formato.

Former Member
0 Kudos

Oi Carlos.

No meu caso e acredito que outras empresas emitimos notas (outra série) através de outro sistema que não o SAP. Ex. notas fiscais de importação.

Na verdade tenho um cenário um pouco mais complexo; pois temos hoje diferentes fábricas, com diferentes aplicações se comunicando via GRC. Entre elas uma (sistema próprio) cujo desenvolvimento foi feito todo nos EUA com todas as regras e requisitos tributários para emissão de nota fiscal.

As mudanças de versão já são complexas por si só e ainda ter que "colocar" todos num mesmo time se torna ainda maior. Por diversas questões... recursos, demanda do mercado...

Abraço

Eduardo

Edited by: Eduardo Chagas on Aug 18, 2010 9:17 PM

former_member193386
Active Contributor
0 Kudos

Mas eles nao usam o GRC e mesmo se usa seria uma customizacao sua. o standart trabalha de maneira correta nesse aspecto, nao existe versoes diferentes trabalhando no mesmo SEFAZ de um mesmo UF para o mesmo ambiente (homologacao/producao).

Entenda Eduardo, se vc esta comunicando com o SEFAZ em homologacao por exemplo, para validar um formato de xml, a solucao vai enviar esse formato para o sefaz, vc nao vai estar testando dois formatos de XML para a solucao GRC NFe, mesmo hoje em dia com o formato 2.0, ou vc envia de um formato com o servico coerente, ou de um outro.

Vcs nao estao visualizando a solucao em completo

Former Member
0 Kudos

Deixa eu ver se entendi...

A SEFAZ não aceita receber o xml de duas fábricas distintas (no mesmo estado) com versões diferentes?

Quero dizer:

fábrica A envia versão 1.10

fábrica B envia versão 2.0

E...

A SEFAZ não aceita receber os xmls de uma fabrica com diferentes versões?

Quero dizer:

Nota fiscal mercado local enviada via SAP com versão 2.0

Nota fiscal importação/exportação enviada outra solução com versão 1.10

Abraço

Eduardo

henrique_pinto
Active Contributor
0 Kudos

Carlos,

estamos falando do B2B de incoming.

Vc nao pode garantir que 100% dos seus fornecedores vao te mandar XML na versao 006 a partir da data XX.

Cada empresa vai ter seu cronograma de migracao, e portanto com certeza vc vai ter um periodo até a data de 31/12 em que vc irá receber XMLs nas 2 versoes.

José,

eu já passei o problema pro dev, eles já estao analisando, mas vale a pena abrir chamado.

Abs,

Henrique.

henrique_pinto
Active Contributor
0 Kudos

Eduardo,

até 31/12, nao há nada em lei que proíba o mesmo CNPJ de enviar XML nas 2 versoes paralelamente.

Claro, a partir de 1o de Janeiro, suas aplicacoes terao que estar adaptadas para o layout 006.

Abs,

Henrique.

Former Member
0 Kudos

Blz!

Isso quer dizer que vou conseguir trabalhar com diferentes versões até 31/12 sem restrições quanto ao GRC?

Abraço

Eduardo

Former Member
0 Kudos

Henrique.

Me refiro as notas de saida! Pois as notas de entrada via B2B dependem da correção que você mencionou.

Abraço

Eduardo

henrique_pinto
Active Contributor
0 Kudos

No GRC nao há restricoes, pois quem manda é a versao quem vem preenchida na /XNFE/NFE_CREATE.

Vc tem que adaptar os legados para mandarem a versao do pacote de liberacao (005a/ 006) no campo novo que foi criado na interface dessa RFC.

Abs,

Henrique.

henrique_pinto
Active Contributor
0 Kudos

Carlos,

eu sei q vc está falando das notas de saida, foi justamente por isso que dei o toque, pois a pergunta inicial do José era sobre as notas de entrada, nada a ver com as notas de saída, entao nao era erro de customizing dele, era bug mesmo.

Leia as perguntas direito antes de comentar.

Abs,

Henrique.

former_member182503
Active Contributor
0 Kudos

Henrique,

obrigado pelo retorno rápido. Vou abrir o chamado ainda hoje.

[]'s

José Nunes

former_member182503
Active Contributor
0 Kudos

All,

atualizando a thread, saiu a nota https://service.sap.com/sap/support/notes/1502612 que corrige o problema relatado.

Valeu Fernando e Henrique.

[]'s

Answers (1)

Answers (1)

former_member193386
Active Contributor
0 Kudos

Falha da sua customizing, entenda, o 005a nao estara mais sendo usado, portanto, para um mesmo estado, no mesmo ambiente ou vc esta usando o 005a ou 006, nao tem que usar mais de um em paralelosmo, até porque, qual seria a logica de usar um formato que esta para cair em desuso e usar o formato novo?