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 |