TiagoTecchio

Essa informação está dentro do XML retornado? Se está poderia ser acessada por alguma prop do objeto ACBR, senão está deve ser informação específica da API da Sefaz.

Parece erro de autenticação, dados de login inválidos. Tentou atualizar as DLLs libeay e ssleay para a versão que suporta TLS (versão 1.0.2) ?

O bom e velho try-except não funciona para pegar a exceção?

Bom dia, Assim como surgiu, desapareceu o problema. Parece aquelas situações onde a coisa se resolve por osmose. O que fiz para não travar o cliente foi liberar o objeto acbrNFE caso a mensagem de erro contenha esse código "183" e na próxima requisição o objeto é novamente instanciado. Obviamente dependerá da forma como você utiliza as classes acbr, no meu caso o XML é gerado na estação e recarregado no servidor (onde é feita a assinatura, envio, etc).

Bom dia Também tenho enfrentado esta situação na última semana. É aleatório, num determinado momento todas as conexões retornam esta mensagem. O interessante é que seu eu libero o objeto ACBr da memória e forço nova alocação funciona, como na imagem anexa (Foi enviada a requisição as 11:23:17, ocorreu o erro, o programa liberou o objeto, o usuário enviou novamente às 11:23:43, forçando o programa a um novo instanciamento do acbrNfe e tudo certo) A aplicação está rodando num Windows Server 2012 Datacenter, aparentemente atualizada.

Olá Italo, Sim, é como você descreveu. Minha sistemática é um pouco diferente, o XML é gerado num lado e posteriormente carregado e autorizado em outro (num servidor). Mudar isso não está no radar até porque funciona bem desta forma a anos (NFE, Manifestos, etc). Relatei a situação porque creio que o componente deva manter em suas propriedades o valor das tags XML ipsis literis. Enfim, indo para o repositório ou não vou manter o ajuste que realizei. Obrigado e bom trabalho.

Bom dia a todos, Também estou testando este novo provedor e detectei uma situação em relação ao campo ItemListaServico O componente ao realizar a carga do XML formata o campo como NN.NN embora na geração eu tenha informado N.NN. Esta transformação causa rejeição do provedor após o envio assíncrono. Isso ocorre porque existem alguns tipos de serviço como informática que na relação deles consta como: "1.07 Suporte técnico em informática, inclusive instalação, configuração e manutenção de programas de computação e bancos de dados." Para funcionar ajustei a função TNFSeR.SetxItemListaServico. Porém não sei como funcionaria este provedor para as demais prefeituras, no meu caso é somente para Farroupilha. pnfsNFSeR.pas

A quem possa interessar, é bom verificar se os arquivos de schemas não estão danificados. No meu caso um arquivo de validação (e210220_v1.00.xsd) estava nulo e ocasionava o erro citado no momento de realizar o "desconhecimento de operação". Substitui por um arquivo íntegro e funcionou normalmente.

As tags do ICMS efetivo destinam-se a informar os valores do ICMS que seria cobrado caso a operação fosse tributada - neste caso a operação é por Substituição Tributária. As últimas notas técnicas explicam o objetivo destes tags, bem como um "google" também lhe fornecerá diversos links detalhando o procedimento.

Boa tarde, Encontrei um "typo" numa mensagem do ACBrValidador, dentro da procedure TACBrValidador.ValidarIE Errado: (está escrito "verique" ao invés de "verifique") fsMsgErro := Format('Tamanho Inválido, esperado %d caracteres, foram digitados somente %d caracteres, verique', [Tamanho, Length(fsDocto)]) ; Correto: fsMsgErro := Format('Tamanho Inválido, esperado %d caracteres, foram digitados somente %d caracteres, verifique', [Tamanho, Length(fsDocto)]) ; ACBrValidador.pas

Tentou reinstalar o certificado? Qual o tipo de configuração do acbr que vc está usando: Wincrypt, Capicom, etc?

Creio que esta regra de "SEM GTIN" ainda não esteja ativa, pelo que vi na nota técnica entrará em produção mais adiante. De qualquer forma só consegui validar (no meu caso no RS) no ambiente de homologação. Produção não passa ainda. Tentou atualizar os schemas?

Bom dia, Não está claro o teu problema. Algum erro acontece?

