11

3

Problema: Identificada falha na transmissão de NFC-e quando o campo de informações adicionais continha apenas 1 caractere, causando interrupção no fluxo de venda.

Solução: Implementada validação impeditiva que exige o preenchimento mínimo de 3 caracteres sempre que a informação adicional for obrigatória. O sistema agora bloqueia o avanço com alerta específico, garantindo a integridade dos dados antes da emissão.

Problema: Os valores dos itens no consultaCampanha do Reshop estavam sendo enviados de forma incorreta na mesa em alguns fluxos como envio para produção, fechamento de mesa e pagamento. Situação ocorria tanto para com quem trabalha com exceção de combos ou não

Solução: Foi feito o ajuste completo em todos os cenários da mesa.

Problema: A consulta de notas alterava informações internas e impedia que notas com erro fossem inutilizadas corretamente.

Solução: Agora apenas o fluxo de inutilização trata essas notas, verificando antes se elas já foram resolvidas. Se estiverem finalizadas, o sistema só atualiza o status local, evitando tentativas desnecessárias e mantendo tudo alinhado com a situação real da nota fiscal.

Problema: Notas fiscais estavam sendo rejeitadas devido a valores de troco inconsistentes (muito elevados).

Solução: Adicionada validação no PDV que limita o valor de troco a R$ 1.000,00.

Problema: O PDV permitia o envio de notas com números de controle já utilizados. Nesses casos, o sistema não registrava a nova venda, mas retornava incorretamente o status "Finalizado com Sucesso", gerando inconsistência entre a operação e o banco de dados.

Solução: Implementada validação de unicidade para o número de controle no fluxo de emissão. Caso o identificador já tenha sido processado anteriormente, o PDV agora bloqueia a operação e retorna uma rejeição clara ao usuário.

Problema: Os valores dos itens no consultaCampanha do Reshop estavam sendo enviados de forma incorreta no Balcão. Situação ocorria tanto para com quem trabalha com exceção de combos ou não

Solução: Foi feito o ajuste completo em todos os cenários do Balcão.

Problema: O robô responsável pela transmissão de notas em contingência não estava parametrizado para tratar o código de rejeição 934 (Não informado valor do ICMS desonerado ou o Motivo de desoneração). Isso causava a interrupção do fluxo de transmissão automática para notas com esse cenário fiscal.

Solução: Atualizada a lógica de consulta e transmissão do robô para incluir TASTE-479o código 934 no mapeamento de erros tratáveis. O motor de regras agora identifica essa rejeição e permite que a nota siga o fluxo correto de reprocessamento ou consulta de status.

Problema: Ao navegar entre diferentes pedidos no HubDelivery, algumas informações antigas permaneciam na tela, fazendo com que itens, quantidades e subitens de um pedido fossem exibidos incorretamente em outro. Isso gerava inconsistências visuais, como pedidos parecendo incompletos ou mostrando detalhes que não pertenciam ao pedido atual.

Solução: O sistema passou a limpar completamente os dados do pedido anterior antes de carregar um novo, garantindo que nenhuma informação antiga seja reaproveitada. A forma como itens e subitens são exibidos também foi ajustada para evitar distorções e assegurar que todos os detalhes carreguem corretamente sempre que um pedido for aberto.

Problema: O botão “Produzir” ficava em carregamento infinito quando o pedido tinha SKU inválido, mesmo após o erro ser exibido. A API retornava corretamente a falha, mas o front não liberava nova tentativa. Com isso, o usuário ficava travado e não conseguia prosseguir.
Solução: Ajustamos o comportamento do botão para encerrar o carregamento quando houver erro e permitir nova tentativa. No fluxo correto, o spinner permanece ativo apenas até a conclusão real do envio. Assim, o usuário consegue seguir normalmente, sem ficar preso no loading.