Compatibilidade mínima com Produtos Linx
Aqui você encontra as versões mínimas dos produtos que estão integrados com o BD STD!
Caso a versão de algum dos produtos esteja inferior às listadas, realize a atualização do produto!
O correto funcionamento desta versão requer que as aplicações abaixo estejam atualizadas nas versões corretas!
Produto | Versão | Caminho |
|---|---|---|
STOREX-HOME-ERP-STD | 7.85.0 | ftp://10.4.229.5/Produtos/STOREX HOME ERP STANDARD/STOREX-HOME-ERP-STANDARD-7.85.0 |
| VA-STANDARD | 1.15.0.0 | ftp://10.4.229.5/Produtos/LINX STOREX HOME VA STD/LINX-STOREX-HOME-VA-STD-1.15.0.0 |
| STOREX-HOME-IPL | 1.0.0.17 |
Configurações necessárias para funcionamento correto da aplicação
Aqui você encontra as configurações necessárias para a atualização da versão!
As instruções estão agrupadas por versão! Fique atento às orientações para configurar corretamente sua aplicação!
Conteúdo da versão
Itens de Legislação Fiscal entregues nesta versão
Não há itens de legislação entregues nesta versão!
Evoluções e melhorias entregues nesta versão
Issue | Resumo | Número do caso |
| BIGRETAIL-139733 | Foi equalizado a base de dados (dbdev) com base do cliente que roda a tela INVF0110 porque estava faltando algumas colunas. Evidências: https://share.linx.com.br/x/wk2hJw | |
| BIGRETAIL-139727 | Chamar o processo de licença da Linx no login do usuário Objeto alterado: PCKG_VA_UX | |
| BIGRETAIL-139181 | Gravar auditoria nos acessos de usuário e vendedor no VA UX Release VA UX: 1.27.0.0 Objetos alterados: PCKG_VA_UX PRCD_ACESSO_VENDEDOR_JAVA PRCD_VALIDA_USUARIO_JAVA PRCD_VALIDA_VENDEDOR_JAVA Evidências de testes: https://share.linx.com.br/pages/viewpage.action?pageId=662953224 | |
| BIGRETAIL-138476 | Causa: Sem rastreabilidade de login e alteracao de usuarios Solucao: Melhoria para ter rastreamento de informacoes de login e usuarios alterados. Evidencia Tecnica: https://share.linx.com.br/x/NJBRJw | |
| BIGRETAIL-138319 | Importante: Essa issue tem dependência da versão de VA 1.27.0.0 para funcionar. Objetivo: Atender o VA na utilização de CNPJ alfanumérico. Objetos alterados: PCKG_CONSULTAS_VA PRCD_HIST_CLI_JAVA TIPO_CLIENTE Como validar: - Cadastrar um novo cliente PJ no VA usando um CNPJ alfanumérico.(buscar um CNPJ alfa válido neste site: ( https://box4.dev/gerador-br/gerador-de-cnpj-alfanumerico/ ) - Consultar o cliente na tela do VA: -- Por cnpj; -- por nome; - Fazer um pedido de venda para o cliente. | |
| BIGRETAIL-137162 | Causa: campo de CNPJ/CPF numérico Solução: campo de CNPJ/CPF alterado para alfanumérico Objetos alterados: EVOLUCAO_WMB_PESSOA_JURIDICA_OB EVOLUCAO_WMB_PESSOA_JURIDICA_OB_IC EVOLUCAO_WMB_NOTA_FISCAL_SAIDA_OB | |
| BIGRETAIL-137147 | Causa: campo de CNPJ/CPF numérico Solução: campo de CNPJ/CPF alterado para alfanumérico Objetos alterados: EVOLUCAO_WMB_FORNECEDOR EVOLUCAO_WMB_FORNECEDOR_IC EVOLUCAO_WMB_NOTA_FISCAL_SAIDA_LEG EVOLUCAO_WMB_NOTA_FISCAL_SAIDA_IB_IC EVOLUCAO_WMB_NOTA_FISCAL_SAIDA_IB EVOLUCAO_WMB_NOTA_FISCAL_SAIDA EVOLUCAO_WMB_NOTA_FISCAL_ENTRADA EVOLUCAO_WMB_NF_ENTRADA_EMPRESA_OB_IC EVOLUCAO_WMB_NF_ENTRADA_EMPRESA_OB EVOLUCAO_WMB_NF_ENTRADA_CLIENTE_OB_IC EVOLUCAO_WMB_NF_ENTRADA_CLIENTE_OB EVOLUCAO_WMB_FISCAL_ENTRADA_FORNECEDOR EVOLUCAO_WMB_FISCAL_ENTRADA_EMPRESA | |
| BIGRETAIL-137145 | Causa: campo de CNPJ/CPF numérico Solução: campo de CNPJ/CPF alterado para alfanumérico Objetos alterados: EVOLUCAO_P2K_MAPA_RESUMO EVOLUCAO_P2K_MAPA_RESUMO_IC | |
| BIGRETAIL-137142 | Causa: campo de CNPJ/CPF numérico Solução: campo de CNPJ/CPF alterado para alfanumérico Objetos alterados: EVOLUCAO_INTEGRA_DE_PARA_EMPRESA EVOLUCAO_DADOS_FISCAIS_CC |
Itens de sustentação entregues nesta versão
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 |