Issue | Resumo | Número do caso |
| BIGRETAIL-142445 | Causa:
Nota de transferência não integrava pois estava repetindo os sequenciais no xml enviado para o Sênior.
Este problema estava ocorrendo apenas para notas de transferência as quais o número de itens era superior a 99 itens.
Ao criar os dados na tabela wmb_item_nf_saida, a rotina faz um mapa dos sequenciais presentes na item_nf_saida e nfe_nota_fiscal_eletronica para inserir na tabela wmb_nota_fiscal_saida.
A variável usada na guardar esse sequencial comportava apenas 2 bytes, no caso de notas com mais de 99 itens essa variável ficava nula e com isso a rotina atribuía o valor que estava mapeado na tabela nfe_nota_fiscal_eletronica que ocasionava a repetição de alguns sequenciais.
Correção:
Aumentamos a capacidade de armazenamento da variável que mapeia os sequenciais para inserir na tabela wmb_nf_item_saida de 2 bytes para 5 bytes, agora o sequencial comportará até 99999 itens.
A nota foi integrada com sucesso.
Evidência:
https://share.linx.com.br/x/QOzGK | 05533726 |
| BIGRETAIL-142301 | motivo: evolução tecnologica do sistema storex home, versão web. adicionar uma tela de perfil, mostrando a versão do storex home web + versões de bancos etc (acessbilidade)
resolução:
Adicionado a acessbilidade no menu principal do storex home |
|
| BIGRETAIL-142229 |
| 05505024 |
| BIGRETAIL-142169 | Geração de script de rollback da versão. |
|
| BIGRETAIL-142014 | Causa:
As rotinas envolvidas com o JOB_CUPOM_CANCELADO, não faziam select por data de cupom, com isso cupons muito antigos eram selecionados a cada execução prejudicando o desempenho.
Correção:
Criado um índice para WMB_CUPOM_IC, para melhorar o desempenho do sub-select executado pelo job.
Criado um parâmetro para estabelecer a data mais antiga de cupom para ser selecionada. Hoje este parâmetro está definido com 40 dias.
Adicionado nos selects das rotinas envolvidas no processamento de cupom cancelado a data do cupom levando em consideração o parâmetro novo.
Evidências:
https://share.linx.com.br/x/CYHGK |
|
| BIGRETAIL-141940 | Objetivo:
Liberar o numero da sorte que estava reservado para um pedido de seguro ainda não pago (no processo de cancelamento por hora).
Objetos alterados:
PRCD_FECPVD_HR
Como validar:
- Fazer um pedido com seguro de vida(prod: 8000001 ou 8000002)
- Não pagar e aguardar o processo automático cancelar o pedido
- Verificar que após o cancelamento, o numero da sorte resrvado estava liberado.
obs: Demonstrado na observação desta issue.
PRCD_FECPVD_HR
|
|
| BIGRETAIL-141919 | Causa:
O cursor C_NF_ENT_CLI, faz o select de vários campos para servir de chave na hora de atualizar as tabelas WMB envolvidas nessa integração e de montar o XML que é enviado para integração. Como a nota tem muitos itens , a coluna que exibe o XML ficava muito grande, então para esse cenário (campos wmb + coluna xml muito grande) o erro -22813 é disparando.
Correção:
Quando ocorre uma exceção é verificado se o código de erro é -22813, se for é chamada uma nova procedure criada para tratar apenas notas muito grandes.
Nesta procedure separamos o cursor com os campos da nota e o XML que é enviado para integração , com isso evita-se o erro. Desta forma podemos enviar o XML para a integração sem problemas.
Evidências:
https://share.linx.com.br/x/2oPGK | 05455412 |
| BIGRETAIL-141894 | Objetivo:
Enviar o lote de distribuição junto com o numero da sorte para o Senior.
Objetos alterados:
PCKG_SEGURO
Como Validar:
Fazer uma venda de seguro de vida Mapfre (produto: 8000001, ou 8000002) só o seguro, sem mercadoria;
Realizar o pagamento;
Verificar se na integração para o Senior o numero de distribuição foi junto com o numero da sorte. Como na tag do exemplo abaixo:
<USU_NUMSOR>458578-1</USU_NUMSOR>
obs: Para buscar o xml acessar a tabela:
wmb_pedido_venda_seg_vida e pegar o campo sq_recb
- Depois buscar o xml na tabela retorno_websrv pelo campo sq_recb
- Verificar no xml_envio a tag USU_NUMSOR |
|
| BIGRETAIL-141864 | Merge das correções feitas no hotfix/bd-std-2026.1.2.2 para release/bd-std-2026.1.3.0 |
|
| BIGRETAIL-141820 | Complemento de objetos ao repositório para alinhamento com a base atual do cliente. |
|
| BIGRETAIL-141778 | Problema: Erro na emissão de notas de devolução qundo o valor do produto é muito baixo (R$ 0,01) e o frete muito maior (R$ 100,00).
Solução: Rotina alterada para tratar com a situação acima.
Link de evidência: https://share.linx.com.br/x/JPmXK |
|
| BIGRETAIL-141593 |
Motivo: Sistema estava gerando valor de pagamento negativo
Ação: Feito ajuste na geração dos valores de notas com valores iguais ou menores que R$0,04
Evidência: https://share.linx.com.br/x/D8uXK |
|
| BIGRETAIL-141560 | Merge de arquivos do hotfix/bd-std-2026.1.2.1 para release/bd-std-1.3.0 |
|
| BIGRETAIL-141390 | Enviando rotina para sincronizar os releases. |
|
| BIGRETAIL-141306 | CAUSA: A procedure DOC_VENDA da package PCKG_INTEGRA_NOTA, teve problemas de desempenho após a adição da verificação se um pedido é tipo nota única. Esta verificação era feita via função em uma parte do cursor que verificava pedidos que não tinham nota 71.
CORRECAO: Foi feito uma revisão no cursor removendo partes que estavam impactando no desempenho , mantendo a integridade dos dados retornados.
Removido alteração 0061 (impacto de desempenho) e adicionado um novo union para selecionar os pedidos de nota única no cursor DOC_VENDA, acessando tudo via índice.
Foi criado um índice para tabela EMISSAO_NF_UNICA pra os campos da nota.
Adicionado limite de data 90 dias (param 1336) para processamento cupom/nota nas rotinas DOC_VENDA,EXPORTA_CUPOM_NOTA_VENDA e REFAZ_DOC_VENDA_PENDENTES. Este parâmetro pode ser modificado posteriormente para um valor menor já que uma vez que é fechado um período fiscal , não faz sentido o reprocessamento, pelas rotinas diárias, de notas que ficaram sem integração.
Outras melhorias no cursor principal da procedure DOC_VENDA:
1) Foi removido ST_SIT_NF <> 99, pois fazia acesso full na tabela nota_fiscal_saida
2) Removido o distinct , reduntante no cursor já que é usado UNION.
3) Removido order by do cursor principal da DOC_VENDA.
Recomenda-se que a alteração no cursor principal da DOC_VENDA também seja avaliado pelo DBA da Berlanda.
Evidências:
https://share.linx.com.br/x/VBdzK |
|
| BIGRETAIL-141070 | Problema: tabela WMB_PRODUTO_LOG sem limpeza.
Solução: Adicionar a tabela na rotina de limpeza.
Link de Evidência: https://share.linx.com.br/x/8suXK | 05397527 |
| BIGRETAIL-139555 | Incluída coluna CODTPT na PK das tabelas envolvidas na consulta e envio dos dados de títulos CP | 05273453 |
| BIGRETAIL-138351 | Problema: Notas com código do sefaz 9998 que já tinha tentando integrar muitas vezes ficam paradas sem integrar.
Solução: Criada uma rotina que está num job diário que buscar todas as notas que tem o código 9998 com data de emissão de hoje-1 e zera a quantidade de tentativas de integração, permitindo assim novas integrações.
Link de evidências: https://share.linx.com.br/x/YmY3K | 05161142 |
| BIGRETAIL-136365 | Motivo: Adicionar as views e procedures usadas na tela de cockpit nfe
Resolução: Adicionado as views e procedures usadas na tela de cockpit nfe |
|
| BIGRETAIL-134535 | Não permitir cadastrar mais de um cliente PJ com mesmo número de inscrição estadual.
Evidências de testes: https://share.linx.com.br/pages/viewpage.action?pageId=682429563 | 04754972 |