Lista de Issue's Liberadas nesta Versão
Número | Resumo | ID Problema |
BIGRETAIL-71282 | Itens com quantidade zerada não devem ser enviados ao VA. | PRB00022003 |
BIGRETAIL-71279 | Segundo pagamento pix estava cancelando o primeiro pagamento. Levanto para a confirmação apenas um pagamento. Detectamos a causa raiz do problema e o corrigimos. | PRB00022056 |
BIGRETAIL-71277 | Depois de realizar o pagamento parcial de uma venda com resgate de pedido foi pressionada a tecla volta para que fossem inseridos mais itens autosserviço. Ao retornar para venda foi realizada uma tentativa de exclusão da transação da venda corrente sem sucesso, essa venda acabou subindo para o banco indevidamente. Foi realizado um ajuste na manipulação da base de transações para que a transação possa ser excluída como esperado sem que fique uma transação inconsistente na base. | PRB00022017 |
BIGRETAIL-71276 | Durante a converção do pedido, o Storex PDV passou a captar a informação de código de IBGE e atribuir as informações do pedido que segue para o objeto da transação durante o percurso de finalização do resgate no PDV. | PRB00021929 |
BIGRETAIL-71269 | Storex PDV não conseguiu recuperar os motivos de devolução no proctrans. O log do Storex pdv não estava exibindo o erro que ocorreu, dificultando a descoberta do origem do problema. Seguimos com a implementação de um código padrão para este tipo de cenário (1 - DESISTÊNCIA) e adicionamos logs. | PRB00021864 |
BIGRETAIL-71261 | Transação de Pagamento chegou ao proctrans primeiro que a transação pai (transacao_p2), não a adicionando no banco Oracle. Alterado código para diminuir a possibilidade do problema se repetir. | PRB00021822 |
BIGRETAIL-71258 | Necessário adicionar uma mensagem de processo finalizado para indicar ao operador que ele pode pressionar entra para continuar. Realizamos a implementação deste item conforme atualização da EF. | |
BIGRETAIL-71115 | Houve um NullPointException no usuário autorizador, no momento do resgate cancela. Apesar de já existir tratamento, ele não foi eficiente. Adicionamos mais uma proteção, validando o preenchimento do usuário autorizador. | PRB00022107 |
BIGRETAIL-71050 | Problema gerado por conta de intervenção manual na recuperação do PDV. Notamos que no processo o usuário foi informado incorretamente, o que acarretou numa utilização indevida do PDV onde o número da nota foi inicializado gerando inconsistência no controle. Foram incluídas proteções para esses cenários, incluindo mensagem de emissão de cupom indisponível. Os detalhes do ocorrido foram inseridos nos logs. Para tentativa de reprodução do cenário segue sugestão: 1. Renomear a base do MIDeClient (\p2k\bin\MIDeClient.h2.db) 2. Renomear o arquivo local de controle (exemplo do meu PDV que termina com 844 e o CNPJ de testes da Linx \p2k\bin\54517628001593844). Se não tiver inicialização da CMOS os números seguirão o que estiver na CMOS de forma indevida. 3. Configurar o usuário do client com erro, adicionei um "t" ao que utilizamos nos nossos ambientes (exemplo: fabricacsi.hml.client -> fabricacsi.hml.clientt). 4. Subir o PDV e tentar autorizar NFCe. Antes de aplicar a versão com a correção o PDV ficava em loop com a mensagem de contatar o administrador do sistemas. Depois de aplicada, aparece a mensagem de emissão de cupom indisponível e no log o detalhe que as configurações devem ser revistas. 5. Derrubar o PDV e ajustar o usuário do client (exemplo: fabricacsi.hml.clientt -> fabricacsi.hml.client). 6. Subir o PDV e verificar que a autorização de NFCe foi normalizada e não houve pulo de nota. |