Renato Rubinho

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.

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, 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, 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

Boa noite, Se deu a rejeição de duplicidade foi enviado duas vezes. Controle o envio pelo sistema, não permitindo um segundo envio. Se travar antes do retorno, faça a consulta e permita um novo envio apenas se a NFe tiver sido rejeitada. Carregue o XML no componente, consulte a nota e o componente vai montar o XML completo com o XML carregado e o protocolo de autorização recebido na consulta.

Veja se este tópico te ajuda em algo.

Boa noite Paulo, O arquivo cidades.ini faz parte do componente antigo que não recebe mais manutenção. Esse município já consta como implementado no componente atual. Considere migrar para o ACBrNFSeX.

Provavelmente o provedor só disponibilizou schemas para esta versão, mas não quer dizer que a outra não funcione. Para saber qual versão você está usando para um município, localize-o no ini e veja a chave VERSAO, se não estiver preenchida o componente assume 1.00. Veja que a alteração que você fez foi na procedure da versão 1.00. A propósito, por favor anexe a unit alterada para ser enviada ao SVN. Só para não esquecer, pode validar e confirmar se a ConsultaNFSe está funcionando?

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

Você alterou o ini? No ini do SVN não tem versão preenchida, assim utilizaria automaticamente a versão 1.00. Se alterou o ini, precisa mandar a alteração para o SVN.

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

Boa tarde Willian, Esse provedor ainda não foi documentado no componente se está está com os métodos validados. A versão 1.00, que você está usando, possui o método ConsultaNFSe. Pode confirmar se também está funcionando, além da emissão?