BigWings

Com CAPICOM, tenho retorno se desmarcar a opção "Usar TLS 1.2" nas configurações avançadas do IE, deixando marcadas apenas "Usar SSL 3.0" e "Usar TLS 1.0" Com WinCrypt e OpenSSL, defino a SSLType como LT_all.

Com SSLLib = libCapicomDelphiSoap há retorno de exceção pelo webservice: <?xml version="1.0" encoding="utf-8" ?> - <soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"> - <soapenv:Body> - <soapenv:Fault> - <soapenv:Code> <soapenv:Value>soapenv:Receiver</soapenv:Value> </soapenv:Code> - <soapenv:Reason> <soapenv:Text xml:lang="en-US">unknown</soapenv:Text> </soapenv:Reason> - <soapenv:Detail> <Exception>org.apache.axis2.AxisFault at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430) at br.inf.portalfiscal.www.nfe.wsdl.core.MessageReceiverInOut.invokeBusinessLogic(MessageReceiverInOut.java:156) at org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.java:40) at org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:114) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:173) at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:167) at org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:142) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:286) at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:260) at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:137) at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:350) at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:247) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3679) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3649) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:326) at weblogic.security.service.SecurityManager.runAsForUserCode(SecurityManager.java:197) at weblogic.servlet.provider.WlsSecurityProvider.runAsForUserCode(WlsSecurityProvider.java:203) at weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:71) at weblogic.servlet.internal.WebAppServletContext.doSecuredExecute(WebAppServletContext.java:2433) at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2281) at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2259) at weblogic.servlet.internal.ServletRequestImpl.runInternal(ServletRequestImpl.java:1686) at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1646) at weblogic.servlet.provider.ContainerSupportProviderImpl$WlsRequestExecutor.run(ContainerSupportProviderImpl.java:270) at weblogic.invocation.ComponentInvocationContextManager._runAs(ComponentInvocationContextManager.java:348) at weblogic.invocation.ComponentInvocationContextManager.runAs(ComponentInvocationContextManager.java:333) at weblogic.work.LivePartitionUtility.doRunWorkUnderContext(LivePartitionUtility.java:54) at weblogic.work.PartitionUtility.runWorkUnderContext(PartitionUtility.java:41) at weblogic.work.SelfTuningWorkManagerImpl.runWorkUnderContext(SelfTuningWorkManagerImpl.java:640) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:406) at weblogic.work.ExecuteThread.run(ExecuteThread.java:346) Caused by: java.lang.NullPointerException</Exception> </soapenv:Detail> </soapenv:Fault> </soapenv:Body> </soapenv:Envelope>

É o que parece, meu teste foi usando o SVRS e de lá o retorno do protocolo está normal, na versão correta.

Desculpe, não percebi que tinham mudado as URL. Com essas URL, está funcionando, pelo menos o status de serviço: <?xml version="1.0" encoding="utf-8" ?> - <soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> - <soapenv:Body> - <nfeResultMsg xmlns="http://www.portalfiscal.inf.br/nfe/wsdl/NFeStatusServico4"> - <retConsStatServ versao="4.00" xmlns="http://www.portalfiscal.inf.br/nfe"> <tpAmb>2</tpAmb> <verAplic>NFEPE_H_16.00.16.129</verAplic> <cStat>107</cStat> <xMotivo>Serviço em Operação</xMotivo> <cUF>26</cUF> <dhRecbto>2017-08-29T15:26:52-03:00</dhRecbto> </retConsStatServ> </nfeResultMsg> </soapenv:Body> </soapenv:Envelope>

Realmente. Fiz um teste com uma nota que emiti em homologação e tive o mesmo erro.

Algum problema lá. O erro "There is no SOAP service at this location" continua.

O certificado está instalado no Windows da máquina?

Olá. O banco fornece o layout personalizado no momento do início da homologação. Basta solicitar ao gerente.

https://hom.nfe.fazenda.gov.br Tente baixar o XML por aí e verifique o protocolo.

Esse é o XML baixado do portal ou o gerado pelo ACBr?

