Daniel Simoes

Se vocês pretendem usar o ACBr, como emissor, então faz todo sentido por a "mão na massa" e desenvolver uma rotina compatível com o formato usado pelo ACBr.... Caso contrário... faz mas sentido usar o Emissor...

Até onde eu sei, arquivo INI é um TXT... não vejo justificativa para lentidão

Apliquei um possível ajuste em ACBrMail... no SVN, rev: 15041

A nova proposta parece mais clara e acertada... porem fiquei na dúvida, em relação a essa modificação:

Parece tudo correto... obrigado pelo ajuste.. no SVN...

Enquanto não tivermos um layout de TXT, consolidado e bem documentado não iremos avaliar o caso... Use o formato INI do ACBr

Obrigado... já no SVN, commit: 15037

Verifique se na pasta do seu projeto, há fontes do ACBr...

Essa nota técnica traz layout atualizado do formato TXT suportado pelo emissor do SEFAZ?

Qual o link para a documentação do SEFAZ que descreva um layout de TXT compatível com a versão 4.0 ?

Eu lhe pergunto... existe alguma documentação oficial do SEFAZ ou Sebrae, sobre um TXT compatível com a 4.0 ?

A validação irá incomodar o usuário, com algo que pode ser tratado pela aplicação ( Trim() ) Talvez seja melhor alterar o componente ACBrMail para fazer o Trim no Setter do destinatário

Não há configuração... isso porque para o ACBrPosPrinter o Timeout não é algo importante... pois os comandos são apenas enviados a impressora, ou seja, não há leitura de resposta, como ocorre com o ECF

Verifique se não existem várias pastas com os fontes do ACBr em sua máquina... aparentemente ele está compilando um ACBrETQClass antigo... (sem esses novos tipos)... Isso também ocorreria, se você tivesse um BPL antigo em sua máquina... mas marcar a opção "Remover arquivos antigos", deveria resolver esse problema...

Não bastaria fazer um Trim(), após o usuário informar os dados ?

Prezados, vou fechar esse tópico... pois está difícil de compreender qual é exatamente o problema de que vocês estão falando... Em relação ao problema original desse tópico... Conforme detalhado, nessa última resposta... Há uma limitação da libXml2 que não é compatível com UNC... Por favor criem um novo tópico e relatem em detalhes e com evidências, cada um dos problemas...

Aparentemente você está manipulando o XML gerado pelo ACBrMonitorPLUS, antes de enviá-lo de volta para o mesmo, com o comando de envio para o SAT... Analisando o seu LOG, fica evidente as diferenças dos arquivos que o ACBrMonitorPLUS criou, com o comando: SAT.CriarCFe... e o conteúdo do que seria o mesmo XML, porém é enviado no SAT.EnviarDadosVenda.. veja a imagem e os arquivos em anexo: cfe2.xml cfe1.xml

Se você se refere a tag: <qrcode_error> ... ela é usada para definir qual o Nível de autocorreção, do QRCode que será impresso https://blog.qrstuff.com/2011/12/14/qr-code-error-correction

SetModelo(ppTexto) Isso fará todas as tags serem ignoradas.. tente ppEscPosEpson

Evite CAPICOM... ela já está a muito descontinuada... Qual é exatamente o comando que você está enviando, para o MonitorPLUS ? (anexe o Log do MonitorPLUS)

Obrigado... já no SVN, rev: 15030

Serve para "falar" com o Integrador Fiscal do CE https://www.djpdv.com.br/como-emitir-nfc-e-usando-o-integrador-fiscal/

Sim, já passei por esse problema (mas não lembro a marca do equipamento)... Foi devido a esse problema, que implementei essa verificação do número da sessão, pelo próprio componente ACBrSAT

O Log anexado, é do aparelho SAT... precisamos do log gerado pelo ACBrMonitorPLUS

Anexe o Log gerado pelo ACBrMonitorPLUS e comandos de Entrada que você está enviando...