William F. L.

Colega estamos tendo o mesmo problema com esse driver "CH340" integração do sistema com a balança Prix Fit 3, funciona até um determinado ponto depois para de ler o peso e mesmo reiniciando o sistema dá erro, inclusive no demo do ACBr. Inicialmente achavamos que todos os adaptadores (SERIAL-USB) eram iguais, porém depois de muitos dias pesquisando, descobri que existem "2 modelos de conversores" nesses adaptadores - Prolific - CH340 Com isso já descobrimos pq a maioria dos clientes e até em nossa bancada sempre funcionou muito bem a leitura de peso, pois sempre usamos o adaptador com conversor e driver "Prolific". O cliente que não funciona a leitura, comprou um adaptador com "CH340", levamos o nosso "Prolific" no estabelecimento dele e na hora funcionou muito bem. Compramos um adaptador "CH340", fazendo vários testes é possível ver que o driver dele é encontrado em várias versões, porém nenhuma funciona bem: - 2011, 2014, 2019 e 2023 A única solução que encontramos é a partir de agora sempre que o cliente perguntar sobre esses adaptadores, orientar sempre comprar com esse conversor "Prolific" (pior que visualmente os 2 são iguais).

Colega sofria demais com isso, clientes de fora do estado, com diferentes marcas de impressora, isso fora os vários tipos de etiqueta que cada cliente usa. Resolvemos isso desenvolvendo um sistema para customização de etiqueta via Fast Report que possui componente para design time. Com isso customizanos a etiqueta direto no cliente, mesmo remotamente.

Em 2023 até o momento temos dezenas de SATs Control ID ativados. Nenhum problema até agora, fácil instalação e suporte muito bom.

Bom dia ! O cliente utilizou no sábado e no domingo, não tivemos logs de erro ou chamados ao suporte. Optei em fazer a alteração no método "InterpretarRespostaPeso": ACBrBALToledo.pas

Bom dia Renato, fiz essa alteração sugerida conforme o print abaixo e vou colocar no cliente para testar: Porém acho que a verificação se a "resposta" está vazia deveria ser feito na função que interpreta as respostas "InterpretarRespostaPeso", nessa função existe uma verificação de "aResposta" mas está no meio da função, podendo ocasionar erros antes dessa verificação:

Olá, estamos com um cliente usando o microterminal Gertec MT-721 integrado a Balança Prix Fit 3. Em alguns momentos do dia, estoura na tela do caixa uma mensagem acusando "Access Violation" na linha 109 da unit "ACBrBALToledo.pas": exception class : EAccessViolation exception message : Access violation at address 01876215 in module 'WFOOD.exe'. Read of address 00000000. main thread ($82c): 01876215 +029 WFOOD.exe ACBrBALToledo 109 +4 TACBrBALToledo.ProtocoloP03Detectado 01876d7d +0b9 WFOOD.exe ACBrBALToledo 365 +10 TACBrBALToledo.InterpretarRepostaPeso 0188409b +017 WFOOD.exe ACBrBAL 389 +1 TACBrBAL.InterpretarRepostaPeso 0188b458 +16c WFOOD.exe ACBrMTer 598 +29 TACBrMTerConexao.OnBufferWaitDone 01466eed +011 WFOOD.exe ACBrBase 525 +1 TACBrThreadTimer.DoCallEvent 0055f75e +172 WFOOD.exe System.Classes CheckSynchronize 007274b0 +7bc WFOOD.exe Vcl.Forms TApplication.WndProc Método apontado na exceção "ProtocoloP03Detectado" como a linha 109: function TACBrBALToledo.ProtocoloP03Detectado(const wPosIni:Integer; const aResposta: AnsiString): Boolean; var l_posini, l_posfim: Integer; begin // detecta o padrão p03 na string. // 1 2 3 4 567890 123456 7 8 (8 é opcional) // Protocolo P03 = [STX] [SWA] [SWB] [SWC] [IIIIII] [TTTTTT] [CR] [CS] if (aresposta[1] = STX) and (aresposta[17] = CR) then <---------- ERRO SERIA NESSA LINHA 109 // primeiro caracter da string é STX e o 17 é CR Result := True else begin // pode ocorrer da string ser lida quebrada, assim procura o primeiro CR, depois do primeiro STX // [IIII] [STX] [SWA] [SWB] [SWC] [IIIIII] [TTTTTT] [CR] l_posini := Pos(STX, aResposta); l_posfim := PosEX(CR, aResposta, l_posini + 1); if l_posfim = 0 then l_posfim := Length(aResposta) + 1; Result := l_posfim - l_posini = 16; end; end; Analisando os logs do microterminal nos horários em que ocorre o erro, observamos que todas as vezes que houve erro foi no trecho abaixo: -- 23/06 14:23:45:122 -- Terminal: 192.168.30.5 - RX <- 262 bytes -> =[NUL][STX][SOH][NUL][STX]00000[ETX][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][NUL][7]

