Compatibilidade mínima com Produtos Linx
Aqui você encontra as versões mínimas dos produtos que estão integrados com o Storex HC!
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 | 6.21.0 | |
Tesouraria | 4.2.13 | |
Servidor de Configuração | 3.3.0 | ftp://ftprec.linx.com.br/Produtos/LINX SERVIDOR CONFIGURACAO |
Portal Big Retail | 3.48.0 | |
Promo | 7.2.4 | Serviço do Promo |
OPTIMUS-WS | 1.57.2 | ftp://ftprec.linx.com.br/Produtos/safe/OPTIMUS-WS/OPTIMUS-WS |
SAFE-RET | 05.80.00 | |
SERV-MONITORACAO | 4.4.0 | ftp://ftprec.linx.com.br/Produtos/LINX SERVIDOR MONITORACAO/LINX-SERVIDOR-MONITORACAO |
GERENCIADOR-INTEGRACAO-WEB | 1.0.2 | ftp://ftprec.linx.com.br/Produtos/Gerenciador de Integracao Web/GERENCIADOR-INTEGRACAO-WEB |
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
Demanda | Resumo | ID Externo |
| BIGRETAIL-87249 | Alterado a criptografia do usuário para utilizar TripleDES como padrão Motivado por um plano que tem como objetivo ajustar possíveis vulnerabilidades na aplicação, foi solicitada a evolução do tipo de criptografia utilizado para criptografar as senhas dos usuários. Até então era feito o uso tipo DES e foi solicitado a utilização do 3DES para que essa informação sensível trafegue entre as aplicações de uma maneira mais segura. Documento de apresentação: https://share.linx.com.br/x/l5pQGQ |
Itens de sustentação entregues nesta versão
Demanda | Resumo | ID Externo |
| BIGRETAIL-89468 | Realizado ajuste na solicitação da identificação do cartão presente afim de Validar o parâmetro “Solicita documento na utilização de Gift Card” para o pedido RD. | Caso 1498135 |
| BIGRETAIL-89064 | Caso os arquivos de "transacoesBd" sejam corrompidos após um encerramento não convencional, na próxima inicialização do PDV será efetuado a verificação de integridade e, caso necessite, será restaurado os arquivos do backup permitindo a inicialização normal do mesmo. | 1484937 |
| BIGRETAIL-89037 | Reteste realizado no ambiente de HOMOLOGAÇÃO da Leroy em 25/08/2023. Favor reavaliar este caso pois tivemos divergência no teste. Foi realizado teste conforme orientação no Release Notes onde colocamos o mesmo item no pedido sendo uma vez Caixa e outra Retira Externa Agendada e, quando realizamos a troca total dos produtos não temos e envio da troca para o item já faturado. Ao consultar o VA não temos o registro de quantidade no campo devolvido para o item faturado. Anexo evidências para que possam avaliar os pedidos 4000024909 da Loja 19. Teste Realizado; 1 - Criar pedido contendo itens RL e RD informando mesma quantidade de um mesmo item 2 - Realizar resgate do pedido 3 - Realizar troca total, ou seja, selecionando tanto o total de itens RL quanto o total de itens RD. ___________________________________________________________________________________________________________________________________________ Foi diagnosticado que estava sendo enviado errado o objeto de requisição para a atualização dos itens devolvidos. Quando se tinha itens faturados e não faturados na devolução, não estava sendo considerados esses itens faturados, gerando assim uma inconsistência com o serviço do cliente. Foi modificado como é feito o preenchimento das informações da requisição, levando em consideração que existem os itens não faturados. Dessa forma o serviço poderá interpretar a quantidade certa de itens devolvidos. >> STEPS PARA TESTE: 1 - Criar pedido contendo itens RL e RD informando mesma quantidade de um mesmo item (10 itens produto 87737790 com tipo entrega caixa/Retira loja + 10 itens produto 87737790 - forma entrega Retira deposito) 2 - Realizar resgate do pedido 3 - Realizar troca total, ou seja, selecionando tanto o total de itens RL quanto o total de itens RD 4 - Validar request (/ConsultaPedidosDevolucao) e response de sucesso (AtualizaItensDevolvidosCancelados) no log integrador_comunicacao_ws.log - diretório: p2k\bin\logger\comunicacao-ws | Caso 1242422 |
| BIGRETAIL-89035 | Incluído uma verificação para caso não seja possível recuperar a transação após a queda do sistema, será feito a desistência automática da operação para não gerar cupom de troca com valor zerado. | 1469096 |
| BIGRETAIL-88888 | Foi realizado ajuste ao realizar a conferencia dos itens com o pedido. Afim de aplicar corretamente do desconto de fidelização ao item AS. | 1438916 |
| BIGRETAIL-88806 | Verificamos que por ausência da informação da data e hora de retorno retornada pelo SAT tivemos uma situação não tratada que não resultava em erro de comunicação com o SAT. Identificamos que necessitará de uma proteção para situações dessa natureza, onde forçaremos uma nova consulta pela sessão para que sejam retornados os dados completos. Este comportamento inviabilizou o tratamento implementado para resolver notas autorizadas e não retornadas ao Storex. Realizamos o ajuste para que quando houver ausência de informações mesmo a nota autorizada, tenhamos um cenário de problemas de comunicação com o equipamento para que a consulta seja refeita. Caso o operador opte por não tentar novamente teremos um registro pendente a ser tratado, o que não ocorreu neste cenário. | 1463770 |
| BIGRETAIL-88775 | Foi identificado que o valor do frete unitário vem truncado no XML da consulta de pedidos no VA causando divergência de valores na anulação de pedidos ao multiplicar por uma quantidade de produto fracionada. Alterado no recebimento da resposta do VA para recalcular o valor do frete unitário utilizando 4 casas decimais após a virgula. | |
| BIGRETAIL-88747 | Verificamos problemas no momento da subida do pdv após o mesmo ter sido derrubado no momento em que houve o travamento na tela do pagamento com qrlinx. Como foi um cenário específico, que não tem como simular, pois pode ter existido qualquer intervenção por parte do cliente, analisamos o log disponibilizado e verificamos o que aconteceu no problema em questão. Dessa forma a solução realizada foi verificar se no momento do processo de cancelar os recebimentos qrlinx há algum erro, ou falta de algumas informações para o cancelamento daquele recebimento, caso haja, é feito um tentativa de uma forma alternativa, verificando se na cmos do componente existem registros guardados sobre os recebimentos que foram feitos para aquela transação a ser cancelada, caso consiga pegar as informações desse recebimento, é enviado para o serviço wallet uma solicitação de cancelamento. | 1270505 |
| BIGRETAIL-88490 | Foi mantido o desconto funcionário durante o fluxo de recebimento. | Caso 1439063 |
| BIGRETAIL-88412 | Problemas no momento em que é pego os valores de desconto unitário do momento da venda. Fazendo com que os arredondamentos fiquem diferentes no processo do somatório para o valor do vale troca. Dessa forma, considera-se como o desconto unitário, o valor total do desconto aplicado no item dividido pela quantidade total de itens, sem arredondar nesse momento. A partir desse valor é calculado o valor de desconto que será aplicado a partir da quantidade de itens selecionados para a troca, após esse momento é realizado o arredondamento. Dessa forma o valor dos descontos ficam equivalentes ao realizado na venda. | Caso 1424924 |
| BIGRETAIL-88258 | Verificou-se que os dados do cliente era passado erroneamente quando se colocava um vale troca de um cliente por numero vale troca e depois colocava um vale troca por cpf, na qual o cliente era diferente do vale troca buscado pelo número. Sendo assim ao começar todo recebimento vale troca, as informações do cliente do vale troca é limpa, justamente para seja gravado as informações do vale troca corrente. | 1409874 |
| BIGRETAIL-88238 | Foi adicionada validação ao número do voucher lido pelo evento de leitor cartão. | Caso 1406834 |
| BIGRETAIL-87985 | Verificamos que o sistema sempre utilizou a data da transação e em alinhamento com o cliente resgatamos a informação da concepção do serviço de atualização do status onde deveríamos usar a informação do fechamento do cupom ou pagamento. Será utilizada a data e hora do fechamento do cupom na tag da data de transação enviada na atualização de status do pedido. | 1403213 |
| BIGRETAIL-87976 | Foi verificado que a conferência de itens no pedido não estava correta quando era vendido itens iguais aos que estavam no pedido do tipo RL. Dessa forma após fazer a separação dos itens para associar aos que serão do pedido e aos que não serão, coloca o número do pedido para os que estão associados a ele, e coloco a valor 0 (zero), para os que não estão associados, no caso, que serão venda de itens auto serviço. | 1368941 |
| BIGRETAIL-87927 | Verificamos que nas vendas identificadas com funcionário o método que resgata as informações do endereço não estava informando o bairro no atributo esperado. Foi realizado o ajuste nesse ponto e reforçado a obtenção da informação no ponto responsável pela criação da requisição que será enviada à SEFAZ. | TP 58929539 / CS 1398556 |
| BIGRETAIL-87720 | Foi identificado que usuários bloqueados poderiam efetuar autorizações de operações normalmente no PDV, foi feita a correção para que não seja possível autorizar uma operação caso o autorizador esteja com o status de bloqueado. | TP 57276332 / CS 1242050 |
| BIGRETAIL-87654 | Foi diagnosticado que o item de devolução no processo que estava sendo realizado no momento, era pego de uma outra devolução feita anteriormente. Dessa forma abrir a tela de informações dos itens para a troca, a lista de elementos selecionados é limpa para que não fique informação anteriormente registrada. | TP 58802015 / CS 01354065 |
| BIGRETAIL-86642 | O ponto específico da falha não foi evidenciado nos logs enviados. Temos um intervalo de notas que não constam nos logs. Verificamos que um ponto específico de poweroff não era tratado da forma correta, pois, a chave da nota já havia sido atualizada na transação e fora usada para o posterior cancelamento por substituição mas a nota seguinte não foi forçada a emissão em contingência, inviabilizando o processo de cancelamento por substituição. Passamos a verificar o preenchimento da informação da nota que será substituída para determinar o tipo de emissão da próxima nota. Foi possível reproduzir o cenário em ambiente de desenvolvimento ao encerrarmos a aplicação com os mesmos dados observados nos logs enviados da loja 0009 e PDV 13. | TP 58471371 / CS 01293632 |
BIGRETAIL-87980 | - Parâmetros dos serviços: SERVICO_VA, SERVICO_VOUCHER, SERVICO_ADEO_IDB_FUNCTIONS_CLIENT e SERVICO_DATA_CAPTURE_LOYALTY_CLIENT migrados para o servidor de configuração: - Parâmetro de reinicializar o PDV automaticamente durante a redução Z, migrado para o servidor de configuração. link: https://share.linx.com.br/x/azMzG | |
BIGRETAIL-88491 | A pedido do cliente, para que possamos realizar autorização de notas via SAT e NFCe sem rejeições, foi implementado o tratamento para campos do endereço que permitam até 60 caracteres e estejam enviando (baseado no cadastro) mais de 60 caracteres. |