Valdir Dill

Daniel, acho que você não leu direito minha resposta ou eu não fui claro, rs.. Como mencionei, não tem necessariamente a ver versão a versão do Windows (pode ser 7, 8 ou 10), mas o problema é falta algum update/pack. Vai por mim, tivemos mais de 180 usuários com esse erro. Todos, absolutamente todos foram resolvidos após a atualização total do Windows. Veja, por exemplo, se este remendo está instalado -> https://support.microsoft.com/pt-br/help/3140245/update-to-enable-tls-1.1-and-tls-1.2-as-a-default-secure-protocols-in-winhttp-in-windows Abraços.

Boa tarde, Isso é problema de Windows desatualizado. Tive vários usuários com esse problema e, em todos os casos, a atualização do Windows resolveu. Não necessariamente a versão, mas falta algum update/pack. Logicamente que não pode ser XP. Esse já não funciona faz tempo, rs.. Abraços.

Bah, que grosseria tchê!! Será que nunca ninguém pode discordar de ti??? Eu só queria ajudar relatando o que acontece aqui. O post nem foi eu que abri. Só estava querendo ajudar o outro colega que iniciou o post. Eu uso os componentes Acbr há mais de 10 anos e Isso NUNCA ocorreu comigo também. Trabalho com instalação de softwares/Windows há mais de 20 anos. Não estou iniciando agora. Se você tivesse lido todo meu relato veria que eu NÃO tenho os fonte onde você diz. Mas tudo bem, da próxima vez não me meto mais nas tuas respostas. De toda forma, obrigado. Encerro minha participação neste post por aqui.

Bom dia, Tenho que discordar @Juliomar Marchetti. Eu fiz uma instalação com o HD formato, ou seja, sem a menor possibilidade de haver .bpls ou outros arquivos do Acbr perdidos na máquina. HD novo, Windows novo e Delphi novo. Pode até isso que você diz, mas então é o instalador do Acbr, quando executado pela segunda vez que faz isso. Veja bem, eu instalo os componentes pelo instalador. Acesso o Delphi e tudo (todos os componentes Acbr) está lá normal. Basta eu fazer um update no svn e executar o instalador novamente. Mesmo que eu não mude absolutamente nada nas configurações de instalação, nem de pasta, nem nada. Só execute o instalador. Quando entrar no Delphi ele vai dar esse erro. Abraços.

Bom dia, Meu Acbr também começou a fazer isso. Já aconteceu 3 vezes nos últimos 15 dias. Toda vez que faço um update e executo o instalador, logo que vou acessar o Delphi ele diz que alguns pacotes não estão lá, mesmo estando. A solução que encontrei foi executar os seguintes passos: - Criar uma nova pasta para os fontes (toda vez tenho que mudar a pasta); - No Delphi eliminar todos os path do Fortes no library path; - No Delphi, em Install Package, remover todos os .bpl do Fortes; - Eliminar a pasta antiga dos fontes; - Na nova pasta baixar os fontes Acbr; - Execute o apagaAcbr.bat; Fiz um teste executando todos esses passos, exceto sem mudar a pasta dos fontes e não funcionou. Instalar instalou tudo certo, mas é só entrar no Delphi que dá o erro. OBs.: não esqueça de na instalação marcar a opção "Copiar todas as dlls(...". Não sei se tem a ver, mas o problema começou depois que mudei para Windows 10. Abraços.

Bom dia, Quando se faz necessária uma reinstalação completa e "limpa" do Acbr, é recomendável executar o apagarAcbr.bat para limpar tudo o que tinha da instalação anterior, correto? Ocorre que esse bat não apaga tudo quando os fontes baixados na máquina tiverem sido gravados numa pasta hospedada em uma partição diferente de C:\. O bat também não tem como apagar esses arquivos anteriores automaticamente, pois não se sabe em qual partição (D:\, E:\, ..) cada um tem seu fontes armazenados. Por isso, estou sugerindo (novo apagarAcbr.anexo) para que se mostre uma mensagem recomendando para que cada um faça essa deleção manualmente. Obrigado. apagarAcbr.bat

Bom dia, No componente ACBrNFe, a configuração default para a propriedade SSLType é LT_all, certo? Vamos supor que, sem mudar nada em SSLType, eu sete meu componente para ACBrNFe1.Configuracoes.Geral.SSLLib = libWinCrypt, ok? Essa configuração fará com que automaticamente: - CryptLib fique igual a CryWinCrypt - HttpLib fique igual a httpWinHptt - XMLSignLib fique igual a xsLibXml2 Certo? Muito bem, agora vem minha pergunta: Supondo que nas opções de internet o usuário tenha habilitado todos os TLS, quem é que vai "decidir" qual TLS (1.1, 1.2, ...) será usado pela conexão no momento de transmitir a nota? É a SSLType? ou a é CryptLib? ou a é HttpLib? ou a é XMLSignLib? ou é o Windows? Obrigado.

Bom dia, Certo. Mas tem um detalhe: dependendo do NCM, tem vários CNAEs que já teriam obrigação de informar o "SEM GETIN", alguns deles desde Jan/18. Contudo, o schema da 3.10 (leiauteNFe_v3.10.xsd) não aceita esse literal. Apenas o layout 4.0 (leiauteNFe_v4.00.xsd) que aceita. Então, no caso, por exemplo, do CNAE 324 e NCM 9503 a 9505, obrigatoriamente o emitente teria que já estar na NFe 4.0 desde janeiro/18, é isso? Obrigado.

