Lista de Issue's Liberadas nesta Versão
| Issue | Resumo | Número do Caso |
| BIGRETAIL-108164 | Removida a validação de pouco papel na abertura de caixa | 02603131 |
| BIGRETAIL-108162 | Removida validação de gaveta fechada na abertura de caixa | 02603109 |
| BIGRETAIL-108160 | Aumentado o tempo de pausa de 1min para 3min | 02603154 |
| BIGRETAIL-107828 | Devido a uma implementação da funcionalidade de envio de nota por email, impactou na geração da nota, quando o pagamento total da venda era realizado com cartão pnb credito/debito, foi refatorado o trecho do codigo que modificava o tipo e identificação do cliente, para seguir o padrão implementado antes da funcionalide de envio de nota por email. | 02576239 |
| BIGRETAIL-107595 | Retirado a obrigatoriedade de fechar a gaveta ao finalizar o fechamento z | 02568034 |
| BIGRETAIL-107406 | O desconto trade up não estava sendo enviado para compor os dados da nota, assim os pagamentos não consideravam o desconto dado na compra causando o erro de valor da nota maior que o valor dos pagamentos. | 02563180 |
| BIGRETAIL-107183 | Criado o MonitorFTP para acompanhar todo o processo de download e determinar o tamanho final do arquivo e seu MD5, afim de localizar futuramente qualquer eventual erro no processo de carga de base. | 02552366 |
| BIGRETAIL-107095 | Criado mecanismo para retornar o buffer quando o limite do cartão for excedido. | |
| BIGRETAIL-106983 | Durante as vendas pagas com QRLinx o pdv estava ultilizando a mesma chave de carrinho para todos os recebimentos wallet, assim se tivesse um cancelamento antes de um recebimento ultilizando a mesma chave, o recebimento só poderia ser confirmado caso o cancelamento fosse confirmado primeiro. | 02538077 |
| BIGRETAIL-106928 | Feito adequação solicitada pelo SITEF para receber o retorno da resposta 51 do cartão com os dados de limites a serem exibidos no PDV. | |
| BIGRETAIL-106519 | Inclusão do titulo conforme solicitado pelo cliente | |
| BIGRETAIL-106504 | Foi realizada uma alteração para considerar o desconto de trade up no valor total da divida ao retornar para a VENDA (após totalização), evitando problemas na remoção dos descontos de campanha (não duplicando). | 02514236 |
| BIGRETAIL-105985 | Foi realizada a correção para exibir corretamente os descontos do trade up nos itens do cupom de cancelamento, e ajuste de total de descontos no fechamento (casos de trade up + campanha), não ocorrendo erros de divergência na Redução Z. | 02482722 |
| BIGRETAIL-105882 | Essa melhoria tem como objetivo garantir que a adesão de Pfins não seja duplicada ou geração indevida de contrato. Gerando prejuízo para e empresa e possibilitar o Desfazimento das vendas, caso seja necessário o cancelamento da adesão durante a venda ou não efetivação da venda por erro sistêmico. | |
| BIGRETAIL-105834 | Retirada da chamada da API conforme solicitado na EF: http://osb-pfsa.pernambucanas.intranet/pdv-neurotech-esb/porting/executarFluxoComParametros | 02476895 |
| BIGRETAIL-105705 | Com o provedor tef Sitef, o pdv não estava executando o fluxo de cancelamento do credito digital, nas operações de cancelamento. Foi implementado para o pdv executar o fluxo de cancelamento do tef para recargas de credito digital, quando executado o fluxo de cancelamento do credito | 02457961 |
| BIGRETAIL-105586 | Foi verificado que o fluxo não passava pela validação da quantidades máxima de dias para troca com cupom. | 02443116 |
| BIGRETAIL-105542 | Quando ocorria um powerOff de uma venda com trade, ao subir novamente o pdv cancelava a transação e colocava na pendencia, possibilitando o resgate do cupom com desconto trade. Este comportamento estava incorreto, quando a transação com desconto trade é cancelada na subida do pdv, não se deve possibilitar resgatar a mesma via resgate de pendencia. Foi ajustado o fluxo de cancelamento na subida de powerOff do pdv, para impossibilitar o resgate de cupons com desconto trade, cancelados na subida do pdv | |
| BIGRETAIL-105532 | Foi realizada a correção para não permitir a exclusão de itens de uma venda quando apenas houver um único item na venda e o mesmo tenha produto financeiro associado, impedindo a geração de uma nota com valor zerado. | 02457134 |
| BIGRETAIL-105026 | Issue implementada conforme EF | |
| BIGRETAIL-104947 | Caso o IP_EP nao esteja configurado no pdv, Storex irá utilizar o IP_PROCTRANS para atualizar a informação da ulg da base carregada. | 02381400 |
| BIGRETAIL-104783 | Correção no fluxo do cancelamento para evitar duplicidade no desconto e retirada do desconto no cupom. | |
| BIGRETAIL-104727 | Durante o processo de devolução de uma transação com forma de pagamento pix, onde ocorreu um powerOff o pdv estava estornando o pix realizado e indicando para devolver o valor em dinheiro ao cliente. | 02409293 |
| BIGRETAIL-104708 | Durante o cancelamento do cupom, o pdv não estava enviando todos os recebimentos do tipo pix para serem cancelados, era enviado somente 1 cancelamento. | 02411039 |
| BIGRETAIL-104483 | Durante o processo de finalização da venda, ocorreu erro na autorização dos pfins contratados, como esperado o pdv cancelou a venda completa, já que a danfe já tinha sido resgatada, porem os recebimentos eram limpos impedindo que fosse mandado o estorno do pix realizado | 02397998 |
| BIGRETAIL-104338 | Essa melhoria tem como objetivo garantir que a adesão de Pfins não seja duplicada ou geração indevida de contrato. Gerando prejuízo para e empresa e possibilitar o Desfazimento das vendas, caso seja necessário o cancelamento da adesão durante a venda ou não efetivação da venda por erro sistêmico. | |
| BIGRETAIL-104255 | O numero do cupom informado na TransCancAnulaDevTroca sera impresso como COO dda anulacao | |
| BIGRETAIL-104247 | Ajustado o tratamento de retorno de status nas transações com WR, TradeUp e ALTSA. Anteriormente, apenas o status "ACCEPTED" era considerado para o sucesso da transação, conforme definido na documentação disponível. A partir desta atualização, o status "APPROVED" também será considerado como indicativo de sucesso da transação. | |
| BIGRETAIL-104246 | Erro no JavaFX 1.1 contornado modificando a chamada a tela. | |
| BIGRETAIL-104245 | Storex estava recuperando o numero do cupom errado. | |
| BIGRETAIL-104021 | Garantir que o PDV Storex no processo de venda e troca através da comunicação com uma NOVA API envie os dados cadastrais confirmados pelo cliente na tela de dados do cliente para o sistema externo, desta forma possibilitando a gravação dos dados em banco de dados para futura utilização. | |
| BIGRETAIL-103989 | O mesmo comportamento deve ser observado no sistema, tando ao cancelar a digitacao do cpf no pinpad quanto apertando entra sem informar cpf. | 02575701 |
| BIGRETAIL-103707 | Foi identificado que mid-e-cliente 6.24 não estava setando a tag tpintegra = 2 para pagamentos pos off | 02366843 |
| BIGRETAIL-103664 | Foi realizada uma correção para guardar na cmos os parâmetros de autorização e ao iniciar o PDV também carregar (em caso de perda de comunicação com o proctrans), dessa forma mesmo com o PDV Offline, os parâmetros estarão contidos no PDV. | 02292182 |
| BIGRETAIL-103564 | Devido a um retorno não mapeado da api de recarga de bilhete transporte, o pdv não enviou para fila off o cancelamento das recargas efetuadas | 02349792 |
| BIGRETAIL-103562 | Implementada correção para impedir que vendas com desconto TRADE Troca Fácil sejam concluídas caso o IMEI retornado da API esteja nulo. Agora, o sistema valida o IMEI recebido da API antes de permitir a conclusão da venda com desconto TRADE Troca Fácil. Caso o IMEI esteja nulo, a transação não será autorizada, garantindo a integridade e precisão dos dados. | |
| BIGRETAIL-103513 | Desenvolvido do tratamento para desistência de SANGRIA . | |
| BIGRETAIL-103346 | Foi retirado o codigo que adicionava uma segunda linha de nsu, autorizador e se o ep estava online. | |
| BIGRETAIL-103339 | Durante as transações de troca rfid com mais de uma transação, na hora de acumular o valor do vale troca gerado no fechamento do operador, as transações anteriores acumulavam mais de uma vez, fazendo o valor ficar incorreto | |
| BIGRETAIL-103331 | Desenvolvido na aplicação filtro, para vale trocas baseado no numero de dias cadastrado no parâmetro. | |
| BIGRETAIL-103064 | Na inserção do evento transação e item serviço no bd, os NSU_EVENTO do evento transação e item serviço estavam diferentes, estes dados precisam ser iguais para composição da chave mãe, que liga o item vendido ao evento passado na transação do pdv. | 02340724 |
| BIGRETAIL-102905 | Foi alterado a descrição do menu conforme solicitado | |
| BIGRETAIL-102696 | Para regra de desconto por valor de produto na campanha mix and match, o pdv não estava armazenando a variavel no local correto. | 02136367 |
| BIGRETAIL-102513 | Inclusão do desconto em tela conforme descrito na EF | |
| BIGRETAIL-102456 | Realizado tratamento, para que, ao definir envio de nota por e-mail, seja anexo o PDF da nota. | |
| BIGRETAIL-102241 | Desenvolvido na aplicação filtro, para vale trocas baseado no numero de dias cadastrado no parâmetro. | |
| BIGRETAIL-102196 | Ajustado na aplicação, para ser impresso duas vias do cupom de dados do SAQUE. | |
| BIGRETAIL-102148 | Incluído a linha que contém dados da transação do pdv | |
| BIGRETAIL-102114 | Havia uma saída incorreta no fluxo de descontos do pdv, fazendo com que o item com desconto fosse apresentado na tela mas não era incluído na contabilidade da transação, ocorrendo de o valor do pagamento estar correto, porem o item não era passado pra nota, fazendo o valor ser menor que o valor pago, ocorrendo o erro de troco. | 02300903 |
| BIGRETAIL-102037 | No envio das informações do código da autorizadora, para cancelamento do cupom corrente, não é mais alterado o código para enviar somente 6 dígitos, agora enviamos o código completo, da mesma forma que ele é recebido pelo pdv | 02302061 |
| BIGRETAIL-101921 | cupom de troca com itens fiscais e não fiscais, no momento da contabilidade do cupom de troca, o valor do item não fiscal aderido pelo cliente na compra anterior, estava sendo somado ao valor final da troca. Foi removido do calculo do valor final do cupom de troca a somatória dos itens não fiscais, assim garantindo que o valor da troca se dará pelo valor dos itens trocados. | 02292781 |
| BIGRETAIL-101849 | Durante a validação do cpf na identificação do cliente da troca, voltando para tela de itens do cupom o valor total da troca não era resetado nem a quantidade de itens que foram trocados, para o cliente e operador a tela mostrava como se não fosse selecionado nem um item, após a nova seleção o valor era incrementado ao valor da seleção anterior, ocasionando o erro. | 02292168 |
| BIGRETAIL-101760 | Garantir que o PDV Storex no processo de venda e troca através da comunicação com uma NOVA API envie os dados cadastrais confirmados pelo cliente na tela de dados do cliente para o sistema externo, desta forma possibilitando a gravação dos dados em banco de dados para futura utilização. | |
| BIGRETAIL-100649 | Melhoramos a abordagem de captura das exceptions no processo de carga de base, para podermos identificar o produto que contém a informação inadequada. | 02252903 |
| BIGRETAIL-100391 | Durante o pagamento com forma off, o pdv estava trocando a busca da forma escolhida, quando era escolhido a forma com código 112 o pdv trocava para a busca da forma 115 somente para mensagem de exibição da mensagem no teclado | 02232012 |
| BIGRETAIL-100298 | Para as consultas a cep no cadastro do cliente vamos utilizar o barramento de serviços do lws para esta consulta, o barramento de pesquisa de cep do lws prove uma forma mais fácil e rápida de consulta dos endereços dos clientes, já que se trata de um serviço amplamente utilizado em vários cliente linx, por tanto caso seja encontrado uma falha em outro cliente, a correção pode ser espelhada para o cliente altsa, facilitando a manutenção do serviço. | 02134022 |
| BIGRETAIL-100059 | Foi trocado a logica do for para um while com interator. | |
| BIGRETAIL-99339 | O calculo do icms efetivo ocorria corretamente, acontecia que na inserção dos dados dos itens, alguns tipos de itens não eram enviados com a informação do icms efetivo preenchida, assim na conversão das informações passadas do storex para o banco de dados o valor do icms efetivo ia null | 02149573 |
| BIGRETAIL-98827 | O comparador que fazia a ordenação das campanhas por maior valor, não estava preparado para receber campanhas de tipo multi unit e mix and match. | 02117301 |