Erro na comunicação - SEFAZ PE (Homologação)

Olá pessoal !

Estamos com problemas no serviço de check do status de comunicação com a SEFAZ Pernambuco no ambiente de Homologação. Entramos em contato com a SEFAZ PE e a resposta é sempre a mesma: não existe nenhum problema com o servidor de homologação. Para o ambiente de Produção, está tudo perfeito. Alguém está enfrentando o mesmo problema ?

Segue abaixo o erro encontrado:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>

- <!-- Inbound Message

-->

- <SAP:Error xmlns:SAP="http://sap.com/xi/XI/Message/30" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" SOAP:mustUnderstand="1">

<SAP:Category>XIAdapterFramework</SAP:Category>

<SAP:Code area="MESSAGE">GENERAL</SAP:Code>

<SAP:P1 />

<SAP:P2 />

<SAP:P3 />

<SAP:P4 />

<SAP:AdditionalText>com.sap.aii.af.ra.ms.api.DeliveryException: Padding length error: 184 > 32</SAP:AdditionalText>

<SAP:ApplicationFaultMessage namespace="" />

<SAP:Stack />

<SAP:Retry>M</SAP:Retry>

</SAP:Error>

Obrigado,

Roger Vier

SAP Managed Tags:
SAP Electronic Invoicing for Brazil (SAP Nota Fiscal Eletronica)

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Accepted Solutions (0)

Answers (5)

Estou manando email pra Sefaz PE todos os dias.

A previsão de implantação da nova versão de SSL/TLS era de 18/10. foi adiada pra 19/10, depois 20/10, e já estamos em 21/10.

Pelo que conversei lá , parece que niguem mais está precionando, e eles nem pensam em colcoa ro SCAN no ar por causa disso.

Acho que a maioria fez o downgrade da lib e deixou pra lá.

abraç

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Alexandre,

se nao me engano, haviam outros clientes grandes sim que decidiram nao fazer o downgrade.

Muito estranho isso deles de ficarem adiando o que está ok em homolog para producao...

Abs,

Henrique.

Alexandre,

Em qual email você está entrando em contato? Passe por favor para que eu possa de alguma forma "pressionar" também.

Não temos intuito de alteração a lib por aqui...

Att,

Marcos

Marcos,

O email é nfe at sefaz.pe.gov.br

Nós gostaríamos de evitar esse downgrade também.

Mas pela demora , acho que a decisão vai ser mais política, de fazê-lo, já que nem o SCAN eles querem liberar.

Henrique,

Poderia me informar algum contato de alguma dessas empresas?

Att.

Alexandre

Edited by: Alexandre L. Barreto on Oct 21, 2010 3:16 PM

Feito! Enviei mais um e-mail para lá (já havia sido 2 sem resposta).

Vamos ver se consigo ao menos um retorno.

Abs,

Marcos

Alexandre,

me manda um email (vc acha o meu no meu business card) que te ponho em contato com eles.

Abs,

Henrique.

Pessoal,

Notícias fresquinhas que recebi da SEFAZ. Segue na íntegra abaixo.

Prezado,

O protocolo do sap não é o descrito no Manual de integração do contribuinte. Ele está usando o TLS 1.1. que é uma evolução do SSL 3.0.

Estamos tentendo ajustar o sistema para ajudar embora formalmente não há a obrigação da SEFAZ em fazê-lo uma vez que o contribuinte é que não está em conformidade com o especificado.

Fizemos ajuste no ambiente de homologação e estamos em fase de conclusão no de produção com uma prioridade baixa (atualmente) para a solução tendo em vista outros problemas mais prioritários em nosso ambiente. Não há prazo para conclusão.

Atenciosamente,

Robson H Soares

Gestor do projeto Nota fiscal eletrônica

Henrique,

Você confirma essa informação sobre diferença da que está no manual de integração?

Abs,

Marcos

Claro que nao.

O Adapter Engine suporta o SSL v3.0, TLS 1.0 e TLS 1.1.

Ele suporta os 3, nao apenas o ultimo.

O ponto é que, por definicao do protocolo SSL/TLS, o client DEVE iniciar o handshake solicitando a versão mais alta que ele suporta, e o server DEVE retornar a maior versão que ele suporta que seja menor ou igual à versão enviada pelo client, até que os 2 acordem em uma versão.

