EMBarbosa

Aqui no meu aplicativo eu uso os dois desmarcados. Não tenho nenum problema. Você não pode marcar a opção AutoEfetuarPagamento. Ela vai de encontro aos requisitos do TEF atual. Ela foi implementada pois anteriormente assim que se fazia o CRT você devia imprimir a forma de pagamento no cupom fiscal No Demo veja que tem um TPanel com a descrição "Pagamentos a Fazer". Fica na aba "Operação", ao lado das mensagens ao operador. Todos os pagamentos não TEF devem ser serializados ali, mas não enviados imediatamente ao ECF. Leia a orientação do TEF, em especial o Fluxo para Multiplos cartões. Exemplo no Cielo Premia você deve aguardar toda a decisão de forma de pagamentos e envios de CRT pois esses podem resultar em acréscimos ou descontos no cupom que você terá de enviar ao subtotalizar o cupom. Então dificilmente vai conseguir marcando essa opção. Não foi bem isso que você escreveu no primeiro tópico. Lá você descreve 2 CRT, uma pagamento Dinheiro e clicar no Fechar. Entendi que o "Fechar" era o botão "FinalizarCupom", pois clicar no botão "Fechar" não fecharia o cupom de forma alguma sem fazer os pagamentos dos cartões. Neste caso, você não precisa enviar os pagamentos feitos pelo CRT. O componente cuidará disso. É só você implementar os eventos dele corretamente, principalmente o onComandaECF, onComandaECFPagamento, OnComandaECFSubtotaliza. E no Demo eles estão implementados. Conforme acabei de descrever acima, você não pode fazer desse modo. Quando o segundo CRT for enviado, ele pode retornar um desconto para ser enviado ao seu cupom fiscal. Mas como você já enviou o pagamento para o ECF, você não conseguirá fazer o desconto. Com isso você não consegue terminar o processo.

Tópico trancado para evitar posts que estão saindo do assunto. Favor seguirem as regras de criar um tópico novo para novas dúvidas que não estão delineados no tópico atual. 2.2 - Permaneça no assunto - Quando tiver uma dúvida diferente do assunto no tópico, poste em novo tópico. Não use algo equivalente a "aproveitando o gancho... [dúvida não relacionada com o tópico aqui]". Favor leia as regras do fórum.

Há alguns anos, eu sofri muito com isso também. Que bom que resolveu.

http://stackoverflow.com/a/13598878/460775 http://stackoverflow.com/q/18779482/460775 http://stackoverflow.com/a/8184262/460775 http://stackoverflow.com/q/281548/460775 http://stackoverflow.com/q/7398580/460775

Formas de pagamento diferentes, cartões diferentes...

Observando o código, algo que faria sentido acontecer o que você relata é se todos os dois pagamentos tivessem a mesma OrdemPagamento e mesmo assim fosse englobados em grupos diferentes.

Acabei de fazer aqui e não tive nenhum problema conforme você relata. Veja: 1) O componente abriu o primeiro comprovante e imprimiu duas vias do primeiro cartão e fechou o comprovante; 2) O componente abriu o segundo comprovante e imprimiu duas vias do segundo cartão e fechou o comprovante; 3) terminou o processo; Não houve tentativas de imprimir uma quinta via. Vou tentar mostrar algumas explicações agora de quando segui o debug, e talvez você possa dizer o que diferente está acontecendo. Não é isso o que acontece no código. Apenas os cartões que estiverem na mesma OrdemPagamento serão impressos. Vou copiar mais o código para você observar: For K := 0 to Length( GrupoVinc )-1 do begin if GrupoVinc[K].OrdemPagamento >= 999 then Gerencial := True; For J := 0 to RespostasPendentes.Count-1 do begin with RespostasPendentes[J] do begin if GrupoVinc[K].OrdemPagamento <> OrdemPagamento then continue ; GPAtual := TipoGP; // Seleciona a Classe do GP Observe a linha que compara GrupoVinc[K].OrdemPagamento com OrdemPagamento e se estiverem diferentes, ele simplesmente ignora aquele cartão e suas vias.

Para referência futura, vou deixar esses links aqui nesse tópico: https://en.wikipedia.org/wiki/ESC/P https://reference.epson-biz.com/modules/ref_escpos/index.php?content_id=2 https://mike42.me/blog/what-is-escpos-and-how-do-i-use-it https://msdn.microsoft.com/en-us/windows/uwp/devices-sensors/epson-esc-pos-with-formatting

Se você está propondo uma correção, anexe o arquivo alterado com as devidas correções.

Você pode gerar um log com o ECFTeste que funciona também? Queremos comparar os dois logs.

