daniel.simoes

Ao que tudo indica, a intenção do Fisco é incluir o retaguarda na homologação... O fisco está atento ao esquema de "parcerias", onde uma empresa não homologada, usa um frente de caixa homologado.. sendo que o "elo" de ligação entre os dois sistemas a troca de arquivos (TXT, TCP/IP ou de outra maneira)... É comum este cenário: No Balcão, software de "retaguarda" que faz o que a Pré-Venda deveria fazer... Esse software grava um TXT para ser importado pelo PAF-ECF que está no caixa, sendo inserido como uma Pré-Venda e precessado... Quais os problemas dessa abordagem ? - O Fisco fica sem controle sobre a Pré-Venda (pois está na parte não homologada, e que por isso pode trata-la como bem entender) - O Retaguarda pode facilmente sonegar... (basta não gerar o TXT para o PAF-ECF) Então, hoje o fisco entende que PAF-ECF é a solução toda, composta de vários programas: Frente, Retaguarda, etc... A meu ver, o fisco quer que todo o controle "fiscal" seja feito por um programa homologado.... No futuro (próximo) o esquema de parcerias estará findado... para as Sw.Houses que não conseguirem homologar só restará fazer representação de algum programa...

Acredito que SIM... não há um requisito claro para isso, a não ser o texto na lei que fala que o PAF-ECF deve ser capaz de comandar todos as funções do Sw.Básico do ECF... Mas vamos pensar.... qual usuário vai querer um sistema que não permite cancelamento de cupom ?

O ACBr e ACBrMonitor são escritos em código aberto... você mesmo pode estudar os fontes e verificar isso... Veja a opção "ArredondamentoMFD" da aba ECF do ACBrMonitor

Qual a versão do ACBrMonitor ? Copie aqui trecho do TXT de envio... e LOG gerado pelo ACBrMonitor

Verifique com o Fabricante (ou no manual do ECF) se o mesmo, nessa versão, é capaz de fazer isso

Algumas das Novas fazem (no caso da Daruma... sim) ... mas vc precisa habilitar a propriedade ArredondaItemMFD

Por favor anexe aqui mesmo no forum, um ZIP com as Units... Assim que possível eu analiso e subo para o SVN... Muito obrigado pela iniciativa

Enviei uma correção para o SVN... por favor teste...

Acho que já identifiquei o problema.... estou enviando uma possível correção para o SVN

Acho que a alteração não está completamente correta... O Create dos ObjectLists deve usar True no parâmetro de criação: constructor TRegistro60M.Create; begin inherited Create; FRegs60A:=TRegistros60A.Create(True); FRegs60D:=TRegistros60D.Create(True); FRegs60I:=TRegistros60I.Create(True); end; [/code] Como True, os Objetos inseridos dentro desses ObjectLists serão destruídos quando ele o for... Ou seja.. com False, a chamada de: FreeAndNil(FRegs60D); não irá destruir os Objetos dentro de: FRegs60D

Isso parece ser um erro de codificação... o ACBrMonitorConsole nunca poderia fazer Uses dessa Unit (que exige um servidor de Janelas, ou seja, não console) Vou verificar... muitas vezes a própria IDE adiciona essas units por ela mesma...

Veja a cartilha do ECF: http://www.sweda.com.br/cartilha.aspx

O componente ACBrTEFD é compativel com o SiTEF apenas no modo CliSitef, ou seja, usando a DLL... Veja o Demo na pasta Exemplos\ACBrTEFD

Há algo estranho... Se o vc desabilitou o AutoFinalizarCupom, o Demo ACBrTEFD não irá fazer nada quando a transação do TEF for concluída... pois nesse caso cabe a você chamar o FinalizarCupom Segui os seus passos e o Demo para quando o GP termina e volta o foco para a aplicação... (pelo motivo que descrevi acima) Mesmo assim continuei e clique em "FinalizarCupom" (com o ECF ainda desligado) O programa tratou corretamente... enviando a pergunta e na sequencia o NCN Verifique se você possui a ultima versão dos fontes.. disponível no SVN

Apliquei uma possível correção para a Classe da Daruma... por favor atualize pelo SVN e teste...

Não existe um "atalho" desses... Todo programa deve ser ligado a um CNPJ e homologado individualmente...

isso é o correto... Se houver exception em: ACBrECF1.DadosReducaoZ o resto das linhas nunca será executado...

Use um Try Except e faça o tratamento do Erro (exception) levantado

Somente com o LOG do ECF poderiamos saber o que aconteceu exatamente... Sua alteração pode causar muitos efeitos colaterais, não posso aplica-la...

Atualmente o fonte está assim: Try DiaIni := copy( Texto.Strings[ 6 ], 1, 10 ); StrtoDate(DiaIni); Except DiaIni := copy( Texto.Strings[ 7 ], 1, 10 ); end; [/code] Isso está correto ? ou seria: [code] Try DiaIni := copy( Texto.Strings[ 6 ], 1, 10 ); StrtoDate(DiaIni); Except DiaIni := copy( Texto.Strings[ 8 ], 1, 10 ); end;

Allan, Finalmente tive um tempo para "comitar" suas modificações... desculpe-me pela demora, e muito obrigado...

Cada classe tem um código totalmente diferente... por isso o fato de funcionar em uma classe não é garantia de que funcionará em outra... somente Debugando

O tipo F é EAN 13, e portanto sempre exigirá 13 caracteres... Tente o tipo "2 of 5"

Se não houver Papel o ECF irá retornar um erro, e o ACBrMonitor irá responder: ERRO: Mensagem de Erro do ECF

O ECF não irá imprimir Redução Z se nada foi impresso no dia... (o dia não foi aberto) Já existe as funções ACBrECF.DadosReducaoZ e ACBrECF.DadosUltimaReducaoZ