Daniel Simoes

O modelo "ecfSweda" deve ser usado apenas com Matriciais.

Esses ECFs não foram descontinuados ?

O ACBrBAL não utiliza DLLs... Tente a comunicação com este modelo utilizando os modelos Filizola ou Toledo.

Depende da sua finalidade. Qual arquivo vc irá gerar com ele ? Sintegra, SPED ? Ou seja, salve o que vc for precisar no futuro.

Acho que a confusão toda é porque existem 2 units com verificação de I.E. A oficial é a do ACBrValidador, mas o componente do SPED usa suas próprias funções... Acho que isso precisa ser revisto e corrigido para usar apenas 1 rotina

Por favor poste um "passo-a-passo" de como reproduzir o problema usando o Demo do ACBr, assim como a configuração que você esta utilizando

Sim, pois o ACBrBarcode é um Image... Mas resta saber se a sua versão do Delphi suporta JPG

Apenas os ECFs mais novos voltaram com a opção de Arredondamento (porém agora é por Item) Nos MFDs antigos não é possível, pois a legislação da época não permitia... Entre em contato com o Fabricante para saber quais modelos suportam ou não o arredondamento

O titulo do Post está errado... o ACBrTEF foi excluido e não o ACBrECF... Instale o Package ACBrSerial

Talvez este Link lhe ajude: http://www.vivaolinux.com.br/artigo/Sis ... parte-1%29

Decimal

- Tente comunicação com o programa da própria Bematech... (isso irá testar a porta Serial, se funcionar é alguma configuração no ACBrECF) - Tente com outro ECF na mesma porta... (isso irá garantir que a Porta está OK)

Falha minha... por favor perdoem-me.. Por favor atualizem pelo SVN e testem novamente...

Talvez com uma chave maior gere mais diferenças... mas não espere grandes resultados... No caso de senhas, é comum gravar apenas o Hash da senha, e nao a senha em si.. nem mesmo a senha criptografada... Assim quando o usuário digitar a senha dele, vc re-computa o hash e compara com o do Banco de dados...

A função StrCript irá gerar caracteres de toda faixa da tabela ASCII, ou seja #0, a #255... alguns desses caracteres não podem ser gravados em arquivos, Exemplo: #26 ou Ctrl-Z fecha um arquivo TXT... Para resolver isso existem funções nessa mesma Unit que convertem um AnsiString para Hexa e vice-versa... function BinaryStringToString(const AString: AnsiString): AnsiString; function StringToBinaryString(const AString: AnsiString): AnsiString; a função writebinarystream faz algo semelhante

Não há como computar a string a partir do número... (isso invalidaria a segurança) veja a função StrCrypt na mesma Unit

Ela calcula um HASH ou CRC ou ainda um número verificador se uma determinada string. O crc16 é fraco em segurança comparado com MD5, más é rápido e fácil de calcular.

Tente um teste de Velocidade com o DEmo ECFTeste... Poste aqui os resultados do LOG e do Memo...

Por favor poste um "passo a passo" com quais operações necessárias para reproduzir o erro no Demo do ACBrTEFD, assim também como você está configurando-o

Observe que o evento OnBobinaAdicionaLinhas lhe envia uma String com a "Operação" ... você pode comandar um "exit" no evento se for uma Operação que você não deseje exibir na tela...

Após conversar com o autor do RecuperarXML, André Moraes, cheguei a seguinte conclusão. O projeto deve ser descontinuado, até termos uma maneira oficial e legal de fazer tal operação... Esta mudança no site da Receita Federal deixou bem claro, para nós do ACBr, que programas como o RecuperarXML não são desejados ou aceitos... Não queremos sujeitar o Projeto ACBr a ser alvo de investigações ou notificações por parte da Receita Federal. Os fontes do projeto serão movidos para a pasta TAG de nosso SVN... Ou seja, assim como todos os fontes da TAG, ele ficará "congelado" e não deve mais receber atualizações ou correções. https://acbr.svn.sourceforge.net/svnroo ... uperarXML/

Se houve Exception quando você enviou o comando ao ACBrECF... qualquer exception que seja, o erro é dessa chamada... não compreendo a dificuldade em tratar isso dentro de um bloco Try/Except A correção proposta é boa... e deve ser aplicada (agradecemos se puder ajudar)... o que quero dizer é que do jeito que está, é perfeitamente possível trabalhar...

Mas com certeza todos os erros de Sem papel serão deste tipo... Alias, não precisa nem verificar o tipo da Exceção afinal, quantos erros vem com a String "PAPEL" neles ??

Realmente o ACBrECF precisará de uma classe de Exceção específica para o Erro sem Papel... Em quanto isso não existe... use o evento de Application.OnException e verifique se o erro é do tipo básico de exceptions gerado pelo ACBrECF, e se na mensagem do Erro existe a palavra "PAPEL"... Exemplo: if (E is EACBrECFError) and (pos('PAPEL', UpperCase(E.Message) ) > 0) then ShowMessage(' ECF SEM PAPEL'); [/code]

Oi Bruno obrigado pela resposta... Nós do ACBr temos muito interesse em desenvolver um componente para o SAT... Sei que o protocolo será padronizado, o que simplifica muito... Se houver interesse e um protótipo disponível, já poderíamos iniciar os trabalhos... Em relação a adoção, vale lembrar que o SAT é um projeto do fisco de SP... Que além de desenvolver toda a do SAT, também está desenvolvendo uma enorme infraestrutura de Servidores e webservices para que o SAT possa entrar em operação... Acho que é seguro dizer que o SAT é incompatível com PAF-ECF. Ou seja, o estado que adotou PAF-ECF, dificilmente adotará o SAT em curto ou médio prazo... E os estados que aderirem ao SAT (como SP) provavelmente nunca adotaram o PAF-ECF...