Boa dia, É constante. Ele ocorre algumas máquinas. Não consegui estabelecer o padrão ainda. Mas quando ocorre, ocorre sempre. Vou tentar fazer debug na máquina do usuário para ver quando ocorre. Obrigado

Bom dia, Também estou enviando sem nada em cEan e cEanTrib e não gera nenhuma rejeição. Será que houve algum adiamento dessa regra de validação? Obrigado.

Bom dia Italo, Obrigado pela ajuda. Na verdade, meu problema começou esta semana em alguns usuários quando atualizei o sistema para usar TLS 1.2. Na SSLHttpLib eu tinha configurado = httpWinHttp, mas em alguns usuários com Windows 7, começou a dar erro "12175..". Aí mudei SSLHttpLib para httpWinINet. Isso resolveu na maioria da máquinas. Mas algumas poucas máquinas, essa mudança para httpWinINet começou a dar esse erro de A.V. Obrigado.

Bom dia, - AcbrNFe1.Configuracoes.Geral.SSLCryptLib := cryWinCrypt; - AcbrNFe1Configuracoes.Geral.SSLHttpLib := httpWinINet; - AcbrNFe1Configuracoes.Geral.SSLXmlSignLib := xsLibXml2; Quando utilizo esta configuração (acima) dá erro de access violation. Ainda não consegui debugar para ver onde exatamente ocorre o erro, pois só acontece em algumas máquinas de usuários. Já com esta configuração (abaixo), o erro não acontece. - AcbrNFe1.Configuracoes.Geral.SSLCryptLib := cryWinCrypt; - AcbrNFe1.Configuracoes.Geral.SSLHttpLib := httpWinHttp; - AcbrNFe1Configuracoes.Geral.SSLXmlSignLib := xsLibXml2; Alguma sugestão? Obrigado.

RESOLVIDO. O problema de fato era no SO. Uma "limpeza" com Cclean resolveu. Obrigado!

Bom dia, Estou enfrentando o seguinte erro: "System error. Code: 1753 O mapeador de pontos de extremidade não possui mais pontos de extremidade disponíveis". Ainda não consegui compilar o fonte para ver exatamente onde ocorre porque em laboratório não consegui reproduzir o erro. Mas só ocorre quando acesso/seto propriedades do componente acbrNFCe. Pelas pesquisa que fiz, me parece ser problema específico do sistema operacional da máquina do cliente. Mas, se alguém já tiver passado por essa situação no uso dos componentes Acbr e puder me dar alguma dica... Obrigado.

Beleza. Obrigado!

Boa tarde, Sim, também é possível. Mas acho que se a função fizer essa verificação ficaria mais completo e o código mais à prova de erros do usuário. Vejamos uma situação hipotética: um usuário trabalhando no sistema informa (cola) um e-mail com um quebra de linha num dbEdit. Se eu apenas executar TACBrValidador.Validar(trim(dbEditEmail.text)), ele vai retornar true (validado). Aí, para garantir que a gravação no BD fique correta, teria que fazer sempre, em todo campo de email, algo do tipo dbEditEmail.text := trim(dbEditEmail.txt). Colocando a função (que até poderia ser o trim) direto no AcbrValidador, garante-se que, se o usuário informar um lineBreak, tabulação ou qualquer espaço antes ou depois do e-mail, retornará false, o que forçará ele (o usuário) a corrigir. Obrigado.

Bom dia, Me deparei com uma situação onde o usuário copiou e colou um e-mail. Dependendo de como ele copia lá na origem, pode vir junto um enter (quebra de linha). O AcbrValidador deixa isso passar, o que pode gerar problemas em algumas situações. Fiz uma mudança na ACBrValidador.pas (inclusão das linhas 850 a 855) no arquivo anexo. Sugiro disponibilizar alteração no svn, se os moderadores entenderem a alteração positiva, é claro. Obrigado! ACBrValidador.pas

Não sei se estou entendendo a mudança que você fez, mas eu havia atualizado o componente hoje pela manhã e está ainda COM o "s". Por via das dúvidas, neste instante, deletei a AcbrConsultaCNPJ.pas aqui e atualizei os fontes pelo svn e continua com o https. Em anexo o print da unit que atualizei agora baixando pelo svn. Obrigado.

Boa noite, Nas opções de internet, marque SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1 e TLS 1.2. Abraços.

Boa tarde, Novamente instável, hehe! Tirei o "s" do https, conforme o @Juliomar Marchetti sugeriu e, aparentemente está funcionando. A linha 250 da ACBrConsultaCNPJ.pas ficou assim: HTTPPost('http://www.receita.fazenda.gov.br/pessoajuridica/cnpj/cnpjreva/valida.asp'); Abraços.

Perfeito. Testado e funcionando. Nada tinha a ver com os fontes e sim com o site da receita. Obrigado.

Bom dia, Eu estava com esse erro na hora de capturar o captcha. Resolveu quando habilitei TLS 1.0, TLS 1.1 e TLS 1.2 nas opções de internet. Abraços.

Bom dia, Sim, fiz inclusive a reinstalação (ACBrInstall_Trunk2.exe) completa. Até a atualização anterior (da semana passada), estava funcionando, tanto na minha aplicação como no demo Acbr. Obrigado.

Boa tarde, Atualizei os fontes do Acbr hoje e está dando erro na consulta do CNPJ na receita. Em anexo envio os arquivos do erro e dos resultados de retornos de debug. Obrigado. cnpj1.txt cnpj2.txt

Perfeito Compreendido. Obrigado!