Daniel Simoes

não é recomendado.. pois você não saberia se um comando falhou... e não funcionará para comandos que aceitam uma String de "INI", com entrada... Pois esses comandos, leem todas as linhas do arquivo...

Isso é algo muito complexo... não vejo outra maneira a não ser, ler e estudar a documentação do SPED Fiscal http://sped.rfb.gov.br/pasta/show/1573 http://svn.code.sf.net/p/acbr/code/tools/SPED/

Isso é demonstrado no Projeto Demo do ACBrETQ... na pasta ACBr\Exemplos\ACBrSerial\ACBrETQ\Delphi

O ACBr possui componentes para geração do SPED, mas eles não estão presentes no ACBrMonitor ou ACBrLib... Porque não estão ? Porque não faria sentido, você gerar um TXT para o Monitor, que irá gerar o TXT do SPED... é mais simples você gerar o TXT do SPED diretamente..

Por favor sempre crie um novo topico... para um novo assunto

Notei que a DLL da Epson não está sendo usada... a comunicação está sendo feita diretamente pelo ACBr, na porta serial: Notei ainda que vocês estão "centralizando" a impressão (repare nos espaços, antes da palavra CAPPTA)... isso não é permitido.. precisa imprimir o comprovante TEF, exatamente como ele vem... -- 25/09 14:25:05:867 LinhaCupomVinculado( CAPPTA CARTOES[CR][LF] ) -- 25/09 14:25:05:874 TX -> [SOH][199][TAB][NUL]2[NUL] CAPPTA CARTOES [NUL]|[168] -- 25/09 14:25:05:895 RX <- [ACK] Creio que o real problema, seja alguma configuração no TEF da Cappta... veja esse tópico:

Todo XML de Documentos fiscais, deve ser em UTF8... esse é o padrão definido por eles...

Creio que seja uma característica desse equipamento... no Log aparece algum retorno de erro?

Tente isso: Uses ACBrUtil, synacode; ... StrFinal := UnZip(DecodeBase64(Base64Str));

Em analise....

É a sua opinião... todos tem direito de ter uma... Já eu, acho que tudo está convergindo para TEF... PIX, Serviços Bancários, etc.. e creio que o PDV sem integração com TEF, corre o risco de ser extinto... (pois ficará desconectado de vários serviços, ou não conseguirá acompanhar todas as integrações) TEF é um ótimo negócio para qualquer Sw.House... traz inúmeras inovações para o PDV, como por exemplo: Recebimento por Cartão de Crédito/Débito de todas as Bandeiras Recebimento de Contas (Boletos) Recarga de Celular Recebimento por TODAS as Carteira Digital (PicPay, PIX) Diversas outras integrações Controle e Provisionamento dos Recebíveis com cartão Apuração automática do Fechamento do Caixa dos pagamentos em Cartão (Sem TEF, o Lojista precisa contar manualmente os Tickes de Cartão) Você conhece algum outro Produto ou Serviço que traga tanta inovação para um PDV, com uma única integração ?? Tudo isso a a um custo muito baixo para o cliente Final... e com uma única e simples homologação... Veja no vídeo abaixo, que nós do ACBr, demoramos apenas 20 minutos para homologar o TEF PayGo Web Todo Lojista já gasta com "maquininha", e a Sw. House não participa disso, e ainda corre o risco de ver o seu sistema substituído, por uma Sw. House ligada a Adquirente... (Veja a Stone e Linx)... TEF traz a Sw. House para o controle dos meios de pagamentos em seus clientes... e traz uma receita considerável que até então ela não tinha...

Esse vídeo aqui, tb é bem legal...

Se for começar agora, melhor ACBrLib a homologação do TEF IP (por TXT), é bem mais complexa que a homologação do PayGo Web não temos planos recentes...

não creio que temos um componente com essas características...

Essa balança tem interface ETH?

Sim mas qual a vantagem em não usar TEF ?? Se você vai pagar para algum intermediador para falar com PIX, eu acho que faz muito mais sentido, pagar para um intermediador (TEF)... que além de PIX, fala com Todas as Carteiras Digitais, e todos os Cartões de Crédito/Débito Ou seja, qual Sw. House tem tempo para integrar diretamente com, ITI, Mercado, PicPay, ou seja, com todas Carteiras Digitais existentes atualmente ?

Deixe todas as dependências, na mesma pasta de AcbrNfe32.dll

Voce poderia usar copy, para pegar Ano, Mes, Dia, etc... e EncodeDateTime para transformar em TDateTime

Na minha opinião... isso deixou de ser SMTP... o ACBrMail foi projetado para trabalhar com SMTP, e as formas de autenticação, previstas nele... Talvez fosse necessário criar um novo componente para acesso do GMail.. mas isso não está nos nossos planos... Minha sugestão é... abandone o SMTP do GMail e use outro serviço de SMTP

Eu não creio isso... a modificação não trará mais performance... Eu particularmente, não gosto de API que retornam tipos complexos, como uma estrutura... gosto de soluções, simples... e o que pode ser mais simples que uma área de memória, com uma String Null-terminated ? Esse é o padrão usado pela API do Windows, pelo OpenSSL, pela LibXML2, pelas DLLs de fabricantes de ECF e SAT, etc... ou seja.. é o padrão de mercado... Porque todos usam dessa maneira ? Porque é simples de compreender, e amplamente compatível...

Se funciona na aplicação Demo do ACBrPosPrinter, creio que então basta olhar com atenção as possíveis diferenças e implementar...

no momento não temos previsão de criar um Demo para o ACBrBPe

Você precisa ver no manual do Equipamento, se ele suporte impressão de QRCode, por EscPos.. e se suportar, qual é o protocolo dele, que dê compatibilidade com os disponibilizados no ACBr... Que modelo você configurou em ACBrPosPrinter ? Tentou como GPrinter ?

poucos usam a Lib diretamente... as Classes de alto nível, já abstraem as chamadas e a alocação de memória...