Daniel Simoes

Que pena... Delphi/Lazarus sao ótimos para Backend baseados em fastcgi O ACBr apenas é compatível com ObjrctPascal A ACBrLib (dll) está em construção... mas ainda leva algum tempo

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Procure por ACBRMail...

Não há mais ACBrMonitor em Delphi.. Se você usa Delphi, não precisará do ACBrMonitorPLUS Por favor leia: https://www.projetoacbr.com.br/fontes/

Você poderia usar o ACBr no BackEnd... há vários desenvolvedores usando dessa maneira... Veja esse curso do @Régys Silveira https://wkconsultoria.com.br/treinamento/curso-nfc-e-com-delphi-e-acbr-no-mobile/

Estou verificando...

Se o SEFAZ recusou o documento.. então ele nunca existiu no SEFAZ...

Não compreendi a sugestão... você está convertendo o mesmo Tipo enumerado (lanNAO_CONECTADO) em Duas Strings diferentes ? function TACBrSATStatus.StrToStatusLan(var ok: boolean; const s: string ) : TACBrSATStatusLan; begin result := StrToEnumerado(ok, s, ['CONECTADO', 'NAO_CONECTADO', 'DESCONECTADO'], [lanCONECTADO, lanNAO_CONECTADO, lanNAO_CONECTADO]); end;

Na dúvida apague o ACBr.INC e baixe a versão original... O Acbr.inc afeta TODOS os fontes, então é necessário rodar novamente o ACBrInstall

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.

Enviei um ajuste para o SVN...

@Waldir Paim, fique confuso... essas duas propriedades não seriam a mesma coisa ? property CodigoInfoExtra: Integer read getCodigoInfoExtra write FCodigoInfoExtra; property CodigoReceita : Integer read getCodigoReceita write FCodigoReceita;

Notei que a nova Classe, TACBrTEFDQuatroS ... não tem nenhuma reescrita dos métodos da classe TACBrTEFDClassTXT ... e apenas redefine novos valores para os diretórios, arquivos e Executável do GP... Não seria mais simples usar uma das classes existentes e apenas ajustar essas propriedades ? Não compreendi a necessidade desses IFs (imagem abaixo)... não é bom ter IFs de um Tipo específico, da Classe mãe... isso fere a OOP, e poderia ser tratado com Polimorfismo, sobrescrevendo alguns métodos na classe TACBrTEFDQuatroS

Obrigado pela analise e correção... já enviei para o SVN...

Por favor anexe as Units modificas, para analise...

Experimente fazer um CleanUp + BuildAll

Veja esse post:

Obrigado pelo log... pelo que notei, o erro 140 não ocorreu mais do que duas vezes, por comando... vou subir para o SVN... Por favor considere apoiar nosso trabalho, contratando o SAC ACBr, ocasionalmente

Se possível, por favor me envie um novo Log, apenas para comprovarmos que a ideia deu certo...

Por favor teste com a Unit em anexo... ela irá tentar o mesmo comando, até 5 Falhas sinalizadas com o erro 140... ACBrECFEscECF.pas

Apenas alguns usuários conseguem efetuar o commit... Você precisaria compactar os fontes, organizando-os por pastas, e anexar nesse tópico, para analise de algum desenvolvedor com acesso ao commit

O ACBrECF não usa as DLLs da Daruma... A Daruma as vezes responde com erro 140, quando está efetuando alguma operação interna... e podemos reparar isso no seu Log... -- 04/04 09:27:47:412 Daruma Erro:140 - RX <- [SOH]J[FF][NUL][16][140][NUL][NUL][NUL][NUL][NUL][242] // ERRO 1 -- 04/04 09:27:47:612 Sincronismo TX -> [22] -- 04/04 09:27:47:613 Sincronismo RX <- [22][NUL] -- 04/04 09:27:47:613 Status TX -> [SOH][SOH][FF][NUL][STX][NUL]1|[188] -- 04/04 09:27:47:613 TX -> [SOH][SOH][FF][NUL][STX][NUL]1|[188] -- 04/04 09:27:47:614 RX <- [ACK] -- 04/04 09:27:47:614 Status TX -> [ENQ][NUL] -- 04/04 09:27:47:615 RX <- [WAK][16][SOH][NUL][NUL][NUL] (1) -- 04/04 09:27:47:665 Status TX -> [ENQ][NUL] -- 04/04 09:27:47:666 Resposta: SEQ:1 CMD:12 EXT:0 CAT:16 RET:[140][NUL][NUL][NUL] TBR:0 BRS:"" CHK:169 -- 04/04 09:27:47:666 RX <- [SOH][SOH][FF][NUL][16][140][NUL][NUL][NUL][NUL][NUL][169] // ERRO 2 -- 04/04 09:27:47:666 ----------------- ERRO ----------------- Erro retornado pela Impressora: DARUMA AUTOMAÇÃO Categoria: 16-Erro específico do Fabricante Motivo: 140-Relógio está travado ---------------------------------------- Nos fontes de ACBrECFEscECF.pas temos o seguinte bloco, para tratar essa situação em específico: if (not fsTentouSincronizar) and IsDaruma and (EscECFResposta.CAT = 16) and (EscECFResposta.RET.ECF = 140) then // 140-Relógio está travado begin GravaLog( ' Daruma Erro:140 - RX <- '+EscECFResposta.Resposta, True); Sleep(200); fsSincronizou := False; // Força a sincronização fsTentouSincronizar := True; // Evita loop infinito, no caso de ocorrer o mesmo erro Self.EnviaComando_ECF(); // Gera chamada recursiva exit; end; Mas parece que ele tenta fazer isso apenas uma vez... e esse ECF está ocorrendo no erro 140 mais vezes...

Estou verificando com os demais moderadores...

Não temos planos recentes de trabalhar nesse arquivo... mas se algum usuário desejar subir alguma contribuição dos fontes, podemos analisar...