Compatibilidade mínima com Produtos Linx
Aqui você encontra as versões mínimas dos produtos que estão integrados com o Storex Farma!
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-Standard | 2025.1.25.0 | ftp://10.4.229.5/Produtos/BD-Standard |
Portal Big Retail | 4.10.0 | ftp://10.4.229.5/Produtos/Portal Big Retail |
Servidor Pedidos | 4.72.0 | ftp://10.4.229.5/Produtos/SERVIDOR DE PEDIDOS/SERVIDOR |
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-133010 | Não havia sido feita a compatibilização da MicIncluiItemPedido com os novos campos de validade e fabricação. AJustamos o fluxo para que os campo fosse solicitados durante o resgate de pedido softium. | |
| BIGRETAIL-132986 | No fluxo de pedidos esse campo não era mapeado dentro do AnalisadorConferenciaPedido Ajustado o fluxo para que o campo seja mapeado e repassado no Item do Pedido | |
| BIGRETAIL-132946 | Ao efetuar uma transação pbm via GDB o PDV não validava os campos de NFE, dessa forma ocorria um null pointer Ajustado o fluxo para que valide qual dados de danfe deverá ser retornado para setar na transação pbm | |
| BIGRETAIL-132583 | O objetivo desta funcionalidade é realizar vendas alto custo para emitir NF-e para clientes com CPF. Clientes com CPF deverão através de uma venda alto custo ao atigir o gatilho de valor obrigatoriamente receber a NF-e (modelo 55). Sendo assim o Storex PDV será evoluido para que os clientes que desejam informar o CPF no incio da venda, deverá emitir NF-e (Modelo 55) através do Storex PDV. Hoje, o ecossistema da DPSP opera somente um modelo fiscal. | |
| BIGRETAIL-132551 | Durante a inclusão do TIPO_NFE na Trans Venda, caso a transação não possuía o atributo a aplicação não atribui como null. Ajustamos o fluxo para que caso o atributo venha vazio o PDV coloque null. | |
| BIGRETAIL-132333 | Durante a impressão na impressora física a mensagem customizada é duplicada Ajustamos o fluxo para que a mensagem seja impressa da forma correta | |
| BIGRETAIL-132276 | O mapeamento do campo não estava sendo realizado para que seja persistido na coluna como era esperado segundo a EF. Ajustamos o fluxo para que seja populado o campo e persistido na coluna. | |
| BIGRETAIL-132249 | Durante uma venda de cupom não fiscal o PDV ao identificar que o cliente era do tipo CNPJ estava chamando incorretamente a tela de cadastro de cliente. Ajustamos o fluxo para que o PDV ao identificar que se trata de um cliente do tipo CNPJ ele valide também se é uma venda de CUPOM NÃO FISCAL, dessa forma o fluxo de VNF ficará inalterado. | |
| BIGRETAIL-130865 | Possibilitar emissão da NFC-e para clientes identificados como PJ. Clientes CNPJ deverão obrigatoriamente receber a NF-e (modelo 55). Premissas e/ou Restrições: Premissas: Api de emissão de NFE Online e disponível para os testes Ef aprovada pelo cliente e P&D antes do incio do projeto Cliente de comunicação com a api de emissão no lws concluído e disponibilizado. Escopo negativo: O projeto não contempla alterações para clientes com CPF A DPSP não possui lojas em todos os estados, o que inviabiliza a emissão correta de NF-e comum em alguns casos por isso não serão enviado o endereço e a tributação será enviada com base na tributação da UF corrente da emissão na loja Não terá contingência offline, somente de forma online. (Caso haja alguma rejeição a venda será cancelada. EF: https://share.linx.com.br/pages/viewpage.action?pageId=611091330 |
Itens de sustentação entregues nesta versão
Issue | Resumo | Número do caso |
| BIGRETAIL-133065 | Verificado que no caso de solicitar a desistencia do pagamento em qrlinx era realizado uma confirmação de cancelamento na iteração com o tef e com isso caso o operador desistisse o contador do tef na iteração do tef era necessário finalizar para que a operação tef fosse encerrada. Efetuado tratamento no storex para encerrar a iterçaão com o tef ao confirmar a desistência do recebimento em pix. | |
| BIGRETAIL-133037 | BIGRETAIL-133037: Foi feita uma validação no valor do objeto da cmos antes de concatená-lo a uma mensagem para exibir popup | 04632987 |
| BIGRETAIL-133022 | BIGRETAIL-133022: Foi implementada uma comparação entre as informações da primeira e da segunda passagem do pedido no ConversorPedidoEasyOrder para preencher o dado de convênio do ItemPedido caso esteja nulo. | |
| BIGRETAIL-133017 | Durante o cancelamento de um pedido Softium o PDV acabava por limpar os dados do pedido durante a execução da MicConfirmaMotivoCancelamento e dessa forma não liberava o mesmo para Caixa durante a execução da MicLiberaPedidoCaixa. Ajustamos o fluxo para que caso o pedido em cacncelamento for do tipo softium o mesmo ainda exista na cmos para que durante a execução da mic que libera os pedidos para o caixa, seja alterado o estado do pedido. | |
| BIGRETAIL-132692 | BIGRETAIL-132692-nao-esta-permitindo-identificacao-de-cnpj-no-final-da-venda-ima-vez-informado-cpf-no-inicio Verifiquei que ao fazer esse processo o analisadorCpfCNPJ não validava a nova digitação sendo assim mantinha a mascara de cpf com o valor antigo não atualizando para o valor novo podendo ser um novo cpf ou um cnpj. | |
| BIGRETAIL-132616 | BIGRETAIL-132616-apos-erro-de-impressora-pdv-nao-escreve-na-mfde-reimpressao-sangria-leitura Ao ocorrer um erro de impressora no final da venda e fazer uma reimpressão não estava salvando as informações na mfde. Após ajustar esse ponto o pdv gravou na mfde. | |
| BIGRETAIL-131996 | Durante a aprovação da venda, o PDV recebeu uma resposta nula do autorizador (MID) e iniciou o fluxo de contingência para a NFC-e. Ao executar a verificação de estado de contingência, o sistema tentou criar uma nova conexão com o banco de dados. Essa ação desencadeou um erro fatal de OutOfMemoryError, pois a aplicação já havia atingido o limite de threads do sistema operacional devido a um vazamento de recursos preexistente. Foi identificado que o método de verificação de contingência criava um objeto para nova conexão com o banco de dados que não era utilizada para nenhuma operação, deixando esses objetos inválidos em memória, causando um outOfMemory, dessa forma, a solução foi a remoção dessa criação indevida do objeto, evitando o erro. | 04539092 |
| BIGRETAIL-131945 | Durante um resgate de FP onde após o operador informar a autorização da mesma, houve uma nova tentativa com uma nova autorização que aparentemente seria de outra PBM, nesse momento o PDV acaba informando que a autorização não foi encontrada na FP e acaba por limpar o pedido FP anteriormente setado na cmos. Dessa forma há inconsistência na gravação dos itens no banco. Ajustamos o fluxo para que siga a regra de PBMs em que a mesma autorizadora PBM não pode ser resgatada duas vezes na mesma venda. Dessa forma ao informar uma FP e tentar novamente o PDV irá informar que a PBM já foi informada. | 04531262 |
| BIGRETAIL-131895 | Atualização de versão - MID-E-CLIENT-8.7.1 | |
| BIGRETAIL-131862 | BIGRETAIL-131862-nota-autorizada-gerando-substituita Foi verificado que na venda adicionada na issue houve um atraso de retorno do mid, então caso o parâmetro PARAM_NFCE_TIMEOUT_ENVIO em parametrosGeraisPDV não esteja preenchido, como default o tempo fica sendo 10 segundos e no log do mid mostra que o retorno de autorização demorou 21 segundos. Sendo assim aumentamos o tempo de espera de retorno de autorização do mid para 30 segundos. | 04525307 |
| BIGRETAIL-131772 | BIGRETAIL-131772: Foi implementada uma lógica para na liberação da impressora só cancelar um cupom se ele não tiver sido transmitido | 04517652 |
| BIGRETAIL-131653 | BIGRETAIL-131653: Foi realizada uma atualização das informações do produto assim que recebe o desconto para garantir de que não vai se perder o desconto de grupo | 04509227 |
| BIGRETAIL-131568 | Problema corrigido na versão do Mid MID-E-CLIENT-8.9.1 do seguinte cenário: Aconteceram alguns casos que na base local contém nota antiga que nunca consegue ser enviada para o Fiscal Flow. Essa nota fica impedindo que o processo de Agendamento de Cancelamento aconteça com as outras notas. Os casos aconteceram na DPSP onde o volume de notas é muito alto. | 04503043 |
| BIGRETAIL-131501 | BIGRETAIL-131501 Venda cancelada após aprovação e impressão do cupom Foi feita uma correção na impressão de cupom para que caso ocorra um erro de comunicação com a impressora o PDV siga com a venda e imprima o cupom pela liberação da impressora quando a conexão com a mesma for reestabelecida. | 04492563, 04602388 |
| BIGRETAIL-131499 | BIGRETAIL-131499: Foi criado um método para remoção de chaves canceladas do mapa de produtos desconto | 04493323 |
| BIGRETAIL-131343 | BIGRETAIL-131343: Foi implementada uma lógica para evitar o looping de habilitar e desabilitar pinpad. Além de uma melhoria para acessar um método otimizado ao invés de acessar o periférico diretamente | 04483135 |
| BIGRETAIL-131104 | Verificado que no cliente dpsp foi resgatado o pedido em sequencia pelo operador originando o caso reltado. Verificado que no resgate do pedido pela segunda vez foi constatado no log que o pedido estava com o estado pago mas o infoPedido estava com status de liberado para o caixa. O cenário ocorreu devido a uma instabilidade no serviço durante a atualização do pedido e procedimento feito de forma indevida pelo operador de resgatar o mesmo pedido duas vezes. Incluído validação para olhar tanto o status da capa do pedido quanto do infoPedido que já é feito hoje para bloquear o resgate em caso de um dos status esteja como pago. | 04450759 |
| BIGRETAIL-130914 | Verificamos erro na atualização de lote de produto devido a um erro ocorrido na atualização do registro no banco h2 onde na atualização do índice em um processamento interno efetuado pela lib fazia com que o registro ficasse inacessível. Efetuado modificação no parametro: PROCESSA_INDICES_LUCENE = false no arquivo PametrosGerais.properties para com que não seja criado o índice do lucene. | 04487196 |
| BIGRETAIL-130783 | Efetuado modificação para que após a notificação do erro no SP seja locado e removido a base mas não efetue uma nova geração para que seja dado continuidade na geração para outras lojas e outras solicitações. Sobre a falta de espaço em disco foi orientado ao cliente validadar a estrutura e arquivos da máquina para que seja disponibilizado mais espaço uma vez que o storex SP não estava com um tamanho fora do normal em sua estrutura. | 04430594, 04522229 |
| BIGRETAIL-129966 | BIGRETAIL-129966: Foi implementada uma lógica para na liberação da impressora só cancelar um cupom se ele não tiver sido transmitido | 04354343, 04362718, 04464075 |
| BIGRETAIL-129899 | BIGRETAIL-129899-16-58-00-venda-cancelada-somando-no-fechamento-como-venda-boa Adicionado a correção para quando o pdv sofrer um power off ao final da venda não retorne em tela de recebimento mesmo após o pagamento evitando assim divergência no fechamento. | 04354058 |
| BIGRETAIL-129896 | BIGRETAIL-129896: Foi implementada uma lógica para na liberação da impressora só cancelar um cupom se ele não tiver sido transmitido | 04353952 |