Veja se isso ajuda: http://www.fazenda.mg.gov.br/noticias/2016_03_30_CEST_Prorrogacao.html

Você está compilando o ECFTeste com o Lazarus?

É porque o fonte provavelmente já foi atualizado.

A melhor coisa é consultar os contadores dos seus clientes.

Que ECFTeste novo é esse disponibilizado pelo Isaque?

Existe como reproduzir esse problema usando os aplicativos de exemplo?

Como assim cortando as informações?

Provavelmente você tem uma transação que não foi fechada corretamente. Se usa "CommitRetaining", a primeira coisa a fazer é corrigir isso para "Commit". Quando entender o motivo disso, provavelmente vai conseguir corrigir o problema.

Não. Você tem várias dúvidas sobre o XML da Redução Z. O que não é o mesmo que ter uma dúvida sobre um assunto. Leia novamente as regras e o segundo post do tópico Como fazer perguntas inteligentes e receber respostas satisfatórias. Daí se atente ao seguinte ponto: Ao criar um tópico, use um título específico como "Devo criar um registro R7 para cada R4 e para cada R6?". Não algo genérico como "Dúvida sobre R6 e R7";

Faltou um passo a passo para reproduzir o erro.

2.2 - Permaneça no assunto - Quando tiver uma dúvida diferente do assunto no tópico, poste em novo tópico. Não use algo equivalente a "aproveitando o gancho... [dúvida não relacionada com o tópico aqui]". Favor leia as regras do fórum.

Por favor, anexe os arquivos alterados e corrigidos.

Então, se o número de tentativas não altera o tempo, o problema é saber exatamente onde o componente está recebendo esse erro e se o tempo que ele demora para receber é realmente culpa dele. Acho improvável que seja, pois alterar as propriedades não resolveu o seu problema. Você conseguiu debugar algum desses problemas e ver exatamente onde ele é levantado? Precisamos de um passo a passo para reproduzir o problema.

Olá doidopb, Preciso dizer que NF-e não é o meu forte, talvez outros possam me corrigir aqui. Acredito que as diferenças se devam à implementação e à quando o erro é retornado. Outra coisa importante, você não deve levar todos os TimeOuts rigorosamente, pois dependem de como foram implementados. Então vamos por parte. Todos esses erros são da WinInet. Isso significa que o ACBr não está emitindo o erro. Apenas passando pra você o erro que ele encontrou enquanto estava tentando fazer o que você pediu. Sendo assim, pode ser que a interface retorne o erro em lugares diferentes, e com um tempo de resposta diferente. No entanto, veja a seguinte implementação de TNFeRetRecepcao.Executar. NOTA IMPORTANTE: Não estou dizendo que é esse o código que é executado, pois você não disse exatamente o que fez, nem colocou o exatamente onde o erro acontece... mas serve para ilustrar o que quero dizer da implementação. function TNFeRetRecepcao.Executar: Boolean; var IntervaloTentativas, Tentativas: integer; begin Result := False; TACBrNFe(FPDFeOwner).SetStatus(stNfeRetRecepcao); try Sleep(FPConfiguracoesNFe.WebServices.AguardarConsultaRet); Tentativas := 0; IntervaloTentativas := max(FPConfiguracoesNFe.WebServices.IntervaloTentativas, 1000); while (inherited Executar) and (Tentativas < FPConfiguracoesNFe.WebServices.Tentativas) do begin Inc(Tentativas); sleep(IntervaloTentativas); end; finally TACBrNFe(FPDFeOwner).SetStatus(stIdle); end; if FNFeRetorno.CStat = 104 then // Lote processado ? Result := TratarRespostaFinal; end; Note que no loop, ele verifica primeiro se a implementação de Executar herdado da classe é verdadeira, para depois avaliar o número de tentativas: while (inherited Executar) and (Tentativas < FPConfiguracoesNFe.WebServices.Tentativas) do begin Inc(Tentativas); sleep(IntervaloTentativas); end; Caso essa implementação tenha alguma espera, isso pode explicar o motivo de você estar esperando alguns segundos a mais do que o esperado. Veja: Quando inherited executar falha de primeira, o tempo gasto é exatamente 5 segundos de timeOut. Mas levando em conta que não falhasse de primeira, daria exatamente 12 segundos para a sua configuração atual. Mais uma vez, não estou dizendo que é esse o código que é executado, pois você não disse exatamente o que fez, nem colocou o exatamente onde o erro acontece... mas serve para ilustrar o que quero dizer da implementação. Se for um código semelhante, bastaria você mudar o número de tentativas para 0. Sugiro você tentar isso.