Olá, segue meus contatos: Email: [email protected] Fone: (11) 99845-2278

Colega tenho uma empresa de sistema para restaurantes, se quiser podemos fazer uma call para entender sua necessidade.

Deixando a solução para quem precisar, como no Android 12 teve mudanças nas permissões, foi necessário marcar essas opções no projeto.

Olá, estou usando Delphi 11.3 e fazendo um teste com o demo ACBrPosPrinter Android em um tablet com Android 12. Meus fontes estão atualizados, o App solicita permissão do Bluetooth ao iniciar mas depois não encontra a impressora pareada. Tenho outro Tablet com Android 8 e funciona normal com o Demo do ACBrPosPrinter. Fazendo algumas pesquisas, encontrei na documentação do Android que essa versão 12 teve mudanças nas permissões para uso do Bluetooth. Alguém já conseguiu imprimir pelo demo com Bluetooth no Android 12 ?

Posso estar enganado, mas dei uma lida nos fontes do ACBr, mais especificamente nessas rotinas de leitura do "ACBrNFeServicos.ini". function TWebServicesConf.LerParamsIniServicos: AnsiString; var ArqIni: String; FS: TFileStream; begin Result := ''; ArqIni := Trim(fpConfiguracoes.Arquivos.IniServicos); if (ArqIni <> '') and FileExists(ArqIni) then begin FS := TFileStream.Create(ArqIni, fmOpenRead or fmShareDenyNone); // Thread Safe try FS.Position := 0; Result := ReadStrFromStream(FS, FS.Size); finally FS.Free; end; end; end; Observe que se a propriedade "fpConfiguracoes.Arquivos.IniServicos" estiver vazia, o componente "não" vai procurar na pasta do executável o arquivo INI. No meu caso sempre deixava essa propriedade vazia, agora mudei a lógica no momento que configuro o componente antes da emissão: if FileExists(PathApp + 'ACBrNFeServicos.ini') then ACBrNFCe.Configuracoes.Arquivos.IniServicos := PathApp + 'ACBrNFeServicos.ini'; Geralmente não uso o arquivo "ACBrNFeServicos.ini" direto na pasta, mas no caso específico dos clientes de Minas Gerais estou reconsiderando essa prática .. rsrs

Estou com o mesmo problema em Minas Gerais, assisti um vídeo do Daniel ontem falando sobre o assunto. Atualizei meu ACBr e compilei novamente o sistema, coloquei a versão no cliente mas contínua o mesmo erro ao emitir.

Estou tendo o mesmo problema em SP, porém usando o componente. Ajustamos timeout, mas tem clientes que passa 1 ou 2 NFC-e, depois dá o erro. Acho que a Sefaz está meio preguiçosa ..rsrsr

Nós também temos aqui um "mini" servidor de SAT, mas é bem mais simples rsrs .. Aqui deixamos rodando no servidor um programa que fica rodando em loop e verificando a fila de Cupons pendentes, se ele acha um Cupom ai parte para verificar a tabela de SATs cadastrados e vai verificando o status de cada um (nesse ponto descarregamos e carregamos novamente a DLL), o aparelho SAT que estiver livre recebe o cupom. Alguns colegas relataram em posts aqui mesmo no ACBr, que aparelhos SAT da mesma marca podem ter dificuldades em ter mais de 1 aparelho no mesmo computador, nesse caso sempre orientamos para ter aparelhos de marcas diferentes, nosso cliente usa 1 ControlId e 1 Linker II. Um ponto interessante é, cada autorização que um aparelho executa, incremento no registro dele +1, sendo assim ordeno a fila de aparelhos sempre pelo aparelho que tem trabalhado menos .. rsrs Temos isso em produção com no máximo 5 PDVs, em laboratório testamos com 3 PDVs finalizando a venda no mesmo segundo e até o momento nada consta de erros.

Uma prática que usamos aqui e reduz bem os problemas é sempre consultar o status do aparelho SAT antes de enviar uma venda. Diariamente temos problemas com: - aparelhos não sendo encontrado pelo windows (problema de comunicação) - aparelho com com status "Em processamento" - aparelho bloqueado por falta de internet Todos esses casos avisamos na tela do PDV o problema, e não enviamos a venda.

