Daniel Simoes

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;

Notei que a aba "Impressão" do ACBrMonitorPlus, ainda não tem os parâmetros de configuração que permitiriam ativar o controle de Porta Vou implementar, e ficará disponível na próxima compilação do mesmo...

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 ?

A parte de ECF praticamente é a mesma da versão anterior... O NFe/NFCe foi totalmente refatorado... então é necessário testes extensivos.. O SAT é novo, tanto o componente ACBrSAT, quanto o suporte do SAT no Monitor... então também precisa de muitos testes... Se você já fez seus testes, e está satisfeito com os resultados, não vejo problema de por em produção...

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...

Será descontinuado... mas a longo prazo... o Trunk e o ACBrNFeMonitor deverão ficar congelados, e receber correções apenas se realmente muito necessárias É muito complicado implementar esse recurso no "trunk" e ACBrMonitor... e não faz muito sentido, já que o trunk2 já tem esse recurso...

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"

O Delphi não está conseguindo visualizar o mapeamento de portas do Windows... No Inicio da Unit ACBrDevice.pas, existe uma diretiva que liga o uso de "Stream", ao invés de AssignFile Tente Mudar: {$IFDEF FPC} {$DEFINE Use_Stream} {$ENDIF} Para: {$DEFINE Use_Stream}

Isso só será possível no e nos fontes do "Trunk2"... onde a impressão de EscPos ficou a cargo do novo componente TACBrPosPrinter, que por sua vez, tem uma propriedade "ControlePorta", ou seja... ele conecta na porta para imprimir e desconecta após terminar a impressão... Não sei se existe algum comando que permita desativar a Porta Serial, do DANFEEscPos, nessa versão do ACBrMonitor (acredito que não)

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:

Obrigado, pelos links... quando eu tiver um tempo, vou compatibilizar essas impressoras no ACBrPosPrinter

Compreendo... Já pensou em migrar a solução para SAT ou NFCe ? Isso te daria mais liberdade para gerar o cupom... Pois vc só monta o XML no final da venda....

Não há como resolver.. a não ser enviando para assistência técnica... O PinPad tem uma mecanismo de proteção, que detecta tentativas de abri-lo (TAMPERING PROOF)... E em algumas situações ele queima o chip de criptografia quando isso ocorre...

A mensagem do SAT é bastante clara ao dizer o que está errado:

O cliente sempre pode optar por outro fabricante... Em todos os anos que trabalho com automação, essa á a primeira vez, que alguém aponta isso como problema... Fiquei curioso, que tipo de negócio exige a impressão de mais de 300 itens por cupom ? Você pode contornar essa limitação, basta fechar o cupom, e abrir outro...

Interface e Especificação: https://www.softwareexpress.com.br/distri/aplicativos/clisitefwin32.zip