# 📃 3.0 Release Notes | Bugs 🐞
##### 🐞 **ERP - Não conformidade geração da Tag `vDesc` em Produtos sem Desconto (NF-e)**
> **Compromisso: 21218 - ERRO AO EMITIR NFE IMPORTANDO DA OS**
- ❌ Na versão atual, o sistema estava **gerando a tag `vDesc` com valor `0.00`** dentro do XML da NF-e, mesmo quando **não havia desconto aplicado** no item;
- 📦 **Exemplo de venda:**
- Quantidade: **9.000**
- Valor unitário: **1,60**
- Total: **R$ 14.400,00**
- Tag gerada incorretamente: `0.00`
- ✅ O comportamento foi corrigido e agora a **tag `vDesc` somente será criada quando existir desconto real** no produto.
##### 🐞 **ERP - Não conformidade no cálculo do Valor Total do Item em Vendas (Tratamento de Valores Nulos) 🛠️**
Foi corrigida uma não conformidade no processo de inclusão de vendas que impedia a exibição do **valor total do item**, que é a soma de (Valor do Item + ICMS/ST + DIFAL).
**Causa Técnica e Solução ✅**
O problema residia na rotina de soma desses três componentes. Durante a inclusão de uma nova venda, o valor do **DIFAL** (Diferencial de Alíquota) é frequentemente **nulo**. A operação de soma, ao encontrar um valor nulo, resultava em um cálculo nulo, impedindo que qualquer valor fosse exibido ao usuário.
A **solução** implementada agora inclui uma validação robusta para tratar a **nulidade** de todos os itens envolvidos no cálculo (Valor do Item, ICMS/ST e DIFAL). Caso qualquer um desses valores seja nulo, o sistema atribui o valor **zero** por padrão para fins de cálculo. Isso garante que a soma seja sempre bem-sucedida, e o **valor total do item** seja exibido corretamente ao usuário.
##### 🐞 **Não conformidade ao compactar o arquivo no sincronizador do força de vendas**
Correção realizada, arquivos agora são salvos em ZIP64, possibilitando uma compactação maior de arquivos, mantendo ainda a extensão .ZIP e compatibilidade com os aplicativos.
Correções adicionais realizadas:
\* Melhoria na performance de criação dos bancos de dados — um banco de dados que anteriormente poderia levar mais de 2 horas para ser sincronizado agora sincroniza em minutos.
\* Exclusão automática — Anteriormente o banco de dados do Altus não era previamente excluído para realizar a sincronização, fazendo com que ficasse desnecessariamente grande; isso foi resolvido, agora um mesmo banco que possuía 3.5gb, fica com cerca de 400mb.
##### 🐞 **Não conformidade na geração do arquivo MDF-e**
Corrigida não conformidade no sistema na geração do MDF-e onde o sistema está gerando um erro de Metodo não encontrado:
[](https://info3.nortesys.com.br/uploads/images/gallery/2025-10/ZGnimage.png)
##### **Não conformidade no Cálculo do Valor Total do Item (NVTOTAL) no PDV 🛠️**
Foi corrigida uma falha crítica na rotina de cálculo do valor total do item (*NVTOTAL*) no PDV, especificamente em produtos configurados para venda **atacarejo**. 💥
**Causa e Solução Técnica ✅**
- **Problema Identificado:** O sistema estava incorretamente tratando o campo *QUANTIDADE* como um valor inteiro durante o cálculo do *NVTOTAL* para produtos atacarejo. Essa falha era especialmente crítica para vendas de **produtos com quantidade fracionada** (como itens de balança ou em kg), resultando em erros e imprecisões nos cálculos de valores finais. 📉
- **Valor da Correção:** A rotina de cálculo foi ajustada para reconhecer e utilizar a coluna *QUANTIDADE* como um valor **decimal** (ou *Float*), garantindo que a multiplicação do preço pela quantidade seja precisa, mesmo para valores fracionados. 🎯
**Ajuste na Precisão Decimal do Atacarejo (F5) ⚙️**
Adicionalmente, foi realizada uma melhoria na precisão dos cálculos de preços atacarejo acionados pelo atalho *F5*:
- O uso da conversão *AsCurrency* foi substituído por *AsFloat*.
- **Valor do Ajuste:** Esta alteração evita o arredondamento prematuro após 4 casas decimais que é imposto pelo tipo *Currency*, permitindo que o sistema mantenha a **máxima precisão** nos cálculos intermediários, o que é crucial para evitar divergências de centavos nas transações. 💰
##### **Não conformidade na Validação da Forma de Pagamento (POS) 🛠️**
Foi corrigida uma inconsistência na validação da forma de pagamento que estava categorizando erroneamente a forma **POS** como **Cartão**. 💥
**Causa Técnica e Solução ✅**
- **Problema Identificado:** A validação estava sendo realizada por meio dos **índices de opções** de um componente *RadioButtonGroup*. Esse método de validação baseado em índices é inerentemente **frágil e sensível**, pois qualquer alteração na ordem das opções do componente gera uma divergência imediata na lógica de validação.
- **Solução Técnica:** Foi restaurada o índice de opções anterior, para que o método de va
##### **Não conformidade na Aplicação de Descontos no PDV e Validação de Limites 🛠️**
Foram realizadas diversas correções e melhorias no sistema PDV, focando na lógica de aplicação de descontos e na segurança via autenticação. 🔒
**Correção na Autenticação de Desconto Master ✅**
- **Problema Identificado:** Quando a configuração **“Venda PDV > Quando o desconto for superior ao configurado para Fiscal, deseja liberar com senha MASTER?”** estava habilitada, o sistema falhava em solicitar a senha master e aplicava o desconto sem autenticação no cenário em que o desconto era dado em **valor monetário (R$)**. A solicitação de senha funcionava corretamente apenas quando o desconto era em percentual (%). 💥
- **Valor da Correção:** O problema foi corrigido. O sistema agora verifica corretamente o tipo de desconto (R$ ou %) e, quando o limite fiscal é excedido e a configuração está habilitada, a **senha master é devidamente requisitada**. Isso garante a **segurança** e o **cumprimento das regras de desconto** em todas as formas de aplicação. 🚀
**Melhoria na Validação de Valores de Desconto 🎯**
- **Aprimoramento Implementado:** O processo de validação dos valores de desconto inseridos pelo usuário foi aprimorado. Anteriormente, era possível que o usuário informasse valores de desconto que **excediam o valor total do item ou o valor total da venda**.
- **Valor da Melhoria:** O sistema agora realiza as **validações necessárias**, impedindo a inserção de descontos superiores aos valores legítimos da transação. 💰
##### **Não conformidade na Chamada Indevida da Precificação Inteligente no Balcão de Vendas 🛠️**
Foi corrigida uma não conformidade no Balcão de Vendas que afetava o fluxo de adição de produtos. 💥
**Causa e Solução Técnica ✅**
- **Problema Identificado:** A função de **precificação inteligente** (que solicita ao usuário a seleção da tabela de preços) estava sendo **indevidamente chamada** no momento em que o produto era selecionado para inclusão na venda. Essa chamada precoce e desnecessária interrompia o fluxo normal da operação. 🖥️
- **Valor da Correção:** O código foi ajustado para **remover a chamada indevida** dessa função na rotina de seleção de produtos. Isso garante que a função de precificação seja acionada somente quando necessário, resultando em um **fluxo de trabalho mais rápido e contínuo** para o operador. 🚀
##### **Não conformidade na Atualização do Preço Atacarejo por Alteração de Quantidade 🛠️**
Foi corrigida uma não conformidade significativa onde o valor do desconto **atacarejo não era atualizado** corretamente quando a quantidade de um item era alterada para um valor **abaixo do mínimo** exigido.
**Causa Técnica e Solução ✅**
O problema era que a rotina de atualização de preços estava vinculada apenas ao evento de pressionar a tecla **Enter**. Isso criava uma falha: o operador podia aplicar o desconto de atacarejo, reduzir a quantidade (abaixo do mínimo) e, ao navegar para outro campo usando o mouse ou a tecla *TAB*, o sistema falhava em recalcular e remover o desconto indevidamente mantido.
A **solução** foi refatorar a rotina de atualização de preços para ser acionada de forma mais abrangente após a alteração da quantidade. Isso garante que o sistema **reavalie o preço atacarejo** imediatamente ao sair do campo de quantidade, garantindo que o desconto seja **removido** sempre que a quantidade mínima não for atingida.
##### **Não conformidade na Validação *Case-Sensitive* em Funções de Parcelamento 🛠️**
Foi corrigida uma não conformidade crítica que afetava três funções essenciais de manipulação de parcelas, devido a uma validação incorreta do nome da coluna de código da forma de pagamento.
**Análise da Causa Técnica e Solução ✅**
As três funções falhavam porque, ao validar a existência da coluna do código da forma de pagamento no conjunto de dados, o sistema estava executando uma comparação **sensível a maiúsculas e minúsculas (case-sensitive)**.
Este comportamento é incompatível com o padrão do SGDB utilizado pelos sistemas Nortesys (SQL Server), que é *case-insensitive* por padrão.
A **correção** foi refatorar a validação para que ela **desconsidere o *case-sensitive*** ao verificar o nome da coluna. Isso garante que as funções de **alterar**, **excluir** e **limpar parcelas** agora funcionem corretamente, independente da capitalização do nome da coluna.