Leandro Araújo

Boa tarde. Estou tentando conciliar um CT-e emitido via EPEC, no ambiente de Homologação da Sefaz MT, só que sempre está retornando a rejeição a seguir: “402 - Rejeicao : XML da area de dados com codificacao diferente de UTF-8.” Já verifiquei o XML, inclusive no Validador de Mensagens do Projeto CT-e, e não acusa erro. - Ao tentar emitir um documento com os mesmos dados, mas forma de emissão 1 – Normal, é autorizado normalmente. - Ao tentar emitir um evento EPEC, o mesmo é criado normalmente. - Ao tentar conciliar o CT-e (com tpEmiss = 4) referente a EPEC anterior, sempre é retornada a rejeição 402. Entrei em contato com o atendimento da Sefaz MT, mas não responderam mais. Expliquei a situação, pedindo para verificarem também se poderia ser algo relacionado ao ambiente, conforme e-mail abaixo: Analisei até o código-fonte (\Fontes\ACBrDFe\ACBrCTe\ACBrCTe.pas linha 338 em diante) e não percebi nada diferente: // Passo 2 calcular o SHA-1 da string idCTe se o Tipo de Emissão for EPEC ou FSDA if TipoEmissao in [teDPEC, teFSDA] then begin // Tipo de Emissão em Contingência SSL.CarregarCertificadoSeNecessario; sign := SSL.CalcHash(idCTe, dgstSHA1, outBase64, True); Passo2 := '&sign=' + sign; sEntrada := sEntrada + Passo2; end; Result := urlUF + sEntrada; Em anexo XMLs: CT-e com emissão Normal: 51240706137422000190570010000000311680036048-cte-normal.xml Evento EPEC: 11011351240706137422000190570010000000254289813233001-procEventoCTe.xml CT-e com tipo de emissão EPEC: 51240706137422000190570010000000254289813233-cte-epec.xml Envio do lote: 25-env-lot.xml e 25-env-lot-decodado.xml Rejeição retornada: 25-pro-lot.xml Caso alguém tenha passado por essa situação e possa contribuir com algo, fico grato, mas acredito não ter algo a ver com o ACBr, já que utilizamos a emissão e conciliação de EPEC normalmente em ambiente de Produção, pelo menos até o momento.

Bom dia Italo! Entendi! Muito obrigado!

Boa tarde. Ao informar Unidades de Transporte no grupo de Outros Documentos (infOutros), e tentar carregar o XML no componente novamente, através do LoadFromFile, é disparada uma exception "EConvertError", como na mensagem de erro abaixo: Exception class EConvertError with message ''15,000</qtdRat></infUnidTransp>' is not a valid floating point value'. No XML está assim por exemplo: <infUnidTransp> <tpUnidTransp>1</tpUnidTransp> <idUnidTransp>1251</idUnidTransp> <lacUnidTransp> <nLacre>54541</nLacre> </lacUnidTransp> <qtdRat>15.000</qtdRat> </infUnidTransp> Olhando o código fonte da unit "\ACBr\Fontes\ACBrDFe\ACBrCTe\PCNCTe\pcteCTeR.pas" nas linhas 1026 e 1032 percebi que está um pouco diferente das declarações para os grupos anteriores acima (InfNF e InfNFe). Na linha 1026 a atribuição a variável "len" está comentada. Na linha 1032 está sendo passada a variável "pos3" como argumento no lugar de "len". //... // len := pos3 - pos2; (Linha 1026) // if (pos1 = 0) and (pos2 = 0) and (pos3 = 0) or (pos1 > pos3) then // qtdRat_UnidTransp := 0.0; if (pos1 < pos3) then qtdRat_UnidTransp := StringToFloatDef(Copy(sAux, pos2 + 8, pos3 -8), 0) // (Linha 1032) else qtdRat_UnidTransp := 0.0; //... Realizei um teste, removendo o comentário na linha 1026 e substituindo a variável "pos03" por "len" como argumento e parou de dar a exceção, além de que o valor ser atribuído corretamente na variável "qtdRat_UnidTransp" (antes ficava zerada). Tem algum motivo das declarações nesse bloco do InfOutros estar diferente do outros grupos (InfNF e InfNFe)? Obs.: Revisão do ACBr utilizada = 34383 Segue em anexo unit modificada com a qual fiz o teste. Obrigado pcteCTeR.pas