Pelo que vi ele estava usando WinCrypt e informando o número de série do certificado na configuração, além do caminho e senha do pfx. Nesse caso o número de série toma preferência, e o ACBr tenta carregar o certificado instalado no Windows. Se a instalação tiver sido feita sem marcar a opção de permitir a exportação da chave privada, vai acontecer esse erro. Para A1 é recomendado o uso do OpenSSL, informando apenas path e senha do arquivo .pfx.

A sintaxe correta é: [NFRef001] refNFe=35141162439211000182550010001096061001096060

Movido para o fórum correto. Informe qual componente DANFE está usando e qual arquivo .fr3, caso seja o ACBrNFeDANFeFR.

3.10 ou 4, dependendo da versão do XML.

Apenas para deixar claro, não afirmei que você queria deixar de imprimir a informação, mas que queria impedir o ACBr de imprimir. Com a sua alteração, ao marcar o TributosSeparadamente, e não informá-los no componente, nada será impresso, mesmo que haja a tag vTotTrib no XML.

Faça uma consulta formal às SEFAZ dos estados, questionando o motivo dessa exigência, sendo que no Manual de Especificações Técnicas do DANFE NFC-e e QR Code - Versao 4.2 não há obrigatoriedade de se informar a IE no cabeçaho da NFC-e.

Outra coisa do log: Usando a versão trial você não consegue instalar pelo ACBrInstall_Trunk2. Terá que instalar os pacotes manualmente.

Foram feitos alguns ajustes no componente para poder atender as UF que estão com os serviços fora do padrão, a princípio para SP mas que poderia servir para o PE já que estão da mesma forma. Bastaria acrescentar ao ACBrNFeServicos.ini: [NFe_PE_H] ... NfeInutilizacao_4.00=https://nfehomolog.sefaz.pe.gov.br/nfe-service/services/NfeInutilizacao4?wsdl NfeConsultaProtocolo_4.00=https://nfehomolog.sefaz.pe.gov.br/nfe-service/services/NfeConsulta4?wsdl NfeStatusServico_4.00=https://nfehomolog.sefaz.pe.gov.br/nfe-service/services/NfeStatusServico4?wsdl NfeConsultaCadastro_4.00=https://nfehomolog.sefaz.pe.gov.br/nfe-service/services/CadConsultaCadastro4?wsdl RecepcaoEvento_4.00=https://nfehomolog.sefaz.pe.gov.br/nfe-service/services/RecepcaoEvento4?wsdl NFeAutorizacao_4.00=https://nfehomolog.sefaz.pe.gov.br/nfe-service/services/NfeAutorizacao4?wsdl NFeRetAutorizacao_4.00=https://nfehomolog.sefaz.pe.gov.br/nfe-service/services/NfeRetAutorizacao4?wsdl WSDL=WSDL_V4_SP SoapAction=SOAP_V4_SP Mas parece que os webservices do PE não estão funcionando no momento: https://nfehomolog.sefaz.pe.gov.br/nfe-service/services/NfeInutilizacao4?wsdl

Se tiver o código cStat da rejeição ficaria mais fácil descobrir o motivo. Que me lembro somente a consulta de NFe por chave de acesso tem essa restrição. O ACBr, por exemplo, tenta fazer a consulta no envio de evento de Cancelamento. Por isso a minha pergunta. Caso você tivesse passado o tipo de evento errado (Cancelamento) poderia retornar essa rejeição. Bem, verifique no seu código se por acaso não está sendo chamado o WebService de consulta de NFe por chave de acesso, pode ser esse o problema.

Você está usando o componente ou o ACBrMonitorPLUS?

Pelo que entendi, você quer uma forma de o componente ignorar a informação vTotTrib do XML, não imprimindo uma informação obrigatória por Lei. Não creio que será aceito. A propriedade TributosSeparadamente é redundante, basta não popular a vTribFed, vTribEst e vTribMun. Se não quer que seja impresso a vTotTrib, basta não informá-la na NFCe.

Sim.

Tente acrescentar a unit MidasLib ao uses do dpr.

Está configurando o CSC e IdCSC no componente antes de chamar o método Enviar?

Testou o certificado pra ter certeza que a chave privada continua lá?