nickolasdeluca

@Daniel Simoes obrigado por me passar as DLLs e desculpa a demora para responder, ontem era feriado aqui na cidade. Copiei todas as DLLs de 64 bits que você mencionou e coloquei na pasta junto com o aplicativo, mesmo assim o problema continua. Se trocar para 32 bits, funciona perfeito. Se manter 64 bits mas remover as units do ACBr, funciona perfeito. Sinceramente não sei mais o que fazer. Já tentei reinstalar o ACBr, para ter certeza, tanto o ACBr como o FortesReport, tudo instala perfeito, só que na hora de iniciar a aplicação, da o erro.

Você sabe me dizer como eu poderia rastrear exatamente qual DLL está causando o problema? pois separei em outro diretório as DLLs e o executável e continua o problema. O mais estranho é que ao trocar pra 32 bits, não precisa nem de DLL na pasta pra rodar. Acredito que ele esteja usando as da pasta do sistema, então preciso de uma forma de investigar EXATAMENTE qual DLL ele está tentando usar.

Mas isso já causaria problemas ao simplesmente executar a aplicação? eu até entendo se desse erro ao usar o componente, mas durante a inicialização também?

Pessoal, estou com uma situação que eu não sei nem como começar a identificar o problema. Em buscas aqui no fórum, verifiquei que outro usuário já teve um problema bem semelhante, se não o mesmo, em 2018. Problema ao compilar para 64 bits utilizando ACBRNFe Eu nem estou fazendo nada ainda com o componente, simplesmente adicionar as Libs ACBrBase, ACBrDFe, ACBrNFe na unit e executar causa o seguinte erro: Se simplesmente mudar a compilação para 32 bits, funciona perfeito. Tanto o ACBr quando o FortesReport foram instalados com as versões de 32 e 64 bits. Alguém tem alguma ideia do que pode ser? pois literalmente da erro ANTES de executar a primeira linha do projeto.

Sei que o post é de 2018, mas, tu conseguiu resolver? kkk Estou com o mesmo problema agora, 32 bits funciona perfeito, 64 bits não vai.

Olá novamente, Favor desconsiderar esse tópico, descobri quem fez o problema. Se os mods puderem fechar o tópico, eu agradeço.

