OFF-DEV

Acho que peguei, vou dar um exemplo: Usei o comando CriarEnviarCFe: ele retornou: [ENVIO] Arquivo=C:\OFFMON\sat\Vendas\08723218000186\201912\AD35191208723218000186599000092610073614188846.xml CodigoDeRetorno=6000 NumeroSessao=858175 Resultado=858175|06000|0000|Emitido com sucesso... Comparo os valores em destaque vermelho, se eles forem iguais, sinal que o SAT processou corretamente e me devolveu o retorno correto (não preciso usar SAT.ConsultarNumeroSessao) . Se o resultado for diferente, uso o comando SAT.ConsultarNumeroSessao(858175) e aguardo o retorno. Se o comando não identificar a seção, eu descarto a operação e tento enviar o CFSAT novamente. Isso mesmo?

Prezados, Estou com uma dúvida aqui sobre o comando SAT.ConsultarNumeroSessao, estou implementando uma compatibilidade com meu appcomercial usando TCP/IP e C# e gostaria de entender em quais circunstâncias eu deveria usar o referido comando? O manual diz : "Comando para efetuar a consulta pelo numero da sessão.". `Testando o comando percebo que recupero dados do cupom emitido por último somente. Abraços Leandro

Seria a expansão tipográfica do destinatário da venda, um modo BOLD para o texto que ali sai. Foto em anexo vide a seta.

OK, fico no aguardo então.

OK, isso eu poderia fazer por aqui ou seria necessário aguardar uma nova versão do acbrmonitor?

A impressão está funcionando, o problema é o bug da restrição de tamanho do xNome quando uso a tag <e> para expandir o nome na impressão do CFSAT.. Se modificasse, teríamos que pensar em como seria passado o comando para expandir o nome do cliente no CFSAT ....

Acho que Entendi, o único meio de persistência da informação é o XML, para validar no SEFAZ, para imprimir, etc. Se eu não posso usar no xNome, então poderia usar em outro lugar?

Então, eu não entendo bem como é a arquitetura do ACBRMonitor, mas vou relatar como ACHO que funciona, posso estar errado, vou colocar em passos aqui, me corrijam por favor em caso de erro: PASSO 1 - o arquivo .INI e a tag xNome (montado pela minha app) é lida pelo ACBRMonitor PASSO 2- o ACBR repassa a informação diretamente para o webservice do SEFAZ. PASSO 3- Aprovado, o ACBR monta o XML baseado nos dados do webservice e devolve para a minha aplicação a resposta PASSO 4- O ACBR recebe comando da minha app para imprimir na impressora com as tags expandidas passadas anteriormente no xNome Ideia: Levando em conta estes passos, porque o ACBRMonitor não trima ou remove as tags <e> e </e> apenas no PASSO 2 antes de enviar ao webservice do SEFAZ e no passo 3 ao montar o XML?

Mas não é melhor simplesmente remover as tags antes do envio ao fisco e deixar só na impressão? O Sefaz não precisa receber nada com <e> ou </e>, nem tem sentido ir isso para lá.

Pego diretamente do ACBrSAT. Na verdade o Fisco processa corretamente com as Tags desde que eu diminua a quantidade de caracteres do xNome. Parece que cada tag está ocupando mais de 3 ou 4 caracteres, retornando o erro de limite de caracteres atingido. Por isso que quando eu corto para 41 caracteres, o fisco aceita sem problemas com as Tags.

Anexado. AD41191182373077000171599000089280010184883249.xml

