Daniel Simoes

Se você já usa o ACBrInstall.. DEVE continuar a instalação por ele... Pois o Delphi usa um diretórios diferente para a saída de compilação de Packages,

Marque todos que você quer, caso contrário o ACBrInstall irá remover os que não estiverem selecionados

Humm.. na verdade precisa de informações da Venda original... portanto: ACBrSAT1.CFeCanc.LoadFromFile('CFe9999999-can.xml'); ACBrSAT1.CFe.LoadFromFile('CFe9999999.xml'); ACBrSAT1.ImprimirExtratoCancelamento;

Verifique se no seu projeto, vc fez uso da Unit Interfaces Program SeuPrograma; {$mode objfpc}{$H+} Uses {$IFDEF UNIX} CThreads, {$ENDIF} Interfaces,

Isso já havia sido corrigido no SVN, favor atualizar os seus fontes

Tente ativar com o

o SAT não tem qualquer vinculo com o TEF... Você deve fazer a homologação de TEF para impressoras não fiscais

Feito.. já está no SVN

OK... mas isso não responde a pergunta que estou fazendo: O mesmo problema ocorre no ECFTeste ? Se SIM, qual o passo a passo ?

Essas Units não parecem ser do ACBr... Acho que os erros estão relacionados a configuração do seu projeto...

Hehe.. tipico... Acredito que a sua ideia está correta.. com as informações da massa de teste, outras informações, podemos fazer alguns testes e chegar numa conclusão por eliminação...

O mesmo problema ocorre no ECFTeste ? Se SIM, qual o passo a passo ?

Não são caracteres especiais, são UTF8.. Use a página de código do ACBrSAT em UTF8

ACBrSAT1.CFeCanc.LoadFromFile( SeuXMLDeCancelamento ); ACBrSAT1.ImprimirExtratoCancelamento;

Poderíamos criar um evento OnGetNumeroSessao, que se for atribuído, deixa a cargo da aplicação gerar a numeração... No entanto, você pode obter o Numero da Sessão gerado, quando ler a resposta: ACBrSAT1.Resposta.numeroSessao; Isso não seria o suficiente para o seu controle ?

Você está equivocado.. o ACBr é compatível com todas as versões do Delphi 7 ao XE8, além do Lazarus/FPC. Problemas pontuais, ocorrem de dependências externas, como no caso citado do post original, onde é citado que o problema são nos geradores de relatórios... Além do mais... o projeto ACBr é código aberto... Se algo não funciona para você... porque você mesmo não tenta corrigir e contribuir com a comunidade, ao invés de simplesmente ficar aguardando que alguém corrija para você ?

Sim, é isso mesmo... dá um trabalho do cão... Os fontes do ACBrECF, já passaram por essa revisão... mas acredito que os fontes do ACBrNFe, do trunk... ainda não... Lembro de ter feito vários ajustes de NOGUI, quando fiz o Refactoring do ACBrNFe para o "trunk2" Talvez se você migrar para o "trunk2", seja mais simples...

Realmente parece um bug causado por excesso de "Ctrl-C, Ctrl-V"... Apliquei a correção no SNV, obrigado...

O mesmo problema ocorre no ECFTeste ? Se SIM, qual o passo a passo ? Noto que não há erro de comunicação no seu Log, mas aparentemente, o seu sistema está entrando em Loop, talvez porque não obteve a resposta correta para alguma informação, que tentou ler do ECF... Para debugarmos, é necessário que sejamos capaz de reproduzir o problema em ambiente de testes

Enviei algumas correções ontem a noite... para correta compilação de ACBrUtil.pas no XE O Regys está trabalhando em uma nova versão do ACBrInstall, para o "trunk2" O Isaque está compatibilizando a versão antoga, para funcionar no "trunk2"

Quando você remove as dependências de Package do Projeto.. a IDE não tem como resolvê-las para você... Nesse caso, o erro indica que o seu projeto deve ter uma dependência do Package (do Lazarus) LazUtils

Você pode configurar o seu projeto, para forçar o ACBr a ser compilado em modo CONSOLE (veja o exemplo das opções de projeto, do ACBrMonitorConsole) - Remova do seu projeto, as dependências de todos os Packages do ACBr (pois eles foram compilados com a dependência da LCL) - Em "Additions and Override", crie a macro para toda a IDE -> LCLWidgetType:=nogui - Em "Other" adicione: -dNOGUI -dUseCThreads - Em "Paths, Other unit Files": Adicione os paths dos fontes dos projeto ACBr, de todos os componentes utilizados - Em "Paths, Include Files", adicone o diretório do ACBrComum (por causa do ACBr.inc) Com isso, todos os fontes do ACBr, serão recompilados em modo NOGUI (console)... Pode ser que nem todos os componentes, estejam com os IFDEFs preparados para compilar corretamente em modo "NOGUI"

Não noto esse problema usando o emulador da Sweda... a comunicação Serial usando um par de portas Seriais Virtuais, entre o ACBrECF e o ConnectSIM, é muito, muito, rápida... Por favor anexe o Log gerado para a analise

Também há um cadastro para as Sw.Houses

não há manual ainda, a melhor maneira de aprender, é lendo com atenção os fontes do projeto Exemplo, SATTeste.... Sobre a Página de Código: Veja esse post: