Compatibilidade mínima com Produtos Linx
Aqui você encontra as versões mínimas dos produtos que estão integrados com o Storex Pos Herval!
Caso a versão de algum dos produtos esteja inferior às listadas, realize a atualização do produto!
O correto funcionamento desta versão requer que as aplicações abaixo estejam atualizadas nas versões corretas!
Produto | Versão | Caminho |
|---|---|---|
| BD-STOREX | 2025.1.13.0 | |
| LINX-WEBSERVICE | 3.33.0 | |
| STOREX-KERNEL | 3.2.0 | http://10.4.229.162:8081/#browse/browse:maven-releases:linx%2Fcomponente |
| STOREX-POS-STANDARD | 3.3.0 | |
| STOREX-EP-HERVAL | 3.6.0 | |
| STOREX-SP-HERVAL | 3.11.0 | |
| INT-TRANS-HERVAL | 3.18.0 | ftp://10.4.229.5/Produtos/HERVAL/LINX STOREX INT TRANS CUSTOM |
| SERV-CONFIGURAÇÃO | 5.1.0 |
Configurações necessárias para funcionamento correto da aplicação
Aqui você encontra as configurações necessárias para a atualização da versão!
As instruções estão agrupadas por versão! Fique atento às orientações para configurar corretamente sua aplicação!
Conteúdo da versão
Itens de Legislação Fiscal entregues nesta versão
Não há itens de legislação entregues nesta versão!
Evoluções e melhorias entregues nesta versão
Issue | Resumo | Número do caso |
| BIGRETAIL-128311 | BIGRETAIL-128311-BR.095775.2025.006 - Ajuste API Parcelas O setor de Consórcio identificou a necessidade de realizar um ajuste no número do aviso utilizado em seu ERP. Para atender a essa demanda de negócio, foi necessário alterar o formato do campo nroAviso. Com isso, foi realizada a modificação do tipo do dado "nroAviso" do tipo "INTEIRO" para o tipo "STRING" para o endpoit ".../recebimento-parcelas/parcelas/pagamento", garantindo assim que o campo agora aceite 12 caracteres para o número do aviso. |
Itens de sustentação entregues nesta versão
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 |