Segue o XML, as tags aparecem no XML tbem. <?xml version="1.0" encoding="UTF-8"?> -<CFe> -<infCFe versaoSB="020100" versaoDadosEnt="0.07" versao="0.07" Id="CFe41191182373077000171599000089280010184883249"> -<ide> <cUF>41</cUF> <cNF>488324</cNF> <mod>59</mod> <nserieSAT>900008928</nserieSAT> <nCFe>001018</nCFe> <dEmi>20191125</dEmi> <hEmi>094708</hEmi> <cDV>9</cDV> <tpAmb>2</tpAmb> <CNPJ>16716114000172</CNPJ> <signAC>SGR-SAT SISTEMA DE GESTAO E RETAGUARDA DO SAT</signAC> <assinaturaQRCODE>XKYlLXuc7SlJ3fuhEk07NS5qxNYSHPLb4bbA4TuXTWaPoQ0CbBpLz9dECtjN8G1KZlXv3cii7ks2vbyDsR/9SJozvAzKYgKaTORfQd4avl8mBfAOSm5gjZC4y3Mpc0T01AtobMoJDlgivKBsJwCOyGBmSJhJB+sH5sZHWewevy1sDmx+IfF5VeEoeU/Jid76tMysCER6o9dj+ed08ZlN0lqOJONBQQg83myoPzBTbAYOoDIsLzDl8Q1BqJ+YklpHy7NNX2w4f1YwIiACYvwB6/Pxg3IQmNmjtt7yohD5oo7Xg37IvuGXPMJCbevqxDWdyqruhs7yIWNaDSWjnma8Cg==</assinaturaQRCODE> <numeroCaixa>001</numeroCaixa> </ide> -<emit> <CNPJ>82373077000171</CNPJ> <xNome>BEMATECH S.A</xNome> -<enderEmit> <xLgr>AVENIDA RUI BARBOSA</xLgr> <nro>2529</nro> <xCpl>: MODULOS 06 07 E 08;</xCpl> <xBairro>IPE</xBairro> <xMun>SAO JOSE DOS PINHAIS</xMun> <CEP>83055320</CEP> </enderEmit> <IE>111111111111</IE> <cRegTrib>1</cRegTrib> <indRatISSQN>N</indRatISSQN> </emit> -<dest> <CPF/> <xNome><e>01000- VENDA AO CONSUMIDOR </e></xNome> </dest> -<det nItem="1"> -<prod> <cProd>00013</cProd> <xProd>GASOLINA COMUM</xProd> <NCM>27101259</NCM> <CFOP>5656</CFOP> <uCom>LTS</uCom> <qCom>2.7040</qCom> <vUnCom>3.699</vUnCom> <vProd>10.00</vProd> <indRegra>T</indRegra> <vItem>10.00</vItem> -<obsFiscoDet xCampoDet="Cod. Produto ANP"> <xTextoDet>320102001</xTextoDet> </obsFiscoDet> -<obsFiscoDet xCampoDet="Cod. CEST"> <xTextoDet>0600200</xTextoDet> </obsFiscoDet> </prod> -<imposto> <vItem12741>3.85</vItem12741> -<ICMS> -<ICMS40> <Orig>0</Orig> <CST>60</CST> </ICMS40> </ICMS> -<PIS> -<PISNT> <CST>04</CST> </PISNT> </PIS> -<COFINS> -<COFINSNT> <CST>04</CST> </COFINSNT> </COFINS> </imposto> </det> -<total> -<ICMSTot> <vICMS>0.00</vICMS> <vProd>10.00</vProd> <vDesc>0.00</vDesc> <vPIS>0.00</vPIS> <vCOFINS>0.00</vCOFINS> <vPISST>0.00</vPISST> <vCOFINSST>0.00</vCOFINSST> <vOutro>0.00</vOutro> </ICMSTot> <vCFe>10.00</vCFe> <vCFeLei12741>3.85</vCFeLei12741> </total> -<pgto> -<MP> <cMP>01</cMP> <vMP>10.00</vMP> </MP> <vTroco>0.00</vTroco> </pgto> -<infAdic> <infCpl>, N. Referencia 00009221 U 01 T 1, Trib.aprox.Federal 1,35 Estadual 2,50 IBPT, , ASS......................................</infCpl> -<obsFisco xCampo="xCampo1"> <xTexto>xTexto1</xTexto> </obsFisco> </infAdic> </infCFe> -<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> -<SignedInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> -<Reference URI="#CFe41191182373077000171599000089280010184883249"> -<Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <DigestValue>ZHFuW7VFjd9ODZOcJqBALDFXBqZ4Ya+cBtQthUiRd44=</DigestValue> </Reference> </SignedInfo> <SignatureValue>lXUDTIdXFQ/VBNu6TVocQ2epA2F0wRld0l66OeADIzB4F3kjmGCq+C0Bdzf4hWNkHyYm8fCBqC8UhFJx6mdXZWupyuy1v8v3mXbENPDWas5hTnI7wxctjjOb/pT+iz5mgRiM274tYYvGZ8Cuj2Bp2YgYMe088DfZR3+6kCudSYuySf6fCdEsQWh7WMBQ18Dn1LfaYP2D50zfB5laQRmir44OCljDQT2yTa1hbLkO/gXIpXTquVp18gQEu5InnYpiIi7k9Z/wMx8aqgy+UQwWNhtvPKg81eFtF7ctqJn4LONzGlKkMjFR0bCvXgenm3+x8sKZpY5MBGt9xogxIY8ybA==</SignatureValue> -<KeyInfo> -<X509Data> <X509Certificate>MIIFtjCCBJ6gAwIBAgICDEEwDQYJKoZIhvcNAQENBQAwaDELMAkGA1UEBhMCQlIxEjAQBgNVBAgMCVNBTyBQQVVMTzESMBAGA1UEBwwJU0FPIFBBVUxPMQ8wDQYDVQQKDAZBQ0ZVU1AxDzANBgNVBAsMBkFDRlVTUDEPMA0GA1UEAwwGQUNGVVNQMB4XDTE2MDYxNDE3NDAyNVoXDTIxMDYxMzE3NDAyNVowgZsxCzAJBgNVBAYTAkJSMQ8wDQYDVQQIDAZQYXJhbmExETAPBgNVBAoMCFNFRkFaLVNQMSgwJgYDVQQLEx9BdXRvcmlkYWRlIGRlIFJlZ2lzdHJvIFNFRkFaIFNQMRgwFgYDVQQLEw9BQyBTQVQgU0VGQVogU1AxJDAiBgNVBAMMG0JFTUFURUNIIFMuQTo4MjM3MzA3NzAwMDE3MTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMckoiROSz4BCAM0jFuvelGPD4siY4aB7VnR77uCZElCuVcbi1x8doQgiX+tREap/CRaJdiqnqxaL2x1UPVoB2fyWWZF8dhtorbDzN/cbVbtqaNff+/GTL2OW5FIsPEPsi268hB12DMxZeBaL+g7qFtcmNR3HA4fZBWfFmJ7EiDqlzG0aSpmofFb9xBaUwiYIYKXLyv7CRxSl41Igz8na+xR/z2I4i+LT+N+jthocpaFlx8r98/Z4xNce/lKxCHz0q9//qPMXHhKTfVZp7op2MJrdEHXaQ89uhmm7Xz5VWR0qDlVdAHBNXl46l6vCk3c3CZzTgR/AnlGcIFH8LmkIqcCAwEAAaOCAjQwggIwMAkGA1UdEwQCMAAwDgYDVR0PAQH/BAQDAgXgMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUCHSfwlkTu1iotBnyGj/NozmAYd8wHwYDVR0jBBgwFoAUFbTjkYYkLOozTwUeLS+Tt0iXx3gwEwYDVR0lBAwwCgYIKwYBBQUHAwIwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2Fjc2F0LmZhemVuZGEuc3AuZ292LmJyL2Fjc2F0c2VmYXpzcGNybC5jcmwwgacGCCsGAQUFBwEBBIGaMIGXMDUGCCsGAQUFBzABhilodHRwOi8vb2NzcC1waWxvdC5pbXByZW5zYW9maWNpYWwuY29tLmJyLzBeBggrBgEFBQcwAoZSaHR0cDovL2Fjc2F0LXRlc3RlLmltcHJlbnNhb2ZpY2lhbC5jb20uYnIvcmVwb3NpdG9yaW8vY2VydGlmaWNhZG9zL2Fjc2F0LXRlc3RlLnA3YzB7BgNVHSAEdDByMHAGCSsGAQQBgewtAzBjMGEGCCsGAQUFBwIBFlVodHRwOi8vYWNzYXQuaW1wcmVuc2FvZmljaWFsLmNvbS5ici9yZXBvc2l0b3Jpby9kcGMvYWNzYXRzZWZhenNwL2RwY19hY3NhdHNlZmF6c3AucGRmMCQGA1UdEQQdMBugGQYFYEwBAwOgEAwOODIzNzMwNzcwMDAxNzEwDQYJKoZIhvcNAQENBQADggEBAMQ9SNRTihm2MipNrkzkFV52BjA+kp+4PPz2a3GyKVR7Ft2SUk1R82BnoooTctAF8EwwMtGwH8wrRp4x6IsdkgIjp9lgw/38TIt2x5w16XbEpUvUC7JduYV4ZvtjVyLdmo9IZ1cH+rARvkrHKxuRtgswRGb/lLYb2Z1NSdz8A9ds+u9plIJfkeduw4nQ5l4UfTcv20L/2a1LF579VnpasFr5pyO0+KnOxL6PHiuf1KGs8cr8WA8pdy2xsqtP0D5Vzyh3KdglQMjGpvQXyC4ww/FX93MwtYoeSGTMb0bjp1yemuCQylA9vEXgRJEGQg3U4LUqpS5lFhsEQCtC9uGDJog=</X509Certificate> </X509Data> </KeyInfo> </Signature> </CFe>

