Issue | Resumo | Número do caso |
| BIGRETAIL-139580 | Oferecer somente condição de pagamento ativa na simulação de parcelas
Objeto alterado:
V_CONDICAO_PAGTO_VENDA_CAMP
Evidência de testes: https://share.linx.com.br/pages/viewpage.action?pageId=664879808 | 03593310 |
| BIGRETAIL-139387 | Controle de status no pedido de venda
Objeto alterado:
PRCD_ALTERA_DADOS_JAVA
Evidências de testes: | 05257495 |
| BIGRETAIL-139346 | Objetivo:
Voltar a enviar o numero dos bilhetes de garantia na integração.
Objetos alterados:
PRCD_INTEGRA_SERVICO
Como validar:
Fazer um venda com garantia e pagar;
Verificar se é enviado na integração o numero de bilhete de garantia. |
|
| BIGRETAIL-139215 | CAUSA: A rotina que gera a nota de entrega, estava considerando produtos com substituição tributária, produtos que estavam com o campo PRODUTO_FISCAL.CD_ICMS_SUBST_SAI populado.
CORRECAO:Como o campo CD_ICMS_SUBST_SAI da tabela PRODUTO_FISCAL, não era correto para ser a referência do produto ter ou não ST. Modificamos a rotina que gera a nota de venda para usar como referência o campo PRODUTO_FISCAL.ID_CTF=60.
Corrige também o issue: BR-139338
Evidências:
https://share.linx.com.br/x/cQ6hJw | 05244691, 05255748 |
| BIGRETAIL-139016 | CAUSA: Rotina de integração com o dado de sistemaIntegracao VAREJOEM ao invés de LINX.
CORRECAO: Corrigido o conteúdo da tag sistemaIntegracao de VAREJOEM para LINX.
Evidência:
https://share.linx.com.br/x/-IaOJ | 05220155 |
| BIGRETAIL-138987 | Objetivo:
Exibir o estoque do seguro vida, com base na quantidade de números da sorte disponíveis.
Objetos alterados:
FNCT_RET_ESTOQUE_LOJAS
EVOLUCAO_SEGURO_NUMERO_SORTE
PCKG_SEGURO
SEQ_NUM_BILHETE
Como validar:
1- Realizar a busca do seguro de vida, tanto pelo cogigo, quanto pela descrição;
2- Realizar uma venda de seguro;
3-Consultar o produto novamente pra ver se baixou o estoque;
Conforme demonstrado nas observações dessa issue |
|
| BIGRETAIL-138950 | BIGRETAIL-138950
NOTA: Alteração de EF.
Devido a mudança da EF , foram adicionado os seguintes cenários:
5. PJ Não Contribuinte Fora do Estado
Retira Posterior com Estoque: Gera NF-e
Entrega com Estoque: Gera NF-e única.
Sem Estoque: Segue o fluxo atual de NF-e de entrega futura.
6. PJ Não Contribuinte Dentro do Estado
Retira Posterior com Estoque: Gera NF-e.
Entrega com Estoque: Gera NF-e.
Sem Estoque: Segue o fluxo atual de NF-e de entrega futura.
Para pedidos que geram NFCE já vêm marcado pelo VA, esses pedidos não passam pelo processamento
das rotinas que modificamos aqui. O que foi modificado foi justamente cenários onde iria gerar notas
71 para vendas com estoque.
---------------------------------------------------------------------------
BIGRETAIL-139163
CAUSA: A trigger TRGR_EMISSAO_NF_VENDA_FUTURA criava nota 71 para uma venda tipo retira posterior com estoque.
CORRECAO: Foi corrigido a verificação do pedido para não gerar notas 71 para casos de venda com estoque retira e posterior.
---------------------------------------------------------------------------
Outros cenários, que a rotina estava gerando nota 71 para venda com estoque:
BIGRETAIL-139302 - Vai gerar nota ttr=2
BIGRETAIL-139337 - Vai gerar nota ttr=2
Evidência:
https://share.linx.com.br/x/VbGDJw | 05243353, 05252748, 05256675, 05274906 |
| BIGRETAIL-138869 | CAUSA: CSTAT 999 não era considerado pela trigger TRG_CUPOM_ELETRONICO
CORRECAO: Adicionado CSTAT 999 no critério de atualização da trigger
Evidência:
https://share.linx.com.br/x/0kVKJ |
|
| BIGRETAIL-138681 | CAUSA: As alterações para processar os pedidos do e-commerce, impactaram no desempenho da query inicial do processo PCKG_INTEGRA_NOTA.DOC_VENDA.
CORRECAO: Foi avaliado o cursor e refeito algumas alterações para o processamento do e-commerce, mantendo o desempenho original da rotina.
Evidência: Em anexo. |
|
| BIGRETAIL-138627 | Geração de script de rollback da versão. |
|
| BIGRETAIL-138594 | CAUSA:Venda com estoque compartilhava o mesmo parâmetros de cfop da venda futura.
CORRECAO:Foi necessário usar outros parâmetros para mapear os cfops da venda com estoque.
Evidência ver anexo | 05175511 |
| BIGRETAIL-138548 | Ajustes nas tabelas CUPOM e PARAMETRO_INTEGRACAO_QRLINX para evitar erros na aplicação. |
|
| BIGRETAIL-138534 | Criar parâmetro que indique que o pedido tipo retira posterior poderá ter transportadora
Objeto alterado:
PRCD_PVD_JAVA.ora
Evidências de teste: https://share.linx.com.br/display/BRPED/BIGRETAIL-138534+-+Entrega+-+%5BBerlanda%5D+%5BVA+UX%5D+Pedido+retira+posterior+com+transportadora |
|
| BIGRETAIL-138224 | CAUSA: Trava criada para não criar linhas repetidas na tabela wmb_cliente_integra, impedia que novas alterações fossem registradas na tabela para o mesmo cliente até que a transação corrente fosse processada.
CORRECAO: Foi colocado um número máximo de linhas (três) que a rotina permite de modificações registradas na tabela wmb_cliente_integra para o mesmo cliente.
Evidência:
Cenário foi validado com o cliente na base de QA Adelino. | 05091081, 05094281, 05130259 |
| BIGRETAIL-138207 | Atenção: Essa issue tem dependência da versão 1.27 do VA, que será tratada para não fechar a tela de endereço quando der a mensagem de erro.
Objetivo: Não permitir cadastrar logradouro nem bairro com menos de 2 caracteres.
Objetos alterados:
PRCD_CLIENTE_ENDERECO_JAVA
Como validar:
-- Abrir o cadastro de um cliente no VA;
-- Clicar para incluir ou alterar um novo endereço;
(obs: pegar um CEP generico, ou seja que não seja especifico de um logradouro. Pegar um CEP na tabela cidade)
-- Tentar cadastrar um logradouro com menos de 2 caracteres --> O VA não deve permitir;
-- Tentar cadastrar um bairro com menos de 2 caracteres --> O VA não deve permitir.
Evidencias colocadas na observação desta issue. | 05060386 |
| BIGRETAIL-137913 | Novo processo que irá apagar as tabelas de logs do VA UX(LOG_JAVA e LOG_VA_JAVA)
Objetos alterados:
DADOS_PARAMETRO_SISTEMA.ora
EVOLUCAO_LOG_VA_JAVA.ora
JOB_PRCD_EXCLUI_AUDITORIA_JAVA.ora
PCKG_VA_UX.ora
PRCD_EXCLUI_AUDITORIA_JAVA.ora |
|
| BIGRETAIL-137912 | Causa:
Foi verificado que, na rotina de envio de cancelamento, o sistema enviava o campo codCli apenas quando o cliente era identificado como estrangeiro.
Solução:
O processo foi ajustado para que o código do cliente (codCli) seja enviado na integração de cancelamento para qualquer tipo de cliente,
Evidências: https://share.linx.com.br/x/KOuDJw | 05024510, 05105871 |
| BIGRETAIL-137495 | Problema: Em vendas com NFC-e em que foram dados descontos nos itens, na integração da NFC-e o desconto era descontado na tag de VLRLIQ do item, porém na tag de VLRLIQ do cabeçalho não.
Solução: Foram feitos ajustes para que o desconto fosse considerado nas duas tag's.
Link de evidências: https://share.linx.com.br/x/YNmDJw | 04974100 |
| BIGRETAIL-137313 | Causa:
Rotina que coleta os dados para geração da tabela wmb_cupom,
para o cenário de cupons com mais de uma nfce (cancelada/invalida + válida)
lia em alguns casos os dados da nota tpemis=1 ao invés dos dados da nota
tpemis=9 (nfce que será a nota válida).
Correção:
Foi atualizado a ordenação da rotina que gera os dados na tabela de integração
de cupons (wmb_cupom) para ler os dados da nfce com tpemis=9 primeiro.
Já que esta será a nota válida.
Evidência:
https://share.linx.com.br/x/eCVtJw | 05022084 |
| BIGRETAIL-137285 | Problema: O nosso sistema não enviava ao Senior a confirmação dos dados dos clientes que foram consumidos.
Solução: Passamos a enviar a confirmação do coonsulmo dos clientes ao senior, sendo confirmado pelo cliente lá.
Link de evidências: https://share.linx.com.br/x/4ttRJw | 04644048 |
| BIGRETAIL-136704 | Causa: Foi verificado que, durante a importação das Notas Fiscais, alguns produtos presentes no XML de retorno estavam com valores contendo até 10 casas decimais.
Solução: O processo foi ajustado para tratar esses valores, limitando a quantidade de casas decimais conforme a definição de cada campo. Dessa forma, campos de quantidade passam a considerar até 3 casas decimais, enquanto campos de valor passam a considerar até 2 casas decimais.
Evidências: https://share.linx.com.br/x/fyWhJw |
|
| BIGRETAIL-136579 | CAUSA:Durante processamento dos dados do pedido, pela rotina que gera a nota 71, o valor do UF destino é alterado para SC , devido uma lógica pré-existente, porém ao avaliar o parâmetro 1117 e validar o endereço de entrega e atribuir o CFOP interestadual, esse dado de UF destino permanece como SC e passado para a rotina que calcula impostos, essa rotina devido os parâmetros altera o CFOP para estadual, com isso a nota fica com o CFOP errado.
CORRECAO: Ao avaliar o parâmetro 1117, devemos restaurar o valor do parâmetro de UF destino para que ao processar os dados pela rotina de calculo de imposto o CFOP fique consistente.
Evidência:
https://share.linx.com.br/x/hT1tJw | 04907938 |
| BIGRETAIL-134268 | Causa:
Ao gerar a devolução de uma nota fiscal com retenção, o VA valida na nota fiscal de saída a existência de valor de retenção. O problema identificado foi que a nota fiscal de saída do CD21 não possuía o valor de retenção registrado, impossibilitando a correta geração da devolução.
Solução:
Foi realizado ajuste na geração da nota fiscal de saída do CD21 para que a aplicação passe a pesquisar a nota fiscal de saída com TTR = 71 e, a partir dela, atualize corretamente os valores de retenção na nota fiscal de saída do CD21.
Evidência: https://share.linx.com.br/x/MZNRJw | 04545531 |