Bom dia! Acredito que seja algum problema relacionado ao SOAPAction do webservice ou a forma como é feita a comunicação com o mesmo. Atualizei o arquivo ACBrNFeServicos.ini para incluir o endereço correto do webservice de consulta da versão 4: NfeConsultaCadastro_4.00=https://cad.sefazrs.rs.gov.br/ws/cadconsultacadastro/cadconsultacadastro4.asmx Debugando o método TDFeHttpWinHttp.Enviar em ACBrDFeHttpWinApi.pas o resultado é sempre HTTPResultCode=500 e a mensagem de retorno que recebe-se do WS em Result := String( ReadStrFromStream(Resp, Resp.Size) ); é a seguinte: <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap = "http://www.w3.org/2003/05/soap-envelope" xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd = "http://www.w3.org/2001/XMLSchema"> <soap:Body> <soap:Fault> <soap:Code> <soap:Value>soap:Sender</soap:Value> </soap:Code> <soap:Reason> <soap:Text xml:lang = "en">System.Web.Services.Protocols.SoapException: Unable to handle request without a valid action parameter. Please supply a valid soap action.'#$D#$A' at System.Web.Services.Protocols.Soap12ServerProtocolHelper.RouteRequest()'#$D#$A' at System.Web.Services.Protocols.SoapServerProtocol.Initialize()'#$D#$A' at System.Web.Services.Protocols.ServerProtocol.SetContext(Type type, HttpContext context, HttpRequest request, HttpResponse response)'#$D#$A' at System.Web.Services.Protocols.ServerProtocolFactory.Create(Type type, HttpContext context, HttpRequest request, HttpResponse response, Boolean&amp; abortProcessing)</soap:Text> </soap:Reason> <soap:Detail/> </soap:Fault> </soap:Body> </soap:Envelope>

Também resolvi instalando o ACBR_Integrador.dpk. Mas porque ele é requerido pelo ACBR_DFeComum.dpk? Porque preciso embutir as rotinas desse pacote no meu executável?

Bom dia, Não ocorreu para mim este tipo de situação com o webservice de Distribuição. Tive tratar tais caracteres em retornos de webservices feitos em Java ou PHP. Mas a solução é bem óbvia e "low-tech": bastaria fazer um StringReplace nos caractéres estranhos.

Boa tarde, Fiz alguns ajustes nas units de escrita (pnfsNFSeW_Infisc.pas) e leitura (pnfsNFSeR.pas) de XMLs para o provedor Infisc. No caso da unit pnfsNFSeW_Infisc programei o nodo de Condições de Pagamentos para a versão v10. Para a unit pnfsNFSeR tive que adicionar a leitura de alguns tags que foram esquecidos (versão v11), o que causava problemas: o XML assinado ficava diferente do gerado. Por exemplo, eram omitidos os tags <regimeTrib>, <mod> e <ambienteEmi>. Ajustei também a unit de cancelamento pnfsCancNfseResposta.pas para alimentar a propriedade "acbrNFSe.WebServices.CancNFSe.RetCancNFSe.InfCanc.Protocolo" com o protocolo de cancelamento. pnfsNFSeR.pas pnfsNFSeW_Infisc.pas pnfsCancNfseResposta.pas

Eu pessoalmente sempre chamo ".clear", não vejo motivo para "correção" pois ao meu ver não está errado.

FelipeIW, Constumo fazer assim: objNFE.Configuracoes.WebServices.AguardarConsultaRet := 5000; objNFE.Configuracoes.WebServices.Tentativas := 30;

Também já sofri com esse problema. Infelizmente não encontrei uma solução definitiva, simplesmente aumentei o tempo de resposta e espera do componente e o erros foram minimizados quase a zero. Eventualmente acontece a situação que você descreveu, então a maneira correta é consultar a chave no site da Sefaz, baixar o XML e anexar no BD.

Olá Italo. Obrigado pelo retorno. Uso sem problemas tanto certificados A1 quanto A3 com o ACBR e nunca tive problemas. A questão é este certificado ACS Cryptomate - há algo de diferente nele ou alguma incompatibilidade com o CAPICOM. A empresa que comercializa este tipo de token aqui no RS, a Invia, usa como base e sempre testa com o programa de emissão de NFe da Sefaz (que acredito que seja feito em Java). Com este programa assina e envia sem problemas... Meu conhecimento de Java é limitado, mas penso que a assinatura digital seja feita de outra forma daquela feita pelo ACBR (estou especulando).

Diogo, De fato, ocorre a mesma situação para mim. No primeiro envio é solicitado o PIN, e autoriza normal. A partir daí, não vai de jeito nenhum. Geralmente retorna "297-Rejeicao: Assinatura difere do calculado" mas eventualmente surge "Parâmetro incorreto". Já limpei o XML, removi espaços em branco, removi apóstrofo, &, etc, e nada. Parece que algo se perde entre uma assinatura e outra. Percebi que o erro de parâmetro incorreto é levantado nessa linha: signedKey := xmldsig.sign(dsigKey, $00000002); Mas como disse, é eventual. Como esse token (ACS Cryptomate) é de uso recente e há pouca gente usando, talvez no futuro alguém descubra onde está o problema... Até lá vou instruir o cliente para a única solução possível: abandonar essa degraça e comprar um certificado A1, que é garantido. Att.

Vale a pena ressaltar a configuração da conta de e-mail. No meu caso, uso o GMail, e para funcionar precisei liberar a opção "Acesso para aplicativos menos seguros" nas configurações de segurança da conta. Sem isso, não envia de jeito nenhum.

Utilizando a dica do colega Mark Apollo, a instalação do pacote funcionou. Removi a linha {$R *.res} do arquivo ACBrComum.dpk consegui dar um "build" sem problemas. Obrigado.