Boa tarde. Pois é, eu realizei vários testes, e além de não imprimir o QRCode (imprime o texto no lugar do QRCode) percebi que as formatações não são respeitadas na hora da impressão. Vou fechar o tópico então. Obrigado!

Bom dia. Estou realizando testes com o ACBrPOSPrinter com a impressora Diebold IM453HU-002, mas a mesma não imprime QRCode. Vi que no tópico abaixo outra pessoa conseguiu configurando como "ppEscBematech". Já tentei com ppEscBematch e outros, também testando as code page 437 e 850 (no manual é informado suporte para essas páginas de código), mas sem sucesso. Uma coisa que observei é que no manual diz que o suporte para impressão de QRCode é pelo set de comandos padrão (ao que dá a entender, pelo menos no meu entendimento, não sendo esc/pos). Poderiam dizer se essa impressora foi homologada para o ACBr? Estou achando que ela não tem suporte para impressão de QRCode por comandos ESC/POS. Se alguém que já trabalhou com ela puder me informar. Obrigado.

* Conclusão: Não foi possível fazer a impressora funcionar. * Motivos: A marca/modelo da impressora parece não ter suporte para comandos "ESC/POS", que são necessários para impressão universal em impressoras térmicas. * Tentativas: Foi pesquisado nos manuais, especificações técnicas e nas configurações da impressora e nada referente a linguagem "ESC/POS" foi encontrado. Também foi utilizado programa exemplo do ACBr, com componente de impressão do ACBr (ACBrPosPrinter), para testar a impressão, mas sem sucesso. * Observações: Ela ainda pode servir para a impressão de etiquetas, mas ainda assim também parece não ter suporte para linguagens "PPLA, PPLB ou ZPL2", que são necessárias para impressão universal em impressoras de etiquetas. Talvez por ser de fabricação de uma marca chinesa específica, essa impressora parece trabalhar bem somente com um programa proprietário (NiceLabel Designer/NiceLabel Print) (para impressão de etiquetas). Obrigado!

Já tentei todos os codepage. Sobre ela ter comandos ESC POS, estou pesquisando as especificações, mas encontrei pouca coisa a respeito, nem o manual.

Bom dia. Gostaria de saber se alguém já trabalhou com a impressora GPrinter modelo GP-3120TU usando o ACBrPOSPrinter? Estou realizando testes em uma, com o exemplo fornecido pelo ACBr mas não sai nenhuma impressão. A página de testes pelo Windows funciona, e do mesmo modo se eu tentar imprimir um .txt pelo bloco de notas. No exemplo do ACBrPOSPrinter ele consegue listar a porta USB "USB:Gprinter GP-3120TU" e também a porta RAW "RAW:Gprinter GP-3120TU" e ativa sem indicar nenhum erro, mas ao tentar enviar texto para impressão nada acontece. Tentei também por compartilhamento da impressora, e informando a porta \\127.0.0.1\GP-3120TU no componente, também ativa sem erro, mas ao enviar texto para impressão nada é impresso. Tentei alterar as propriedades da impressora no Windows para usar porta COM, mas quando faço isso, ao tentar ativar a impressora ocorre o erro "First chance exception at $76B87452. Exception class ESynaSerError with message 'Communication error 1: Função incorreta'.". Então mantive a comunicação pela porta USB mesmo, acredito que seja o mais recomendado. Já olhei o log e lá não é indicado nenhum erro. Obs.: A Code Page da impressora é 437 e isso também está configurado de acordo no ACBrPOSPrinter como pc437. Obs.2: Já resetei a impressora para os padrões de fábrica também. Marca: GPrinter Modelo: GP-3120TU Versão: V1.1 (G 2018-06-07) Interface: USB Label Value: 525 506 994 1-14 752 65 Size 80mm, 101mm Chinese GB18030: TSS24.BF2 Se alguém souber se tem alguma configuração específica que tenha que ser realizada nas opções dessa impressora para funcionar com o ACBrPosPrinter eu agradeço.

