EMBarbosa

Sim. Como eu disse antes, verifique com a certificadora - os manuais são outros. Pesquise no fórum pois já falaram sobre isso.

Qual o modelo da nota?

Pois é, então não tem necessidade de fazer uma reimpressão do cupom utilizando o ADM... A má notícia é que o ACBrTEFD foi feito especificamente para atender a comunicação feita ao imprimir um cupom. A boa notícia é que já foi dito ser possível fazer a comunicação nestes casos de recebimento não fiscal utilizando o ACBrTEFD. Só que não há nenhum exemplo neste sentido. Tente entrar em contato com a certificadora para obter informações sobre qualquer certificação neste sentido. Também procure no fórum mais informações e daí desenvolva com base nisso.

Estamos cansados de repetir aqui no fórum que tem coisas que devem ser geradas diretamente do BD.

Você leu o manual e comparou o modelo do registro com o que o manual diz sobre ele?

Por favor, não faça posts duplicados. Continue em:

Quando se paga com cartão a prazo, o cliente não volta daqui a 30 dias pra pagar fazer outro lançamento de pagamento TEF no cupom. O cupom já foi impresso, não dá pra refazer. Ele faz o pagamento no cartão na hora e "resolve com o banco" depois. Agora se o pagamento foi computado no cupom como crediário (não como cartão), então não houve transação TEF no cupom. Se mais tarde o cliente volta pra pagar a parcela do crediário com cartão, a aplicação pode fazer um recebimento não fiscal via TEF. Mas aí já é outra coisa, visto que não há impressão de cupom.

Anexe o log por favor.

O anexo não veio...

Olá Ignácio, Isso foi um "ok, vou testar" ou um "ok, deu certo."?

Não ficou claro o motivo de o programa não conseguir renomear o arquivo. O problema poderia ser algum antivirus, antimalware ou outro programa que varre o sistema?

Pode ser que o arquivo não foi encontrado.

Sim. Por exemplo, você pode utilizar o ACBrBoleto com o Fortes Report ao invés do QuickReport.

Por favor, anexe a unit alterada.

Eu perguntei pois você estava com a legislação mais fresca na cabeça pois tinha acabado de consultar e eu não parei para ver. Só que agora eu já sei que é preciso implementar esses pormenores. Pode ser com outras propriedades criando uma nova classe tipo a TACBrECFRodapeRestaurante, ou talvez pode ser por adicionando um parâmetro ao TACBrECFRodapeRestaurante que vai identificar se está falando de mesa ou conta. De qualquer forma, é algo novo a ser implementado.

Eu estava falando de fazer as mudanças no SVN, não apenas no seu aplicativo.

Tentou o manual da gaveta? Contato do fabricante?

Que problema?

Acho que isso que fez foi uma boa saída. Mas você acha que será necessário criar propriedades específicas? Me parece que Conta de Clientes e Mesa são praticamente o mesmo funcionamento, só que com nomes diferentes. Talvez apenas trocando os textos a funcionalidade já fique atendida, não?

Você fez atualização do código fonte do ACBr? Acho que o código atual está pronto para a versão 02.01. Não sei se foram feitas as mudanças para a versão 02.02 nessa área do componente...

Será que alguém consegue apontar exatamente o que foi alterado que está dando esse problema? Também seria proveitoso alguém apontar como reproduzir o erro no aplicativo de exemplo e tal...

Depois de fazer a limpeza e reinstalar o ACBr, tente abrir todos os forms do seu aplicativo no Delphi. Daí faça um Build All. Se mesmo após isso continuar dando erro, tente reproduzir o problema com um dos exemplos do componentes.

Praticamente certo que é problema no ECF. Ele deveria bloquear fazer outra subtotalização quando já está nesse modo. Verifique o LOG só para desencargo de consciência.

Mais uma vez não é possível afirmar isso pelo guia prático atual... Eu tentaria responder as seguintes perguntas: Esse cupom de cancelamento é realmente um CF-e-SAT? Ele possui os campos necessários para esse registro mesmo quando ele é cancelado (COD_MOD, COD_SIT, NUM_CFE, NR_SAT e CHV_CFE)?

Infelizmente, o manual atual não diz... Mas parece que podemos deduzir que você deve suprimir. Por que? Veja a descrição do Campo 11 (CHV_CFE). Ele menciona o valor de Número de série do SAT como sendo tamanho 9 e significando "Número sequencial atribuído pela SEFAZ, iniciando em 000000001". Assim, os dois dígitos a mais, (talvez dígitos verificadores), não parecem estar inclusos.