5.82

MILLEN-852

Teste realizado na versão branches e na versão 5.81, o erro não aconteceu.

MILLEN-1043

Tratado para não realizar filtro de conta nesta query, pois neste caso o campo conta não tem relação com o cadastro de contas, e sim trata-se de um endereço de email.

MILLEN-1076

Realizado ajuste para não carregar brindes que não façam parte da campanha

MILLEN-1078

Não mostrava o percentual de desconto da promoção só o valor. Ajuste realizado para exibir percentual em cima do valor do item, e separada região de valores relativos a promoção.

MILLEN-1081

Ao Utilizar a Campanha de Fidelidade, um Cliente que tenha Pontos para ser trocado, veja que o valor total da venda e puxado para a opção "Fidelidade", o cliente Deveria escolher a opção. Botão colocava o máximo possível direto para uso. Ajuste realizado para botão aparecer zerado.

MILLEN-1117

O relatório já agrupa os registros por produção, produto, fase e data de finalização, então não precisa somar os dias de atraso na fórmula. Alterada fórmula da coluna "dias em atraso" de: sum(date()-data_prevista_fim_fase.DATA.DATA) para: max(date() - data_prevista_fim_fase.data.data)

MILLEN-1121

Conforme verificado com o consultor, a pendência pôde ser fechada.

MILLEN-1122

Situação não ocorreu na versão 5.81. As sessões são finalizadas ao fechar o sistema. Caso haja um fechamento inesperado (queda de energia ou algo do tipo), a sessão é inutilizada após o período de inatividade (atualmente são 10 minutos).

MILLEN-1125

Feita análise detalhada na base, e não há nenhum indício de "crescimento anormal" na base de dados. Como pode ser verificado, as tabelas com maior concentração de megabytes são as tabelas PRODUTOS_EVENTOS e MOV_ESTOQUE, mas ainda assim não corresponde nem a 10% do tamanho total da base de dados: O fato de estas tabelas terem este tamanho se justifica pela quantidade de produtos de cada movimentação, como pode ser visto na amostragem abaixo: Pautando-se na base de dados enviada, não há inconsistência, mas sim o crescimento natural.

MILLEN-1141

Conforme testes realizados na versão branches foi detectado que a base de dados disponibilizada só tem dados até o mês 5, sendo assim, se mudar o filtro do relatório para Este Ano os dados contabilizados são apresentados corretamente. Existe um erro parecido que foi corrigido a pouco tempo então recomendo a atualização da versão no cliente.

MILLEN-1144

Não é um erro. Essa solicitação deve ser analisada pela equipe de ecommerce e avaliar a possibilidade de alteração do recurso para permitir múltiplos vínculos na importação, porque apenas aumentar a quantidade de colunas do jeito que está hoje vai impactar no recurso de importação do ECO. Por favor, solicite a análise de viabilidade e estimativa de tempo para a equipe de Pedidos repassar para o pessoal de ecommerce.

MILLEN-1378

Após atualizar a versão não estamos conseguindo alterar o cadastro do cliente pelo Histórico. O tratamento que verificava o destino do link para converter os nomes dos campos no mecanismo do gerador de relatório para os nomes padrão do método, estava verificando apenas no padrão antigo. Foi tratado para verificar o destino também no novo padrão (HTML).

MILLEN-1469

Alguns tipos de registros não gravam numdocto na tabela mov_estoque. Foi tratado para nesses casos pegar o número do documento da view inf_estoques, que lê o número do documento a partir da origem e tipo de origem.

MILLEN-1493

Não há erro. Isso que está sendo feito não é um aproveitamento de crédito, o label destacado é apenas um indicativo de títulos pagos. Para aproveitamento de crédito, é necessário clicar nos "..." indicados na imagem abaixo, e selecionar o crédito para aproveitar.

MILLEN-1504

Lentidão identificada no processo de Colmeia pelo cliente Le Biscuit. Solução: Melhoria de 60% em média após o primeiro carregamento da tela na conferência de Colmeia (Locais Origem/Destino)Melhoria de desempenho na finalização de local de Colmeia e no estorno de movimentação (30% em média) Obs: Não foi possível simular a lentidão mostrada no vídeo de carregamento da lista de lotes de separação e o log disponibilizado não mostrou lentidão na lista. É necessário um novo log com esse ponto específico. Se possível, simular no servidor de homologação do cliente para termos mais evidências da lentidão.

MILLEN-1538

O problema está no filtro utilizado no campo. Faltou utilizar o filtro para pode conferir. Alterando o rpt conforme abaixo o relatório trouxe a quantidade 43, conforme a lista de pré-faturamentos.

MILLEN-1540