Isso funciona ok para TODAS as outras SEFAZs do país, com exceção de SEFAZ MT que insiste em manter o SSL 2.0, indo até contra o manual do contribuinte...

A conexão com a SEFAZ PE tb é estabelecida via SSL v3.0, mas o que o time de suporte analisou é que a aplicação da SEFAZ ao final parece "esquecer" que está com SSL v3.0 e tenta fazer validacoes utilizando o TLS 1.1, que foi inicialmente solicitado, e daí os problemas.

Essa solução deles no homolog deve ter sido apenas suportar o TLS 1.1 e não corrigir a causa raiz, de fato...

Abs,

Henrique.

Henrique,

Eu já enviei um email explicando isso pra eles, mas não adiantou.

Vi , acho que aqui no fórum, alguém falando que eles usam esse componente da IBM. Está correto isso?

Não seria o caso de pedir ajuda a eles? eles poderiam entrar em contato com a SEFAZ PE ajudando arrumar o problema.

Pessoal, ótimas notícias.

A SEFAZ/PE voltou a responder as consultas de status de serviço e autorizar NF-e a partir das 19 horas de hoje. Tomara que continuem a operar.

Obrigado a todos que participaram do forum e contribuiram para ajudar na solução do problema.

Andre, tudo bem?

Você hoje ainda consegue obter o status OK (ambiente de produção) do SEFAZ de Pernambuco?

O ambiente de homologação está estabilizado, porém o de produção continua com o mesmo erro anterior, ou seja, parece que não aplicaram a correção em produção.

Acabei de realizar um teste agora a pouco...

Abs,

Marcos

Boa Tarde,

Pessoal,

Preciso de um help

Estamos com o mesmo problema, abri o chamado com a SAP recebi os arquivos.

Realizamos a substituição dos arquivos .JAR através dos caminhos

abaixo:

aik_ssl.jar

.../j2ee/cluster/dispatcher/bin/ext/tc_secssl/iaik_ssl.jar

.../j2ee/cluster/server0/bin/ext/tc_secssl/iaik_ssl.jar

.../j2ee/j2eeclient/iaik_ssl.jar

./j2ee/j2eeclient/signed/iaik_ssl.jar

w3c_http.jar

.../j2ee/cluster/dispatcher/bin/ext/tc_secssl/w3c_http.jar

.../j2ee/cluster/server0/bin/ext/tc_secssl/w3c_http.jar

Mas não funcinou, o status continua como o mesmo.

Tem algo a mais que deve ser atualizado através dos arquivos?

Marco

abs,

SEFAZ PE normalizou os procedimentos de comunicação. Agradeço a todos que participaram desta discussão.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Oi Roger,

em nosso ambiente interno de testes, funciona pra Homologacao, mas ainda vemos erros pra Producao.

Pra vc, producao está ok tb?

Abs,

Henrique.

Olá Henrique,

Sim, está normal. Ocorreu manutenção no site da SEFAZ PE no sábado do dia 25/09. Desde a data não tivemos mais nenhum problema reportado por nossos clientes. Ainda mantenho o .JAR enviado pela SAP no chamado. Pretendo no próximo final de semana retirar o mesmo para avaliar o comportamento da aplicação.

Abraços,

Roger Vier

Ah, você está com o .jar no ambiente produtivo? Provavelmente é por isso entao.

Aqui está ok na homolog mas continua com problemas na producao.

Bem que eles poderiam subir as correcoes pro produtivo...

Abs,

Henrique.

Marcos,

Desculpe a demora em te responder, mas a fase do projeto aqui estava meio que crítica e não tive tempo para fazer atualizações por aqui.

Desde que tivemos o contato com o pessoal da SEFAZ e eles atuaram no ambiente de homologação, não tivemos mais problemas.

Quanto a conexão com o ambiente de produção, continua na mesma, sem conseguir comunicar.

Se tiver novidades, atualizo vocês.

Abs.

Marcos,

Desculpe a demora em te responder, mas a fase do projeto aqui estava meio que crítica e não tive tempo para fazer atualizações por aqui.

