EMBarbosa

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.

Por favor, anexe a unit alterada.

Tentou o manual da gaveta? Contato do fabricante?

Que problema?

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.

Você pode procurar no fórum e analisar o código no branches. Se desejar compartilhar alguma atualização, anexe aqui no fórum informando o que foi alterado.

Basicamente é assim: Se você vai usar herança, então não precisa copiar as units. Se você vai criar um componente diferente onde os métodos precisarão ser alterados então você faz cópia dos arquivos.

Agora sim uma pista. Eu não sei se entendi direito, mas talvez seja algum problema no isolamento dos privilégios do SO.

De forma educada, pergunte a ele de o porquê de ele pensar ser necessário fazer esse tipo de teste. Tente descobrir de onde ele tirou isso...

Não. Os projetos ACBrMonitor e ACBrNFeMonitor é que serão unificados no ACBrMonitorPlus.

https://github.com/mantisbt-plugins/source-integration