jackson Lima

Identifiquei o erro: um dos produtos estava indo com um valor na tag: vOutro com: 0.01 centavos. 

Obrigado pela resposta mano.
Me informaram que não precisa passar esses 3 campos quando a comunicação é por troca de arquivo.

Atualizando aqui, caso alguém precise: os cancelamento não passam mais pelo integrador, me passagem a informação errada. Apenas os pagamentos no cartão passarão por ele agora, a venda e cancelamento vai direto para o MFE.

O problema era que minha aplicação não estava arredondando o valor total pela regra abnt, ai influenciava no valor da forma de pagamento, fazendo com que dê a diferença. Solução: usar no total da venda a função do acbr para arredondar para abnt.

Descobri o problema, o erro não estava no xml, mas no parâmetro CancelarUltimaVenda eu estava passando a chave do cfe sem o prefixo cfe junto na chave.
O Bruno da elgin que identificou isso. (suporte da elgin é top)
O exemplo do acbr chama a função sem parâmetros, o que não funciona também.
Obrigado.

Pessoal, encontrei o problema, o erro era pq um programador alterou o timeout dentro de uma função aqui no nosso sitema. 

Você não passa o valor do saque, quem retorna ele é o TEF. dependendo da credenciadora e como foi selecionado no pinpad
Passos:
Você manda apenas o valor de 10,00 que é o valor original.  O TEF vai retornar 14,00 (você não controla isso, pode vir saque ou não). O acbrtefd vai retornar o saque, então, você vai no evento DepoisConfirmarTransacoes ver teve saque: if RespostasPendentes[resp].saque > 0 Se tiver saque retornado pelo tef ai você envia como valor de pagamento no ecf que ela mesma gera troco automaticamente.  

Desculpem pessoal, encontrei o problema. Tinha uma unit no meu projeto que tinha no uses: ACBrMDFeDAMDFEFR ai por isso que pedia o fast.

Por enquanto não tem jeito, tem que usar a variável. 

Resolvi chamando o imprimir transações pendentes (que não irá imprimir pq está buferizado) logo após cada CRT, assim o ACBrTEFD aciona o evento e eu salvo os dados que quero. Caso o cliente desista minha aplicação envia o CNC para o CRT cancelado.

Resolvi isso fazendo a confirmação das transações depois de cada operação CRT, caso haja algum cancelamento ele precisa cancelar usando o CNC.

O número do cartão ele vem sempre mascarado segundo o layout, nos testes que fiz aqui ele vem: 111111*****11111
Como no caso, eu preciso dos últimos quatro dígitos para o MF-e acredito que não vai ter problema salvá-lo no banco, correto?
As propriedades que já existem pegam valores de campo que não encontrei no layout por exemplo:
300 : case Linha.Sequencia of 1 : fpNFCeSAT.DataExpiracao := Linha.Informacao.AsString; 2 : fpNFCeSAT.DonoCartao := Linha.Informacao.AsString; end; Esse 300 ai não tem nem no layout de 2015.
Mas de qualquer forma vou ler esse valores usando: LeInformacao no DepoisConfirmarTransacoes

Achei aqui no layout a solução:
No caso do uso de uma Impressora Fiscal, recomenda-se registrar as formas de pagamento e eventuais descontos concedidos pelo estabelecimento somente após a realização da operação de TEF, convivendo assim com as restrições de determinados modelos de equipamentos que não permitem:  Registrar um desconto após ter registrado uma forma de pagamento (tipicamente, dinheiro);  Registrar mais de um desconto. Desculpa ai pessoal, deveria ter lido o manual completo antes de postar a dúvida.
Baseado nesta parte do layout já é possível implementar mais tranquilamente.

Galera só atualizando este post aqui:
 
O problema do tamanho das colunas para este modelo já foi resolvido nos fontes do acbr como explica o Daniel Simoes:
 

Consegui passar no teste na homologação, pois como Régys disse o acbr apenas envia o comando para a impressora, então descobri que a cada reinicio de operação na impressora daruma ao gerar o LMF a mesma imprime os totalizadores desde o inicio. Obrigado.