Desde que tivemos o contato com o pessoal da SEFAZ e eles atuaram no ambiente de homologação, não tivemos mais problemas.

Quanto a conexão com o ambiente de produção, continua na mesma, sem conseguir comunicar.

Se tiver novidades, atualizo vocês.

Abs.

Obrigado pelo feedback Ricardo.

O ambiente de homologação de lá ainda tá "meio estranho", segundo o Service Status aqui do GRC passou praticamente o final de semana inteiro "fora do ar"...

Desculpem a pergunta estúpida mas se o ambiente de produção está inacessível, como é possível emitir NF para a SEFAZ de Pernambuco? Somente utilizando o SCAN?

Obrigado a todos.

Att,

Marcos

Prezados,

Informo que aqui a Verificação do Status do Serviço com a SEFAZ-PE voltou a funcionar. Havia aberto o chamado na SAP e quando recebi o arquivo IAIK para realizar o deploy verifiquei que a comunicação retornou ao normal.

Portanto não foi necessário atualizar o arquivo conforme orientações anteriores, creio que a SEFAZ-PE deva ter realizado atualizações em seu ambiente de Produção conforme fez com o ambiente de Homologação.

Gostaria que verificassem se o processo já está normal para vocês também.

Grato,

Guilherme Augusto

Estranho, no ambiente interno da SAP ainda tá dando o padding length error no sistema producao da SEFAZ PE.

Qual URL vcs utilizam?

E estao falando do check status service 005a ou 006??

Abs,

Henrique.

Bom Dia Henrique,

Desculpe pelo retorno prematuro... Durou só duas horas a verificação do Status do Serviço da SEFAZ-PE.

Pode ter sido alguma alteração temporária que eles fizeram mas depois o erro voltou a ocorrer.

Realizamos a substituição do arquivo IAIK e agora está funcionando em Produção.

Quando tiverem novidades favor avisar.

Atenciosamente,

Guilherme Augusto

Pô, mas isso quer dizer que eles já identificaram o que está errado, e que não mantem no Produtivo sei lá porque!!

Agora é momento de haver uma pressão para que eles implementem (e deixem) em produção o que já está ok em homologação.

Abs,

Henrique.

realmente é um problema com o SEFAZ de PERNAMBUCO, o WebService de verificacao de estatus de servico do ambiente produtivo deles endereco https://nfe.sefaz.pe.gov.br/nfe-service/services/NfeStatusServico esta ok, retornando os dados corretamente e validadan com o SAP, avise o pessoal do suporte do sefaz que o problema é com o ambiente de homologacao deles

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Bom dia pessoal,

Estou com o mesmo problema com o ambiente de homologação da SEFAZ PE.

Vocês tiveram alguma solução ou ainda estão com os problemas?

Se solucionaram, o que foi feito?

Obrigado.

Abs

Olá Ricardo,

Estou com chamado aberto na SAP. Ontem pela manhã, me enviaram um componente .jar para ser feito o deploy no ambiente. Fiz os ajustes e resolveu o problema de comunicação imediatamente. Porém, todas as NF-e´s que estão sendo agora enviadas, estão retornando com status 999 (erro não catalogado). Por este motivo, ainda não havia divulgado aqui no Post a solução. Vamos entrar novamente em contato com o pessoal técnico da SEFAZ PE. A SAP tb está aguardando o retorno do chamado, acredito que após a confirmação, irão divulgar o arquivo em uma nota específica. Não sei se é permitido, poderia te enviar o arquivo .jar por e-mail.

Abs,

Roger Vier

O SEFAZ resolveu o problema de hanshake segunda-feira, ainda nao testei os outros servicos no meu projeto, mas qual o problema que vcs realmente estao tendo.

Esse do erro 999 é um erro do lado do SEFAZ provavelmente, vc já chegou a testar o XML no SEFAZ do RS ou em um outro qualquer?

Sim, todas as notas retornam com 999 e o XML está sendo validado com sucesso na página Web da SEFAZ RS. Tivemos problemas semelhantes ano passado com a SEFAZ AM e realmente o problema foi resolvido no lado deles. Estamos aguardando o retorno do pessoal da SEFAZ PE.

