Daniel Simoes

Pelo que li agora pouco na Especificação do SAT, ele é aceito sim... O que mudou foi apenas a regra de tamanho mínimo máximo que agora é 11 em ambos

Já analisou os fontes da pasta Exemplos ?

Por favor seja mais objetivo, no relato do problema em si... Qual é o passo a passo, para reproduzir o problema no ECFTeste ??

Não é necessário ou não é aceito ??

O MonitorPLUS não é compilado em 64 bits... você deve usar DLLs 32 bits

SIM... basta configurar o MonitorPLUS, para usar a DLL da Bematech, conforme as instruções do fabricante

Antes não era HTTPS

Seus fontes estão atualizados ? Lembro que foi enviado ajuste para o SVN referente a esse assunto

Você removeu a instalação anterior ? ( inclusive apagando a pasta C:\SAT )

Se você compila em 64 bits então precisa das DLLs de 64 bits do OpenSSL

Isso porque o ECF realmente ainda permite vendas... Se o ECF não mais permitir, ele estará em estPagamento Isso varia por ECF... alguns equipamentos não fazem nada, quando ocorre um comando de Subtotalização, sem Desconto ou Acréscimo

Humm.. bem lembrado... o ACBr usa a Synapse, que usará o OpenSSL para conexão segura... isso ocorre pois o endereço foi modificado para HTTPS O tópico abaixo, explica mais sobre isso...

Eu acredito que SIM.. pois isso já acorreu comigo (certificado inicial vencido) e os SATs continuam em operação...

Se não me engano, isso já foi alterado pelo Juliomar, no inicio dessa semana...

Desculpe.... mas esse IF não parece fazer sentido... if ConteudoINI.Text <> '' then ConteudoINI.Text := ConteudoINI.Text Você já está usando os eventos "QuandoLerArqINI" e "QuandoGravarArqINI" ?

Provavelmente o ACBrPosPrinter, nesse modelo, não suporta esse recurso... Verifique com o fabricante, se o Hardware suporta a impressão de CodeBar128C de 44 caracteres da chave, em apenas uma linha... Se SIM, qual é o comando em EscPos para implementá-lo

Altere o fonte que gera o Texto a ser impresso...

Veja... vamos pela lógica... se funciona uma vez... então o componente está correto... e nada precisa ser modificado nele... Se está intermitente, o problema só pode estar no Servidor da SEFAZ... Não há o que corrigir/modificar do lado do componente...

O problema parece ser no ECF... O ACBrECF está agindo de acordo com o protocolo EscEcf... Ele pergunta o Status ao ECF, e o mesmo retorna WAK (ocupado)... -- 15/06 19:56:39:237 Status TX -> [ENQ][NUL] -- 15/06 19:56:39:238 RX <- [WAK][16][ETX][NUL][NUL][NUL] (566) -- 15/06 19:56:39:289 Status TX -> [ENQ][NUL] -- 15/06 19:56:39:290 RX <- [WAK][16][ETX][NUL][NUL][NUL] (567) -- 15/06 19:56:39:341 Status TX -> [ENQ][NUL] -- 15/06 19:56:39:347 RX <- [WAK][16][ETX][NUL][NUL][NUL] (568) Ou seja, o loop está no Sw.Básico do ECF... entre em contato comm o Fábricante...

provavelmente esse programa está usando uma DLL diferente da sua.... O fato é... O ACBrSAT NUNCA fala com a porta do SAT... então não há como o problema ser nosso...

O componente NUNCA fala direto com o SAT... mas sim com a DLL do fabricante... esse erro indica que a DLL do fabricante não encontrou o SAT Ou seja, você DEVE procurar o suporte do fabricante

Acho que todos os equipamentos de Automação Brasileiros, usam arredondamento conforme a ABNT

Se o SAT Dimep processa e o outro não... então está evidente que o problema é no SAT... Já tentou enviar para o emulador do SEFAZ ? Com isso você terá subsídios para escrever um email ao suporte do fabricante, provando que em outros equipamentos o XML é aceito

Se deseja propor melhorias para os fontes, favor anexar as units modificadas para analise...

Tente com o Demo do ACBrPosPrinter.. use o modelo ppEscBematech