Nesse seu contexto de preocupação, eu já começaria a pensar nessa situação de quando atualizar a tabela IBPT, o próprio sistema já revisar os produtos e travar a venda deles.

Então como citei acima, no meu caso é exibida uma tela para correção rápida para aquele cupom fiscal, após o preenchimento do que precisa o cupom será emitido, independente de ser SAT ou NFC-E.

Então, no meu caso como é em SP, automaticamente exibo a mensagem de erro para o operador, nesse seu caso "erro de NCM". Ai cabe alguns tratamentos por parte da aplicação, porque esse tipo de erro mesmo você virando automaticamente para SAT (o SAT não valida NCM só quantidade caracteres), você estaria acobertando um erro de preenchimento. Nesse caso, o ideal seria exibir uma tela para o operador com a opção de corrigir o NCM, eu tenho isso para os principais campos (NCM, CST, CSOSN, CFOP, PIS e COFINS), e não deixar ele emitir SAT com esse NCM errado. Outro ponto que merece destaque, nas atualizações da tabela de NCM (eu uso a tabela IBPT como base), sua aplicação passar uma varredura nos seus produtos, informando uma lista de produtos caso tenha NCM não encontrado na tabela IBPT. Ai você pode serguir de várias maneiras: - flag no produto deixando como inválido para venda - obriga uma correção imediata dos NCMs

Em SP esse erro não seria tão grave, pois aqui se der esse erro com NCM você simplesmente não vai conseguir autorizar e pode tratar isso excluindo essa NFC -e (pois não foi autorizado) e virando para emissão com SAT. Fora de SP se você emitir essa NFC-e de maneira OFFLINE, só vai saber desse erro quando for regularizar ela e nesse caso já foi impresso o extrato do cupom com a chave para o cliente, ai qualquer correção feita iria alterar o XML original (que poderia ser um problema de fato).

Minha dica nesse caso é tratar bem os retornos e também "não retornos" durante o envio da NFC-e. No meu caso senão retorna nada, jogo como pendente e emito outra OFFLINE, essa pendente fica para ser regularizada: - consulta e se estiver autorizada, cancela por substituição - senão foi autorizada, inutiliza a numeração Usamos até um monitor para automatizar esse processo, mas o usuário também tem uma tela para regularizar manualmente.

Tenho alguns clientes usando MP 4200TH e MP 4000TH em rede, 2 deles tem mais de 5 impressoras de departamento. Em um dos clientes é a vivo que fornece internet, porém não temos problemas com essas paradas. Porém sempre usamos o seguinte padrão: modem vivo -> roteador Intelbrás -> switch 24 portas -> dispositivos (impressoras e computadores) Quem gerencia o range de IP dos dispositivos é o roteador Intelbrás, outro ponto é que mudamos o range, exemplo: modem vivo: 192.168.15.XXX roteador Intelbrás: 192.168.10.XXX

Colega tive o mesmo problema com SAT da Jetway, tentamos de tudo: - trocar a porta - reinstalação do driver - desligar o gerenciamento de energia das USB - colocar o cabo "Y" com 2 entradas USB, separando 1 para energia e outra para dados - troca de computador Nada adiantou, emite uma horas tranquilo e depois começa retornar "Sat em processamento". Solução, o cliente trocou por um aparelho SAT bematech Go, já tem 4 semanas e não deu mais problema.

Pessoal estou com um probleminha chato para fazer a carga na balança usando o MGV6, geramos o arquivo TXT de carga normalmente pelo sistema. Porém quando fazemos a importação no MGV6, ele acusa erro na data de validade, analisando o TXT e testando, vimos que se adicionar 2 digitos a mais no "código" do produto, ele importa normalmente. Porém olhando os fontes do ACBr e a documentação do MGV6, o campo código pede 6 digitos, mas nesse caso só funciona se colocamos 8 digitos no campo código. Já revirei o MGV procurando a existência de alguma configuração que mude essa regra do TXT.

Em Minas tá complicado mesmo, os clientes tem deixado ativado a contingência offline e o monitor de NFC-e vai despachando na medida do possível. Fora a internet dos clientes que não ajuda também, quando não é a SEFAZ é a internet que falha.

Integra com um painel de liberação via WEB usando uma api Json. Aí vc pode liberar ou bloquear o terminal usando um celular.