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.78.0 | ftp://10.4.229.5/Produtos/STOREX HOME ERP STANDARD/STOREX-HOME-ERP-STANDARD-7.78.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 |
Itens de sustentação entregues nesta versão
Issue | Resumo | Número do caso |
| 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-139303 | Cenário 1: Número de série não enviado no xml para integração: CAUSA: Para nota autorizada, o número de série era enviado apenas para orgão público, para todos os outros cenários não era enviado o bloco "loteSerie". SOLUÇÃO: Foi alterado a rotina para verificar também pedidos que geraram nota única. Cenário 2: Valores do documento e pagamento não estavam batendo. CAUSA: O Número da nota não era gravado na tabela de serviços para os pedidos de nota única. SOLUCAO: Foi alterado a rotina que grava os dados na tabela de serviços considerando o cenário de nota única. Outros issues relacionados que foram corrigidos com essa entrega: BR-139139 - relacionado com o cenário 2 BR-139213 - colocamos trava para não processar nada de nota única na integração outras-saídas. BR-139302 - cenário 1 - enviar bloco "loteSerie" BR-139304 - cenário 1 - enviar bloco "loteSerie" BR-139337 - cenário 1 - enviar bloco "loteSerie" Evidências: https://share.linx.com.br/x/6xqhJw | 05244798, 05252473, 05253737, 05255064, 05256425, 05264218 |
| 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-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-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-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-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 |