Daniel Simoes

na verdade agora.. o modelo antigo, está instanciando a classe nova... a única diferença, é que no modelo antigo, havia busca por Endereço...

parece que vc mesmo já respondeu as suas perguntas... Vc já salva no BD.. nesse caso, cabe a sua aplicação, saber se a venda foi ou não enviada para o SAT, e cancelá-la se necessário...

nesse caso informe o passo a passo de como reproduzir o problema...

Pense bem... se você não conseguir controlar isso... o próprio operador poderá fraudar o lojista, quando quiser... basta ele derrubar o sistema e pegar o dinheiro recebido Você precisa gravar a venda, conforme ela vai ocorrendo...

Modificações recentes, aplicadas na classe "TDFeSSL" permitem gerar o código do SAT, com OpenSSL (A1) ou MS CryptoAPI (A1/A3)

Faça testes como o Demo do ACBrNFe... compare os fontes do Demo com os seus...

Somente se o seu sistema permitir isso... ou seja, vc teria que ser corresponsável pela sonegação do lojista...

Notei que o objeto de Inutilização não traduz de UTF8 para a String nativa da IDE... por isso o Delphi tem problema... (ele usa UNICODE e não UTF8) Tente assim: Uses ACBrUtil; .... XMLStr := DecodeToString(XMLInu, True); // Converte de UTF8 para a String nativa da IDE // NFe.InutNFe.LerXMLFromString(XMLStr);

parece haver erros no seu XML...

Nesse caso vc não está usando o ACBrMonitorPLUS, correto ?

Repare que já existe uma pasta "Testes", com vários teste cases para DUNIT e FPCUnit

Erro na abertura de Porta é uma mensagem que vem da DLL, e não do ACBr Primeiro faça o SAT funcionar com os aplicativos fornecidos pelo fabricante... Depois veja quais DLLs esse SAT usa, e copie-as para a pasta do .EXE

Qual é o comando que você envia ? (ENT.TXT)

Estude o demo do ACBrMail...

Anexe os XMLs com problema..

Mas isso é o correto ? Dependerá do usuário uma nova conexão ?

Você precisa configurar isso no Driver de Spool da Impressora... Cada fabricante tem uma maneira... geralmente isso é corrigido, criando um novo tipo de folha, com o tamanho bem superior ao A4... Sugiro entrar em contato com o suporte do fabricante

O projeto é escrito em Lazarus... você terá que convertê-lo para Delphi ou usar o Lazarus

Não temos relatos de bug semelhante ao seu... centenas de programadores usam a integração TXT sem problema algum... Ou seja, muito provavelmente não há nada de errado na rotina de leitura de TXT do ACBrMonitorPLUS... infelizmente não tenho como lhe ajudar... Uma alternativa é você usar a comunicação por TCP/IP

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.

Verifique se não é a falta das DLLs que o NFe depende... Veja esse tópico:

Já que o serviço antigo "morreu"... apliquei alguns ajustes para instanciar o novo modelo...

Analisando os fontes...achei o código bastante interessante, e muito bem implementado...parabéns Sou meio "avesso" ao uso de Interfaces... mas o uso me parece correto... Algumas observações: - Falta o cabeçalho do ACBr nos fontes - Falta chamar ACBr.inc no inicio dos fontes - Faltam diretivas de compilação para modo CONSOLE... não temos TTimer em modo CONSOLE... (veja como foi implementado em ACBrLCB.pas) - O método "SetModelo", parece errado, e pode causar MemoryLeak (ele não libera o modelo anterior) - Seria melhor ter um método para o disparo de Exceptions... algo como "DoException"... e dentro desse método, você pode chamar "FOnError", isso economizaria várias linhas de código... - Em "OnTimer", se ocorrer um Exception, o monitoramento irá parar... Isso é intencional ? - É mais indicado usar o nome do Protocolo do que do equipamento (TopTron)... (ou pelo menos o nome do Equipamento que foi o primeiro a introduzir este protocolo)

tirando a linha de gravação no Memo (que não parece fazer parte da sua aplicação)... o resto parece correto

Humm.. acho que uma possível causa, é a IDE não estar encontrando no Libpath DLLs que o ACBr depende... por favor leia esse tópico: