Renato Rubinho

Boa noite, Está faltando o Fast Reports ou com erro. Se você possui o fast report, deve usar uma versão enterprise 5 ou superior. Se não possui, desmarque do instalador as opções relacionadas ao fast.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde, Veja este post que cita a solução atualizando sdk e configurando o delphi.

Boa tarde, Pode ser erro no logo. Exemplo, um logo bmp renomeado para jpg. Teste sem o logo, com outro logo, abra o logo com algum editor de imagem e salve-o novamente para testar.

Boa tarde, Veja a tabela que consta na NT destacando o que será gerado para cada ator. O emitente não recebe o XML do CTe. Uma opção é pegar os xmls do outro software e criar uma rotina de importação dos xmls para sua aplicação. Veja no programa de exemplo de NFe como foi feito no botão Distribuição por ultNSU, pois o processo é o mesmo para CTe.

Boa tarde, Veja que as dlls que tem na sua pasta não são iguais as atuais distribuídas pelo componente. Copie dlls atuais para a pasta do exe, inclusive as da libxml2 também, conforme os dois links a seguir. https://svn.code.sf.net/p/acbr/code/trunk2/DLLs/OpenSSL/1.1.1.10/X86/ https://svn.code.sf.net/p/acbr/code/trunk2/DLLs/LibXml2/x86/

Boa noite Alexandre, Você consegue ver as alterações direto na revisão. https://sourceforge.net/p/acbr/code/26739/ Caso tenha sugestões para correção deste problema, favor abrir um novo tópico e anexe os arquivos alterados. Vamos fechar este troço pois o problema original foi resolvido.

Boa noite, Utilize OpenSSL para o A1 e copie as dlls para a pasta do exe. ../trunk2/DLLs/OpenSSL/1.1.1.10/X86/

Boa noite Leandro, O erro inicial do tópico parecia ser de comunicação. Seu caso está retornando uma informação que indica um retorno do banco. Veja com o banco se conseguem explicar o motivo. Foi informado que pelo programa de exemplo está funcionando corretamente, tente emitir por ele também e compare o que está diferente entre eles para tentar localizar seu erro. Caso o problema persista abra um novo tópico com maiores detalhes, retorno do banco, etc.

Boa noite @João Paulo Alcântara Obrigado pela colaboração, pois conforme o post do @Italo Giurizzato Juniora url de homologação era o que faltava para poder incluir o DF no ini. Se quiser adiantar seus testes, altere o ini e siga os passos do tópico a seguir. Caso encontre problemas com o novo provedor, abra um novo tópico específico contendo maiores detalhes e os soaps do envio/retorno para que possamos ajudar.

Boa tarde Willian, Já está na fila de tarefas e quando for enviado ao SVN será postado no tópico.

Boa tarde Carlos, O curioso é funcionar no monitor. Erro de autenticação também pode ser problema com as dlls do OpenSSL. Salve as dlls atuais na pasta da sua aplicação https://svn.code.sf.net/p/acbr/code/trunk2/DLLs/OpenSSL/1.1.1.10/ e revise as configurações SSLLib := libOpenSSL SSLCryptLib := cryOpenSSL SSLHttpLib := httpOpenSSL SSLType := LT_TLSv1_2 https://acbr.sourceforge.io/ACBrLib/DFe.html

Boa tarde, Como seu caso é muito fora da curva, vamos ter que pensar fora da caixa para achar o problema. Revise sua rotina se ela para quando receber o código 137, se o código for antigo pode ter herdado uma prática de tentar mais vezes, devido a falhas que haviam no retorno da Sefaz. Confirme o timeout, caso não seja parametrizado no banco, pois pode estar derrubando uma chamada e a segunda gera a rejeição. Confirme se sua rotina permite "clique duplo" na chamada o que poderia ser o vilão da história. Os detalhes acima deveriam gerar mais de um XML, que também seria notável, a menos que você guarde-os no banco e os esteja sobrepondo. Outra coisa, veja se na pasta do exe do seu cliente tem o arquivo ACBrNFeServicos.ini e apague-o caso tiver, pois pode estar com a url de produção apontando para homologação e gerando o problema. Por último, se conseguir trazer para o seu ambiente a pasta do sistema do seu cliente para o seu cenário, salvar no mesmo caminho e tente debugar para caçar a bruxa.

Bom dia, No tópico citado anteriormente foi incluída a informação, recebida da Sefaz, de que foi indentificado um problema e efetuada uma provável correção.

Boa noite Carlos, No tópico que o Diego indicou tem dois tipos de configurações da Locaweb, você tentou seguindo ambas? Tente sem codificar o usuário e senha para base64.

Boa noite, No tópico que o Kiko indicou tem a indicação de um possível problema se estiver usando com Capicom/ configurações das opções de internet. Como estão suas configurações de SSL / TLS? A1: SSLLib := libOpenSSL SSLCryptLib := cryOpenSSL SSLHttpLib := httpOpenSSL Copie as dlls atuais na pasta do seu exe. trunk2/DLLs/OpenSSL/1.1.1.10/ A3 : Windows atualizado SSLCryplib = cryWinCrypt SSLHttpLib = httpWinHttp SSLLiB = libWinCrypt Para ambos SSLXMLSignLib = xsLibXml2 SSLType = LT_TLSv1_2 Copie as dlls atuais da LibXml2. trunk2/DLLs/LibXml2/ Lembrando, se a sua aplicação for x86, use as dlls x86, mesmo que o S.O. seja 64.

Boa noite Willian, Vamos às 3 alterações em questão. 1. Esta alteração deverá ser enviada, pois conforme verificamos, os campos realmente não são obrigatórios. 2. Essa alteração não foi correta, xMunicipo é o nome do município e CodigoMunicipio é o código IBGE. De acordo com o tamanho do campo tudo indica que estava correto enviar o nome do município. 3. Não eram a mesma informação ? Se forem a mesma não tem problema a mudança e fica igual às demais declarações.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde Willian, Obrigado pelo contribuição, por favor aguarde os consultores também analisarem e mandarem ao SVN. #TK-3128

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Segue um tópico com mais informações a respeito do componente que já atente diversos provedores e também está sendo adequado ao padrão nacional.

Boa noite, Adicione o novo município no ini seguindo o exemplo de Santos Dumont e sua os passos do tópico a seguir. Se funcionarem os métodos anexe aqui o ini atualizado para envio ao SVN.

Boa noite bnobre, O mesmo ultNSU que consultou no cliente e deu rejeição, ao consultar no seu cenário funcionou? Confirmando, foi o mesmo ultNSU? Quando você consultou no seu cenário, a sequência de ultNSU foi alterada e você atualizou o ultNSU no cliente para seguir a partir do ultNSU mais recente recebido no seu cenário? Se o ambiente é via parâmetro, veja se no cliente não está como Homologação. Tente no cliente fazer uma consulta com ultNSU zero para baixar novamente todos os NSUs disponíveis do período e "reiniciar" a contagem do ultNSU.

Boa noite, Você deve estar usando Capicom. Para certificado A1 utilize OpenSSL e utilize as dlls atualizadas na pasta da aplicação Para A3 utilize winCrypt com todas as atualizações do Windows em dia. https://acbr.sourceforge.io/ACBrLib/DFe.html