Issue | Resumo | Número do caso | | BIGRETAIL-127980 | Atualizado a versão do MidClient 8.1.0 para atendimento da NT Alterações: Leiaute do QR-Code Versão 3 da NFC-e; Demais alterações |
| | BIGRETAIL-127657 | O problema ocorre porque, quando um valor total é dividido em partes (como uma parte fiscal e uma não fiscal) e essas partes são arredondadas para os centavos, a soma delas pode não bater perfeitamente com o total original. Exemplo:
Um cliente faz um pagamento de R$ 100,00. O sistema calcula a parte fiscal do pagamento e, devido a arredondamentos, ela se torna R$ 76,99.
A parte não fiscal, também após cálculos e arredondamentos, resulta em R$ 23,02.
Se somarmos essas duas partes (R$ 76,99 + R$ 23,02), obtemos R$ 100,01. Isso significa que sobrou um centavo em relação ao pagamento original de R$ 100,00.
Foi criada função que compara a soma das partes calculadas com o valor total original do pagamento.
As regras de ajuste seguem uma lógica de prioridade e cascata:
1 - a parcela não fiscal absorve essa diferença, seja ela positiva (se faltarem centavos, a parcela não fiscal é incrementada) ou negativa (se sobrarem centavos, a parcela não fiscal é decrementada).
2 - caso a parcela não fiscal não possua valor suficiente para cobrir uma diferença negativa (ex: o valor que precisa ser abatido é maior do que a própria parcela não fiscal), ela é zerada e o restante do ajuste é transferido para a parcela fiscal.
3 - Por fim, se a transação não possui uma parcela não fiscal (o percentual não fiscal é zero), qualquer diferença é diretamente ajustada na parcela fiscal. Essa mesma lógica de precisão é aplicada também para os valores em outras moedas, assegurando a integridade dos dados financeiros. | 04159001 | | BIGRETAIL-127474 | Verificado que durante a verificação na anulação dos tef´s cancelados na varredura dos tef´s efetuados o banrrisul não estava considerando mesmo após o cancelamento que o tef já foi cancelado, causando o cenário do erro. | 04131889 | | BIGRETAIL-127230 | BIGRETAIL-127230
[HERVAL] Mensagem de troca não permitida ao tentar emitir vale troca
Foi feita uma correção no fluxo de geração de vale troca para pegar a quantidade correta dos itens que já foram trocados, como o PDV verifica a quantidade total com a quantidade já trocada para prosseguir ou não com a troca, com essa correção o problema não vai mais ocorrer. Além disso, solucionando problemas de exibição incorreta da quantidade de itens já trocados. | 04119563 | | BIGRETAIL-127223 | Vai ser ajustado a montagem do item pagamento vale troca para subir corretamente no banco. | 04120307 | | BIGRETAIL-126950 | BIGRETAIL-126950-herval-pedidos-faturados-no-pdv-constam-como-checkcout-e-ou-em_processamento-na-tabela-srvped_pedido
Foi adicionado uma validação para caso o pedido já tenha sido pago e o servidor de pedidos esteja fora no momento de alterar o status no banco, assim que o servidor voltar o pdv ira atualizar o status do pedido no banco na tabela srvped_pedido. | 04093801 | | BIGRETAIL-126402 | O storex-kernel inicialmente não estava preparado para capturar os dados de tipo de desoneração e alíquota de desoneração da tabela produtos_loja. Com isso, esses valores não eram corretamente propagados para o banco H2 do PDV.
Após ajustar esse ponto, identificamos que, no código já existente na aplicação, o valor registrado como montante de desoneração era, na verdade, a alíquota de desoneração — o que estava incorreto.
Corrigidos esses aspectos, o cliente questionou a fórmula utilizada para o cálculo do montante de desoneração. Em reunião, foi esclarecido que a fórmula aplicada era a mesma utilizada para todos os produtos dos clientes HBL. O cliente se comprometeu a avaliar e retornar qual fórmula deveria, de fato, ser adotada.
Ao final, manteve-se a fórmula usada nos clientes HBL/DPSP:
ontante de Desoneração =
((valorNotaFiscal * (1 - (aliquota * (1 - reducaoBaseCalculo))) / (1 - aliquota)) - valorNotaFiscal) | 04032802 |
|