Conforme análise do cenário foi constatado que trata-se de uma funcionalidade do sistema solicitada pelo próprio cliente como consta a BM-1630.

MILLEN-1541

Query alterada para considerar a quantidade do serviço.

MILLEN-1558

Sistema não retornava quando era selecionada uma NF para devolução no grid de produtos, no evento utilizado. Solução: Alterada DLL eventos para evitar o erro.

MILLEN-1572

Teste realizado na versão 5_81, o erro não ocorreu.

MILLEN-1575

As alterações atuais estão sendo gravadas no log. Quanto as alterações passadas, não há o que ser feito.

MILLEN-1602

Inconsistência na base de dados. Alguns registros na tabela mov_estoque estão com precisão decimal acima de 6, o que faz com que a soma não totalize zero "redondo", mas sim algo como 0,00000000001, fazendo com que estes registros retornem no relatório. Existe a opção de colocar o campo dentro de uma fórmula no gerador de relatórios, dentro da macro #round, e utilizar essa macro como filtro, ou executar o comando criado para arredondar tudo para 6 casas decimais, que é o máximo suportado pelo sistema. Devido ao tamanho da base, este comando pode levar muitas horas para ser executado, por isso recomendo que seja executado durante a noite ou final de semana.

MILLEN-1636

A conexão está sendo rejeitada pelo servidor, não há intervenção que possamos fazer. Verificar as configurações da conta, tanto no BM quanto no servidor de email.

MILLEN-1688

Já foi concluída e os testes foram realizados pelo cliente.

MILLEN-1691

Não é erro! Por padrão a grid soma todos os valores que são numéricos. O percentual visto na em pedidos de venda é uma rotina utilizada especificamente da tela.

MILLEN-1715

Processo de troca de produto por descrição estava com lentidão.

SOLUÇÃO: Criado debouncer de 500ms para que busca no servidor não dispare a cada mudança no input. Modificado código que causava uma segunda busca no final do processo. Modificado método no servidor para sempre limitar buscas pela descrição ou código de barras do produto à filial corrente, buscas pelo número do cupom ou CPF continuam globais. Limitado resultado a apenas 11 quando a busca é por produto.

MILLEN-1723

Método pedido_venda.consulta_simples sendo chamado indevidamente, sem parâmetro de entrada.

SOLUÇÃO: Tratado para não chamar o método quando não há pedido na tela

OBSERVAÇÕES: Após a correção, o processo de efetivação levou cerca de 8 segundos em nosso ambiente, considerando a lentidão "natural" da VPN. No ambiente do cliente o tempo cairá bem mais.

MILLEN-1737

Rotina foi alterada para limpar a grid de produtos quando a filial destino for alterada para evitar que o pré-faturamento fosse feito em filial "errada".

SOLUÇÃO: Adicionada validação para efetuar essa limpeza apenas se a coluna pré-faturamento existir.

MILLEN-1749

A função RSUM foi concebida para fazer o acúmulo por linha, por isso o formado de tabela funciona normalmente. O recurso não é suportado usando o Cross (agrupamento nas colunas). Caso essa necessidade seja primordial para o cliente, deve ser solicitado via pedidos para verificar a possibilidade de customização do recurso.

MILLEN-1763

Como se trata de um erro esporádico, coletar Log ou abrir uma nova pendência no momento que ocorrer o erro.

MILLEN-1764

Como se trata de um erro esporádico, coletar Log ou abrir uma nova pendência no momento que ocorrer o erro.

MILLEN-1791

Situação não ocorre mais. Realizado teste com a base do teste conforme descrito no cenário e o erro não ocorreu.

Obs: Informado no cenário que o erro é devido as telas HTML, como existem correções frequentes referente ás telas é muito provável que esse erro foi corrigido anteriormente. Teste realizado na versão branches e 5_81, o erro não ocorreu, portanto a pendência será fechada.

MILLEN-1809

Cliente foi orientado a migrar para o novo coletor.

MILLEN-1821

Em teste realizado na versão branches, foram refeitos o faturamento e a movimentação foi salva. Orientar o cliente a atualizar para a última versão do BM, e atualizar também o módulo millenium!enfe.minst.

MILLEN-1827

O template não é preenchido na tela ao selecionar. O GUID do modelo selecionado é enviado ao servidor para ser processado internamente junto com a mensagem digitada.

MILLEN-1839

A query que verifica as entradas de devolução não considerava estorno da mesma. SOLUÇÃO:A query foi tratada para considerar também os estornos das entradas de devolução

MILLEN-1856

Teste realizado na versão 81, o erro não ocorre mais, foi possível anexar o arquivo normalmente. Portanto a pendência foi fechada.

MILLEN-1867