Abs,

Roger Vier

ok, poderia por favor nos manter atualizados sobre esse problema? creio que seja de interesse geral do pessoal do grupo

Carlos,

mesmo sem trocar o .jar, vc agora consegue comunicar com a SEFAZ_PE ok?

No nosso sistema interno, o erro persiste.

O lance de trocar o .jar é paliativo, vejam o que o dev respondeu:

Hi Henrique,                                                            
https://nfehomolog.sefaz.pe.gov.br seems to be an IBM_HTTP_Server                                                                                
The situation here is that our client tries to establish connection with
TLS 1.1 (= SSL3.2). The server selects TLS 1.0 (=SSL 3.1) which is      
correct behaivior.                                                      
Due to the wrong implementation of target ssl server                    
later the server "forgets" that it was asked about SSL3.2 and           
calculates wrong MAC which causes SSL break on client side.                                                                                
The problem is reproducable using e.g.                                  
http://jce.iaik.tugraz.at/sic/Products/Communication-Messaging-Security/
iSaSiLk/demo                                                            
and typing the hostname nfehomolog.sefaz.pe.gov.br                                                                                
I don't know whether IBM_HTTP_Server  has solved                        
that problem in the mean time.                                          
Do you have a possibility to cantact administrator of                   
nfehomolog.sefaz.pe.gov.br and point their attention to this issue.

Trocando o .jar pra uma versao anterior, a versao que o client (sap j2ee) mandaria pro server seria menor, daí talvez o server não se perca. Mas eu recomendo verificar com a SEFAZ PE sobre o erro acima.

Abs,

Henrique.

Bom dia Pessoal,

Só um comentário. Já tivemos problemas com a Sefaz PE no passado (2008 primeiro evento e uma recorrência em 2009), em ambas às vezes após extensa investigação. Eles próprios fizeram algo que corrigiu o sistema deles. Talvez tenham a receita em algum lugar (espero que o expert que fez não tenha saído de lá)...

Atenciosamente, Fernando Da Ró

Sim funcionou.

Oi Carlos,

qual versao / SP do PI vc está?

Tou achando que tinha mais de 1 problema, a SEFAZ corrigiu um mas nao todos.

Abs,

Henrique.

Ola Henrique

Estou usando o 7.0 sp 21

Olá pessoal,

A SEFAZ-PE diz que o ambiente deles está OK e que apenas o cliente em que trabalho que reportou problemas de comunicação com eles.

Dando uma olhada no erro que gera ao tentar se conectar, retorna a mensagem:

<SAP:AdditionalText>com.sap.aii.af.ra.ms.api.DeliveryException: Padding length error: 111 > 32</SAP:AdditionalText>

Não sei se é o mesmo erro que retorna para vocês...

Quanto a esse .jar paleativo, eu teria também que abrir um chamado para obtê-lo, trocar e depois adotar a solução definitiva?

E qual a função deste .jar?

Abs.

Ricardo,

se vc ler a msg que colei acima, do suporte interno da SAP, vc entederá o problema.

