Sergio Augusto

Pessoal tenho um cliente que recentemente adquiriu um certificado e-CNPJ em Nuvem da CertiSign - RemoteID (fica um programa desktopID.exe rodando - vou mandar o print). Eu tenho 2 maquinas que consegui fazer assinar com a configuração que segue: ACBRnfe1.Configuracoes.Geral.SSLLib:=libWinCrypt; ACBRnfe1.Configuracoes.Geral.SSLCryptLib := cryWinCrypt; ACBRnfe1.Configuracoes.Geral.SSLHttpLib := httpWinHttp; ACBRnfe1.Configuracoes.Geral.SSLXmlSignLib :=xsLibXml2; ACBRnfe1.Configuracoes.WebServices.ssltype:=LT_TLSv1_2; Mas vou falar para vocês, eu tenho 3 máquinas que não assinam a nota de jeito nenhum com este tipo de certificado. Ele pede um token e uma identificação que usa um aplicativo de celular. Consulta de Status funciona em todas, mas ele falha a primeira vez, na segunda vez consulta perfeitamente, é assim nas 5 máquinas. Mas assinar a Nota nestas 3 máquinas, não assina de jeito nenhum. Já troquei as dlls da pasta LibXml2, coloquei na pasta do projeto, no system32 no syswow64 já fiz de tudo nelas. Já peguei dlls do ACBR mais antigo que tinha, substitui tudo tente. Atualizei os ACBRs, compilei de novo. Usei ACBRs mais antigos. Nossa não sei mais o que fazer. Cada máquina dá um erro diferente. A última máquina que briguei mais com ela, esta dando o erro de: ***Falha em obter Provedor de Criptografia do Certificado. Erro: 80090006, erro: $80090006 Mas já houve erros de tudo que imaginarem: Falha ao obter a Chave Privada do Certificado para Assinatura Até - Schemas inválido Keyset does not exists Mas o último erro é o que destaquei com ***. Parece não conseguir pegar a chave do certificado para a assinatura. Mas o programa que instala o certificado em nuvem sozinho, não é igual a gente instalar um pfx. Nossa é muito estranho. Tenho o sistema com ACBR em clientes com A1 e A3, faz muitos muitos anos... e é a primeira vez que enrosco tanto em um certificado. Não querendo falar mal, mas achei este programinha que fica rodando com o certificado desktopID.exe muito ruim, ele deveria simular um A1 normal, acho que ainda tem muito que melhorar. Se alguém tiver alguma luz ficarei grato. Não sei o que fazer. Abração pessoal, obrigado desde já.

Também gostaria de saber, não estou conseguindo até hoje. Erro não catalogado e tal.

Salva o valor antes e compara depois, eu tive que fazer tipo isso: valor_display:=0; //coloque aqui o valor que deseja iniciar na sua calculadora old_valor:=valor_display; Result:=valor_display; ACBrCalculadora1.valor_display; if ACBrCalculadora1.Execute or (old_valor<>ACBrCalculadora1.Valor) then Result := ACBrCalculadora1.Valor; Assim se tem um resultado diferente na calculadora ele tras. Funcionou para mim, espero nao ter erro de sintaxe.. mais ou menos assim kkk Abraço espero ter ajudado

Também estou tendo bastante reclamações de um cliente na última semana. Pedi para verificar outros programas e contabilidade se não estão baixando os documentos e utilizar a opção que baixa tudo novamente com ultnsu 0 para o sistema resetar os nsus e ver se nao da mais erros. Mas esta muito estranho.

O problema é ainda maior.. Tenho clientes Simples Nacional e MG que fazem o Sintegra. E o validador Sintegra, a última versão é de 2017 (5.4.0). Não tem como enviar com esta inscrição nova, pois ele rejeita. Instrui o Cliente a colocar ISENTO enviar o Sintegra e depois voltar. Qualquer coisa depois se sair outra versão ele retifica.

Obrigado pela dica Juliomar, vou conferir. Entretanto não vi problema na implementação acima uma vez que se não funcionar a Autenticação acaba nao retornando 235 no final e acabou funcionando para os emails que ja tinha configurado e agora para locaweb também. Então pode ser que ajude alguém. Mas se eu conseguir com outras dlls, vou deixar da forma original. Abração, boa noite e bom descanso ai.