Voltar a tela do cliente para o padrão win32.Problema na tela HTML sendo tratado em tarefa interna.

MILLEN-1892

Teste realizado na versão 5_80_2 e branches, o erro não ocorre mais.

MILLEN-1904

Testado na versão branches, o relatório foi executado em aproximadamente 20 segundos, considerando a lentidão natural da VPN, este tempo deve ser reduzido quase a 0 em ambiente de produção. Situação foi corrigida na pendência MILLEN-967 Foi solicitada a confirmação da versão do cliente para que possamos passar para um sub-release e fechar a pendência.

MILLEN-1925

Não ocorreu na Branches. Está funcionando na versão 5.81.

MILLEN-1994

Conforme análise do cenário foi identificado que houve reservas em lotes, porém a baixa foi feita usando outro lote, segue script em anexo para correção.

MILLEN-1998

Não é erro. Este comportamento é definido pelo fato de o campo "TABELA DE VENDA DE PREÇO MÍNIMO (DESCONTO)" estar preenchido.

OBSERVAÇÃO: Atualmente o campo desconto p/ produto está desligado no evento, mas esteve ligado em algum momento, o que permitiu o preenchimento do campo destacado. Para permitir a edição do desconto, ligar o campo desconto p/produto, limpar a tabela do campo em destaque, e desligar novamente o campo desconto p/ produto.

MILLEN-2006

Alguns escopos do relatório, como o de fornecedor, não contemplam o SKU, mas o método estava tentando ligar os preços por SKU.

SOLUÇÃO: Alterado o método, para nos escopos que não contemplam SKU, ligar o preço apenas por produto.

OBSERVAÇÕES Pode ser enviado o método ao cliente

MILLEN-2011

Atribuição indevida de cortesia automática devido a arredondamento.

SOLUÇÃO: Tratada a lógica que faz a atribuição da cortesia de ajuste para não atribuir cortesia quando o abs da diferença é 0.

MILLEN-2014

O programa trazia o produto em uma única linha, mesmo que não tenha sido devolvido totalmente. Com isso o flag trocado/devolvido vinha marcado e o usuário não conseguia devolver a quantidade restante

SOLUÇÃO: Tratado para desagrupar quantidade já devolvida, da quantidade ainda disponível, de forma que o usuário consiga devolver o saldo.

MILLEN-2046

Não havia atribuição para a pseudopropriedade CodigoProtestoSICOOB e nem para a propriedade InstrucaoCobranca3 do componente cobrebemx.

SOLUÇÃO: Atribuição de valores conforme orientação do suporte técnico do cobrebemx.

MILLEN-2048

Erro não ocorre mais. Realizado teste na versão 5 branches, utilizando a base do teste.

MILLEN-2057

Quando quiser filtrar por 'contido em' deve usar o level, e não o atributo tipo 'String'.Da maneira que está o código do pedido monta a consulta SQL errado. Com isso, se a necessidade for utilizar o 'contido em' no filtro do pedido, então:é preciso trocar o filtro existente pelo level do pedido_venda, usando movimento.pedidovenda.pedidodevenda. Não utilizar o atributo, e sim utilizar o level. Outra maneira, é utilizar o 'igual a', nesse caso não é preciso mudar o atributo que está no filtro, porém só será permitido selecionar um código de pedido de venda, e não vários como no exemplo acima. Por isso é preciso verificar a necessidade do cliente, pois conforme cenário o cliente só está selecionando um único pedido, basta trocar o 'contido em' pelo 'igual a'. Verificar qual das 2 opções informadas acima atende a necessidade do cliente e realizar a alteração no relatório conforme orientado.

MILLEN-2058

Não é erro do sistema. O relatório está utilizando o recurso "Finalizar na Quebra", criado na BM-1399 para que relatórios do gerador sejam compatíveis com o acionamento da guilhotina em impressoras térmicas. Por definição, esse recurso só deve ser utilizado com o parâmetro "Quebrar Antes" utilizando atributos de ficha (que não é o caso do relatório do cenário).Para que o sistema considere a configuração da margem, o cliente deve desmarcar o "Finalizar na Quebra". Após isso, o sistema respeitará a configuração da margem inferior e exibirá os cabeçalhos em todas as páginas.

MILLEN-2062

Teste executado na versão 5.81. e na versão branches utilizando o datasources enviado pelo cliente. O erro não ocorreu.

MILLEN-2064

Quando preenche o grid de produtos utilizando o pré-faturamento é chamado uma função "AtualizaVolumes", nessa função é calculado a quantidade de caixas (volumes). O erro era que existia uma divisão por 0 dentro da função, isso ocorria quando a variável quantidade de caixa retornava 0.