Olá Daniel. Antes: [xNome] 00008-PREFEITURA MUN.TEJUPA(ADMINISTRACAO TRANSP.UNIVER Efeito : Cupom impresso corretamente, não sofre rejeição ao enviá-lo ao governo. Depois [xNome] <e>00008-PREFEITURA MUN.TEJUPA(ADMINISTRACAO TRANSP.UNIVER</e> Efeito: Cupom é rejeitado após ser enviado ao fisco, erro: Resposta:555308|06010|1999|Erro desconhecido|. Para corrigir o problema e continuar usando as tags preciso truncar para <e>00008-PREFEITURA MUN.TEJUPA(ADMINISTRACAO</e> É possível fazer um ajuste no ACBR para que as tags não contem mais no envio ao fisco ou tem uma outra forma de resolver este problema? Se não ficou claro ainda, explico mais.

Prezados, Atendendo a alguns clientes, implementei as tags <e> e </e> para expandir o nome/razão impresso no cupom, porém tenho a impressão que tais tags estão sendo enviados ao fisco como parte da razão social o que acaba excedendo a quantidade máxima permitida de caracteres quando a razão social é grande. Enviando com as tags e com uma razão social grande o suficiente, recebo o erro retornado pelo fisco é: Resposta:555308|06010|1999|Erro desconhecido| Para resolver o problema, tive que limitar o máximo de caracteres da razão social a 41 e depois usar as chaves <e> e </e>. É possível fazer um ajuste no ACBR para que as tags não contem mais no envio ao fisco ou tem uma outra forma de resolver este problema? Obs. Antes (sem as tags) a razão social poderia ter o máximo de 60 caracteres e não gerava erro na resposta do envio do CFSAT. Atenciosamente Leandro

Boa Tarde, Testei aqui a nova versão e está funcionando corretamente! Muito obrigado e parabéns pelo excelente trabalho! Abraço Leandro

Prezado, Estive olhando a seção de download ( projetoacbr.com.br/forum/files/file/454-acbrmonitorplus-windows-64-bits ) e aqui para mim aparece uma versão do ACBRMonitorPlus de 27 de outubro. Sabe se chegaram a lançar alguma atualização para este problema? Atenciosamente Leandro Segatti

Muitíssimo obrigado, ficarei no aguardo. Vlw

Bom dia, Creio que não precisaria nem tratar especificamente os diversos tipos de erros, apenas uma negativa da operação retornada como um Boolean já seria o suficiente para o usuário ter que revisar as configurações no AcbrMonitor já que dá pra testar por lá mesmo. Alguma ideia de data de liberação desta versão? Atenciosamente Leandro

Prezados, Uma dúvida aqui ao testar o SAT.EnviarEmailCFe, a implementação que fiz está OK, envia normalmente os emails com XML e PDF anexados, porém caso o servidor SMTP estiver fora ou ocorrer algum problema no envio, o componente sempre retorna "OK: Email enviado com sucesso" o que torna o comando sem muita utilidade. Tem alguma forma de captar o erro ocorrido após um SAT.EnviarEmailCFe, ou vou ter que fazer uma implementação particular mesmo para enviar os emails e detectar se ocorreu algum erro? Como a comunidade tem resolvido este probleminha? Atenciosamente Leandro S. Ps. tentei buscar no fórum mas não achei ninguém falando sobre, o que fiquei com a dúvida se era só comigo.

Realmente o controle de tudo está em controlar a Porta Serial (virtual) no envio de dados, nos diversos modelos de impressoras não fiscais. Assim posso controlar na saída da impressão o timeout entre vias e ter controle dos status de imprimindo e erros na impressora. Agradecimentos a Equipe ACBr.

Boa tarde, Segue o log, conforme solicitado. Ambiente: ACBrMonitorPlus 1.2.0.72 Windows 10 (32 bits) DR700 -ATIVAR - 26/07/19 17:12:26:563 - Modelo.: EscDaruma - TimeOut: 3 - Serial.: COM2 - BAUD=115200 DATA=8 PARITY=N STOP=1 HANDSHAKE=XON/XOFF SOFTFLOW MAXBANDWIDTH=0 SENDBYTESCOUNT=8192 SENDBYTESINTERVAL=100 Todas as atualizações efetudadas (sistema operacional, firmware DR700 e ultimo drive da impressora no site darumadesenvolvedores.com.br) Teste efetuado: Emissão de venda a prazo com impressão de 02 vias extrato sat com 100 itens. Retorno LOG (status) 26/07/2019 17:12:26 - SAT.ImprimirExtratoVenda("C:\OFFMON\SAT\vendas\08723218000186\201907\AD35190708723218000186599000092610069327704181.xml") 26/07/2019 17:12:30 - OK: 26/07/2019 17:12:30 - SAT.ImprimirExtratoVenda("C:\OFFMON\SAT\vendas\08723218000186\201907\AD35190708723218000186599000092610069327704181.xml") 26/07/2019 17:12:31 - ERRO: Communication error 9997: Timeout during operation obs: segue em anexo os logs. Att; LOG.TXT PosPrinter.txt

Precisamos emitir vias adicionais no cupom a prazo. Ao utilizar a impressora não fiscal DR-700, quando contém muitos produtos está ocorrendo na primeira via um retardo da impressão do extrato sat, ocasionando falha de comunicação: "ERRO: Communication error 9997: Timeout during operation " ou seja impressora ocupada!!! Motivo: Antes do término da impressão na primeira via o monitor ACBrMonitorPlus retorna status "OK:" Assim quando envio as demais vias, ocasiona vários erros de status: "ERRO: Communication error 9997: Timeout during operation " Não consigo pegar o retorno correto de várias modelos de impressora não fiscais, conforme o comando ESCPOS.LerStatusImpressora, conforme foi passado pelo suporte, visto os clientes utilizarem USB (serial virtual). O status "Timeout during operation" significa que a impressora está ocupada. Como eu posso tratar um erro REAL e alertar o usuário e o TI de suporte para devida correção, se eu ignorar os estados (porta inválida, desligada, sem papel, tampa aberta, etc...) vindo da impressora no meio da impressão? Então não tenho como saber o tempo de impressão da primeira via e nem o tempo de impressão das demais vias. A solução encontrada até o momento foi colocar um mensagem para o usuário aguardar a finalização da impressão e após a confirmação do usuário (OK) enviar o comando para impressão a cada via adicional. Pedir para o usuário aguardar a impressão do cupom em todas as vias adicionais e o usuário ficar confirmando visualmente (OK), aguardando o término da impressão vai gerar muita reclamação, então teria uma outra solução?

Consegui resolver o problema, segui o que você disse, apenas me atentei ao retorno do TX para a porta, ignorei os status e agora imprimiu até 200 produtos sem maiores problemas. Valeu e muito obrigado, se aparecer algo novo volto aqui.

Estou usando três impressoras com modo de comunicação direta na porta, não RAW Spool do windows. O que poderia estar fazendo esta não sinalização? O problema acontece nas 3 impressoras, elgin, daruma e epson sempre quando uso uma grande quantidade de produtos.

Então baseado nisso eu poderia: Apenas enviar os pedidos de reimpressão de vias sem consultar qualquer status entre os pedidos, o ACBR conseguirá tratar os dois comandos normalmente?