Daniel Simoes

Nunca testei o SAT da Bematech... mas deve funcionar com um dos modelos satStdCall ou satCdecl... pois a assinatura dos métodos é padrão

Sobre o Erro do XML, isso ocorre porque as informações são Hardcoded, configure o tipo de empresa para: Regime Tributário: RTRegimeNormal Regime ISSQN: RTISSMicroempresa Ind.Rat.ISSQN: irSIM Infelizmente a IDE do Delphi se atrapalha com String e AnsiString... Remova os eventos: ACBrSAT1GetcodigoDeAtivacao e ACBrSAT1GetsignAC (mas antes copie o conteúdo dos mesmos para o bloco de notas) Crie novamente os eventos, usando o clique-duplo da IDE, sobre os eventos do componente ACBrSAT1 (observe que a IDE irá criar usando corretamente String ou AnsiString, conforme a versão)

Por favor leia: Bem_Vindo_ao_Trunk2.pdf

Ajustes as margens... Há vários tópicos sobre isso aqui no forum... Use a busca

Por favor descreva um passo a passo, de como reproduzir o problema... de preferencia usando aplicação de testes

As correções para a impressão da Bematech e Daruma no ACBrSATExtratoESCPOS estão apenas no "trunk2"

Você usa o GNRE ? Se não usar, remova-o da instalação....

Segundo a Espcificação Técnica do SAT, o Campo qCom permite no máximo 4 casas decimais (pag: 65) Deve ser algo errado na sua rotina... veja que no XML gerado pelo Demo SATTeste.exe, há uma Item com 4 casas decimais: <det nItem="2"> <prod> <cProd>6291041500213</cProd> <cEAN>6291041500213</cEAN> <xProd>Outro produto Qualquer, com a Descricao Grande</xProd> <CFOP>5529</CFOP> <uCom>un</uCom> <qCom>1.1205</qCom> <vUnCom>1.21</vUnCom> <indRegra>A</indRegra> <vOutro>2.00</vOutro> </prod>

A DLL da Dimep, depende da ZLIB.DLL... ela está presente na mesma pasta de dllsat.dll ? Tente por favor baixar novas DLLs no (confuso) site da DIMEP https://d-sat.4bee.com.br

Tentou com o já compilado com o "trunk2" ? Tente ainda a impressão de QRCode com o

Não compreendo a sua dificuldade... Acho que se você deveria estudar melhor os fontes do Demo...

Ok.. compreendido... você precisa configura corretamente as abas "Dados do SAT", "Emitente", "Dados Sw.House"... e salvar a configuração... Você mesmo compilou o Demo ou baixo do fórum ? Tente com a versão baixada do fórum

O método LoadFromFile sempre tentará ler do disco... Você pode usar a atribuição de uma String ao XML: ACBrSAT1.CFe.AsXMLString := SuaStringContedoOXML;

Isso mesmo... é uma linguagem "de linha" (comandos são ativos por linha)... A título de curiosidade, também existem equipamentos com suporte a linguagens "de página", como as impressoras de Etiqueta (PPLA, PPLB, ZPL), onde a página toda é montada em memória e depois de terminada, um comando de impressão envia toda a página para o equipamento... O EscPos é um padrão bem estabelecido, e vários equipamentos suportam o mesmo... É o caso das Impressoras DASCOM, que são 100% compatíveis com EscPos Alguns fabricantes, porém, estenderam o padrão, criando comandos novos... ou não seguem 100% o padrão para certos comandos mais novos (como a Impressão de QRCode, por exemplo)... É o caso das impressoras da Daruma e Bematech... Nota: Alguns posts aqui do fórum, afirmam que as impressoras da Daruma possuem uma configuração que permite configurá-las para 100% de compatibilidade com o padrão EscPos Quais as vantagens de usar o EscPos ? - Facilidade de uso: "Não precisa do Driver instalado no Windows" - Rapidez: "Poucos dados são transmitidos para impressora" - Qualidade: "A impressora usa fontes nativas, e ela mesmo desenha os Cod.Barras"

parece ser um Bug do projeto... experimente editar o arquivo .INI e digitar lá a porta... deve funcionar... Tente ainda com o

Já testou com o Demo ETQTeste.exe ? Pode ser que você precise efetuar um Reset na sua Impressora, para ele reconhecer o "gap" entre as etiquetas corretamente

Por favor forneça mais detalhes... Pois o ACBrECF não usa a DLL dos fabricantes, para emitir Redução Z... pode ser algo do seu sistema Porém pela mensagem de erro que você postou.. tudo indica que a sua DLL do fabricante está desatualizada...

Você precisará ajustar os seus fontes... No trunk2, algumas propriedades mudaram de nome ou foram extintas... Alguns métodos mudaram de Unit ou classe.. O ajuste não é difícil... mas o trunk2 não é 100% compatível com o trunk... De maneira que você deve fazer a migração com calma, e manter um ambiente de compilação com o trunk em paralelo... (faça um "branche" dos seus projetos) Leia o documento: "Bem Vindo ao Trunk2.pdf"

Lógico que o XML tem conteúdo... basta ver o conteúdo do memo... veja no componente qual é a pasta que o mesmo está configurado para salvar os XMLs gerados...

O XML é o mesmo, mas é claro que há diferenças no preenchimento... Na NFCe, em alguns estados, também é permitida a contingência "Off-line"

isso é o que a legislação determina, veja na Especificação Técnica do SAT, pag: 66

Sim, é isso mesmo... atendendo a pedidos, os componentes foram organizados em Paletas, que são na verdade, a mesma representação dos Packages (ACBrSerial, ACBrTCP, etc..)

O trunk2 não é 100% compatível com o Trunk... Isso é proposital.. Há um PDF (em construção) que cita algumas das diferenças e como ajustar o seu projeto... O fato é... o Trunk tem a tendência é ser congelado e todas as novas melhorias serão aplicadas apenas no trunk2

O TACBrEscPosPrinter NÃO será disponibilizado no trunk... A equipe do ACBr está trabalhando para terminar a compatibilidade do trunk2 com o Delphi... em Lazarus eu já uso em produção a meses.. Dependendo dos componentes que você precisa, o trunk2 já pode ser usado sem problemas...

Realmente havia um bug em FechaCupomVirtual... que tratava todos os documentos que chegavam até ele como "Venda"... Já apliquei no SVN trunk2, uma possível correção para o problema...