SOLUÇÃO: Realizado ajuste na função para não realizar uma divisão por zero dentro da função.

MILLEN-2065

Existem itens das requisições de compras que estão com quantidade de pedidos, mas não existem pedidos vinculados ao produtos.

CORREÇÃO: Executar o script.: *** - Corrige Req-Compra invalida.sql para corrigir os produtos inválidos. Após a correção o fornecedor foi identificado pela rotina.

MILLEN-2074

Este erro de fato existiu, porém foi corrigido na pendência BMMANU-24367.Anexo instalador do módulo atualizado.

MILLEN-2083

Problema relacionado a tela em HTML já reportado e sendo tratado em tarefa interna. Paliativamente, alterar o arquivo standard_win32 para retornar a tela no cliente para o padrão antigo.

MILLEN-2085

Trata-se de problema na migração de telas e está sendo tratado por solicitação interna. Pode-se retornar o cliente à tela antiga paliativamente.

MILLEN-2086

Não identificado a base do cliente, realizado o cenário com a base de testes e o erro não ocorreu na versão congelada 5.80.3

MILLEN-2099

Lógica que captura a literal da classificação com base no ID, não estava preparada para já receber a literal ao invés do ID.

SOLUÇÃO: Tratada a lógica para compatibilizar com rotinas que enviam a literal.

OBSERVAÇÕES: Na planilha, necessário alterar o R para REVENDA;O produto da planilha é o 123443211 e não 12344321 como está no cenário; Como o produto já está cadastrado na base, necessário ligar o parâmetro abaixo para que a rotina faça a alteração, do contrário a rotina tentará incluir um novo produto e dará erro de código de duplicado: Ao selecionar os campos para importar, não basta selecionar o campo produto, é necessário selecionar as categorias que ficam dentro da árvore do produto (para testar o cenário, basta ligar o produto acabado dentro da árvore produtos).

MILLEN-2120

A causa da rejeição era um espaço no final do nome do cliente, porém houve uma mudança do lado da API da linxpay, que fazia com que não conseguíssemos devolver a mensagem de erro correta para o usuário.

SOLUÇÃO: Tratado para remover espaços no início e/ou fim do nome do cliente, e alterado o tratamento de erro para compatibilizar com a API.

MILLEN-2135

O retorno dos correios é SANTA BARBARA D'OESTE, enquanto na nossa tabela de municípios o esperado é SANTA BARBARA D`OESTE (crase ao invés de apóstrofo). SOLUÇÃO: Incluído na tabela de municípios SANTA BARBARA D'OESTE, com apóstrofo, conforme já existia na tabela municipios_ibge

MILLEN-2151

Rotina abria como origem o pedido de compra distribuído. Adicionado a tag de consulta para quando for listado os link o programa consiga "distinguir".

MILLEN-2171

O Problema ocorre por causa do formato do Código de Barras configurado no Parâmetro Geral. O Padrão do nosso sistema para cores é 3 posições, conforme configurado para teste. Após alteração feita acima não mais apresentou a mensagem pois passou a encontrar a cor 000-UNICA cadastrada na base. Teste realizado e o problema não ocorreu após a alteração.

MILLEN-2175

Não é erro! Os códigos de cores e estampas informadas na planilha, estão invalidas. Ao consultar as cores e estampas, é possível ver que o código correto é '000' para único. Ao atualizar os códigos na planilha e efetuar a atualização, o sistema consegue encontrar os produtos com suas grades e assim efetuar a alteração de preços.

OBS: Aguardar a importação ser completada, pode levar alguns minutos.

MILLEN-2217

Visto que o campo Valor Máximo configurado no tipo de frete estava sendo utilizado apenas como filtro no gateway de frete fazendo assim com que listasse apenas as transportadoras que atendem ao critério, foi implementado também no client uma validação para o caso de se escolher a transportadora manualmente.

MILLEN-2219

Foi Feita correção para somente preencher a IE de Entrega quando for pessoa Jurídica e o campo IE do Endereço de Entrega estiver preenchido. No caso da pendência a Tag não foi gerada e a nota passou corretamente na Sefaz.

MILLEN-2236

O problema não é o tempo do processo, e sim o volume do processo. Cliente processa mais de 8k pedidos de uma vez, o que naturalmente é demorado.

SOLUÇÃO: Criada opção limite de pedidos por execução, no cadastro da automação de pré-faturamento

MILLEN-2253

Ajustada a consulta do relatório 171, pois o relatório estava pesquisando os fornecedores cadastrados para o produto, dessa forma estava duplicando a informação. Conforme conversado com a Cris, utilizar o fornecedor base no cadastro de produtos para efetuar a consulta. Orientar o cliente para que cadastre um fornecedor base no cadastro de produtos.

