Daniel Simoes

Marcelo me desculpe... Realmente está uma correria aqui com a chegada da AUTOCOM Deixei este e vários outros tópicos no meu "Favoritos", e pretendo analisa-los ainda esta semana

Esses ECFs são bem diferentes dos ECFs comuns... Comandos comuns como por exemplo a Venda de Item possuem parâmetros diferenciados... O ACBrECF não é compatível com eles... Acredito que eles tenham saído do mercado... foi mais uma péssima ideia do fisco que só atrapalhou...

Muito interessante essa lei... Acaba com a informatização informal... Onde o cliente só quer "um programinha, com uma impressorinha, etc" Desse jeito a concorrência fica mais justa... e a pressão dos clientes, para nós programadores, darmos um jeito para o "caixa 2", diminui... Eu, a tempos, já adotei a política de evitar clientes com esse perfil... só dão dor de cabeça, e o que eu ganharia com eles não paga um advogado para me livrar de um processo por sonegação fiscal... ( tô fora )

Ferinha.Master, Como o André já comentou, hoje em dia isso já é tratado nos fontes doACBrECF quando associado a um componente ACBrAAC... Portanto, verifique nos fontes do ACBrECF a implementação de VendeItem

Sim, o gráfico de dependências é esse mesmo que o Elton traçou... Essa DLL é utilizada para a assinatura digital (EAD) Já tenho planos de corrigir a dependência estática dessa DLL, mas por enquanto é necessário copia-la na mesma pasta do executável.

Você leu com atenção o post inicial ?? A resposta a sua pergunta está escrita nele...

Ainda não existe um SAT oficial, e se implementado, dependerá de cada UF.... o projeto foi idealizado pelo fisco de SP, e outros estados já mostraram interesse.. Acho que o SAT não chega antes de 2012 Quando o SAT vier, não haverá mais a necessidade de homologação PAF-ECF... pois assim como na NFe, ele mesmo cuida de toda a segurança da emissão e autenticação do documento fiscal... Mas... pode ser que os legisladores criem uma lei PAF-SAT, com novas regras para homologação.

Seu Madruga, Este "problema" é bem simples de resolver... Você mesmo pode criar um outro Forum, ou talvez até mesmo um "fork" do projeto ACBr... Após isso, você mesmo, e com a ajuda de alguns amigos, passam a prestar suporte gratuito e voluntário a todos os usuários... além de manter a qualidade dos commits... A licença do ACBr permite isso, portanto fique a vontade...

Não existe tal conceito... Você simplesmente tenta escrever no Socket, e trata a exceção em caso de falha... Veja esse link: http://www.ararat.cz/synapse/doku.php/p ... connection

Não... sempre a emulação será necessária... USB não possui um protocolo único (ou simples) de comunicação, por isso equipamentos USB são altamente dependentes do driver do próprio fabricante... Seria um caos ter que programar para cada equipamento distinto... A emulação de Serial nesses casos é uma saída "elegante"... Pois permite a alta velocidade da USB, aliada a facilidade de programação da Porta Serial... outro fato muito importante é compatibilidade legada, com sistemas antigos... Também fica mais simples suportar vários S.O. Mesmo equipamentos novos como será o caso do S.A.T. (ou Cupom Fiscal Eletrônico) trabalharão desta maneira... ou seja, cabo USB mas com emulação de uma porta serial Mais informações sobre programação USB: http://www.rogercom.com/ http://www.libusb.org/

Para Local, use o mesmo procedimento... Exemplo: Supondo que vc tenha instalado uma impressora ARGOX USB, e compartilhado a mesma como "ARGOX" no Windows.... para imprimir na mesma máquina faça: \\localhost\@ARGOX

A ideia do TEFD foi justamente esta... ele parece ser o único componente existente para TEF que comporta simultaneamente Multiplos GPs... Cada classe utilizada é instanciada na criação, do componente... Ou seja, SIM, vc poderia usar TEF_DIAL e TEF_HIPER na mesma transação... (mas isso nunca será testado pelas homologadoras)

Funciona, mas depende do ECF... Fizeste uma busca no Forum antes de postar ? Veja: viewtopic.php?f=10&t=2020 viewtopic.php?f=10&t=1880&hilit=ecf+usb viewtopic.php?f=10&t=1002&hilit=ecf+usb

Provavelmente é algum problema na maneira que vc está alimentando o componente... copie aqui um trecho de código... (observe como é feito nos fontes do Demo do ACBrSintegra)

Vários desenvolvedores do ACBr usam D2006 ou superior, de maneira que não creio que o problema seja nos fontes do ACBr...

Obrigado Elton... Nós deparamos com esse erro na nossa homologação, e corrigimos na "alimentação" do componente... mas desse jeito fica bem melhor

não há esse limite... eu mesmo uso a minha própria chave Privada... mas a criptografia do AAC não exige uma chave privada RSA... vc pode passar qq String, de qq tamanho... Exemplo: Chave := 'SUA CHAVE' + #34 + #12 + #76 + #255 + #24 (Repare que os códigos em ASC é uma maneira de dificultar a ação dos Crackers que poderia descobrir a sua chave usando programas como por exemplo HackerResource)

Leia com atenção as instruções de instalação no arquivo LEIA-ME.TXT (na raiz da pasta) (provavelmente vc não adicionou os Paths ao LibPath do Delphi)

Por favor seja mais específico... Qual componente ? Qual Arquivo ? Qual Registro ? Acabei de homologar PAF-ECF usando os componentes ACBrPAF, ACBrSPED e ACBrSintegra... não notei nada de errado no layout gerado

parece ser um problema com a DLL do OpenSSL... Use a libeay32.dll que está na pasta ACBr\DLLs\OpenSSL (copie-a para a mesma pasta do seu .EXE)

Para ECFs Elgin com MFD usa o protocolo ecfFiscNET

Por favor atualize os fontes e tente novamente... enviei uma possível correção na Rev.2377

Onde vc achou o link para download ? No meu (antigo) ainda consta a 3.0 http://www.softwareexpress.com.br/ArqCl ... efdial.htm

O SoftwareExpress que é a desenvolvedora do "amado" G.P.... então a versão dela deve ser a mais atual...

A nova versão do ACBrMonitor já instala os logos dos bancos em uma sub-pasta... de maneira que não é necessário fazer nada de especial... O logotipo é encontrado de acordo com o número do Banco