Apanhei igual cachorro desta rotina hoje. Resolvi com a imagem anexa.

Pois é eu fiz uma copia separada da função acima e vou ter que liberar assim para funcionar. Estou com medo de influenciar em algo, mas fiz alguns testes e parece que não. Talvez compense subir assim por enquanto e analisarmos se sumiu a url da tag futuramente e comentar no código. Eles não vão resolver tão já. O prazo que estava no site para voltar o sefaz era hoje as 8 hrs. E voltou com o erro.

Foi exatamente o que eu fiz, sem ter visto este tópico, mas fiquei com medo da alteração estou fazendo testes.

Não consegui identificar algum padrão. É muito de vez em quando, mas já aconteceu em clientes diferentes. Maioria SAT da bematech.

Pessoal tive já alguns problemas. Quando o equipamento dá "ERRO NA PORTA DE COMUNICAÇÃO" o cupom no SAT é autorizado pelo equipamento e esta no SEFAZ. Mas para o componente retorna Erro ou seja, minha automação acha que não deu certo. Então a automação sugere e envia novamente o mesmo. Ou seja ficam 2 cupoms iguais na sequencia no SEFAZ, mas na automação somente 1. Exemplo: 1-) envio o cupom que será o nro.90 => R$ 100,00 ok 2-) envio o cupom que será o nro.91 => R$ 300,00 (erro na porta de comunicação - mas vai para o sefaz como 91, mas o componente retornou erro e não gravo) 3-) envio o cupom que será o nro.91 => R$ 300,00 novamente (emitido com sucesso) MAS ELE VIRA 92 (POIS QUEM NUMERA É O APARELHO) TANTO NA AUTOMAÇÃO COMO NO SEFAZ. 4-) Concluindo => A automação fica sem o cupom 91 (Fica 90 => 100,00 e 92 => 300,00). Então temos uma rotina que nos alerta e fazemos toda inclusão do 91 no sistema e sugerimos para o cliente fazer uma nota de entrada cancelando o mesmo. Algum dica??

Obrigado EdmarFrazao, fiquei com medo de ter acontecido algum detalhe só nos meus sistemas, pois não achei nada em lugar algum mencionando a lentidão.

Pessoal não fiz alterações no meu software e estou com problemas em alguns clientes de comunicação com SEFAZ/MG. Alguém esta na mesma situação?? Mas é só MG, os demais funcionam. Erro 12175, 10091, timeout e por ai vai. Nesses clientes de vez em quando vai. Alguns lugares dá "Network subsystem is unusable", mas parece que nem tem firewall ativo e nem antivirus no cliente.

Então no método Sincrono ele nem é muito baseado em recibo, se ele funcionou a nota foi transmitida... os dados são um pouco diferentes verifique algo do tipo: ACBrNFe1.Enviar(0,false,SINCRONO,false); se (ACBrNFe1.NotasFiscais.count>0)and(ACBrNFe1.NotasFiscais.Items[0].Confirmada) então "deu certo" <= aqui já funcionou a transmissao e a nota foi carregada na primeira posicao do objeto, onde você já pode salvar acbrnfe1.NotasFiscais.items[0].GravarXML(arquivo) ACBrNFe1.WebServices.Enviar.xxx <= pode conter o recibo desejado tem várias propriedades que retornam aqui. ACBrNFe1.NotasFiscais.items[0].NFe.procNFe.xxx <= protocolo

No método de transmissão do ACBR: ACBrNFe1.Enviar(0,false,SINCRONO,false) o terceiro parâmetro se for passado TRUE de Sincrono esta funcionando que nem um tiro. Entretanto os retornos são para diferentes por exemplo protocolo: ACBrNFe1.NotasFiscais.items[0].NFe.procNFe.nProt Tem que dar uma estuda no método diferente por ai. Quando o lote possui um erro, por exemplo endereço ou coisas do tipo no método "Assincrono", o retorno demora uma eternidade.

Resolvi assim: -Copiando a dll do aparelho e o arquivo SYGMASAT.INI para dentro da aplicação. Dentro do arquivo ini tem um parametro "MostraTempo=1", mude para "MostraTempo=0". Reinicie a aplicação.