MILLEN-2300

Não havia filtro para o estado Sergipe no método citado.

SOLUÇÃO: Adicionado filtro conforme solicitado (já foi feito e homologado no cliente).

MILLEN-2303

Em conexão no servidor do cliente, conseguimos fazer a manutenção necessária sem a necessidade de parar o sistema. Foi solicitado um monitoramento durante os próximos dias e que nos posicionassem sobre o problema de deadlock ser ou não sanado.

MILLEN-2304

Incompatibilidade da query com sql server .

SOLUÇÃO: Alterada a aquery, tornando compatível com sql server e firebird

MILLEN-2332

Desenvolvido recurso que verifica se possui NF pendente de envio para o Linx. Caso tenha, abaterá a quantidade dos produtos da quantidade de estoque listada pelo Linx.

MILLEN-2343

Conforme foi informado, o problema foi corrigido na tela Win_32 na versão 5.81. Como forma paliativa por gentileza atualizar a versão do cliente para 5.81 e alterar o arquivo STANDARD_HTML para STANDARD_WIN32 dentro da pasta C:/wts/appmap e executar o gerenciador de usuário logo após.

MILLEN-2396

Em versões antigas (ou configurações erradas) faziam com que a CFOP registrada no BD fosse diferente da que consta no XML da NFCe (essa é a correta - XML).Identificado também problema para o número do item registrado no BD.

Solução: A partir dos XMLs foram criados dois comandos : um para corrigir a ordem dos itens e outro para corrigir a CFOP.

MILLEN-2412

Conforme informado pelo programador, existem registros na mov_estoque, inseridos via script, com local de estoque inválido. Foi criado um comando e enviado para ser executado na base do cliente, a fim de sanar o problema.

MILLEN-2452

O Omni estava subtraindo o valor do desconto da venda no produto quando a venda possuía frete.

SOLUÇÃO Alteração para subtrair somente o frete da venda quando houver frete. OBSERVAÇÕESVendas com desconto devem devolver o desconto que o produto recebeu, caso haja frete também será subtraído o valor do frete.

MILLEN-2464

Conforme mencionado pelo programador, o erro não ocorre nas versões 5_Branches, 5.81_2 e 5.79_9 após testar com o cenário apresentado pelo analista. Conforme vídeo anexado na pendência.

MILLEN-2471

O método millenium_omni.refund.cancel estava recebendo o número do cancelamento como A(0), criando uma conversão incorreta para varchar(max) no SQL Server e gerando o erro.

SOLUÇÃO: Alteração no tamanho do parâmetro "REFUNDREF" para 100.

MILLEN-2477

Conforme mencionado pelo programador, não foi identificado erro, o produto ficou sem estoque porque todo o saldo já foi utilizando. O que precisa ser revisto é o desenho do workflow. Recomendamos que o pedido seja reservado no Millennium e depois na Microvix para que assim o cliente possa seguir com o faturamento."

MILLEN-2483

Não foi possível acessar o sistema utilizando o datasources disponibilizado. A pendência MILLEN-1632 adicionou um lookup no campo 'Formata Descrição de Produtos' que acessa o método 'vitrine.Lista_Formatacao_FiltroPopup'. Conforme informado no cenário, o cliente está na versão 5.79_4, e nessa versão a alteração descrita acima pela pendência MILLEN-1632 não existe, pois foi feita em versões mais recentes. Porém, analisando o millenium_vitrine.wts do cliente (anexado na pendência) o erro é que o lookup do campo 'Formata Descrição de Produtos' está acessando o método 'vitrine.Lista_Formatacao_FiltroPopup', mas esse método não está criado. Aparentemente, criaram o lookup do campo manualmente direto no ambiente do cliente, mas não adicionaram o método. Com isso, segue millenium_vitrine.wts original da versão 5.79_4.Se o cliente precisar do recurso da 5.79_4 é preciso verificar uma possível atualização ou a autorização de passar o ajuste para versão do cliente.millenium_vitrine.7z IMPORTANTE: Se no ambiente do cliente houver mais alguma alteração própria na millenium_vitrine.wts, o wts original da 5.79_4 anexado irá substituir essas alterações, portanto é necessário verificar essa condição.

MILLEN-2490

Produto 1000048 "TOCHA PLASMA PT31 4M WK", APARENTEMENTE, foi transformado em KIT a partir de 12ago.Produto componente 1000779 "TOCHA PARA MAQUINA CORTE PLASMA PT 31 4M" (confirmar com cliente)O comando aplicado na base retorna as vendas com o produto 1000048. A coluna "componente" mostra o uso do componente na venda. O retorno mostra que nenhuma venda até o dia 11ago20 usa o componente do kit.

