Marcel Bitbyte

Boa tarde, Acabamos de receber essa mensagem de cliente de MG também. Acredito que deva ser algum erro na SEFAZ, pois estava funcionando normalmente até poucos minutos. Alguém mais com o mesmo problema?

Ao gerar o arquivo de remessa a sequencia acabou pulando por conta do multiplicador (fpQtdRegsLote) que mudou de 3 para 4 quando entrou título com percentual de multa maior que zero. Isso acabou retornando valor errado para a variável que armazena a sequencia ISequencia := (ACBrBoleto.ListadeBoletos.IndexOf(ACBrTitulo) * fpQtdRegsLote) + 1; No meu teste, já havia adicionado 7 títulos onde o percentual da multa era igual a zero. Até esse momento a variável fpQtdRegsLote é igual a 3, e a sequencia estava em 21. No próximo título que deveria ser a sequencia 22, por ter o percentual de multa maior que zero, a variável fpQtdRegsLote mudou para 4, e o resultado da multiplicação retornou como 28, quebrando a sequencia dos registros, pois a conta não leva em consideração quantas linhas foram adicionadas em cada título anterior. Observei isso na classe ACBrBancoBradesco também, que aparentemente pode quebrar a sequencia caso tenha títulos com percentual de multa zerados e outros com valor informado, mas não cheguei a testar. Fiz uma alteração no fonte do ACBrBancoSantander para testar, me baseando na classe ACBrBancoItau, e aparentemente ficou correto. 1. Removi a declaração da variável ISequencia do método GerarRegistroTransacao240, e passei a declaração para o protected. 2. Instanciei a variável como 0 no constructor. 3. Substituí a linha onde fazia o cálculo da sequencia pelo comando: Inc(ISequencia); 4. E zerei a variável no método GerarRegistroTrailler240. Se alguém souber de outra maneira de deixar a sequencia correta sem precisar alterar o fonte, e puder me orientar, seria de grande ajuda. Ou se realmente houver esse problema, fica minha sugestão para alteração do fonte oficial. Desde já agradeço a atenção.

Sim, estou usando os fontes do trunk2. Mas acabei de ver onde errei. No trunk2 entrou a configuração de Tipo de Emissão e não reparei que havia um envento no OnChange desse campo, e no componente do ACBrNFe a propriedade SSLLib deixei selecionada a opção libCapicomDelphiSoap por engano. Só troquei essa propriedade para libCapicom que voltou a funcionar. E outro detalhe é que tive que mudar as configurações nas Opções da Internet e deixar marcada as opções: Usar TLS 1.0 Usar TLS 1.1 e desmarcar as opções: Usar SSL 2.0 Usar SSL 3.0 Usar TLS 1.2 Agora esta tudo normal. Agradeço a atenção.

Bom dia. Estou com o mesmo problema em um cliente. Tentei atualizar a pasta do Schema, usando a pasta que esta na pasta do projeto do ACBr - Trunk 2, mas o erro continua. Já no ambiente de homologação até o momento não tive problemas.

Olá! Eu estou com o mesmo problema do nosso amigo geanjesus. Também estou usando o SAT Tanca com o aplicativo SatTeste. Ocorre o mesmo comigo, logo após o envio da venda ou cancelamento, se eu tentar consultar o numero da sessão que foi gerado, o retorno é sempre: sessao nao existe. Eu extrai os logs e a venda foi aceita.

Bom dia! Eu estou tendo problema ao imprimir o extrato no Fortes. Na visualização está normal e quando mando imprimir só imprime o cabeçalho. O erro ocorreu quando tentei imprimir um extrato com 141 itens, mas em outro teste com pouco mais de 100 deu certo. Fiz um teste comentando a linha RLLayout.PageSetup.PaperHeight := CalcularTamanhoDaPagina( RLLayout ); e passei o valor fixo RLLayout.PageSetup.PaperHeight := 297; //Tamnho da folha A4 Dessa forma deu certo, imprimi normalmente os 141 itens. Se o tamanho do extrato for menor que o tamanho de uma folha A4, a impressora ignora o espaço em branco no final e imprime até onde tem texto, e se o tamanho do extrato passar o tamanho da folha A4, então haverá a quebra de pagina e a impressora imprime normalmente as paginas. Se a impressora tiver guilhotina, é só deixar configurada para cortar o papel no final no documento.

Q estranho, eu acabei de gerar mais 3 notas junto com meu cliente depois consultei as mesmas, estava normal.

Voltou, está funcionando. XD Ótimo dia a todos. Marcel

Bom dia! Vejo que ainda estamos com problema? é isso mesmo? mais alguém continua com o mesmo problema? Está complicado viu... no ambiente de homologação o negócio funciona, como que pode?! Alguém conseguiu alguma resposta da Ginfes que não seja o problema na nossa aplicação? Marcel

Alguém já conseguiu uma resposta da Ginfes que não seja o problema da nossa aplicação?

Então né.... já estou esperando esse tal retorno que eles falam já faz umas 18 horas. Será que essa demora é porque está com muita fila? Ou será que essa demora é porque o webservice deles é muito lento? Palhaçada essa Ginfes, além de atrasar o serviço do meu cliente, está atrasando o meu também.

Continue reclamando com eles, se necessário envie o trecho do código fonte do programa para a Ginfes mostrando que a aplicação só está realizando uma consulta e mesmo assim acontece o erro. Não é a primeira vez que eles lançam uma atualização com erro. Só que para fazer eles admitirem, só com muito esforço mesmo.

Pois é Por isso orientei meu cliente a deixar o sistema parado ontem para ver se parava o erro. E hoje ao tentar consultar uma nota que já estava gerada o erro voltou a aparecer. E a aplicação só fez uma consulta, então não era para aparecer. Acabei de enviar um email para a Ginfes, vamos aguardar. Qualquer novidade eu posto aqui.

Bom dia, Comecei a receber e essa mensagem ontem do final do dia e hoje continua. Erro: A02 Empresa ja com uma consulta em andamento. Favor aguardar o termino de uma consulta para efetuar outra. Será que lançaram alguma atualização? Marcel