Por definicao do SSL standard (http://www.ietf.org/rfc/rfc2246.txt), durante a fase inicial do handshake SSL (fase chamada de "hello phase") entre o server (SEFAZ) e o client (adapter engine do PI), o client deve requisitar ao servidor qual a versao mais alta que ele usa para fazer o handshake. Daí, o servidor responde dizendo qual a versao mais alta que ele consegue suportar que seja abaixo ou igual à versao requisitada pelo client, e daí se o client aceitar, o processamento segue usando essa versao.

No caso, se vc analisar o log, o adapter solicita a versao SSL 32 (TLS 1.1) e a SEFAZ responde dizendo que ela consegue usar o SSL 31 (TLS 1.0). Daí o adapter aceita essa versao e segue o processamento.

Segundo o suporte, a causa raiz do problema é que aparentemente há um erro no codigo do servidor e ele "esquece" que solicitou uma versao mais baixa, e daí faz o calculo do MAC baseado na versao que o client solicitou (32 e nao 31) e isso causa os erros de mismatch que sao observados. Provavelmente uma variavel está guardando a versao solicitada originalmente pelo client e nao a versao que foi acordada ao final da "hello phase".

Ainda segundo o suporte, o motivo de algumas empresas nao estarem tendo esse problema é que o Adapter Engine do XI só passou a suportar o SSL 32 (TLS 1.1) bem recentemente, em uma das ultimas atualizacoes de SP. Em versoes anteriores, a versao mais alta já era a 31 (TLS 1.0), e daí o servidor nao se perdia. Essa é a razão pela qual o fato de substituir o .jar da biblioteca IAIK por uma versao anterior (que suporta até o TLS 1.0/SSL 31) aparentemente "resolve" o problema. Na verdade nao resolve, apenas nao causa o servidor de se perder.

Para corroborar isso, o mesmo problema pode ser reproduzido pela ferramenta de testes da propria IAIK (que é uma biblioteca aberta externa, nao desenvolvido pela SAP, apenas utilizada pelo Adapter Engine), que se encontra no seguinte endereço: http://jce.iaik.tugraz.at/sic/Products/Communication-Messaging-Security/iSaSiLk/demo

A recomendacao é então atuar juntamente à SEFAZ PE para tentar reproduzir esse procedimento lá e daí corrigir o erro de codigo.

Abs,

Henrique.

Obrigado pela resposta Henrique.

Eu havia lido seu comentário anterior mas como não possuo muito conhecimento no assunto SSL, fiquei meio sem entender.

Vamos entrar em contato com a SEFAZ e tentar solucionar o problema junto a eles.

Abs.

Ricardo,

nao sei se vc ou mais alguem entrou em contato com a SEFAZ PE, mas hoje notei em nosso ambiente interno que algumas tentativas da verificacao de status foram bem sucedidas (intermitentemente). Em algumas das que falharam, notei também algumas mensagens de erro um pouco diferentes (e.g. "com.sap.aii.af.ra.ms.api.DeliveryException: Padding error: -62 != padding value 13"; antes era sempre algo do tipo "padding length error: X > Y").

Talvez a SEFAZ PE tenha começado a mexer no problema para corrigi-lo.

Só tomara que nao tenham parado ainda de mexer (rs), pois do jeito que está ele está falhando pra aproximadamente metade dos casos (entao ou estao mexendo ainda, ou o algoritmo que implementaram agora ainda nao está 100%).

Vamos continuar no aguardo.

Abs,

Henrique.

Desde semana passada já estava funcionando ao menos o servico de verificacao de status do servidor

Como expliquei, para SPs anteriores, sim, o que nao quer dizer que funciona pra todos.

Abs,

Henrique.

Olá pessoal,

Entramos em contato hoje com uma pessoa de TI da SEFAZ-PE.

Ele informou que houve uma alteração no ambiente de homologação e que o TLS 1.1 não está sendo aceito e que, até o momento, fomos os primeiros a reportar tal erro.

Inclusive chegamos a discutir que outros grandes contribuintes que também utilizam a solução SAP não reportaram o problema, o que pode acontecer devido a versões anteriores de SPs. (aqui utilizamos o PI 7.0 SP20 e SLL-NFE SP12).

O rapaz pediu um prazo até o dia 15/08 para que ele possa analisar e junto com a equipe deles conseguirem solucionar o problema e, vale dizer que o atendimento foi muito bem feito (acho que conseguimos falar com a pessoa correta, hehe).

Então, como ainda não estamos em fase de paralelo, podemos aguardar para ver se eles conseguem solucionar e, no nosso caso, se até dia 15/08 não tivermos um posicionamento, provavelmente iremos abrir um chamado para conseguir o .jar da versão anterior como solução paleativa.

Fica a dica para os que estão com o problema.

Abs.

Olá Ricardo,

O rapaz da SEFAZ PE está enganado, já fazem quase 2 meses que mantemos contato semanal com eles. Ontem a tarde conseguimos aprovar a 1a. nota para a SEFAZ PE !

Em resumo: o .JAR enviado pela SAP não foi um paletivo. Sem ele, não conseguimos estabelecer comunicação com a SEFAZ PE. Com o mesmo instalado, o serviço de homologação funciona normalmente e é possível a emissão de NF-e. Portanto, vc tem que conseguir esse arquivo. Para os serviços de Produção da SEFAZ PE não é necessária nenhuma mudança, continua funcionando normalmente.

Abraço,

Roger Vier

Olá Roger,

Bom saber sobre isso.

Para não sermos pegos de surpresa, vou abrir um chamado na SAP e já solicitar o arquivo, assim se eles não tiverem um posicionamento, já ficaremos preparados.

Com esse "downgrade" do .jar há impactos para as comunicações com as outras SEFAZes nos dois ambientes?

Abs

Nenhum impacto, Rodrigo. Estamos utilizando o .JAR nos ambientes de Homologação e Produção com SEFAZ RS, SP e PE e todos estão funcionando normalmente.

Abraço,

Roger Vier

Roger e Ricardo,

o entendimento de vocês está errado.

Ricardo -> ninguem falou em suportar o TLS 1.1. O problema ocorre que o servidor deles diz para o client que quer usar o SSL 3.0 (até aí nao tem problema), mas posteriormente esquece que solicitou o 3.0 e acaba internamente "achando" que está usando o TLS 1.1.

Roger -> trocar o .jar é paliativo sim, pois isso é um procedimento que vc vai ter que repetir a cada aplicacao de patch ou SP, alem de limitar o seu PI para nao suportar o TLS 1.1 ou 1.2 em outros cenarios que sua empresa venha a ter.

Abs,

Henrique.

Olá Henrique,

Discordo de vc pq fiz o teste:

. JAR original - não funciona a comunicação com a SEFAZ PE Homologação;

. JAR enviando pela SAP - funciona a comunicação com a SEFAZ PE Homologação

Portanto, no meu caso o .JAR NÃO foi paliativo. Estou utilizando o mesmo e conseguindo aprovar e enviar notas normalmente para SEFAZ PE.

Abraço,

Roger Vier

Roger,

vc analisou diagnostico e nao causa raiz.

A solucao adotada nao é permanente pois assim que vc subir SP do Netweaver, vai voltar, pois a causa raiz do problema na SEFAZ persiste. E se é solucao temporária, é paliativo por definição.

Se vc ler minhas msgs nessa thread vc vai entender o porquê de o .jar novo "evidenciar" o problema na SEFAZ.

Enfim, a decisao é sua.

Se pra vc, é melhor realizar esse procedimento sempre que houver uma necessidade de manutencao, em vez de investir mais na descoberta da causa raiz com a SEFAZ, é uma escolha sua.

Att,

Henrique.

Olá Henrique,

Com certeza. O .JAR não é a solução ideal. Todos sabemos que é um problema técnico na SEFAZ PE que reconfigurou o servidor de Homologação impedindo a comunicação do SAP GRC NF-e. A questão é que estou há 2 semanas do Go-live e não me restam outras alternativas. Com o .JAR enviado pela SAP consegui liberar os testes dos usuários e manter a data prevista para entrada em Produção (lembrando: não existem problemas no ambiente de Produção da SEFAZ PE). Diariamente faço os testes utilizando o .JAR original e o enviado pela SAP e até agora, apenas o último me permite sucesso na operação.

Vou manter esta thread em aberto, caso tenhamos novos desdobramentos.

Abraço,

Roger Vier

Olá Roger,

sem problemas, apenas ponha um * nesse ponto qdo terminar o projeto, para que o pessoal dê sequencia na avaliacao com a SEFAZ PE.

Abs,

Henrique.

Bom dia pessoal,

Quando entramos em contato com a SEFAZ-PE há +- 15 dias, eles disseram que iriam tentar resolver o problema.

Ontem nos responderam dizendo que ainda não foi possível.

Como faço para obter o arquivo .jar? Devo abrir um chamado, certo? Se sim, dentro de que área/componente abro este chamado?

Outras dúvidas:

1-Ao fazer o deploy desse .jar de versão anterior, como faço o bkp do que já está no servidor?

2-A cada deploy é necessário restart do ambiente (visto que queremos entrar em paralelo, esses restarts são difíceis por outros estados já estarem em produção).

3-Os outros estados todos continuam conseguindo fazer o STATUSCHECK?

Obrigado.

Olá Ricardo,

sim para todas as perguntas.

Quanto ao backup, pergunte no proprio chamado (a ser aberto no componente BC-XI-CON ou BC-JAS-SEC).

Abs,

Henrique.

Pessoal, boa tarde.

Estou com o mesmo problema com a SEFAZ de PE no ambiente de homologação...

Alguém tem alguma novidade sobre este assunto? Estou tentando entrar em contato com eles para obter maiores informações.

Obrigado,

Marcos

Cara cria uma nova thread e explica o seu problema, o meu eu resolvi

Olá Marcos,

Para homologação SEFAZ PE é necessário o deploy do arquivo IAIK_SSL.jar no ambiente GRC. Após o deploy , a comunicação com a SEFAZ volta a funcionar normalmente. Para o ambiente Produtivo SEFAZ PE não é necessário nenhuma alteração. Este arquivo é fornecido pela SAP na abertura do chamado.

Abraços,

Roger Vier

Olá pessoal,

Só para atualizar vocês quanto ao meu caso:

Como no cliente onde estamos implantando NFe ainda utiliza o XML 1.1 e está na iminência de trocar para o 2.0, a solução paleativa de fazer o deploy do .jar seria muito trabalhosa, uma vez que teriamos que fazer no ambiente PI-DEV, testar e passar para Produção. E logo em seguida, viria a subida de SP no ambiente que no link de WebService v2.0 não sabemos como se comportaria.

Então, hoje fizemos uma conference call com o pessoal de TI da SEFAZ-PE.

Enviamos uns logs de requisição no momento que estabelece a conexão com o ambiente deles e o retorno de erro e eles iriam verificar no ambiente deles qual erro e qual solução poderia ser tomada por parte deles.

Assim que tiver um retorno, posto aqui para que vocês saibam se foi resolvido ou não.

Abs

Muito bom Ricardo.

Acho que o dialogo é sim a melhor maneira de interagir.

O SP15 do SLL-NFE necessita um update do SP do Netweaver para o SP14, mas se vc já tiver nesse ou superior, entao nao teria impacto. Dessa vez.

Abs,

Henrique.

Pessoal,

Obrigado pela resposta.

Como ainda temos um "tempo" no projeto, irei esperar o retorno que o Ricardo possa conseguir da SEFAZ de Pernambuco.

Caso a resolução do problema demore muito, terei que abrir um chamado e fazer o deploy deste .JAR

Ricardo,

Por favor, mantenha-nos informado sobre a sua conversa com a SEFAZ, tentei entrar em contato sem sucesso.

Obrigado a todos,

Marcos

Bom dia pessoal,

Respondendo a você Henrique, com certeza, o diálogo é a melhor forma e, no nosso caso, o pessoal de TI da SEFAZ-PE foi muito colaborador em resolver o problema.

E atualizando a todos, após todos os contatos com a SEFAZ, conseguimos estabelecer comunicação com o ambiente de Homologação deles sem termos que alterar o arquivo .jar. Provavelmente eles fizeram alterações no ambiente deles, depois de muitos testes e envio de logs de erros para eles.

Espero que os que ainda estejam com problema consigam resolver rapidamente.

O último posicionamento é que eles iriam fazer o mesmo para o ambiente de Produção.

Um abraç

Olá pessoal,

Ricado, obrigado pelo feedback. Observei que desde ontem conseguimos obter sucesso na consulta de status de serviço junto ao SEFAZ / PE.

Ainda bem que você teve mais sorte do que nós, tentamos dois contatos por email sem sucesso com eles.

Abraço,

Marcos

Ricardo,

muito boas noticias!

Esse é de fato o procedimento correto, garantindo que as causas raizes dos problemas sejam analisadas e corrigidas.

Agora esperemos que repliquem a correcao pro Producao!

Abs,

Henrique.

Sim, com certeza, boas notícias!

Eles até já perguntaram sobre o ambiente de produção, se tinhamos uma data limite para entrada em produção, mas como o cliente onde presto serviços atualmente está com problemas de cadastramento fiscal junto a eles, não temos previsão para entrada em produção.

Inclusive, deixei alinhado com o pessoal de lá para que, o quanto antes a parte de TI estiver resolvida, melhor para nós, assim não ficamos como fator impeditivo.

Agora resta-nos resolver outro problema, mas com a SEFAZ-MT, que está um pouco mais complicado.

Abs.

Ricardo, tudo bem?

Vocês voltaram a ter problemas com Pernambuco?

Desde segunda-feira que aqui voltou a aparecer o erro do "Padding length error".

Pelo amor de Deus, como essa SEFAZ de Pernambuco da trabalho..

Obrigado,

Marcos

Roger,

recomendo abrir chamado no componente BC-XI-CON-AFW.

De qq maneira, o que o audit log do Communication Channel (no communication channel monitoring) fala?

Alternativamente, verifique o audit log da mensagem indo pelo Message Monitoring (componente Adapter Engine).

Abs,

Henrique.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

vc poderia colocar o payload da mensagem que vc esta enviando ?

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Olá Carlos,

Segue abaixo:

Obrigado,

Roger Vier

o opcao, "do not use soap envelop" no seu Comunication Channel esta selecionada?

Olá Carlos,

A opção não estava selecionada. Para fazer um teste, selecionei a opção e mesmo assim o erro continua. Já fazem alguns meses que essa configuração estava concluída e funcionou inicialmente. Porém, nas últimas semanas não funciona. Nos web services com as URL´s de Produção, o funcionamento está normal. Continuo ainda acreditando que o problema seja na SEFAZ PE (Homologação).

Obrigado,

Roger Vier

ela não é para estar selecionada mesmo, coloque aqui os dados que aparecem na primeira janela de mensagem do sxi_monitor por favor, assim terei uma visao mais clara do que esta acontecendo no seu processo.

Olá Carlos,

Segue abaixo:

----

O acesso direto na URL pelo Internet Exlorer é realizado colocando o certificado digital. Porém, o resultado é uma página em formato texto bem diferene da páginas de outros estados - SEFAZ. Pode ser neste ponto que o webservice não está conseguindo interpretar.

Obrigado,

Roger Vier

nao seria isso se nao estaria dando erro de mapping, essa mensagem é syncrona, todos ela esta pegando a resposta do sefaz?

Estava analisando os dados que vc me envio, vc ativou a opcao de SSL???

Edited by: Carlos Rodrigo Pereira on Jun 17, 2010 3:23 PM

Não ativei SSL. Isto pode estar interferindo ?

nao é para ativar tbem. estou analisando as possibilidades

criei o mesmo cenario seu aqui, estou tentando validar o servico com o SEFAZ de Pernambuco e estou tendo o mesmo problema

Realmente o SEFAZ de 26 ( Pernambuco ) Não esta respondendo a msg no mesmo formato esperado pelo CC SAP, tente entrar em contato com eles para saber o que esta ocorrendo, pois eles estão com o formato fora do padrão, eu aconselharia vc tbem abrir um chamado na SAP em contrapartida, Henrique, se puder dar uma mao nisso aqui verificando o porque o SEFAZ 26 esta respondendo de maneira errada ( DIFERENTE ) da que é esperada pelo SAP já nos ajudaria muito pois mes que vem estarei trabalhando na implementacao de um cenario em Pernambuco tbem.

Legal, Carlos ! Perfeito ! Estamos há 2 semanas em contato com o pessoal técnico da SEFAZ PE e os mesmos argumentam que o problema não existe. Agora com a sua validação, tenho mais argumentos para reforçar a nossa posição.

Muito obrigado pela ajuda.

Abraço,

Roger Vier

Mas me mantenha informado nesse topico por favor, provavelmente ainda esse mes eu tenha que configurar uma interface com o sefaz de PE e esse assunto me interessa.

HENRIQUE PINTO: Se puder dar uma verificada nisso com carinho agradecemos pois realmente o SEFAZ 26 de pernambuco esta enviando os dados de maneira diferente ao esperado

Com certeza, Carlos. Estou com essa pendência já fazem 2 meses. A comunicação com a SEFAZ PE em Homologação chegou a funcionar, agora não mais. Com o ambiente de Produção da SEFAZ PE, todos os webservices estão funcionando normalmente.

Ask a Question

Top Q&A Solution Author

User

Count