Tinha respondido o texto abaixo, mas agora que consegui ver o tópico do colega, dizendo que o prazo foi dilatado. "Até onde fiquei sabendo eram 24 horas para transmitir um cupom emitido offline (e o problema de MG se estende a mais de dias), se alguém souber que é diferente gostaria de obter o respaldo legal para isso."

Eu abri um chamado no site deles a 3 dias, sem retorno.

Pessoal estou apanhando que nem cachorro aqui em MG.. "Lote em processamento" Veja o arquivo de envio as 15:57 e ainda esta dando Lote em Processamento mais de uma hora depois 17:37

As vezes tem que abrir a form que a classe é herdada, depois abrir a form do relatório novamente que não da mais erro. Basta segurar ctrl+clique na classe que esta sendo herdada que vai abrir outra form vazia. Depois você fecha e abre novamente esta que está com erro. No meu sempre da certo.

Muito ruim Firedac.... tinha que ser igual BDE Deu append, colocou os dados e deu Post no table tem que salvar e dar commit... No Firedac (com Firebird), se não por esse "monte" de comandos... pode ligar o que for que não vai para na base em tempo real... já me estressei, nem migrei outros projetos. Ainda migrei um projeto achando que ia ficar mais rápido, com o monte de opção que tem no FetchOptions, ainda ficou mais lerdo. E não foi falta de conhecimento, eu mexi na ferramenta de cima em baixo.. muito ruim.

Pessoal, porque a consulta de cadastro tem webservice disponivel para versão 3.1 e para 4.0 (SP por exemplo). Mas os XSD só tem até versão 2.0 para consulta de cadastro??? Não entendi. Tem que enviar 2.0 mas para o webservice de endereço 4.0 ??? Estou em "parafuso".

Cara eu tive bastante problemas com Commit no Firedac (com Firebird). Como não era um projeto com muitos terminais nem muitas movimentações eu resolvi com uma solução que acredito não ser das melhores. Crie um componente do tipo TFDTransaction e ligue no seu componente TFDConnection (Propriedade Transaction e UpdateTransaction) No Evento do Seu TFDConnection = AfterCommit coloque: if FDTransaction1.Active then try FDTransaction1.Commit; except end; No Evento do Seu TFDTransaction Coloque: try if (not debugando)or(database1.intransaction) then database1.Commit; except end; if FDTransaction1.Active then try FDTransaction1.Commit; except end; A varíavel "Debugando" que criei de nivel global recebe "True" se achou algum arquivo PAS na pasta de execução. Fiz isso porque se não fica dando erro ao DEBUGAR, mas pode tirar a condição dela se quiser ficando apenas " if (database1.intransaction) then" E ainda teve uma janela do sistema que tiver que ligar os TABLES em um outro FDTransaction separado e colocar este mesmo evento (acima) no FDTransaction (mas o mesmo FDConnection). Resolveu 99,9% dos problemas deste projeto e vários terminais alterando ao mesmo tempo. Se possível entre as opções do menu feche seu FDConnection que ai os commits vão direto para base. No UpdateOptions dos meus objetos de conexão, base e query ... deixei AutoCommitUpdates TRUE, LockMode lmPessimistic, LockPoint lpDeferred, RefreshMode rmAll e UpdateMode upWhereKeyOnly. Também não sei se são a melhor opção para você, mas pode tentar. Se alguém tiver outra solução, mas realmente complicado o Firedac. Abraço a todos.

Pessoal sugiro a correção do nosso amigo @Afranio Lucas Sem ela impossível enviar NFCe 4.0 para Amazonas. Pelo menos eu só consegui depois que mudei isso, se eu tirar falha. Alteração no ACBrNFe.pas: function TACBrNFe.EhAutorizacao( AVersao: TpcnVersaoDF; AModelo: TpcnModeloDF; AUFCodigo: Integer ): Boolean; begin Result := (AVersao >= ve310); if (AModelo = moNFCe) And (AVersao < ve400) then Result := not (AUFCodigo in [13]); // AM end; Grande abraço a todos.

Também concordo com @Antonio Carlos L se não tem como fazer NFCe com cfop interestadual, acho que não faz sentido FCP. A não ser que mudaram isso e eu não testei ainda.