MILLEN-2493

Não é erro. O parâmetro 'Produtos sem Vendas' marcado com a opção 'Somente c/Saldo Diferente de ZERO' verifica o saldo do produto no estoque, e não a quantidade vendida. Sendo assim, se o produto tiver quantidade vendida igual a 0, mas existir saldo no estoque o mesmo será exibido no relatório se utilizado os filtros definidos conforme cenário.

MILLEN-2540

Conforme análise do cenário, realizada pelo programador, foi entendido que o sistema está correto pois já existem pedidos de compra gerados para as requisições de compra mencionadas. É possível identificar o pedido de compra ao entrar na alteração da requisição, selecionar um produto e clicar em FollowUp Pedido de Compra. "Ou seja, ele não está gerando mais requisições pois aquelas requisições em questão já possuem um pedido gerado.

MILLEN-2579

Cliente importou XML (somente houve importação dos itens com CST 10, deixando de fora os com CST 00) e configurou no parâmetro Geral "Calcular Icms ST" em "Entrada de Nota Fiscal Eletrônica". Dessa maneira o sistema deveria respeitar o que foi configurado pelo usuário. A definição na base de fornecida é a de Zerar o imposto FCPST. O sistema zerava do item mas não zerava do totalizador.

Solução: Corrigida a DLL para utilizar as informações de acordo com a configuração do usuário, tanto para os itens quanto para o totalizador da Nota.

MILLEN-2588

Ajustada a consulta do relatório, pois o campo desc_gerador tem um tamanho maior que o campo criado no retorno da consulta. Relatório gerado com a correção em anexo á pendência.

MILLEN-2609

Conforme conversado com técnico, indicar ao usuário refazer a entrada pois os preços unitários estão diferentes (maiores na entrada).

MILLEN-2627

Caracteres inválidos ao cadastrar/atualizar produto.

SOLUÇÃO: Tratamento da tag metaKeywords e PageTitle antes de montar o json.

MILLEN-2632

Não é erro, são uma série de configurações que o programa consiste antes de preencher automaticamente os campos. Para carregar evento e CFOP, o evento, ou algum outro evento da base precisa conter em sua tabela de CFOPs, a CFOP que está na nota.

MILLEN-2633

Omni não estava liberando produto sem estoque adicionado no carrinho pelo código de barras. Comentado propriedade do CSS que desativa o clique em "liberar" e alteração para enviar "inventários" no formato lista.

MILLEN-2638

Ao listar as origens de uma determinada filial com um usuário que contem limitações de acesso ao filial, a query aplicada não estava considerando o que de fato era as informações respectiva a filial selecionada.

SOLUÇÃO: Realizado as seguinte implementações :Passado o método para dll, devido o filtro do gerenciador de usuários estar afetando o resultado na tela.

MILLEN-2654

foi criado um script para ser executado na base do cliente. A execução desse script tende a ser extremamente demorada, devido ao tamanho da base do cliente, e deve ser executado com o broker fora do ar. Por isso é de extrema importância que seja alinhado um período com o cliente, como uma noite ou um final de semana, para que o script possa ser executado

MILLEN-2661

Não era possível faturar pré-faturamentos de encomenda do OMNISOLUÇÃO:O erro era causado pois o evento configurado no tipo de pedido era pra cupom fiscal, esse problema é resolvido mudando uma configuração que foi criada pra solucionar esse problema na MILLEN-2442.Pra isso o evento do faturamento via OMNI de pronta entrega deve ser configurado na vitrine e configurado para ele ser o preferencial.

MILLEN-2664

Cadastro do cliente suporta CÓDIGO de até 12 caracteres, e no filtro de gerador do chamado só é possível digitar 10 caracteres para busca.

SOLUÇÃO: Aumentado o tamanho do campo código no filtro de geradores do chamado para tamanho 15. OBS: No filtro de gerador é possível selecionar REPRESENTANTE e TRANSPORTADORA, e os CÓDIGOS nessas tabelas tem tamanho 15. Por isso foi alterado para tamanho 15 o CODIGO.

MILLEN-2665

Teste realizado na versão 5.81, o botão de abrir nova aba está disponível. O erro não ocorre mais.

MILLEN-2666

O erro não ocorre mais, teste realizado na versão 5_81 e branches, a barra de pesquisa apareceu normalmente.

MILLEN-2669

foi criado um script de correção do erro mencionado e deverá ser executado no cliente, recomenda-se atualização da versão para evitar novos episódios desse erro.

MILLEN-2676

Foi conversado com o solicitante da pendência, e o mesmo afirmou que o problema foi corrigido.

MILLEN-2677

Foi conversado com o solicitante da pendência, e o mesmo afirmou que o problema foi corrigido.

