Erro ao transmitir no SAT RB-1000

[Intelliware]

Bom dia pessoal, 

No dia 01/03 recebemos de um cliente(SAT Bematech RB-1000) uma reclamação que estava ocorrendo problema na emissão do CF-e. Analisando o log, encontramos um erro no processo de adicionar os dados do CF-e no banco de dados. Segue:

[01/03/2018 17:29:08]
[TRANSMITIRCUPOMSAT]ERRO(#07): '255,255,255,000' is not a valid floating point value
- IDCUPOM: 5414226000

Só para esclarecer melhor, o nosso sistema, efetua antes de enviar a venda para o SAT, a seguinte validação:

1) SAT está em operação?
2) Status do SAT é não BLOQUEADO?
3) Qual o status da impressora?

No log  do SAT gerado pela ACBr, obtivemos:

Ou seja, pelo visto o sistema tentou converter uma resposta da posição 09, que a princípio é resultado do comando ConsultarStatusOperacional e não do EnviarDadosVenda. No sistema eu faço:

with Resposta do
begin
  //06000 - Emitido com sucesso + conteúdo notas
  if (codigoDeRetorno = 6000) then
  begin
    ValorTotalCFe := StringToFloat(Resposta.RetornoLst[9]);
(...)

O problema relacionado a isso é que o nosso sistema cancelou o cupom pois foi executada uma exceção, mas o CF-e estava aprovado na SEFAZ. 

Algo que notei é que o tempo entre o número de sessão 158050 e 710051 foi de 0,936 ms. As requisições ao SAT são sequenciais, ou seja, é efetuada uma chamada, processada a resposta, efetuada outra chamada e assim por diante. Seria possível no componente uma resposta sobrescrever a outra?

Este erro ocorre ocasionalmente em um cliente e não conseguimos reproduzir.  Em outros clientes não recebemos este tipo de reclamação.

Gostaria da opinião de vocês a respeito deste procedimento. Vocês já tiveram algum problema deste tipo?

Desde já agradeço o retorno.

 

[Daniel Simoes]

Tudo indica que a DLL (ou o SAT), respondeu com a sessão errada, para o comando enviado... Você pode confrontar isso verificando no Log da DLL do fabricante... 

O ACBrSAT já faz uma verificação, pelo numero de sessão retornado, conferindo se é o mesmo que foi enviado... Provavelmente essa verificação está desligada em sua aplicação... (verifique se a propriedade "ValidarNumeroSessaoResposta" está True)

 

[Intelliware]

Bom dia Daniel,

De fato, não estávamos utilizando esta propriedade. Adicionei ela como um parâmetro do sistema pois neste caso ajuda muito na validação e visualização do problema. Realmente, analisando um novo log do cliente, era erro de retorno de sessão, no print abaixo, coloquei um retorno que ocasionou um cancelamento e um retorno em que foi aprovado com sucesso:

Acreditamos que ao executar um comando que resulte em erro na porta de comunicação, o driver/SAT está retornando um número de sessão do comando anterior na próxima execução.

Hoje de manhã, entramos em contato com a Bematech para verificarmos este erro na leitura da porta de comunicação, pois neste cliente em questão, estava ocorrendo direto, causando lentidão, rejeição e erros. Nos foi passado que para resolver problemas de comunicação foi lançado uma versão do driver USB mais atual. Para efeito de maior esclarecimento, para hoje dia 08/03/2018 as versões que são as últimas para o SAT da Bematech RB-1000 são:

- Versão do Software Básico(Firmware): 02.01.00
- Versão do driver USB: 3.4.0.0
- Versão da BemaSAT(DLL): 1.0.2.35

Atualizamos todos os caixas. 

Estou efetuando alguns testes e vou liberar uma versão com a propriedade da ACBrSAT parametrizada.

Mais uma vez, agradeço a ajuda.

[Daniel Simoes]

A vantagem da propriedade ValidarNumeroSessaoResposta é que quando a Sessão retornada está errada, o próprio ACBrSAT interroga o SAT sobre a Sessão correta (usando o comando ConsultarNumeroSessao)... e se a resposta da sessão correta, estiver disponível na memória do SAT, o ACBrSAT conseguirá corrigir a situação...

[Intelliware]

Excelente Daniel. Agradeço a ajuda.

[Intelliware]

Daniel, desculpa a demora do retorno, mas ainda estamos acompanhando o cliente de perto, pois ainda acontece um evento realmente muito incomum no mesmo. No log do evento OnGravarLog do componente ACBrSAT temos a seguinte sequência de comandos:

A princípio foi executado uma ConsultarStatusOperacional(2), no intervalo entre enviar os dados da venda e gravar no banco de dados, mas não temos esta instrução no sistema neste intervalo exato. Não utilizamos thread neste caso em nenhum momento. O que é acontece é que chamamos o comando EnviarDadosVenda, validamos se o retorno é 6000 e simplesmente adicionamos os dados no banco. Como a consulta entra no meio do fluxo, os dados do componente mudam lançando exceção. Isso ocorre uma vez ou outra mas força o cancelamento do cupom.

Como condição de contorno, realizei o seguinte tratamento:

- Criei um record que guarda a resposta de retorno do comando EnviarDadosVenda, o seu respectivo número de sessão logo abaixo da chamada da respectiva instrução e o caminho do arquivo da venda. Isto foi feito pois nos testes quando mandava consultar o número de sessão, o SAT reportava que a sessão não existia(estou em ambiente de homologação), embora no log, estivesse o número de sessão gravado normalmente.

- Caso lance exceção eu efetuo os procedimentos:

dmSAT.ACBrSAT.CFe.LoadFromFile(SATVendaContencao.CaminhoXML);
dmSAT.ACBrSAT.Resposta.RetornoStr := SATVendaContencao.RespostaSessao;

Nos testes, o procedimento funcionou, lançou a exceção, mas recarregou os dados e confirmou a venda. 

Você já viu algo parecido em relação a isso? 

[Intelliware]

Bom dia pessoal,

Só efetuando um feedback para concluir este tópico, antes de gravar no banco de dados, eu valido o número de sessão com o número da sessão da venda e o código do comando(6000) gravado no componente, com isso, caso seja detectado alguma incoerência, o componente é recarregado conforme citado acima. Este tratamento é adicionado em conjunto com a propriedade ValidarNumeroSessaoResposta, conforme também descrito acima.

Um parceiro nosso enviou um e-mail para a Bematech com uma explicação nossa sobre o que ocorre mas não obtivemos retorno, logo, o tratamento ficou somente dentro da aplicação.

[Daniel Simoes]

Em 27/03/2018 at 14:36, Intelliware disse:

Você já viu algo parecido em relação a isso? 

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

[Intelliware]

Blz Daniel. Agradeço a resposta.