Bom dia! Testado e validado com sucesso aqui. Obrigado @EMBarbosa

Obrigado @EMBarbosa Assim que possível vou atualizar pelo svn e realizo os testes, e informo novamente aqui.

Bom dia.. Observei que o problema possivelmente poderia ser resolvido também alterando o valor das propriedades PosIni e PosFim do componente ACBrBAL e trabalhar com isso dentro da unit ACBrBALSaturno (que não deixa de ser inválido para uma implementação futura), mas ainda assim ficariam margens para erros inesperados, sem garantias de que o retorno possa vir no tamanho esperado/especificado, porém, conforme as alterações acima, agora a resposta de peso está sendo sanitizada (limpada) por completo, então no meu ver acredito que as melhorias possam ajudar de alguma forma. Caso eu possa marcar o post como resolvido ou tenha que aguardar, me avisem por favor. Obrigado!

Boa tarde... Consegui identificar o que estava acontecendo. O retorno recebido da balança continha CarriageReturn (#13) que não eram tratados quando entrava na primeira condição do if wAchouE or wAchouO then da função InterpretarRepostaPeso da unit ACBrBALSaturno, já que a remoção de caracteres especiais não estava tratando os caracteres #13 e #10, e no else estavam sendo tratados, fazendo que com dependendo do tamanho do pacote a conversão da resposta pela função StrToFloat sempre caísse no bloco Except. Trecho anterior (Condição if da função InterpretarRepostaPeso: if wAchouE then wPosEO := Pos('E', UpperCase(aResposta)) else wPosEO := Pos('O', UpperCase(aResposta)); wResposta := Copy(aResposta, 0, wPosEO - 1); { Removendo caracteres especiais, caso encontre algum } wResposta := StringReplace(wResposta, '°', '0', [rfReplaceAll]); wResposta := StringReplace(wResposta, '±', '1', [rfReplaceAll]); wResposta := StringReplace(wResposta, '²', '2', [rfReplaceAll]); wResposta := StringReplace(wResposta, '³', '3', [rfReplaceAll]); wResposta := StringReplace(wResposta, '´', '4', [rfReplaceAll]); wResposta := StringReplace(wResposta, 'µ', '5', [rfReplaceAll]); wResposta := StringReplace(wResposta, '¶', '6', [rfReplaceAll]); wResposta := StringReplace(wResposta, '·', '7', [rfReplaceAll]); wResposta := StringReplace(wResposta, '¸', '8', [rfReplaceAll]); wResposta := StringReplace(wResposta, '¹', '9', [rfReplaceAll]); // Sem tratamento para #13 e #10 end Acabei unificando a remoção dos caracteres especiais em uma function interna SanitizarRespostaPeso(const aResposta: AnsiString) : AnsiString; e deixando nela também o tratamento para #13 e #10 (igual estava condição else) independente se na reposta de peso forem encontrados os indicadores de Estado do Peso (Caracteres "E" ou "O"). Também passei para remover os valores inválidos antes de tentar localizar os indicadores de Estado do Peso, pois imagino que de qualquer forma os caracteres especiais devem ser removidos nos dois casos (de ter localizado indicador de Estado do Peso ou não), caso isso estiver errado posso corrigir. Modifiquei também para ler o valor do parâmetro aResposta somente no início, passando para a variável wResposta, para a partir disso o método somente trabalhar com o valor de wResposta já sanitizado. Segue abaixo o trecho modificado de InterpretarRepostaPeso na unit ACBrBALSaturno: function TACBrBALSaturno.InterpretarRepostaPeso(const aResposta: AnsiString): Double; var wAchouE, wAchouO: Boolean; wPosEO: Integer; wResposta: AnsiString; function SanitizarRespostaPeso(const aResposta: AnsiString) : AnsiString; begin Result := Trim(aResposta); if Result = EmptyStr then Exit; Result := StringReplace(Result, '°', '0', [rfReplaceAll]); Result := StringReplace(Result, '±', '1', [rfReplaceAll]); Result := StringReplace(Result, '²', '2', [rfReplaceAll]); Result := StringReplace(Result, '³', '3', [rfReplaceAll]); Result := StringReplace(Result, '´', '4', [rfReplaceAll]); Result := StringReplace(Result, 'µ', '5', [rfReplaceAll]); Result := StringReplace(Result, '¶', '6', [rfReplaceAll]); Result := StringReplace(Result, '·', '7', [rfReplaceAll]); Result := StringReplace(Result, '¸', '8', [rfReplaceAll]); Result := StringReplace(Result, '¹', '9', [rfReplaceAll]); Result := StringReplace(Result, #13, '', [rfReplaceAll]); Result := StringReplace(Result, #10, '', [rfReplaceAll]); Result := StringReplace(Result, '[CR]', '', [rfReplaceAll]); Result := StringReplace(Result, '[LF]', '', [rfReplaceAll]); end; begin Result := 0; wAchouE := False; wAchouO := False; wPosEO := -1; wResposta := EmptyStr; { Removendo caracteres especiais, caso encontre algum } wResposta := SanitizarRespostaPeso(aResposta); if (Trim(wResposta) = EmptyStr) then Exit; wAchouE := (Pos('E', UpperCase(wResposta)) > 0); wAchouO := (Pos('O', UpperCase(wResposta)) > 0); // Se encontrar a letra 'E' (Estável) ou 'O' (Oscilante), captura o peso da // posição 1 a 7 da string if wAchouE or wAchouO then begin if wAchouE then wPosEO := Pos('E', UpperCase(wResposta)) else wPosEO := Pos('O', UpperCase(wResposta)); wResposta := Copy(wResposta, 0, wPosEO - 1); end else begin wResposta := Copy(wResposta, 1, 9); end; if (Length(wResposta) > 0) then begin try Result := StrToFloat(wResposta); except case PadLeft(Trim(wResposta),1)[1] of 'I': Result := -1; { Instavel } 'N': Result := -2; { Peso Negativo } 'S': Result := -10; { Sobrecarga de Peso } else Result := 0; end; end; end else Result := 0; end; Segue em anexo o código-fonte completo alterado, caso puder ser analisado por algum committer do projeto ACBr e ser ou não adicionado no trunk. Ainda com relação a gravação do log de pesagem, desculpem o equívoco, acredito que o componente está gravando correto, favor desconsiderar essa questão. Qualquer dúvida ou erro estou a disposição. Obrigado. ACBrBALSaturno.pas

Bom dia... Consegui a informação referente ao Indicador de Pesagem (Marca: WEIGHTECH Modelo: WT27). Na página oficial (https://www.weightech.com.br/indicador-de-pesagem-wt27) não consegui baixar o manual técnico, tive que encontrar em outra fonte. Até onde entendi, era o que eu suspeitava, é possível personalizar um protocolo para envio dos dados. No caso a mensagem de leitura respeita o protocolo da Saturno, mas parece que incluíram os textos [CR] e [LF] em forma literal ou então o ACBrBALClass está gravando dessa forma no log. Estou analisando melhor os manuais obtidos, para ver se a modificação na interpretação da resposta de pesagem pode ser mantida na ACBrBALSaturno mesmo ou se é o necessário a criação de uma nova unit (caso os administradores aceitem a alteração). Nos manuais que encontrei a mensagem de resposta parece ser no formato: Seguem as fontes de onde consegui os manuais: WT27: https://www.yumpu.com/pt/document/read/49558520/indicador-digital-wt27-manualpdf-weightech WT27R http://primaxbalancas.com.br/wp-content/uploads/Manual-técnico-WT-27-R.pdf https://www.balancasrr.com.br/indicadoresweightech https://drive.google.com/file/d/1rtKlOvnztysnJHhVMcvyqTVrlY8_-U1o/view Obrigado.

Boa tarde. Estou realizando a integração do nosso sistema com uma balança da marca Saturno. O padrão de resposta é composto juntamente com os indicadores de peso (Estabilidade do Peso e Estado da Balança) <CR>, PPPPPP, “E”/“O”, “L”/“B”, “_”, “ ”, <LF> (Conforme manual de integração), por exemplo: 023060EL_. Onde: <CR> = Carriage Return (#13), PPPPPP = Peso na Balança, E/O = Estado do Peso, L/B = Estado da Balança, <LF> = Line Feed. Testando o retorno por um outro software (Hercules SETUP utility) o retorno vem da seguinte forma no próprio Hercules utility: 006320OL_. Copiando esse valor e informando no "Exemplo de Emulador de Balanças do ACBr" e enviando, o retorno é interpretado corretamente pela classe TACBrBALSaturno da Unit ACBrBALSaturno no nosso sistema e peso é exibido de forma correta. Porém, ao realizar a leitura diretamente pela porta COM, o peso recebido fica zerado sempre, e observei que conforme o log de pesagem, ao que parece os textos [CR] e [LF] estão sendo recebidos de forma literal diretamente na resposta. Realizei o tratamento no método InterpretarRepostaPeso, também removendo esses textos (CR e LF) e ao que parece, classe passou a interpretar corretamente nesse caso. Obs.: Sei que CR = Carriage Return e LF = Line Feed, ambos sendo representados por #13 e #10 consecutivamente. Segue abaixo onde foi modificado (duas últimas linhas). if wAchouE or wAchouO then begin if wAchouE then wPosEO := Pos('E', UpperCase(aResposta)) else wPosEO := Pos('O', UpperCase(aResposta)); wResposta := Copy(aResposta, 0, wPosEO - 1); { Removendo caracteres especiais, caso encontre algum } wResposta := StringReplace(wResposta, '°', '0', [rfReplaceAll]); wResposta := StringReplace(wResposta, '±', '1', [rfReplaceAll]); wResposta := StringReplace(wResposta, '²', '2', [rfReplaceAll]); wResposta := StringReplace(wResposta, '³', '3', [rfReplaceAll]); wResposta := StringReplace(wResposta, '´', '4', [rfReplaceAll]); wResposta := StringReplace(wResposta, 'µ', '5', [rfReplaceAll]); wResposta := StringReplace(wResposta, '¶', '6', [rfReplaceAll]); wResposta := StringReplace(wResposta, '·', '7', [rfReplaceAll]); wResposta := StringReplace(wResposta, '¸', '8', [rfReplaceAll]); wResposta := StringReplace(wResposta, '¹', '9', [rfReplaceAll]); wResposta := StringReplace(wResposta, '[CR]', '', [rfReplaceAll]); // Modificado: Remover [CR] wResposta := StringReplace(wResposta, '[LF]', '', [rfReplaceAll]); // Modificado: Remover [LF] end Segue um trecho do log de pesagem: -------------------------------------------------------------------------------- ATIVAR - 04/04/22 14:22:34:841 - Modelo: Saturno - Porta: COM4 Device: BAUD=9600 DATA=8 PARITY=N STOP=1 HANDSHAKE= MAXBANDWIDTH=0 SENDBYTESCOUNT=0 SENDBYTESINTERVAL=0 -------------------------------------------------------------------------------- - 14:22:35:862 RX <- [CR]023060EL_ [LF][CR]023060EL_ [LF][CR]023060EL_ [LF][CR]023060EL_ [LF][CR]023060EL_ [LF] UltimoPesoLido: 0 - Resposta: [CR]023060EL_ [LF][CR]023060EL_ [LF][CR]023060EL_ [LF][CR]023060EL_ [LF][CR]023060EL_ [LF] O cliente ainda não informou o modelo em específico, mas assim que informar eu posto aqui. Gostaria de saber se alguém já passou por isso, se pode ser alguma particularidade do módulo que envia os pacotes de dados (alguma configuração como ele envia a resposta de peso), ou se realmente a alteração que eu fiz faz sentido e pode ser incluída no trunk do ACBr? Existe algum motivo do log gravar com esse [CR] e [LF] de forma literal? Seguem em anexo o código fonte modificado e o log de pesagem. Obrigado. ACBrBALSaturno.pas Log-Pesagem.log Teste-Balanca-Saturno-HerculesUtility.txt

Imaginei mesmo, é uma alteração grande, teria que ser bem testada. Argumentei com o pessoal, que nem a biblioteca fiscal (ACBr) que usamos havia implementado as mudanças, sendo que o ACBr sempre sai na frente quanto às mudanças na legislação tributária. Mas ok, só precisava de uma confirmação a mais. Muito obrigado!