MILLEN-2678

Conforme informado pelo analista via Teams, foi realizada uma validação no ambiente de homologação do cliente e o erro não ocorre mais.

MILLEN-2679

Processo já resolvido no cliente.

MILLEN-2697

Tratativa para produto alternativo trouxe o sku correto, mas em todas as filiais.

SOLUÇÃO: Repassada a Filial_externa no filtro dos sku, impedindo no resultado trazer sku com trans_id baixo.

MILLEN-2701

O Sql Serve não permite que inner join com Select tenha o order by. O order by deve estar no select principal.

SOLUÇÃO: Foi retirado o Order By no inner join com Select

MILLEN-2710

A solução é adicionar uma validação para verificar se a consulta MX não é eof, anexado o método com a solução sugerida.

OBSERVACAO: Pedido que estava bloqueando a fila foi cancelado para que os restantes dos pedidos possam ser liberados, mas pode existir outros pedidos que irão cair no mesmo cenário.

MILLEN-2714

O processo com a solução já foi aplicado no cliente.

MILLEN-2717

O cliente utilizado na devolução não tem endereço cadastrado, portanto o sistema utiliza o registro INDEFINIDO para exibir as informações no relatório, mas o registro INDEFINIDO (-2000000000) estava sem os campos de ENDERECO_NOTA e ENDERECO_COBRANCA marcados na base.

SOLUÇÃO: Criado um comando para se executado na base do cliente.

MILLEN-2719

O campo CONTROLA_LOTE da tabela PRODUTOS por default, ele grava TRUE na tabela e não é visível, porém os produtos de Material de consumo estão FALSE. Na alteração do produto existe uma validação para quando este parâmetro estiver FALSE considerar o tamanho da grade 0, que é tamanho 'U'. E ocorrendo isso, para o produto do cenário que tem tamanho 'KG' exibe a mensagem da trava, pois o sistema está considerando que estamos alterando o tamanho 'KG' pelo tamanho 'U', e para isso não pode haver dependências. Realizado um teste, e ao incluir um produto novo o campo CONTROLA_LOTE gravou por default TRUE, ou seja, o erro não vai mais ocorrer, pois acontece quando o campo CONTROLA_LOTE está FALSE. No caminho da base da pendência existe uma base da versão 2009, o que pode ter ocorrido é que no momento de migrar os produtos para a base da versão 5, o campo CONTROLA_LOTE tenha sido atualizado com FALSE, pois a maioria dos produtos foi cadastrado nessa condição.

SOLUÇÃO: Foi criado um comando para ser executado na base do cliente.

OBSERVAÇÕES: Correção através do comando disponibilizado. Se possível, testar a inclusão de um produto Material de consumo novo e verificar se o campo CONTROLA_LOTE da tabela PRODUTOS gravou com 'T'.

MILLEN-2721

Corrigido junto do desenvolvimento da MILLEN-2814. Foi Homologado e validado diretamente no cliente, o programador responsável obteve o retorno do mesmo sobre o processo.

MILLEN-2730

Foi detectado que o problema foi gerado por uma nova tratativa feita pela Core, impedindo o envio das notas fiscais. Feita reunião com a equipe da Core e revisaram a tratativa feita por eles. Feito um teste com um pedido novo no ambiente de homologação disponibilizado e a nota foi enviada corretamente.

MILLEN-2735

Geração excessiva de log na importação do estoque.

SOLUÇÃO: Feita uma flag para ligar e desligar a gravação de log no banco de dados. Quando desligado, o log ainda é gerado em arquivo para visualização, e se ligado, grava também em disco.

OBSERVAÇÕES: Deve-se ligar o log apenas quando for necessário para ajudar a encontrar problemas

MILLEN-2757

Está correto exibir para o valor do ICMS desonerado de 0,01 para um item e 0 para outro item, pois é uma tratativa de arredondamento do sistema. Foi feito um tratativa na emissão da nfe para não expor os campos vICMSDeson e motDesICMS quando o valor do ICMS desonerado for igual a zero. Foi emitida a nota e a mesma foi autorizada.

MILLEN-2759

Ao realizar a troca de um produto o sistema realizava um update no funcionário que realizou a venda.

SOLUÇÃO: Alteração no método millenium_omni.POS.PostSaleResult para não atualizar a devolução para o funcionário que realizou, mas para o que gerou a venda.

MILLEN-2795

Processo corrigido na versão 5.81.

MILLEN-2798

Durante o processo de Consolidação de Status de Rastreio, em alguns casos, um pré-faturamento possuía mais de 30 IDs da fila para processar e acabava estourando o campo string para o processamento desses status.

