Sergio Augusto

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".