Boa tarde, Estamos tentando enviar um CTe, tanto em homologação quanto em produção, no estado de RO e estamos recebendo o seguinte retorno: Element '{http://www.portalfiscal.inf.br/cte}infCTeSupl' is unexpected according to content model of parent element '{http://www.portalfiscal.inf.br/cte}CTe'. Expecting: {http://www.w3.org/2000/09/xmldsig#}Signature. Esse retorno ocorre APENAS ao enviar um CTE para a SEFAZ deste estado específico, em todos os outros autoriza normal. Verifiquei que essa é a tag do qrCode e que faz um tempinho já que foi removida a possibilidade do envio dela ser opcional. Alguém mais tendo esse problema? Anexei o XML do CTE de testes que estamos tentando enviar. 11230946542418000121570000000000011001528128-cte.xml

Servidor do RS aceitando apenas sem hífen. Que piada!

Cara, como você fez para trocar para essa forma SVC-SP? Alterando a UF do webservice para SP? Pergunto isso por que tentei fazer dessa forma e continuo recebendo o retorno em branco.

Tentei enviar pelo estado de MG e de SC hoje, ambos retornando resposta em branco. Alguém conseguindo enviar em algum estado?

Por acaso temos acesso a essa lista para acompanhamento?

Bom dia, alguma novidade sobre isso? Toda vez que atualizamos o nosso repositório interno somos obrigados a aplicar essa correção em cima dos fontes do ACBr. Seria bem interessante se essa solução fosse incorporada ao repositório oficial.

Juliomar, consegue me dar mais detalhes de como fazer essa instalação correta do driver do leitor? No meu caso, estas são as configurações que fiz durante a instalação: E quando tu fala que da pra salvar a senha no componente, podes me dizer qual a propriedade para informar o PIN do token A3? Leandro, infelizmente o cliente é mais teimoso que uma mula...

Infelizmente não, o cliente precisava do certificado então tivemos que devolver, não tenho mais como testar com o certificado... Existe alguma possibilidade de abrirmos a tela do PIN manualmente? no caso, forçar utilizar o PIN antes de iniciar qualquer ação, por exemplo, ao carregar o certificado no componente antes de realizar algum evento?

Boa tarde, alguém com problemas para enviar eventos da NFe através do componente ACBrNFE utilizando certificado A3? estamos enfrentando um caso bizarro aqui onde se não ativar o TimeOutPorThread do ACBrDFeSSL o componente fica travado por horas esperando uma resposta. O erro ocorre na unit ACBrDFeSSL no trecho de código a partir da linha 1405: if TimeOutPorThread then begin EndTime := IncSecond(now,TruncFix(TimeOut/1000)); SendThread := TDFeSendThread.Create( Self, TDFeSSLHttpClassOf(FSSLHttpClass.ClassType), ConteudoXML, AURL, ASoapAction, AMimeType); try while (not SendThread.Done) and (Now <= EndTime) do Sleep(50); finally Result := SendThread.Response; ErrorMsg := SendThread.ExceptMessage; if not SendThread.Done then SendThread.Abort // Isso forçará a Thread terminar, e morrer por si... else SendThread.Free; end; if not EstaVazio(ErrorMsg) then raise EACBrDFeException.Create('Erro na thread de envio: ' + ErrorMsg); if EstaVazio(Result) then raise EACBrDFeException.Create('Timeout - Não foi possível obter a resposta do servidor'); end else begin FHttpSendCriticalSection.Acquire; try Result := FSSLHttpClass.Enviar(ConteudoXML, AURL, ASoapAction, AMimeType, AAuthorizationHeader); finally FHttpSendCriticalSection.Release; end; end; No caso, se ativarmos o TimeOutPorThread através da seguinte configuração: ACBrNFe.Configuracoes.WebServices.TimeOutPorThread := True; o componente, após 5 segundos, retorna um erro de timeout e finalmente pede o PIN do token, após informarmos o PIN, todas as requisições são enviadas normalmente pelo componente. Se não ativarmos tal configuração, o componente fica travado e nunca pede o PIN, porém, só com o PIN ele vai conseguir fazer as requisições... Alguém tem alguma ideia do que pode ser? Isso não acontece em todas as máquinas, na minha por exemplo, funciona normalmente, porém, na máquina de outro colega acontece também. Anexo coloquei um relatório de erros que o componente retorna quando ativamos o TimeOut, caso seja necessário... erro.txt

Realmente Lucas, agora que tu falou, percebi que vi errado... estranho que a SEFAZ ta obrigando a inserção destes campos...

Sobre a latitude e longitude, pelo que eu entendi na nota técnica, os 2 são obrigatórios... especificado como [1,1] Sobre o produto predominante, a gente ta obrigando o usuário a especificar o produto predominante sempre... pelo que eu entendi da nota técnica, ele é obrigatório... especificado como [1,1] O grupo de informações de pagamento não é obrigatório somente se o pagamento for à vista, se for a prazo tu tem que informar... especificado como [0,n], ai tem uma observação dizendo: Informar somente se indPag for à Prazo.

@Italo Jurisato Junior desculpa te incomodar, mas por um acaso a ACBr tem algum webservice que retorne o CEP com a latitude e a longitude? baita sacanagem da SEFAZ fazer a gente fornecer esses dados... Nas APIs que a gente usa, nenhuma delas fornece a latitude e longitude...

Pois é, também foi isso que eu entendi após ler mais sobre no link enviado pelo @BigWings. Já estamos desenvolvendo as modificações nessa NT. Também aproveito para agradecer aos demais que comentaram suas duvidas, sem duvidas serão uteis para responder as nossas dúvidas também.

Ok, vamos utilizar a mesma validação do CTe para o desenvolvimento então, obrigado @BigWings!

Boa tarde pessoal, Estamos implementando as modificações referentes a NT2020_001 v1.03 e me surgiu uma duvida. Sobre o grupo InfLotacao, a nota técnica diz que é para somente informar esse grupo de tags quando o MDFe for de carga lotação, porém, como definir se um MDFe é de carga lotação ou não? isso não ficou bem claro pra mim. Eu li em uma das validações e entendi que o grupo deverá ser gerado quando : 1 - O modal do MDFe for moRodoviario e o tpEmit for igual a teTransportadora. 2 - O tpEmit for igual a teTranspCTeGlobalizado e o MDFe possuir apenas um DFe transportado no grupo infDoc. O meu entendimento está correto? São essas duas regras que hoje classificam um MDFe como carga lotação? Agradeço pela atenção e aguardo ansiosamente pelo retorno.

Farei isto, obrigado!

As vezes, de forma completamente aleatória, ao consultar o status de envio de uma nota fiscal de serviço na prefeitura de Criciúma (A prefeitura usa o ambiente da Betha Sistemas) ocorre uma exceção na IDE (Delphi 10 Seattle): O estranho é que nem os arquivos de envio e retorno do ACBr chegam a ser salvos na pasta para que possamos verificar alguma inconsistência. E também esse erro é completamente aleatório, visto que a próxima nota enviada retorna o status corretamente. Alguém sabe o que pode ser?

Apenas pra finalizar o assunto, funcionou perfeitamente Italo. Muito obrigado!

Boa tarde Italo, desculpa a demora pra responder. Fiz os testes, Infelizmente ainda deu erro no envio. Este foi o retorno do componente: 500 - Inativo ou Inoperante tente novamente. Notei que alguns arquivos foram gerados pelo ACBr e decidi investiga-los. O primeiro arquivo gerado foi o 20190730152717-ANe.xml e este arquivo realmente foi gerado sem o grupo do qrCodMDFe. Notei que o ACBr gerou outro arquivo logo em seguida, 20190730152717-ped-ANe.xml e dentro deste arquivo ainda existe a tag qrCodMDFe. Fiz então a simulação pelo SoapUI com os 2 arquivos, com o primeiro (20190730152717-ANe.xml) o webservice nos retorna o código de declaração, tudo certinho. Já quando eu faço o envio do segundo arquivo (20190730152717-ped-ANe.xml) o webservice retorna esse erro: <faultstring xsi:type="xsd:string">error in msg parsing: XML error parsing SOAP payload on line 8: Mismatched tag</faultstring> Por que o ACBr gerou esse segundo arquivo? imagino que seja ele que o ACBr esteja enviando e por isso gera o erro... Inclui os 2 arquivos gerados pelo componente, obviamente, alterei os dados de acesso na ATM, fora isso está exatamente como foi enviado e feito os testes. Alguma ideia de como resolver essa situação?