SOLUÇÃO: Por esse motivo, foi abandonado delete via IN no agrupamento LIST, e usado um subselect para consultar e posteriormente deletar um a um. OBSERVAÇÕES: Esse problema não deve voltar a acontecer, independente da quantidade de atualizações do volumes pendentes para processamento.

MILLEN-2802

Erro no faturamento do pedido.

SOLUÇÃO: Feito correção para que, quando o pedido tiver múltiplos itens de diversos fornecedores, tratar produto por produto.

MILLEN-2803

Verifica via postman que o "peso" (weight) aceita apenas valores inteiros, não podendo enviar o separador decimal.

SOLUÇÃO: Como em outros clientes e na homologação foi enviado o numero fracionado, para manter a consistência, foi criada uma flag, permitindo escolher se o numero será inteiro ou fracionado.

MILLEN-2810

O erro não ocorre mais a partir da versão 5.81

MILLEN-2812

Foi detectado que o cliente estava com a versão SM_86, sendo que houve ajustes na versão SM_88. Realizado ajuste no método, para que aquelas vendas subissem para o BM, mas, foi aconselhável atualizar para a SM_88

MILLEN-2818

Foi criado um script para sanar o problema de leitura dos itens reservados no estoque.

MILLEN-2821

Cliente deseja que a nota de Devolução de Venda reproduza o mesmo valor para a Tag "indpres" utilizado na Nota de Venda. (Solicitado por Cris) Solução: Corrigida a DLL para reproduzir o solicitado. Indicado que o cliente Grendene utiliza a versão 78.4 (finalizada).A correção foi feita na DLL millenium_nfe, portanto pode ser aplicado o pacote BMNFe. Pode ser tentado somente a substituição da DLL mas é indicado atualizar o pacote BMNFe completo. Informações para teste indicadas por Edson na Descrição da pendência. Necessário imprimir Informações do pedido de venda na NF (parâmetro "Imprime Num Ped Cliente na NFe (Pirelli)" do cadastro de Eventos).

MILLEN-2828

Este erro já foi corrido na MILLEN-2628 , aguardando liberação do commit. Passada a correção para a versão do cliente, dll foi enviada ao consultor de implantação.

MILLEN-2829

Não há erro. Não é possível adicionar novos lançamentos em movimentações com nota(s) emitida(s).Este comportamento sempre existiu e não tem nenhuma relação com a atualização da versão.

MILLEN-2830

Ajustado método de listagem de preço e já colocado direto em produção para o cliente.

MILLEN-2866

Já está funcionando no cliente.

MILLEN-2903

Alguns campos estavam sem índice e poderiam causar lock nas tabelas durante os UPDATE do processo. Removido código que processava as transferências de recebimento/pré-faturamento via scheduler, porque já forçamos a execução do ProcessaTransferenciasLocais passando o id na chamada de confirmação da TPC (ConfirmaRecebimento ou InformaStatusPicking). O Scheduler só vai processar as transferências simples que forem enviadas pela TPC.

SOLUÇÃO: Foi criado um script para ser executado no servidor de produção para criação dos índices.

MILLEN-2911

Sistema estava desprezando alguns valores (centavo) para itens, dependendo do número de casas decimais envolvidas no valor final do item.

SOLUÇÃO: Corrigida DLL para não desprezar qualquer centavo na distribuição nos itens agrupados.

MILLEN-2912

Adicionado having na consulta do método, sendo que se EMTRANSITO='T' já realizada o having, com isso a consulta do método fica com 2 cláusulas having ocasionando o erro. SOLUÇÃO: Realizado ajuste para realizar um AND na cláusula having quando necessário.

MILLEN-2916

Realizado ajuste, para quando no cenário descrito se repetir, enviar a mesma conta da filial na qual o pedido será lançado.

MILLEN-3117

Sistema tentava ler a CFOP e SIT_TRIB do XML, mesmo não existindo essa informação no XML.

SOLUÇÃO: Alterada DLL eventos para somente utilizar os campos citados se esses tiverem valor no XML ou, se não for uma importacaoDI.

MILLEN-3175

Programa considerando os vários volumes criados através de bipagem DUN no mesmo local, como sendo um único volume. Além disso, como os locais de volume DUN são locais de picking comum, o programa não estava priorizando apenas quantidades completas, e sim tratando como qualquer picking, apenas colocando o local na frente no momento da atribuição.

SOLUÇÃO: Realizadas duas tratativas: No momento da análise dos locais de picking, tratar o saldo de cada volume de maneira separada; aplicada a regra de pegar do volume apenas se a caixa for separada por completo, assim como já ocorre com local de palete. A exceção ocorrerá quando não houver quantidades fracionadas no picking, forçando o sistema a abrir um volume.