Issue | Resumo | Número do caso |
| BIGRETAIL-136893 | Merge do hotfix/bd-std-2025.1.8.9 |
|
| BIGRETAIL-136657 | CAUSA: Quando ocorre de outras rotinas criarem linhas na tabela wmb_cupom e wmb_cupom_ic, pode existir a possibilidade de termos uma nfce com cstat=100 que é cancelada momentos depois para cstat=135 , mantendo a wmb_cupom_ic com cstat=100 a rotina até então fazia a amarração pela chave toda da nfce entre wmb_cupom_ic e cupom_eletronico e também pelo cstat, como esse campo pode diferir em algumas ocasiões
CORRECAO: Foi removido o check do cstat.
Evidência:
https://share.linx.com.br/x/o0lrJg | 04982424 |
| BIGRETAIL-136629 | Objetivo:
Fazer o merge da PRCD_CANC_PEDIDO_VENDA_JAVA da versão 2025.1.8.7 para a 2025.1.9.0
Objetos alterados
PRCD_CANC_PEDIDO_VENDA_JAVA
Como validar
Objeto compilado com sucesso. |
|
| BIGRETAIL-136582 | Objetivo:
Trazer na troca Assurant os pedidos que são de "E" ou "P" que tenham emitido NFCe
Objetos alterados:
PCKG_TROCA_GARANTIA
Como validar:
-- Pegar um pedido de "E" ou "P" que tenha emissão de NFCe e tenha também garantia para o produto;
-- Pagar o pedido;
-- Acessar a tela de troca assurant e consultar pelo cliente desse pedido;
-- O Pedido deve ser carregadpo na tela. | 04951414 |
| BIGRETAIL-136509 | Ajuste no cursor de produtos para que sejam carregados todos os produtos presentes na venda independente do cupom. | 04943745 |
| BIGRETAIL-136497 | Objetivo:
Ajustar o script de criação da tabela SEGURO_NUMERO_SORTE
Objetos alterados:
SEGURO_NUMERO_SORTE
Como validar:
Validar se o script rodou com sucesso |
|
| BIGRETAIL-136447 | Causa: Foi identificado que, na consulta de NFC-e Cancelada, a query estava utilizando o campo Sequencial de Retorno da nota, quando o correto seria utilizar o Sequencial de Retorno do Cancelamento.
Solução: Realizado ajuste na query para que passe a considerar corretamente o Sequencial de Retorno do Cancelamento.
Evidências: https://share.linx.com.br/x/dgVrJg | 04962130, 04966509 |
| BIGRETAIL-136408 | CAUSA:O serviço é exibido 2x pois o cupom tem 2 nfces uma com cstat=100 e outra 102
CORRECAO:Adicionado a verificação do cstat=100 na exibição do serviço para nfce
Evidência:
https://share.linx.com.br/x/6SZrJg
Evidência:
| 04960324, 04961709 |
| BIGRETAIL-136370 | Causa: o caso citado ocorreu na rotina PRCD_INT_GET_FULLFILMENT, pois retornou dois pedidos para o mesmo Order. E assim dando erro e não inserindo o pedido na tabela WS_PVD_FULLFILMENT.
Solução: inclusão de tratamento de validação apenas do pedido a ser faturado pela Loja.
Link de evidências: https://share.linx.com.br/x/gushJQ |
|
| BIGRETAIL-136342 | Causa:
Foi identificado que a aplicação, a partir da tabela WMB_SR_PARAM_FILIAIS, estava enviando a sigla <sigInt>LNX_INT</sigInt>. Como retorno, era recebida a mensagem <mensagemRetorno>Sigla de sistema desconhecida: LNX_INT</mensagemRetorno>.
Dessa forma, o lote não era confirmado na Senior e, como consequência, o sistema Senior continuava enviando a nota fiscal. Quando essas notas chegavam à nossa tabela temporária, o processamento tornava-se inconsistente, pois as notas fiscais já se encontravam confirmadas.
Como resultado desse comportamento, atualmente existem mais de 31.285 registros inconsistentes na tabela temporária. Além disso, foi observado que o sequencial de recebimento do retorno não estava sendo atualizado na tabela WMB_SR_PROC_LOG, o que dificultou a identificação do problema de forma mais rápida.
Solução:
Foi realizada a alteração na tabela WMB_SR_PARAM_FILIAIS para incluir a sigla 'LINX'.
Em seguida, foi executado um script responsável por confirmar as notas fiscais inconsistentes, removendo-as do escopo de pesquisa da tabela WMB_NOTA_FISCAL_TRANSF.
Adicionalmente, foi implementado o registro do sequencial de retorno na tabela WMB_SR_PROC_LOG, facilitando o rastreamento e a análise de eventuais problemas futuros.
Evidências: https://share.linx.com.br/x/t5xBJg |
|
| BIGRETAIL-136298 | Objetivo:
Criar um parâmetro para o VA (Java) utilizar na exibição do campo observação na tela de cadastro de cliente.
Objetos alterados:
DADOS_PARAMETRO_SISTEMA
Como validar:
Validar se o parâmetro foi criado corretamente.
Segue abaixo a issue que vai utilizar o parâmetro:
http://jira.linx.com.br/browse/BIGRETAIL-133016 |
|
| BIGRETAIL-136259 | Causa: O seguro de parcela era retornado mais de uma vez. A rotina atual estava trazendo 2 vezes o seguro de parcela, uma para cada nfce.
Correção: Foi feito um ajuste para que o seguro de parcela seja retornado apenas para nfce relacionada ao cupom do id_pvd_garantido atribuído ao seguro de parcela.
Evidência:
O serviço aparece em apenas uma das nfces
https://share.linx.com.br/x/attBJg
*************************************************************************************
*** Feito a correção adicional para as tags de vlrLiq, vlrBse e vlrLse para sessão nfce, elas ainda somavam o valor do seguro duplicado ***
Evidência:
Nfces todas integradas.
https://share.linx.com.br/x/SfJBJg
| 04951205 |
| BIGRETAIL-136200 | Objetivo:
Atualizar o endereço dos clientes e da filial, quando o CEP de uma cidade for alterado.
Objetos alterados:
DADOS_PARAMETRO_SISTEMA
FNCT_INCLUIR_CLIENTE_ENDERECO
JOB_ATUALIZA_ENDERECO
LOG_ALTERACAO_CEP
PCKG_INTEGRA_CEP
Como validar:
Validar conforme o documento abaixo:
https://share.linx.com.br/pages/viewpage.action?pageId=644569385 |
|
| BIGRETAIL-136147 | Objetivo:
Carregar o campo VL_BASE_ICMS para a tabela ITEM_DEV_CLIENTE, para ser utilizado pelo time do ERP.
Objetos alterados:
EVOLUCAO_ITEM_DEV_CLIENTE
PRCD_FINALIZA_DEVOLUCAO_JAVA
Como validar:
Fazer uma devolução no venda assistida e verificar se o campo VL_BASE_ICMS foi carregado com o valor que tinha no item da nota.
Evidencia na observação da Issue. |
|
| BIGRETAIL-135978 | Motivo: Valor incorreto no valor base de ICMS.
Ação: Feito ajuste para buscar o valor da base de ICMS a partir do item da devolução (baseado no valor gerado pela nota de saída do cliente)
Evidência: https://share.linx.com.br/x/TyZrJg |
|
| BIGRETAIL-135936 | Replicar ajustes RT para versão MOBILE [STD] |
|
| BIGRETAIL-135819 | CAUSA: A rotina que gera os dados na wmb_cupom ( prcd_wmb_cupom ) estava em algumas ocasiões gerando linhas com dados da nota tpemis=1 em cenários que 1 cupom tinha 2 notas (tpemis=1 (Cancelada/Invalida) e tpemis=9 )
CORRECAO: Foi feito uma ordenação dessas linhas por tpemis desc na rotina prcd_wmb_cupom para que sempre seja enviado primeiro os dados da nota com tpemis=9 , a qual muito provavelmente será a nota válida. Em cenários que existe apenas 1 nota para 1 cupom o cenário não se altera.
Evidência:
https://share.linx.com.br/x/ZKtBJg | 04914745, 04914764 |
| BIGRETAIL-135573 | Objetivo:
Ajustar o calculo da inscrição estadual do estado da Bahia
Objetos alterados:
PRCD_CALC_DV
Como validar:
- Cadastrar um cliente do estado da Bahia com inscrição estadual com 8 digitos;
- Cadastrar um cliente do estado da Bahia com inscrição estadual com 9 digitos;
- Ambos os clientes devem ser cadastrados corretamente |
|
| BIGRETAIL-135416 | CAUSA: A rotina que gera os dados na wmb_cupom ( prcd_wmb_cupom_fat ) estava em algumas ocasiões gerando linhas com dados da nota tpemis=1 em cenários que 1 cupom tinha 2 notas (tpemis=1 (Cancelada/Invalida) e tpemis=9 )
CORRECAO: Foi feito uma ordenação dessas linhas por tpemis desc na rotina prcd_wmb_cupom_fat para que sempre seja enviado primeiro os dados da nota com tpemis=9 , a qual muito provavelmente será a nota válida. Em cenários que existe apenas 1 nota para 1 cupom o cenário não se altera.
Evidência:
https://share.linx.com.br/x/ZKtBJg |
|
| BIGRETAIL-135167 | Motivo: Não permite dar baixa de pedidos com NF-e com codigo de retorno 150 do SEFAZ
Ação: Feita alteração para permitir baixa de pedidos com código de retorno 150 do SEFAZ
https://share.linx.com.br/x/hyEuJg | 04843007 |
| BIGRETAIL-135055 | Nova view utilizada pelo java para mostrar os dados agrupados do pedido múltiplo
Objeto alterado:
V_PEDIDO_VENDA_MULTIPLO.ora |
|
| BIGRETAIL-134962 | Objetivo:
Criar um parâmetro que quando ativado não valide a idade na venda de serviço se a idade minima for =0 e a maxima = 999
Objetos alterados:
fnct_valida_parametro_servico
Como validar:
1- Deixar o parametro 1310 = N, e tentar fazer a venda de um serviço para um cliente sem data de nascimento, e o serviço parametrizado com idade minima = 0 e idade maxima = 999
--> O VA não deixa vender o serviço e da mensagem de idade.
2- Deixar o parametro 1310 = S e tentar fazer a mesma venda acima.
--> O VA deixa vender o serviço
Evidencia na observação dessa issue | 04333956 |
| BIGRETAIL-134843 | Causa:
O CFOP está sendo identificado. Quando o cliente é órgão público e a modalidade de entrega é igual a 'R' ou 'P', o sistema está aplicando automaticamente o CFOP estadual 5102.
Solução: A regra foi evoluída para considerar os seguintes critérios:
Se o parâmetro 488 – Emitir nota estadual para endereço interestadual estiver definido como 'S';
E Modalidade de entrega diferente de "E" - Entrega
E o cliente for órgão público;
Então o sistema deverá utilizar o CFOP definido no parâmetro 1147 – Regra CFOP – Venda (P ou R) Dentro do Estado, que corresponde ao CFOP 5117.
Caso contrário, o CFOP aplicado continuará sendo o estadual 5102.
Evidencias: https://share.linx.com.br/x/B5v8JQ | 04800280 |
| BIGRETAIL-134750 | Motivo: Storex não está retornarndo consumo de cliente enviado pelo senior
Ação: colocado log de erros para melhor controle destes problemas
https://share.linx.com.br/pages/viewpage.action?pageId=639296193 | 04644048 |
| BIGRETAIL-134655 | Merge do objeto da issue BIGRETAIL-132725 corrigida na versão 2025-1.7.5 para versão 2025-1.9.0.
Objetos:
FNCT_RET_ESTOQUE_LOJAS.ora |
|
| BIGRETAIL-134469 | Objetivo:
Não permitir converter pedido para orçamento caso tenha algum produto com numero de serie, também para pedidos de orgão publico.
Objetos alterados:
PRCD_CONVERTE_PEDIDO_JAVA.ora
Como validar:
Fazer um pedido para orgão publico com produto com numero de serie. Informar a serie na tela do VA;
Finalizar o pedido;
Acessar o pedido novamente e tentar transformar em orçamento;
O VA não permite a conversão
Conforme exemplo no link abaixo:
https://share.linx.com.br/pages/viewpage.action?pageId=633634052 | 04773426 |
| BIGRETAIL-134456 | Causa:
A procedure estava identificando o cliente como pessoa física apenas pelo fato de o código ser diferente de nulo. Contudo, foi necessária uma alteração para que, o código do cliente pessoa física passasse a ser gravado com valor zero. Em função dessa mudança, a aplicação deixou de identificar corretamente o cliente como pessoa jurídica durante o processo de alteração.
Solução:
Foi realizado um ajuste na procedure para considerar o cliente como pessoa física somente quando o código for maior que zero. Dessa forma, quando o código do cliente pessoa física for igual a zero, a aplicação passa a buscar o código do cliente pessoa jurídica, permitindo que a alteração seja realizada corretamente.
Evidências: https://share.linx.com.br/x/ZCNrJg | 04762530 |
| BIGRETAIL-134385 | Merge da versão 2025-1.7.5 na versão 1.9.0
BIGRETAIL-133513 e BIGRETAIL-133483 |
|
| BIGRETAIL-134382 | Causa:
Foi identificado que, para as tags <ICMS40> com <CST>41, a tag <vICMSDeson> não é exibida porque, pelas regras atuais, ela só deve aparecer quando o valor for maior que zero e quando o parâmetro V_TAG_DESON "FNCT_ENVIA_TAG ('vICMSDeson', v_empresa.id_est)" estiver configurado como "S".
Também foi verificado que, para o CST 05 de PIS e COFINS, as tags <vBC>, <pPIS>, <vPIS>, <vBC>, <pCOFINS> e <vCOFINS> não são exibidas, pois a regra atual não prevê a geração dessas informações para esse CST.
Solução:
Para a tag <ICMS40> com <CST> 40, 41 e 50, a tag <vICMSDeson> deverá ser exibida sempre, independentemente do valor informado e sem considerar a parametrização V_TAG_DESON.
Da mesma forma, para o CST 05 de PIS e COFINS, as tags <vBC>, <pPIS>, <vPIS>, <vBC>, <pCOFINS> e <vCOFINS> deverão ser apresentadas independentemente dos valores.
Evidências: https://share.linx.com.br/x/ytgaJg | 04744527, 04769271 |
| BIGRETAIL-134021 | Motivo: Erro ao incluir a tabela wmb_embalagem
Ação: feito ajuste para não deixar incluir embalagem com quantidade maior que 1
https://share.linx.com.br/x/3HG4JQ | 04711910 |
| BIGRETAIL-133975 | Geração de script de rollback da versão. |
|
| BIGRETAIL-133968 | Causa: O problema na geração da tabela WMB_NOTA_FISCAL_ENTRADA ocorreu porque a consulta na tabela NFE_NOTA_FISCAL_ELETRONICA estava filtrando apenas registros com código de retorno 100 – Autorizado o uso da NF-e.
Solução: A consulta na tabela NFE_NOTA_FISCAL_ELETRONICA foi ajustada para considerar registros com código de retorno 100 – Autorizado o uso da NF-e ou 150 – Autorizado o uso da NF-e, autorização fora de prazo. Com isso, ambos os cenários passaram a ser contemplados, garantindo a correta geração da WMB_NOTA_FISCAL_ENTRADA.
Evidências: https://share.linx.com.br/x/d2LEJQ |
|
| BIGRETAIL-133891 | Alterado o processo PCKG_WMB_ERROS_INTEGRACAO.PRCD_WMB_ERROS_CANC_NFCE para verificar se há algumas mensagem de erro na coluna MSG_ERR da tabela RETORNO_WEBSRV. Caso tenha, os registros serão retornados na tela de Cockpit.
Evidências:
https://share.linx.com.br/x/AEu4JQ | 04716463 |
| BIGRETAIL-133816 | Motivo: ao retirar um item do kit no Sênior não atualizava no ERP
Ação: Feito ajuste para replicar os dados do kit da forma correta
https://share.linx.com.br/x/rzezJQ | 04705237 |
| BIGRETAIL-133798 | Causa: Durante a análise da rotina de importação das notas fiscais de entrada, foi identificado que o campo responsável pelo número da nota fiscal, atualmente definido como NUMERIC(6,0), precisa ser ampliado para NUMERIC(9,0). Essa evolução é necessária devido ao recebimento de documentos cuja numeração ultrapassa 6 dígitos. As tabelas impactadas são: WMB_ITEM_NF_TRANSF, WMB_ITEM_NF_TRANSF_IC, WMB_NOTA_FISCAL_TRANSF, WMB_NOTA_FISCAL_TRANSF_IC e CONTROLE_ESTOQUE_ERP.
Solução: Foram criados os scripts de evolução para ajustar a estrutura das tabelas mencionadas, sendo eles: EVOLUCAO_WMB_ITEM_NF_TRANSF, EVOLUCAO_WMB_ITEM_NF_TRANSF_IC, EVOLUCAO_WMB_NOTA_FISCAL_TRANSF, EVOLUCAO_WMB_NOTA_FISCAL_TRANSF_IC e EVOLUCAO_CONTROLE_ESTOQUE_ERP, garantindo assim a atualização do tamanho do campo e o correto processamento das notas fiscais.
Evidências: https://share.linx.com.br/x/ovrnJQ | 04020941 |
| BIGRETAIL-133684 | Causa: Durante a análise, foi identificado que, na geração dos registros na tabela WMB_ITEM_NF_ENTRADA_EMPRESA, os campos ID_TP_LOC (tipo de localização) e ID_GRCDI (grupo CDI) não estavam sendo devidamente preenchidos.
Solução: Foi implementado um tratamento na rotina de geração da tabela WMB_ITEM_NF_ENTRADA_EMPRESA, visando identificar e preencher corretamente os campos ID_TP_LOC (tipo de localização) e ID_GRCDI (grupo CDI), com base nas informações das tabelas de itens das Notas Fiscais de entrada de fornecedor ou entrada de empresa ou entrada de cliente.
Evidências: https://share.linx.com.br/x/KYuVJQ | 04668723 |
| BIGRETAIL-133653 | CAUSA: A tela não apresentava alguns movimentos devido incoerência nos critérios de busca.
Para outros movimentos estava considerando st_sit_it = 0 trazendo movimentos indesejados
Para auto serviço fazia a comparação com id_pvd = 0 falhava em alguns casos já que alguns cupons criados
manualmente foram criados com id_pvd nulo.
CORRECAO: Adicionado as modificações sugeridas na descrição.
Foi colocado o critério st_sit_it <> 0 no Cursor OUTROS MOVIMENTOS
No Cursor Auto Servico foi adicionado o nvl(c.id_pvd,0) = 0
*** Atualiação da procedure PRCD_REP_EST060 a qual usa o mesmo select da tela INVF0100 ***
Evidência:
https://share.linx.com.br/x/-219JQ |
|
| BIGRETAIL-133628 | Mostrar número da nota da tabela CUPOM_ELETRONICO(ID_NFCE_CFE) no detalhe do pedido na tela Gestão de Pedidos
Objeto alterado:
V_NF_PEDIDO_VA.ora
Evidências de testes: https://share.linx.com.br/pages/viewpage.action?pageId=629603541 | 04608398 |
| BIGRETAIL-133465 | Foi alterado o processo PCKG_INTEGRA_NOTA.EXPORTA_NF_OUTRAS_SAIDAS, responsável pela exportação (arquivo XML), integração via webservice e sincronização dos dados de Nota Fiscal/Não Fiscal entre LINX Senior.
A partir desta atualização, o processo não irá mais considerar pedidos originados do E-commerce, garantindo que apenas operações pertinentes sejam processadas.
Evidências:
https://share.linx.com.br/x/7Sz1JQ |
|
| BIGRETAIL-133277 | CAUSA:Código atual não contemplava que o seguro de parcela estivesse em um id_pvd_garantido diferente.
CORRECAO: Foi separado a parte de garantia e seguro de parcela.
Evidência:
https://share.linx.com.br/x/btWVJQ | 04636570 |
| BIGRETAIL-133260 | Criação dos campos CBS_IBS_BC, CST_CBSIBS, CD_CCLASSTRIB na tabela ITEM_CUPOM para auxiliar integrações. |
|
| BIGRETAIL-133157 | Substituído a validação no processo PCKG_NFE_V40_GERA.PRCD_GERA_XML_SAIDA_SEFAZ onde verificava se o campo VL_ICMS_PART_DEST era maior que Zero pelo campo PC_ALIQ_ICMS_DEST, pois como o valor do produto é muito baixo, exemplo: 1 centavo, o valor calculado do imposto será Zero.
Evidências:
https://share.linx.com.br/x/G5WGJQ | 04631133 |
| BIGRETAIL-132691 | Causa: Ocorreu uma atualização na tabela WMB_ESTOQUE_CARGA_IB no dia 09/10, mas a procedure PRCD_WMB_ESTOQUE_CARGA_IB não foi executada naquele momento. Como consequência, os movimentos de 09/10 e 10/10 foram processados conjuntamente no dia 10/10, resultando na duplicação das informações observada.
Solução:
Ajuste realizado para otimizar o tempo de processamento: a rotina de cursor utilizada para zerar o estoque dos produtos foi substituída por um comando UPDATE direto na tabela de estoque. O limite do contador de commits foi ampliado de 100 para 1000 registros, e a quantidade de registros processados passou a ser exibida no campo MES_ERR da tabela ERROS_FECHAMENTO.
Observação Importante ao pessoal do Adelino.
A procedure PCKG_INT_SR_UTILS.IntegraSaldoEstoqueERP_WMB deverá ser ajustada para incluir o comando
EXECUTE IMMEDIATE 'TRUNCATE TABLE WMB_ESTOQUE_CARGA_IB' antes da inserção de novos registros na tabela WMB_ESTOQUE_CARGA_IB, garantindo a limpeza dos dados anteriores e evitando duplicidades durante a execução do processo.
Evidências: https://share.linx.com.br/x/5ceGJQ | 04578184 |
| BIGRETAIL-132465 | Foi realizada uma atualização no objeto PCKG_LIMPA_TABELA com o objetivo de ampliar o escopo da rotina de limpeza.
A tabela LOG_PROCESSO_MIDE_CONSULTA foi incluída no processo, e também foi criada a tabela TAB_PRESERVA_DIAS_LIMPEZA, que será utilizada para parametrizar o número de dias de preservação dos registros das tabelas envolvidas nos processos de limpeza.
Além disso, foram criados os seguintes jobs para automatizar a exclusão de registros e a manutenção das tabelas:
JOB_LIMP_TAB_LOG_VA_JAVA, JOB_LIMP_TAB_LOG_PROC_MIDE_CON, JOB_LIMP_TAB_LOG_JAVA, JOB_LIMP_TAB_HIST_INTERFACE, JOB_LIMP_TAB_ERRO_WEBSERVICE e JOB_LIMP_TAB_CARN_PARC_PAG_LOG.
Evidencias: https://share.linx.com.br/x/1AV9JQ
Anexo: Jobs_Habilitar_Berlanda_v1.0 - Observação: Não houve inclusão na rotina de limpeza da tabela nfe_nota_fiscal_eletronica, porque possui grande relevância, pois armazena os dados dos XMLs de transações com a SEFAZ, incluindo informações cruciais sobre notas fiscais de entrada e saída. | 04574557 |
| BIGRETAIL-131158 | Objetivo:
Possibilitar a venda de seguro de vida Mapfre no VA, integração com Senior e cancelamento conforme especificado.
Objetos alterados:
PRCD_ATUALIZA_MARGEM_TOTAL
PRCD_DESCONTO_MARGEM_JAVA
DADOS_PARAMETRO_SISTEMA
PCKG_SEGURO
JOB_CARGA_NR_SORTE
PRCD_PVD_JAVA
PRCD_EXCLUI_PVD_JAVA
EVOLUCAO_CONTROLE_ARQUIVO_NR_SORTE
Como validar: Segue documento abaixo:
https://share.linx.com.br/display/BRPED/BIGRETAIL-131158+-+Entrega+-+%5BBerlanda%5D+Venda+de+seguro+Mapfre |
|