Histórico da Página

...

Painel

titleColor	#FFB200
titleBGColor	#2C004B
title	5.86

Pendência	Resolução
MILLEN-5576	Conforme informado pelo programador: Atualizar a cadmapa.dll (arquivo zip anexo no jira) anexada nos diretórios abaixo: C:\wts\cadmapa.dll C:\millenium\cadmapa.dll C:\wts\files\apps\cadmapa.dll Executar como administrador: C:\wts\files\apps\mkupd.exe Para corrigir o erro: ('0,5' is nota a valid floating point value ) É necessário configurar a região do Sistema Operacional para pt-br: Iniciar\Painel de Controle\Alterar Formatos de Data e hora Formato: Português (Brasil) Para corrigir o erro: ("Toolbar item index out of range") É necessário alterar a impressora padrão para uma qualquer e depois voltar para a impressora padrão original. Importante que seja registrada a cadmapa.dll no c:\wts. Para registrar, abrir o prompt do DOS em modo de administrador (Iniciar\cmd\botão direito (Executar como administrador)) Digitar o comando: regsvr32 C:\wts\cadmapa.dll Aparecerá a mensagem que obteve êxito. Obs: Não é possível testar no ambiente local, apenas no servidor de homologação do cliente. No ambiente de homologação, já ajustado. Orientar o solicitante a realizar as alterações no servidor de Produção.
MILLEN-5585	CAUSA/MOTIVO A tela não estava preparada para alterar o crud pelo pop up. SOLUÇÃO Criado a rotina baseado na tela millennium.dataform.ts.
MILLEN-7053	Causa/Motivo O Erro ocorria no server do millennium ao processar a movimentação vinda do Store Solução Foi corrigido na versão Branches, que será congelada na próxima semana.
MILLEN-7388	CAUSA/MOTIVO Cliente com problemas ao finalizar uma operação comercial. O sistema trava ao efetivar. Realizamos as análises e identificamos que o problema se encontra em um método. SOLUÇÃO Feito ajuste conforme solicitado no cenário. OBSERVAÇÕES Foi enviado a millenium.dll da versão 5.85.5 para o Arlindo Aparecido Rodrigues homologar no cliente. Após o retorno deverá avisar o programador para comitar no último release da 5.85 as alterações feitas na versão 5 master.
MILLEN-7393	Testado na branches, erro ocorre apenas na versão HTML, na versão WIN32 ao tentar alterar/incluir um novo chamado SAC o erro não acontece. Teste efetuado utilizando a base de testes pois a correção é feita na tela. Corrigido na versão 5_branches (5.87) conforme a pendência MILLEN-7210 e conforme orientação, aguardará versão.
MILLEN-7401	Não ocorre exatamente o erro descrito no cenário, mas ocorre erro ao tentar assumir o chamado, conforme evidência em anexo no jira. Teste efetuado utilizando a base de testes pois a correção é feita na tela. Corrigido na versão 5_branches (5.87), conforme a pendência MILLEN-7210 e conforme orientação, aguardará versão.
MILLEN-7449	CAUSA/MOTIVO Telas HTML não estavam com o mesmo comportamento da tela Win32 ao digitar/colar texto em campos do tipo Memo (Alfanuméricos com tamanhos indefinidos), como campos de Observações. O sistema deve permitir a digitação livre nesses campos, pois eles não são utilizados para consulta/filtro no sistema. Normalmente são utilizados para histórico/observações/especificações em texto que podem estar em caixa alta ou caixa baixa. SOLUÇÃO Alterado código que forçava texto em caixa alta para campos do tipo Memo. OBSERVAÇÕES Pode ser simulado em qualquer base, desde que esteja na tela HTML (botão laranja para salvar)
MILLEN-7498	CAUSA/MOTIVO Alguns registros não apareciam durante a geração do SPED. SOLUÇÃO Copiada a correção da branches.
MILLEN-7529	CAUSA/MOTIVO Cliente utiliza 2 emails para recebimento dos emails de NFe e CTe, ao processar o recebimento, caso não for o email configurado nos parâmetros gerais do módulo o sistema aborta o processamento. SOLUÇÃO Adicionado um novo campo para configuração do email a utilizar para recebimento de CTe. OBSERVAÇÕES Analisando a pendência, foi possível identificar que o cliente utiliza 2 emails para recebimento de NFe e CTe. Será necessário o cliente acessar a tela de configurações do módulo millenium!enfe e configurar os emails conforme a necessidade.
MILLEN-7561	CAUSA/MOTIVO Somente após a importação do arquivo, o sistema está identificado 2 caracteres (§ e £) que não são do padrão UTF-8 e apresentando erro de conversão. SOLUÇÃO Inclusão dos 2 caracteres na função que trata os caracteres que não são UTF-8.
MILLEN-7564	CAUSA/MOTIVO Relatório não estava preparado para que passe múltiplos registros diários. SOLUÇÃO Ajuste no método para que aceite múltiplos registros diários.
MILLEN-7568	Através da auditoria, foram identificados os lançamentos que tiveram suas datas de vencimento alteradas e foi gerado o script anexo para corrigi-los. Anexo também uma planilha do Excell para identificar nos registros que foram corrigidos através do script. Teste realizado ok! Ao executar o script no banco de dados, a data de vencimento foi alterada para a correta. A correção para que o erro não ocorra novamente está disponível na versão 5.86.7. Para corrigir os títulos anteriores, favor executar o script em anexo. OBSERVAÇÃO Fazer backup da base antes de executar o comando validar em homologação antes de executar.
MILLEN-7663	CAUSA/MOTIVO O pré faturamento automático não está respeitando o tipo de pagamento informado no pedido. SOLUÇÃO Foi alterado o método de consulta do pré-faturamento para trazer a informado no pedido e alterada o pré faturamento para respeitar o pedido ao invés do cadastro do cliente. Conforme acordo dos desenvolvedores que analisaram a pendência.
MILLEN-7766	CAUSA/MOTIVO O registro no banco de dados referente a configuração "NAO_VALIDA_ORCAMENTO" na tabela CONFIGURACOES está corrompido, precisa deletar este registro. SOLUÇÃO Executar o comando em anexo no jira. E após isso ir em Configurações Gerais \ Pedido de Venda \ Financeiro Marcar Desconto por Produto e o campo Não Valida Limite de Desconto para Tipo de Pedido Orçamento. Salvar as configurações Após isso voltar as 2 flags para FALSE. Salvar novamente. OBSERVAÇÕES Deletando o registro já irá funcionar, a configuração não é obrigatória. INSTRUÇÕES Realizar backup da base antes de executar o script; Executar primeiramente em homologação, e somente após validação completa de dados executar em produção; Não executar em outra base de dados, por mais similar que um possível problema possa parecer; Antes de executar em produção, certificar-se de que o Broker NÃO esteja no ar.
MILLEN-7957	Após a análise dos desenvolvedores, foi constatado que era irregularidades na base de dados, após os ajustes foi importado os preços conforme esperado.
MILLEN-4903	CAUSA Os anexos do cliente, estão duplicados, existem 3 anexos com cerca de 4 milhões de linhas no banco de dados, a demora ao tentar entrar na tela de cadastro é o sistema pesquisando essa quantidade. Feita uma pesquisa geral para identificar todos os anexos duplicados no banco, foram encontrados 31 itens únicos duplicados. SOLUÇÃO Rodar script em anexo VESTEM BM5 Deletar anexos duplicados.sql Script irá deletar as linhas duplicados na tabela anexo que conseguimos identificar no banco que nos foi disponibilizado. OBSERVAÇÕES Caso ocorra novamente, será necessário validar com o cliente o cenário de cadastro de cliente que sendo utilizado, para que possamos analisar. Atenção: Realizar backup da base antes de executar o script. Executar primeiramente em homologação, e somente após validação completa de dados executar em produção. Não executar em outra base de dados, por mais similar que um possível problema possa parecer. Antes de executar em produção, certificar-se de que o Broker NÃO esteja no ar. Após execução, limpar os caches. Lembrando: Utilizamos agora o DBEAVER para acesso a base firebird. Script demora menos de 10Min para ser executado.
MILLEN-5436	Ao importar o relatório em: inteligência de negócio > central de informações > importar o relatório VENDAS RECEBIDAS COM VENDEDOR ANALITICO_3.mdr Ele é gerado em menos de 1minuto e não apresenta mais o registro que antes estava como "indefinido", Isso ocorreu porque o registro analisado em questão é um evento MP-DEVOLUÇÃO DE COMPRA / (Romaneio: 3162202 / Fornecedor: 00001085 - DANIEL TEXTIL) e a visão do relatório é de saídas de vendas. Correção: importar o relatório VENDAS RECEBIDAS COM VENDEDOR ANALITICO_3.mdr
MILLEN-5653	CAUSA/MOTIVO Sistema apresentava a mensagem "Pelo cadastro do cliente a filial não está permitida para venda" ao visualizar/alterar Pedido de Venda. Ocorria pois o cliente possui mais de um cadastro com o mesmo documento (CGC/CNPJ). SOLUÇÃO Ajuste feito para caso sejam encontrados Clientes com o mesmo documento (CNPJ/CGC/CPF), o sistema irá validar somente o cliente com o ID interno igual ao do Pedido de Venda. OBSERVAÇÕES Apenas para observação, existe na configuração geral um parâmetro que permite ou não cadastrar clientes com mesmo documento, neste caso, o parâmetro está desligado. Por isso o cliente está apresentando 3 cadastros com mesmo CGC/CNPJ. (Existem também outros cadastros duplicados de outros clientes).
MILLEN-5679	A situação não ocorre mais. Foi corrigida na pendência MILLEN-5782 Inconsistência no saldo de estoque de matéria prima.
MILLEN-5782	CAUSA/MOTIVO Ao quitar uma baixa de matéria-prima na movimentação, o erro 'Erro de conversão em ResUnit.ST' é apresentado. SOLUÇÃO Alterada a passagem de parâmetro do tipo do campo LOTE na chamada da função ST para 'S', por se tratar de campo string. OBSERVAÇÕES Seguir o cenário da documentação.
MILLEN-6087	CAUSA/MOTIVO Campo nosso número vai em branco para a posição 64-80 no detalhe. SOLUÇÃO Incluído uma verificação para o Banco do Brasil caso o campo esteja em branco preencher com 0 a posição 64-80.
MILLEN-6272	Processo não implementado nas telas html necessário para a tela de estoque mínimo. Corrigido, conforme evidências em anexo no Jira.
MILLEN-6289	CAUSA/MOTIVO Erro devolução Inbrands, divergência de valores. SOLUÇÃO Considerar o desconto/cortesia na troca devolução.
MILLEN-6329	Foi verificado que o campo "TIPO_EMBALAGEM" não está presente na versão do cliente. Essa situação já foi corrigida na versão 5.84.17. O cenário foi testado e não ocorre mais.
MILLEN-6339	CAUSA/MOTIVO Erro ao importar pedido: Não foi possível localizar a filial externa na migração do VTEX pro VTEX ACTIVE. SOLUÇÃO Criar flag nas configurações da VTEX para ignorar a filial do item. OBSERVAÇÕES Por padrão a flag vem desabilitada.
MILLEN-6368	CAUSA/MOTIVO Não era enviado a descrição do produto devido a configuração na tabela de informações da Fbits. SOLUÇÃO Corrigido a configuração para o envio da descrição. Feito a melhoria no sistema, para logar todo o processo de envio, auxiliando na configuração do envio das informações. OBSERVAÇÕES Antes todo o processo era "silencioso", sendo muito difícil rastrear o envio ou não das informações.
MILLEN-6396	CAUSA/MOTIVO O motivo do erro está relacionado a exclusão do lote de separação. SOLUÇÃO Para solução foi realizado duas alterações sendo estas baixo: 1 - Quando, uma transferência de Local foi geral com o tipo de conferência '2' (COLMEIA) no momento e que o usuário clicar no botão "Conferir Transferência de Local" através da tela do ERP, foi aplicado um mensagem informativa na qual forçar o mesmo finalizar as conferências pelo Coletor de Dados. MENSAGEM TELA LOTES DE SEPARAÇÃO : Atenção existem Transferências com o Local Destino de COLMEIA já informado conclua o processo de conferência. 2 - Caso um lote especifico, contenha um transferência onde o processo de conferencia já foi iniciado, e também bipado o local de colmeia, no momento em que o usuário clicar em Excluir o Lote de Separação no ERP, foi aplicado uma mensagem informativa a qual informa que, o processo de exclusão não pode ser feito. MENSAGEM TELA TRANSFERÊNCIA LOCAL : A transferência do tipo COLMEIA só pode ser finalizada pelo Coletor.
MILLEN-6425	CAUSA - Grupos com o caractere "/" não estavam sendo tratados corretamente em html. Efetuada correção e realizados testes, o acesso passou a ser feito sem erros.
MILLEN-6460	CAUSA/MOTIVO Ao tentar realizar o retorno de oficina o sistema gera a mensagem de "Invalid variant operation". SOLUÇÃO Foi identificado que o sistema estava retornando valor NULL no 'SUM' da query. Implementado tratamento para não retornar mais com valor nulo.
MILLEN-6510	CAUSA/MOTIVO Não esta sendo importado corretamente o kit. SOLUÇÃO Feito tratamento para no produto pai ser alimentados todos os componentes, e atrelar esses componentes ao produto pai.
MILLEN-6541	CAUSA A opção de configurar as telas do ERP esta aberta para todos os usuários. SOLUÇÃO Feita correção e foram realizados testes utilizado as telas de Inclusão de Produto (HTML) e Inclusão de pedido de venda (WIN32) para o cenário descrito acima.
MILLEN-6566	CAUSA/MOTIVO Foi identificado que um prefaturamento foi excluído da base, fazendo com que fique empenho preso. A razão pelo qual foi excluído, não foi identificado. SOLUÇÃO Comando para ser executado, para que normalize o campo reserva. Execute o comando em anexo no jira: sql.sql OBSERVAÇÕES Realizar backup da base antes de executar o script. Executar primeiramente em homologação, e somente após validação completa de dados executar em produção. Não executar em outra base de dados, por mais similar que um possível problema possa parecer. Antes de executar em produção, certificar-se de que o Broker NÃO esteja no ar. Apos execução, limpar os caches. Lembrando: Utilizamos agora o DBEAVER para acesso a base firebird.
MILLEN-6568	CAUSA/MOTIVO Sistema não exibia a opção para definir valor padrão de campos formado por expressão. No caso da mora, era um call nas configurações, porém o cliente precisa ter a opção de definir outro valor caso queira. SOLUÇÃO Único caso em que desabilitaremos a opção para definir um padrão do usuário é para chamadas do utils.default. Para situações em que o cliente não possa alterar o valor padrão, o campo deve ficar como "somente leitura" no iEditor. A opção de valor padrão para numérico não funcionava quando havia casas decimais (parse do js quebrava com a regex de texto), portanto foi definido um breakChars para numérico e ajustado a conversão dos separadores de vírgula e ponto.
MILLEN-6576	CAUSA/MOTIVO Erro na captura dos dados do celular. SOLUÇÃO Correção na captura dos dados do celular.
MILLEN-6583	CAUSA/MOTIVO Erro ao validar a série dos CT-e que foram importados ao passar o arquivo do SPED no validador. SOLUÇÃO Feito o ajustes para buscar a SÉRIE do CTe; através do campo IDNFe.
MILLEN-6585	CAUSA/MOTIVO O sistema não estava encontrando o código do IBGE de algumas cidades. SOLUÇÃO O problema acontecia porque o nome do município vinha com acento do cte, foi feito um tratamento para retirar este acento.
MILLEN-6612	Causa/Motivo Internamente as configurações de imposto está registrada de forma incorreta. Solução Rodar o comando em anexo no jira, que irá apagar as informações incorretas.
MILLEN-6615	Relatório gerado sem imagem dos últimos produtos no fim da página SOLUÇÃO Com a mudança para html, todos os relatórios dependem da conversão para PDF. O problema descrito já acontecia em qualquer exportação para PDF, mas não ocorria na visualização/impressão em win32 normal. Foram modificados: -wtsreports.dll -z:\dimmod\MDR_DOCS3.pas -z:\GmPrintSuite\GmObjects.pas -z:\GmPrintSuite\GmResource.pas
MILLEN-6644	CAUSA/MOTIVO Sistema estava Sistema estava considerando duas vezes o valor do desconto ao inserir o movimento. SOLUÇÃO Conforme ajustes efetuados anteriormente esse desconto está sendo calculado na inserção do pedido de venda juntamente com o frete conforme regra de frete, com isso o desconto que estava sendo somado na inserção do movimento não é mais necessário, foi devidamente ajustado para não mais somar esse desconto.
MILLEN-6659	CAUSA/MOTIVO Lentidão ao enviar estoque para plataforma. SOLUÇÃO Sensibilizar o transid do estoque ao adicionar o produto na vitrine.
MILLEN-6681	MOTIVO O PDV Omnichannel informava somente a primeira expressão informada no cadastro da vitrine para realizar a consulta da imagem. SOLUÇÃO Alteração para ler verificar o caminho de cada expressão informada no cadastro da vitrine até encontrar um caminho válido.
MILLEN-6709	CAUSA/MOTIVO Variação da carteira saindo com a numeração 060 sendo o correto sair com a 019. Foi identificado que o sistema estava atribuindo o valor do campo "agência correspondente" e subscrevendo o campo "Variação de Carteira" no arquivo de remessa. SOLUÇÃO No manual técnico do Banco do Brasil, o campo "Agência Correspondente" não é utilizado no arquivo de remessa CNAB. Foi realizado uma validação que, quando for banco do Brasil não será enviado o valor desse campo no arquivo de remessa. OBSERVAÇÕES O sistema automaticamente envia o código "019" no arquivo de remessa quando for Banco do Brasil, para isto, é necessário que o campo "Complemento" no cadastro de Carteira esteja vazio. Caso contrário, será enviado o conteúdo desse campo. Para verificar o conteúdo do campo. Siga o caminho: Financeiro\Receber\Cadastros\Carteira No filtro insira: Tipo Carteira: Carteira Simples Banco: 001 Clique em "Procurar" e selecione o código 52. Após cliquem em "Alterar Carteira"
MILLEN-6750	CAUSA/MOTIVO Foram encontrados 2 problemas: Módulo Fortes não funciona Aparece o erro participante 0108 Kena .. na nota 127702 não encontrado O sistema estava realizando uma busca passando um parâmetro com o tratamento para retirar espaços em branco, porém o campo na tabela estava sem esse tratamento, causando a diferença. Foi alterado o padrão de nomenclatura dos arquivos adicionais do sistema onde trocaram millenium_fortes para millenium!fortes SOLUÇÃO Foi alterada a pesquisa no banco de dados para retirar os espaços em branco do nome do fornecedor. Foi atualizado o padrão de nomenclatura dos arquivos para o padrão atual (millenium_fortes para millenium!fortes).
MILLEN-6761	CAUSA Foi detectado que existe uma produção onde o tamanho esta NULL SOLUÇÃO Executar o comando em anexo na pendência. O comando irá ajustar o tamanho, para o tamanho único, tamanho apontado no cadastro do produto. OBSERVAÇÕES Após a execução do comando, o relatório abriu normalmente. Não foi possível identificar o motivo da tabela ficar sem a referência do tamanho do produto. Atenção: Realizar backup da base antes de executar o script; Executar primeiramente em homologação, e somente após validação completa de dados executar em produção; Não executar em outra base de dados, por mais similar que um possível problema possa parecer; Antes de executar em produção, certificar-se de que o Broker NÃO esteja no ar. Após execução, limpar os caches (cache, cfgcache, kvcache). Script demorou menos de 1m para ser executado.
MILLEN-6873	CAUSA/MOTIVO A informação do numero de objeto enviada para o millennium não estava sendo replicada para vtex porque o processo de envio já havia acontecido SOLUÇÃO Ajustado método para realizar também a atualização do rastreio para vtex. caso o faturamento do pedido ainda não tenha ocorrido vamos dar erro
MILLEN-6886	CAUSA/MOTIVO Necessidade de sempre gravar o json de envio do pedido vtex para workflow/extensão trate o pedido corretamente. SOLUÇÃO Feito tratamento para melhorar a gravação do response do pedido, gravando também da contingência e garantindo que todos os pedidos sejam tratados corretamente pelo workflow OBSERVAÇÕES Verificado erro no envio do estoque, com ID inexistente. Esse problema deixará todos os produtos na fila de estoque, gerando lentidão e chamadas excessivas.
MILLEN-5660	CAUSA/MOTIVO Cliente informou que existem registros com a Flag "Pode Conferir" marcada porém sem data no campo "Data Pode conferir". Onde no momento que é marcado como verdadeiro a flag, deve salvar o horário que foi executado. SOLUÇÃO Foi alterado dois pontos realizavam Update na tabela Pre Faturamentos marcando "Pode conferir" e não informando a "data do pode conferir" e o "Usuário do pode conferir". Com isso este erro não ocorrerá novamente. Porém para os registros que já estão nesta situação foi criado o comando anexo no jira, onde foi considerada a "Data do Pode Conferir" como "Data do Expedição" e o "Usuário do pode conferir" como o "System". Verificado na base esse comando abrangeu em média 41.000 registro, porém ainda existem em média 800 registros sem serem alterados. Esse comando levou aproximadamente 41 minutos para execução.
MILLEN-5712	CAUSA/MOTIVO Dados enviados para microvix retornaram com informação de inconsistência. SOLUÇÃO Embora não tenhamos informação da causa da falha realizamos ajuste no lançamentos para quando há brinde envolvido. OBSERVAÇÕES Por causa do envolvimento de brinde de 100%, mas cobra frete pode haver inconsistência no aceite do Microsiga. Por depender de outra plataforma e falta de informações sobre a causa da recusa na Microsiga foi aconselhado enviar dll para realizar testes. Preferencialmente em ambiente de homologação
MILLEN-5831	Ocorreu um outro erro na importação de estoque, foi identificado que o problema estava na regra onde o programa quando não encontrava valor para posição 1 dos tamanhos, o programa não importava. Porém na base de dados do Cliente existe o conceito de grade pai e filha, onde nem todos os tamanhos são preenchidos. O ajuste foi enviado para ser validado no cliente.
MILLEN-5896	CAUSA Existem movimentações de Prefaturamentos que já foram entregues, mas os empenhos e algumas quantidades nao foram consumidas devidamente. SOLUÇÃO Executar o comando QUESTION UNDERWEAR - CORRIGE EMPENHO PREFAT ENTREGUE -V2009.sql O script ajustar os empenhos indevidos. OBSERVAÇÕES Recomendamos atualizar o cliente para a versão mais recentes, pois as rotinas que ocasionam essa falha nos empenhos já foram tratas. Atenção Realizar backup da base antes de executar o script; Executar primeiramente em homologação, e somente após validação completa de dados executar em produção; Não executar em outra base de dados, por mais similar que um possível problema possa parecer; Antes de executar em produção, certificar-se de que o Broker NÃO esteja no ar. Apos execução, limpar os caches; Script demora menos de 10Min para ser executado.
MILLEN-5992	Conforme informado e conversado com o programador, a mensagem apresentada ao efetivar a movimentação não se trata de um erro. E sim porque o pré-faturamento foi efetuado com o kit de forma parcial. Informado também pelo programador: "Identificamos que esses faturamentos parciais foram incluídos manualmente. Ao analisar o saldo do produto faltante do kit, verificamos que o saldo do mesmo está negativo. Tentamos efetuar o faturamento de um pedido novo de teste, porém retorna uma mensagem de trava do sistema que está acionada: Os faturamentos manuais que negativaram o saldo foram a partir do dia 15/03/2021. Será necessário validar com o cliente o cenário que ele utiliza para esses faturamentos manuais. Orientar o cliente a não faturar um pré-faturamento com kit parcial. Quando houver saldo para reservar apenas parte do kit, o cliente deve alterar o pré-faturamento existente e adicionar a peça restante" E também foram encontradas "sujeiras" na compilação que podem ser corrigidas com o script em anexo no jira.
MILLEN-6004	CAUSA Existem consignações de 2013 indevidas na base de dados, como o empenho é muito antigo não foi possível identificar o motivo, pois pode ser uma conversão/importação e/ou alteração na configuração do evento e forma como o sistema trabalha. SOLUÇÃO Executar o comando.: SGLUM - Corrige empenho indevidos - V2009.sql Script irá corrigir as movimentações indevidas da base de dados e executar o reload_estoque. OBSERVAÇÕES Atenção Realizar backup da base antes de executar o script; Executar primeiramente em homologação, e somente após validação completa de dados executar em produção; Não executar em outra base de dados, por mais similar que um possível problema possa parecer; Antes de executar em produção, certificar-se de que o Broker NÃO esteja no ar. Após execução, limpar os caches; Script demorou cerca de 40m para ser executado em base local.
MILLEN-6046	CAUSA/MOTIVO Cliente necessita visualizar o campo data de entrega do item, mas ao tentar utilizar o campo no dashboard, a rotina não retorna informações. SOLUÇÃO Ajustado o arquivo do cliente, o vinculo com o pedido estava errado. OBSERVAÇÕES Para efetuar importação deverá seguir os seguintes passos.: 1 - Parar a execução do broker 2 - No banco de dados do cliente, executar o comando em anexo no jira. 3 - Na pasta wts\dbdic remover o arquivo anterior do cliente.: HistoricoProdutos_M.mdd 4 - Copiar o arquivo ajustado para a pasta wts\dbdic.: HistoricoProdutos_MC.mdd 5 - Executar o dbdic para registrar o relatório 6 - Iniciar o broker e acessar o gerenciador de usuários para "gerar o link" para o relatório, clicar no grupo Mestre e salvar; 7 - Acessar o relatório conforme o cenário da pendencia
MILLEN-6080	CAUSA/MOTIVO Sistema não estava atualizando o financeiro na integração quando havia ruptura no pedido, estava criando um titulo a pagar para o cliente com a difereção quando configurado para controlar crédito. SOLUÇÃO Foi criado um procedimento onde no lugar de criar esse titulo a pagar para o cliente, o sistema irá atualizar o financeiro do lado do linx, para que ocorra a atualização o pagamento deve ser cartão e transacao_aprovada deve estar como 'R', caso contrário, se a integração estiver configurada para controlar o crédito, o sistema irá gerar a parcela, senão, não irá atualizar nada pois é um valor que já foi cobrado do cliente.
MILLEN-6111	CAUSA/MOTIVO Tela de Consulta do SAC calculando valor de frete incorreto para devoluções parciais. SOLUÇÃO Retirado a função de arrendondar do método de consulta que foi adicionado pela BMMANU-25020, este arredondamento foi feito para devoluções completas e não é mais necessário pois o sistema já ajusta o valor na inclusão dos produtos na tela.
MILLEN-6148	CAUSA O Lançamento foi gravado com o tipo do gerador "Fornecedor" no campo GERADOR e com o id (FORNECEDOR) da tabela FORNECEDORES no campo COD corretamente, no entanto, o campo GERADOR_ORIGEM não foi gravado, sendo que é esse campo que realiza a ligação do gerador com o gerador do Lançamento. Por esse motivo o campo Credor não é exibido na consulta de títulos a pagar. SOLUÇÃO Ao tentar simular o cenário inserindo uma venda utilizando o mesmo evento, cliente, produto ocorreu a mensagem de alerta abaixo: Essa mensagem é devido a venda ser para o estado "AM" e nas configurações está apenas informado o estado "AP". Com isso, não conseguimos simular o cenário do cliente, onde temos um lançamento gravado sem o GERADOR_ORIGEM. Portanto, segue em anexo um comando para gravar o GERADOR_ORIGEM correspondente do Fornecedor do lançamento.
MILLEN-6184	CAUSA/MOTIVO Solicitado o split dos produtos SE dentro dos item acabados. SOLUÇÃO repassado os produtos SE no output do método MILLENIUM_FV_POSITIVO.PEDIDO_VENDA.LISTAFATURAMENTO_ASSURANT respeitando a quantidade vendida de serviços.
MILLEN-6203	CAUSA/MOTIVO Existem registros de partida_contabil com data de 2021, referenciando registros da mov_contavil de 2017. SOLUÇÃO Foi localizados todos os pontos do sistema onde apaga a tabela partida_contavil e em todos eles o sistema apaga a mov_contabil, e não foi encontrado nenhum outro ponto que apaga somente a partida contábil. Segue o comando para excluir os registros da mov_contabil referenciando partidas onde a data da partida_contavil está diferente da mov_contabil. Rodar como Script emanexo no jira.
MILLEN-6215	CAUSA/MOTIVO Sistema estava permitindo alteração de item de recebimento de embarque que já estava faturado. SOLUÇÃO Adicionar trava para não permitir alteração depois de recebimento de embarque faturado.
MILLEN-6263	MOTIVO Conforme descrição da pendência. SOLUÇÃO Conforme MILLEN-389.
MILLEN-6267	CAUSA/MOTIVO Pedidos não estão sendo encontrado na plataforma pela busca ser case sensitive SOLUÇÃO Retirar o uppercase.
MILLEN-6273	CAUSA/MOTIVO Sistema se perdia para fazer a conta de quantidade na NF e quantidade devolvida, porque o mesmo produto estava lançado duas vezes na NF (com campo ITEM diferente) SOLUÇÃO Agrupado as quantidades dos produtos na consulta, para que ser abatido a quantidade conferida corretamente.
MILLEN-6334	O problema descrito da pendencia estava ocorrendo por causa do valor do trans_id estar negativo.

ajustado

Ajustado o sequence diretamente no servidor de produção do cliente, acertando as tabelas envolvidas e reposicionado a publicação. Ajustado diretamente em produção.
MILLEN-6344	CAUSA Um dos grupos foi criado errado na raiz do Millennium, assim causando a inconsistência na abertura do gerenciador de usuários. SOLUÇÃO Executar os comandos em anexo no jira. Abrir o gerenciador de usuários e salvar. OBSERVAÇÕES Após a execução, validar os acessos e consistência dos usuários do grupo; Existem registros de usuários com histórico no grupo "MILLENNIUM\TDC_LOJA_NS", mas que não aparecem no gerenciador de usuários (devem ser recriados se necessário): MARIAHELENA MARIAPAULA Atenção Realizar backup da base antes de executar o script. Executar primeiramente em homologação, e somente após validação completa de dados executar em produção; Não executar em outra base de dados, por mais similar que um possível problema possa parecer; Antes de executar em produção, certificar-se de que o Broker NÃO esteja no ar. Após execução, limpar os caches(wts\cache, wts\cfgcache, wts\kvcache, wts\content_cache); Script demora menos de 1Min para ser executado.
MILLEN-6347	CAUSA/MOTIVO O SQL continha uma opção com : min ( -1 ) as 'componente' , min (null) as 'observacao' , O que estava ocasionando erro para banco MySQL. SOLUÇÃO Foi realizado um CAST no campo componente e observação para evitar que o problema se repita. CAST ( -1 AS integer ) AS 'componente' , CAST ( NULL AS varchar (1) ) AS 'observacao' ,
MILLEN-6359	CAUSA/MOTIVO Alguns itens sem preço decorrente a falha na comparação do desconto com preço do produto impedindo na identificação de brinde. SOLUÇÃO Arredondamento dos valores para comparação.
MILLEN-6366	CAUSA Existe um evento de workflow na tabela WTSSYS_EVENT, que não aponta para nenhum contexto. Não foi possível identificar a origem dessa linha, não há nenhum Workflow vinculado a esse evento e pedido de venda vinculada a saida deste evento, aparentemente é um teste ou manipulação no banco de dados. SOLUÇÃO Executar o comando em anexo no jira. Script irá apagar as linhas que não apontam para nenhum próximo evento de workflow. OBSERVAÇÕES Atenção Esse Script serve apenas para esse cenário, não executar em outros clientes. Realizar backup da base antes de executar o script. Executar primeiramente em homologação, e somente após validação completa de dados executar em produção; Não executar em outra base de dados, por mais similar que um possível problema possa parecer; Antes de executar em produção, certificar-se de que o Broker NÃO esteja no ar. Após execução, limpar os caches.
MILLEN-6381	CAUSA/MOTIVO Pedido brinde não é integrado SOLUÇÃO Feito tratamento para recuperar o valor do produto quando este estiver zerado, e ser marcado como brinde.
MILLEN-6389	CAUSA/MOTIVO ajustes aplicados na millen-5687 repercutiram na alteração na sequencia de envio das imagens, que implicitamente refletiu na ordenação da imagem dentro da EZcore. SOLUÇÃO retirado processo de envio de imagens em multi - thread.
MILLEN-6391	QUEBRA DE TESTE
MILLEN-6395	CAUSA Quando realiza o filtro por funcionário no relatório 86, internamente gravamos o ID do funcionário em uma tabela temporário no campo chamado REPRESENTANTE. O problema ocorria, porque o cliente tem no gerenciador de usuários Restrição aos Dados de alguns Fornecedores, e nesses casos, o broker automaticamente realiza um filtro em todas as tabelas que possuem o campo REPRESENTANTE a fim de consultar apenas os Representantes que o usuário tem acesso. E com isso, como a tabela temporária está com o funcionário gravado no campo REPRESENTANTE, o mesmo não é filtrado ocorrendo o erro. SOLUÇÃO Utilizado no método a macro #NOFILTER(), pois ela tem a função de não realizar o filtro de acordo com o que foi estabelecido no Gerenciador de Usuários.
MILLEN-6397	CAUSA/MOTIVO Produto não era inativado na plataforma, pois não retornava o preço do produto inativo/excluído. SOLUÇÃO Feita correção no método para trazer valores mesmo de produtos excluídos e ou inativos. Feita também uma melhoria na tray que irá sempre inativar um produto, mesmo sem preço.
MILLEN-6409	CAUSA/MOTIVO exportação da vitrine com erro Field not found in dataset SOLUÇÃO alterar o dataset que estava quebrando o dataset de Produtos
MILLEN-6423	Conforme informado pelo solicitante, a pendência já foi corrigida no ambiente do cliente e está funcionando corretamente.
MILLEN-6446	Causa Sistema NÂO está considerando o código cBenef para os CSTs 60, 30, 10 e 90 Solução Regras distintas para cada UF e o Estado do RS, ATUALMENTE e diferentemente do PR e RJ, exige informação para qse todas as CSTs, exceto 00 e 90 https://blog.oobj.com.br/cbenef/#:~:text=O%20que%20%C3%A9%20cBenef&text=Cada%20UF%20possui%20orienta%C3%A7%C3%B5es%20espec%C3%ADficas,prazos%20e%20condi%C3%A7%C3%B5es%20desses%20estados. Modificada a DLL millenium_nfe para repassar o código cBenef definido no produto, para todos as UFs q estejam definidas no arquivo NFeSolucoes.ini, propriedade UFs_CBENEF. Para controlar o uso por UF há, no cadastro de CFOPs, aba Impostos, a tabela UFs Benefício. O valor definido para uma UF será prioritário na exibição/uso no XML, desde q a UF tenha sido informada no arquivo NFeSolucoes.ini.
MILLEN-6447	CAUSA/MOTIVO Criação, pela Fbits de uma nova tag, "valorDesconto", dentro do grupo de "pagamento". SOLUÇÃO Devido a constante alteração do json da fbits, foi passado para a versão 75 ajuste semelhante ao feito na versão atual, em que a partir dos valores efetivos pagos pelo cliente e dos valores dos itens e frete, se obtém o valor dos descontos e/ou juros.
MILLEN-6456	Motivo Erro ocorre devido aos campos de CFOP retornarem fora da ordem esperada pela tela de pedido de venda. Erro será passado ao Gustavo para que possamos corrigir. Solução Neste momento teremos que corrigir de forma paliativa. Na base de dados do cliente, devemos passar a configuração de CFOP da tela em HTML, para a tela antiga. Tirei um print com as configurações atuais, para facilitar a "reconfiguração". Rotina Para Solução Parar o Broker e limpar os caches. Executar o script.: DELETE FROM CONFIGURACOES c WHERE c.PARAM_NAME = 'CFOP_PV' Ligar o Broker. Ir no millennium e utilizar a tela antiga da configuração de pedidos.: Menu->Vendas->Configurações Menu lateral.: Pedido de Vendas Botão.: Tabela de Cfop possíveis no Pedido Cadastrar novamente as CFOPS nessa grid. Após o cadastro, parar novamente o broker e limpar os caches. Ligar o broker. Com este cadastro, o pedido de venda carregou normalmente Observação Pendência semelhante a.: MILLEN-6014 Atenção Realizar backup da base antes de executar o script. Executar primeiramente em homologação, e somente após validação completa de dados executar em produção. Não executar em outra base de dados, por mais similar que um possível problema possa parecer. Antes de executar em produção, certificar-se de que o Broker NÃO esteja no ar. Apos execução, limpar os caches
MILLEN-6469	CAUSA/MOTIVO Sistema esta montando a barra de acordo com a grade do produto quando o tipo de código de barras era igual a 2. SOLUÇÃO Efetuado ajuste para ler da maneira como vier do linx erp.
MILLEN-6516	CAUSA Existem movimentações de Prefaturamentos que foram quitados, mas os empenhos foram consumidos devidamente. SOLUÇÃO Executar o comando.: PRO EURO_02 - Corrige Empenho Completo - V5.sql O script ajustar os empenhos indevidos. OBSERVAÇÕES Feito diversos testes e não foi possível replicar o erro encontrado na base, existem diversas travas como esta por exemplo. Caso continue ocorrendo este erro será necessário validar com o cliente o cenário que ele utiliza para que possamos analisar uma trava. Atenção Realizar backup da base antes de executar o script; Executar primeiramente em homologação, e somente após validação completa de dados executar em produção; Não executar em outra base de dados, por mais similar que um possível problema possa parecer; Antes de executar em produção, certificar-se de que o Broker NÃO esteja no ar. Após execução, limpar os caches; Script demora menos de 10Min para ser executado.
MILLEN-6529	CAUSA/MOTIVO Sistema não estava enviando o valor total da nota fiscal devido a regressão da pendencia 6080 SOLUÇÃO Ajustado para preenchimento adequando do valor total quando for devolução ou venda.
MILLEN-6572	CAUSA Existe uma configuração que a informação esta inconsistente no banco de dados, fazendo com que o broker não identifique o tipo do param_value. SOLUÇÃO Executar o comando ema nexo no jira. Após o comando o sistema conseguiu abrir normalmente a configuração. OBSERVAÇÕES Como estamos removendo uma configuração, se_rá necessário validar com o cliente a configuração que ele utiliza na rotina.:_ Menu->Utilitarios->Administrador->Configurações Gerais->Logistica->Pré-Faturamentos de Saída-> Aba DAP->Campo.: Modo de Geração dos Pré-Faturamentos no DAP. Para Teste Para efetuar o teste de permitir conferencia, será necessário copiar o arquivo.: millenium!foreverliss.wtspara as pastas.: millennium e wts. Atenção Realizar backup da base antes de executar o script; Executar primeiramente em homologação, e somente após validação completa de dados executar em produção; Não executar em outra base de dados, por mais similar que um possível problema possa parecer; Antes de executar em produção, certificar-se de que o Broker NÃO esteja no ar. Após execução, limpar os caches(wts\cache, wts\cfgcache, wts\kvcache, wts\content_cache); Script demora menos de 1Min para ser executado.

CAUSA/MOTIVO
Campo para ordenação do item no cupom e no ticket.
SOLUÇÃO
Troca do campo referência para que seja o mesmo em ambos os sistemas.
OBSERVAÇÕES
Também houve necessidade de realizar uma correção no linx_ticket.incluir que estava pegando um campo incorreto e gerando exception

Painel

titleColor	#FFB200
titleBGColor	#2C004B
title	5.86_216.Custom.3

Pendência	Resolução
MILLEN-

7864

SOLUÇÃO
Alterado o método MILLENIUM.VOLUMES_EVENTO.ALTERA_STATUS utilizado tela na Logística\TMS\Consulta Volume' Botão 'Alterar Status', para fazer a chamada do evento de entrega.
Já existe uma flag na configuração para VTEX enviar o status de entrega feito na pendência BMMANU-26107, esta alteração está na versão 79.17 e branches.
OBSERVAÇÕES
Para o pedido VTX-607856 não foi identificada uma baixa automática para a transportadora, já que está utilizando a opção 'modules', e não está utilizando uma interface por outra transportadora.
como TotalExpress/Jadlog.
Flag da configuração de status de Entrega da VTEX
Vitrine\Vitrines\Alterar\ Botão Configurações Adicionais: Enviar Status de Entrega
Foi validado o processo do Workflow, por não ter o ambiente de vtex para envio de status.

MILLEN-8524

CAUSA
Sistema não dava suporte ao cálculo de ICMSST definido para o RS. A fórmula apresentada pelo solicitante é a seguinte :
Base ICMS : ValorDaOperacao
Valor ICMS : baseICMS * aliqICMSinterestadual
Base ICMSST : ((baseICMS - valorICMS) / (1 - aliqICMSinterna/100))
Valor ICMSST : (Base ICMSST * aliqICMSinterna) - Valor ICMS
SOLUÇÃO
Criado no cadastro de CFOPs, no campo Regime Substituição a nova opção "DIFAL( ICMS abate Base ST)".
Alterado o código fonte para qdo essa opção estiver marcada efetuar o cálculo de acordo com a fórmula proposta.

MILLEN-8864

Correção aplicada. Segue anexo na pendência o boleto emitido após a correção:Boleto_8864.pdfBoleto_8864.pdf**
Observação
As informações de Juros, mora e observação tem como prioridade as do Tipo de pagamento, caso não tiver preenchido ele acata as do borderô.

MILLEN-9162

CAUSA/MOTIVO
Seguir cenário.
ALTERAÇÃO
Alteração realizada em millenium_eco_active_hub.dll na branches.
SOLUÇÃO
Correção no programa no envio das informações de altura, largura, comprimento e peso que estavam sendo recuperadas do metodo lista_vitrine de forma incorreta.

MILLEN-9254

CAUSA/MOTIVO
Ao incluir um pedido ou mesmo fazer a conferencia de um pedido usando o parâmetro "Utiliza KIT Como Assistente de Preenchimento" o sistema carrega as quantidades erradas dos componentes.
SOLUÇÃO
O sistema assumia a quantidade do produto KIT apenas. Agora o sistema passa a multiplicar a quantidade do produto KIT * quantidade dos componentes do kit para considerar na venda.

MILLEN-9442

CAUSA
No arquivo de retorno existe uma linha referente ao código "510 - Boleto com PIX".
No entanto o layout do banco do Brasil para ler o arquivo de retorno não tinha esse registro implementado, causando o erro na leitura do arquivo.
SOLUÇÃO
Adicionado para o Banco do Brasil, com convênio de 7 dígitos o Registro Boleto com PIX no retorno.
OBSERVAÇÕES
Na geração do arquivo (remessa), o Millennium não manda informações referente ao PIX, porém quando esse arquivo é processado pelo banco e retornado para o cliente (arquivo de retorno) esse registro do PIX retorna. Verificando no layout, pelo que entendi se trata de um processo novo.
Acreditamos que um boleto possa ser pago via PIX agora, lendo um QR Code no boleto ou copiando o código de barras no pagamento via PIX. Porém, não mandamos para o PlugBoleto informações para gerar QR Code de pagamento via PIX. O que pode estar ocorrendo é através do número do código barras ser possível efetuar o pagamento, mas não temos a informação se essa forma de pagamento é possível.
As informações sobre o comando (ação) sobre o boleto estão na linha de registro "7", que é a linha que precisamos para saber se o boleto foi pago, protestado, agendado entre outros, com isso, adicionamos o registro do PIX apenas para não ocorrer erro na leitura do arquivo, pois retornava uma informação que o sistema não conseguia ler.

MILLEN-9540

CAUSA/MOTIVO
Tratamento para pgtos assumidos pelos afiliados não considera afiliado BBlend(BBL)
SOLUÇÃO
Implementação no tratamento do afiliado BBlend(BBL)

MILLEN-9587

Foi verificado com o desenvolvedor que a combinação "Usa Múltiplos Tipos Fretes" = 'T' e "Ignora Filial do Item" = 'T' não pode ser aplicada, pois um parâmetro anula o outro. Quando o "Ignora Filial do Item" aparece igual a 'T', o processo do "Usa Múltiplos Tipos Fretes" é anulado.
Foi definido que deve ser criada uma trava quando os dois parâmetros estiver igual a "T".

MILLEN-9613

CAUSA/MOTIVO
Campo Valor, na tela de consulta Histórico Cliente - Mer... está trazendo valores com muitas casas decimais.
SOLUÇÃO
Realizada a implementação na rotina de consulta contida no MOVIMENTO.MDO. O atributo "TOTAL_LIQUIDO" possui uma lógica onde são calculados 3 campos distintos para se chegar no valor final, e neste cálculo, a soma destes campos, após dividir, estava resultando em valor com mais de 5 casas decimais. com isto foi aplicado um CAST AS NUMERIC(8,2)) no campo TOTAL_LIQUIDO
OBSERVAÇÕES
O cliente cita que, mesmo alterando o displayformat não surtiu efeito, ressalto que, esta propriedade é apenas para o Gerador de Relatórios.
Ao homologador, caso o cliente não queria atualizar, é só gerar a versão e passar o arquivo " MOVIMENTO.MDU." localizado wts\mdmeta\movimento.mdo, sempre fazer o backup do original, e qualquer alteração, deve ser feita em ambiente de QA, antes de aplicar em produção.

MILLEN-9622

CAUSA/MOTIVO
Não apresentava o componente de lista no campo "Pedido".
SOLUÇÃO
Removida flag chave e ajustado o tipo do campo do pedido no método Lista.

MILLEN-9632

CAUSA/MOTIVO
Diverge da soma dos valores.
SOLUÇÃO
Ajuste no calculo do valor total do pedido.

MILLEN-10015

CAUSA/MOTIVO
O campo expressão de imagem da vitrine estava sendo passado para a query com aspas duplas e o broker não estava convertendo corretamente.
SOLUÇÃO
Alterado o uso do campo diretamente pela query.

Painel

titleColor	#FFB200
titleBGColor	#2C004B
title	5.86_22

Pendência

Resolução

MILLEN-4243

CAUSA/MOTIVO
Ao selecionar o tipo de pagamento, não está alterando a coluna desconto.
SOLUÇÃO
Foi verificado que a rotina não é para levar em consideração o tipo de pagamento, o tipo de pagamento deve ser selecionado no cadastro da condição de pagamento, o campo do modal deveria ser apenas um campo de leitura.

MILLEN-4885

CAUSA/MOTIVO
O campo Opções de Cores, só estava sendo considerado quando a Origem de Compilação fosse 0 -'Compilação de Pedidos' e 5 - 'Compilação de Pedidos + Previsão de Vendas/Produção'.
Utilizando a Origem de Compilação '3 - Fases' a select havia uma recursão para localizar todos os produtos que eram utilizados como componentes na ficha técnica sem a validação da cor inativa para o componente.
SOLUÇÃO
Removida a visibilidade do campo 'Opções de cores' para a tela 'Compras/Pedido de Compras automático' pois a finalidade da tela é a inclusão do pedido, e neste caso a cor sempre deverá estar Ativa.
Ajustada a select dos componentes de ficha técnica para levar em consideração a flag de cor ativa no método MILLENIUM.PRODUCAO. Necessidade quando aberto pela tela de 'Pedido de Compras automático'.
Incluido um check no MILLENIUM.PEDIDO_COMPRA.Inclui para travar a inclusão de pedidos com produtos com cor inativa independente da pesquisa anterior.
OBSERVAÇÕES
Não foi alterado o funcionando do relatório '106 – Necessidade de Matéria-Prima' pelo Menu.

MILLEN-6833

CAUSA/MOTIVO
Evento de Devolução fica carregando, demora cerca de 10 minutos para gerar. Porém, às vezes ocorre mensagem apresentado: "binbrowser.exe não responde".
Isso ocorre porque o sistema executa algumas vezes a query que preenche o combo com os dados Nota Ref.
SOLUÇÃO
Uma vez que foi preenchido o combo não há mais necessidade de preenchê-lo novamente.
Foi inserida uma validação neste processo que verifica se o combo com as Notas Ref está preenchido.

MILLEN-6921

CAUSA/MOTIVO
Método MILLENIUM.PRECOS.DERIVA_LISTA_PROD estava formatando com o comando 'CAST' o preço para 2 casas decimais.
SOLUÇÃO
Conforme solução dada na MILLEN-6939, foi alterado o método MILLENIUM.PRECOS.DERIVA_LISTA_PROD comando'CAST' para formatar o preço com 6 casas decimais.
OBSERVAÇÕES
Conforme orientação da MILLEN-6939
Após clicar em "Próximo" na tela de 'Derivar Preços', na tela que mostra o grid, os produtos são mostrados com 2 casas decimais, que é o padrão da tela.
Caso ele seja cadastrado com custo 0,0033, esse valor será corretamente gravado em banco de dados e nesta tela, o grid mostrará 0,00. Porém ao derivar, o preço será repassado corretamente.

MILLEN-7429

CAUSA/MOTIVO
Cálculo do abatimento da cortesia no IPI sendo forçado no e-commerce.
SOLUÇÃO
Utilizado mesmo flag do financeiro para condicionar uso.

MILLEN-7600

CAUSA/MOTIVO
Ao importar a planilha, e importar as características de sku, não estava respeitando campos com casas decimais.
SOLUÇÃO
Ajustado para que os campos decimais sejam lidos corretamente.

MILLEN-8037

CAUSA/MOTIVO
Relatórios não mostram extensão para Excel. Quando renomeado ao salvar o relatório perde a extensão caso o usuário não coloque.
SOLUÇÃO
Colocado no binbrowser um método para que seja gravada a extensão original, independente do que foi digitado pelo usuário.
OBSERVAÇÕES
1 - Para que o relatório tenha dados é necessário solicitar "ESTE ANO" invés de essa semana como na descrição da pendência.
2 - Substituir a pasta MdMeta pela anexada, caso contrário ocorre um erro ao abrir o relatório.

MILLEN-8452

CAUSA/MOTIVO
Consulta de SALDO estoque com problema
SOLUÇÃO
Para o produto em questão foi gerado um comando para correção, será disponibilizado para solicitante a validção em QA,
OBSERVAÇÕES
- POR FAVOR, APLICAR O COMANDO EM QA, E FAZER A VALIDAÇÃO PARA O PRODUDO CITADO NA PENDÊNCIA, '000125'
APLICAR O COMANDO EM AMBIENTE DE QA DO CLIENTE.

MILLEN-8546

CAUSA/MOTIVO
Erro ao enviar Status Faturado (não enviamos o Bairro)
SOLUÇÃO
Adicionar o campo bairro.

MILLEN-8864

CAUSA/MOTIVO
Sistema não estava preparado para enviar as informações de instruções para o PlugBoleto conforme fazia anteriormente com Cobrebem.
SOLUÇÃO
Migrada a função de mensagens do Cobrebem para PlugBoleto e adaptado para os códigos do PlugBoleto.
Criadas as mensagens para desconto, multa e juros.
OBSERVAÇÕES
Título que gerou boleto anexo na pendência já foi excluído do ambiente do cliente no PlugBoleto pelo programador.

MILLEN-9067

CAUSA/MOTIVO
Erro de "EZ Core: HTTP/1.1 500 manutençao</title>:<!DOCTYPE html>" ao ao alterar o status do pedido para despachado
SOLUÇÃO
Retirada de carácter incorreto que foi gerado no campo de url.

MILLEN-9068

CAUSA/MOTIVO
Quando foi alterado o parâmetro "Formata por sentença" no Formata descrição de produtos não estava sendo respeitada a flag dentro do sistema.
SOLUÇÃO
Para resolver esta situação foi implementado no código a funcionalidade de "Formata por sentença" para enviar somente a primeira letra em maiusculo da frase referente a descrição produto.

MILLEN-9128

CAUSA/MOTIVO
Não havia implementação da tela de agendamento para template html (.mdh) na versão HTML.
Houve alterações no modo como o sistema salva o campo parâmetros dos relatórios para a versão HTML.
SOLUÇÃO
Ajustado o HTML para trazer os campos referentes ao template html (.mdh) no agendamento de relatórios.
Conforme orientação, foram retirados os links do menu dos templates html (.mdh) do menu.
Ajuste no Render do template que estava perdendo a transação WTSSYSTEM.DIRECT.PASSTHROUGH'
Ordenação do agendamentos para enviar mdh, mdr.
OBSERVAÇÕES
O modelo .mdr fornecido pelo cliente utiliza na condição o comando 'today -5, este comando só é aceito para os bancos Firebird, para o SQL SERVER deve ser usado o #DATE() -5.

MILLEN-9267

CAUSA/MOTIVO
Na dica do campo MODALIDADE_FRETE estava informando equivocadamente que quando informado a "Modalidade Frete = 5" o Valor do Frete não era somado no Total do Pedido, porém o sistema, sim, efetua a soma quando informada esta modalidade.
SOLUÇÃO
Foi feito um ajuste na dica do campo MODALIDADE_FRETE para não causar mais dúvidas quanto a sua regra de utilização.

MILLEN-9495

CAUSA
Ao realizarmos uma publicação na vitrine 18 ("ECOMMERCE MAGENTO"), esta sendo retornado erro no envio de grupo de atributos. abaixo um fragmento do arquivo REST da pasta Trace.
Este erro ocorre pois quando listamos os grupos de atributos, não estamos olhando todas as paginas.
sendo assim o millennium entende que o grupo "MILLENNIUM" não está cadastrado e tentamos cadastra-lo.
SOLUÇÃO
Correção no parametro ao realizar a consulta nos itens de listagem de grupos e de atributos do produto na plataforma magento , ajustando a paginação de acordo com o exemplo da documentação em anexo.

MILLEN-9692

CAUSA/MOTIVO
No momento que está incluindo o pedido de venda o sistema não cadastra o Contato do Cliente.
SOLUÇÃO
Ao incluir o pedido no sistema foi implementada a rotina de incluir o contato do cliente.
Para corrigir, foi necessário a implementação da variável Contatos que recebe a MILLENIUM_ECO.CLIENTES.CONTATO para popular os dados que fará a inclusão dos dados de contatos do cliente no banco de dados. Dessa maneira não ocorrerá mais o erro.

MILLEN-9808

CAUSA/MOTIVO
Sistema não estava efetuando a consulta utilizando o parâmetro de "NOSSO_NUMERO_SEM_DIGITO"
SOLUÇÃO
Foi feita uma nova consulta utilizando o parâmetro NOSSO_NUMERO_SEM_DIGITO quando nenhuma das consultas anteriores retornar o resultado esperado.

MILLEN-9811

CAUSA/MOTIVO
Ao enviar Notas Fiscais do Millennium para o Linx ERP, o campo TRIBUT_ICMS (tabela LOJA_NOTA_FISCAL_ITEM - Linx ERP) recebe o conteúdo do campo SIT_TRIB (tabela PRODUTOS_EVENTOS - Millennium), porém o mesmo estava sendo cortado em 2 caracteres (pegando apenas o 2º e o 3º carácter), ou seja, quando preenchido com "101 ou 102" truncava para "01 ou 02".
SOLUÇÃO
Foi feito um ajuste para não cortar mais o conteúdo do campo, pois ambos os campos possuem o tamanho de 3 caracteres tanto no Linx ERP quanto no Millennium.

MILLEN-10060

CAUSA/MOTIVO
Plataforma da Ezcore permite atrelar skus entre vários produtos, podendo mesclar skus de produtos com grande variação de preço em um único produto.
SOLUÇÃO
Feito tratamento para impedir que um sku seja atrelado a um sku que não seja ao do próprio produto.

MILLEN-10261

Sobre a correção do Copiar Imagem, foi analisado e resolvido na pendência MILLEN-7692.
Disponível na versão 5.89 e estará disponível na versão 5.90
Ao clicar com o direita do mouse e abrir a configuração dos campos na tela HTML será tratada na pendência MILLEN-10111. Solução proposta é voltar a tela para o WIN32.

MILLEN-10277

CAUSA
Com a paginação dos produtos, deve-se proteger a publicação de imagens evitando o desligamento
Andar o trans_id do preço e estoque, conforme a publicação é feita, evitando que, se a publicação é interrompida, seja reiniciado e enviado novamente preço e estoque já enviados.
SOLUÇÃO
Para resolver a instabilidade da Vtex (SOAP), FOI necessário alterar o timeout do serviço (RIO)

Painel

titleColor	#FFB200
titleBGColor	#2C004B
title	5.86_27

Pendência

Resolução

MILLEN-6753

CAUSA/MOTIVO
Andamento por código de barras liberou quantidade incorreta no estoque, quando produto possui mais de uma parte e elas têm quantidades diferentes entre si. O sistema faz a validação das quantidades para saber se tem partes incompletas, mas somente as que estão gravadas na base de dados e não as que estão na tela do andamento via código barras.
SOLUÇÃO
Feito tratamento para validar as quantidades passadas pela tela de andamento por código de barras, quando produto possui mais de uma parte, mediante parâmetro criado no método de finalização de produção.
OBSERVAÇÕES
O produto 8028, cor 999 - única, estampa 000 - única, tamanho 10, na ordem de produção 033856, ao finalizar a produção dele, era para ter entrado no estoque 2 unidades, porém na ocasião entrou 1,5 e sobrou 0,5 na produção. Executar o script em anexo na pendência para fazer o estorno dessa operação e voltar 2 unidades na produção para serem finalizadas novamente e entrar 2 quantidades corretamente no estoque.
Atenção!
Realizar backup da base antes de executar o script.
Executar primeiramente em homologação, e somente após validação completa de dados executar em produção.
Não executar em outra base de dados, por mais similar que um possível problema possa parecer.
Antes de executar em produção, certificar-se de que o Broker NÃO esteja no ar.
Após execução, limpar os caches.
Lembrando: Utilizamos agora o DBEAVER para acesso a base firebird.
Script demora aproximadamente 1Min para ser executado.

MILLEN-8542

CAUSA/MOTIVO
A tela de andamento múltiplo não estava utilizando o campo Ciclo para filtrar as ordens de produção.
SOLUÇÃO
Ajustado a consulta para incluir o Ciclo no filtro.

MILLEN-9063

CAUSA/MOTIVO
Erro ocorria somente em bases sqlserver, a view materializada SALDO_CONTABIL (agrupamento da MOV_CONTABIL) não suporta soma com campos nulos
SOLUÇÃO
Método MILLENIUM.CONTABILIDADE.Recontabiliza alterado todos os pontos que incluem na tabela MOV_CONTABIL (campo QUANTIDADE_MP estava nulo).
OBSERVAÇÕES
Para teste foi contabilizado período 01/07 a 02/07. Verificamos que o erro apresentado após a correção é contábil (deverá ser visto com a contabilidade do cliente).

MILLEN-9384

CAUSA/MOTIVO
Solicitava para informar peso em quebra.
SOLUÇÃO
Ajustado para quando não tiver produto então não validar peso.

MILLEN-9640

CAUSA/MOTIVO
O produto agrupador deve ser retornado completo sempre que um ou mais dos seus componentes for alterado, pois pode ser necessário recriar o agrupador. Isso pode trazer produtos com trans_id menor.
SOLUÇÃO
Feito tratamento para repassar o maior trans_id para o agrupador.

MILLEN-10000

CAUSA/MOTIVO
Ao integrar os Pedidos de Venda do Millennium para o Linx ERP, estava sendo apresentada a mensagem: "O tamanho do número do título supera o permitido na base de dados do Linx ERP".
A mensagem ocorre pois no Linx ERP o campo NUMERO_TITULO (tabela LOJA_PEDIDO_PGTO) possui 15 caracteres e no Millennium o campo N_DOCUMENTO (tabela LANCAMENTOS) possui 35 caracteres.
Logo, no Millennium o conteúdo deste campo estava sendo informado maior que o máximo permitido no Linx ERP. Por exemplo: "ANY-54628118/2/AD" o qual possui 17 caracteres.
SOLUÇÃO
Foi criado o parâmetro "Remove Prefixo Número do Documento" (campo: REMOVE_PREFIXO_N_DOCUMENTO tabela: LX_CONFIGURACOES) nas Configurações (Utilitários -> Linx -> Configurações). Quando habilitado este parâmetro, no momento da integração dos Títulos do Millennium para o Linx ERP, será removido o prefixo que antecede o Número do Documento (Título). Por exemplo, o Título "ANY-54628118/2/AD" vai para o Linx ERP como "54628118/2/AD".
Evitando assim de extrapolar o tamanho máximo permitido pelo campo no Linx ERP.

MILLEN-10058

CAUSA/MOTIVO
Para notas que fossem de numeração automatica, o sistema renomeia o lançamento para a inicial do tipo do titulo ("ICMSP" / "ICMSFP" -> "I") + Número do Romaneio. Ex: ICMSP -> I701324
SOLUÇÃO
Para lançamentos que forem do tipo ICMSFP (Fundo de pobreza) ou ICMSP (Partilha), o sistema irá manter a nomenclatura completa + Número da Nota ou Romaneio, caso já tenha gerado o número da nota irá utilizar a nota, se não, utilizará o número do romaneio.
OBSERVAÇÕES
Ao efetuar o teste da pendência, tomar cuidado pois o parâmetro AMBIENTE no banco de dados original está duplicado, o que está ocasionando a emissão da NF em ambiente de produção, mesmo que no sistema esteja configurado para homologação.
Recomendamos verificar no banco de dados como está configurado antes de enviar a NFe.

MILLEN-10091

Feita uma implementação para acertar o arredondamento dos itens do produto quando gera o kit.

MILLEN-10143

SOLUÇÃO
Correção no Cálculo da Base ICMS de NF brinde usando rateio.

MILLEN-10314

CAUSA/MOTIVO
O campo "Número do Pedido" correspondente ao Pedido do Marketplace do cliente não estava sendo enviado do Millennium para o Linx ERP.
SOLUÇÃO
No Millennium existe o campo N_PEDIDO_CLIENTE da tabela PEDIDO_VENDA, o qual possui essa informação, então foi criado o campo N_PEDIDO_CLIENTE na tabela EML_MOVTOS_INTEGRADOS do Linx ERP e passamos a enviar esse conteúdo na integração dos Pedidos.
OBSERVAÇÃO
É necessário criar o campo N_PEDIDO_CLIENTE na tabela EML_MOVTOS_INTEGRADOS na base de dados do Linx ERP, conforme script disponibilizado no arquivo modules\linx\scripts-db\Scripts_Manutençao_Linx.txt

MILLEN-10339

CAUSA/MOTIVO
A importação de produtos via Excel estava gravando apenas a primeira especificação do produto, caso houvesse mais de uma especificação para o mesmo produto SKU, não gravava no cadastro.
SOLUÇÃO
É necessário marcar o campo "Importador Excel Atualiza Produtos Já Existentes", disponível em Utilitários / Administrador / Configurações Gerais / Produtos e Serviços / Produtos, para todas as especificações serem importadas com sucesso. Feito também um ajuste para não gravar especificações repetidas do produto.

MILLEN-10431

CAUSA/MOTIVO
Erro ao reprocessar os dados de autorização do pagamento "SQLC LAYER ERROR:Field DOCUMENTO not found in context: [LANCAMENTOS as LANCAMENTOS]"
SOLUÇÃO
Correção do select e do update responsável pelo processo de atualização do nsu ao processamento do envio do faturamento do pedido para a VTEX. No select estava sendo utilizada a coluna "DOCUMENTO" da tabela LANCAMENTOS , foi feita a correção para a coluna "N_DOCUMENTO".

MILLEN-10437

Criados os Logs Importação Linx ERP e os link para visualização.

MILLEN-10584

CAUSA/MOTIVO
Erro ao processar arquivo de retorno CNAB.
Foi verificado que há uma conversão errada do campo DATA_VENCIMENTO somente quando Itaú e Ocorrência 29.
SOLUÇÃO
Foi realizada a conversão do campo.

MILLEN-10666

CAUSA/MOTIVO
O valor do IPI não estava sendo considerado no envio para o linx ERP.
SOLUÇÃO
Somados os valores do IPI ao valor total e liquído do método de listagem do pedido e consequentemente somando o valor do mesmo no envio ao linxERP, conforme orientação da equipe do linxERP.

MILLEN-10688

CAUSA/MOTIVO
O Millennium estava enviando a Conta Contábil para o Linx ERP sempre buscando da conta parametrizada na tabela "PARAMETROS_LOJA" do Linx ERP. Ajustar para pegar do Produto, caso tenha.
SOLUÇÃO
Foi feito um ajuste para verificar se existe a Conta Contábil parametrizada no produto e, se existir, vai considerar esta conta, se não vai continuar pegando do parâmetro como era anteriormente.

MILLEN-10689

CAUSA/MOTIVO
A coluna VALOR_IMPOSTO_AGREGAR não estava sendo preenchida na integração Linx ERP.
SOLUÇÃO
Foi feito um ajuste para passarmos a enviar para o campo "VALOR_IMPOSTO_AGREGAR" o Valor Total do IPI.

MILLEN-10690

CAUSA/MOTIVO
Alguns campos não estavam sendo alimentados/atualizados na tabela "LOJA_PEDIDO" do Linx ERP na integração.
Campos: DATA_VENDA, TICKET_VENDA, NF_NUMERO_VENDA, SERIE_NF_VENDA, DATA_FATURAMENTO e ID_INTERMEDIADOR.
SOLUÇÃO
Foram feitos ajustes para passar a alimentar esses campos na integração dos Pedidos.

MILLEN-10731

CAUSA/MOTIVO
Ao cadastrar um produto do tipo kit e selecionar uma vitrine estava dando um erro.
SOLUÇÃO
Ajustada a criação de um objeto, pois este nem sempre era criado mas sempre era acessado gerando o erro.

MILLEN-10809

Ajuste na integração de pedido Linx ERP x Millennium (Preços)

MILLEN-10826

CAUSA/MOTIVO
Estava sendo utilizado o campo Valor_IPI da pedidos_venda que era apenas um campo informativo
SOLUÇÃO
Buscado o valor do IPI da tabela produtos_pedidov calculando o valor do IPI dos itens do pedido.

MILLEN-10909

CAUSA/MOTIVO
O campo TAMANHO (tabela PRODUTOS_BARRA) é do tipo INTEGER, porém estava sendo usado um comando "TRIM" neste campo, ocasionando o erro "Argument data type int is invalid for argument 1 of Trim function".
SOLUÇÃO
Foi retirado o comando TRIM, dessa forma não ocorrendo mais o erro.

MILLEN-10928

CAUSA/MOTIVO
Ao integrar as Notas Fiscais com o Linx ERP, o Millennium estava enviando o Acréscimo e o Desconto para o mesmo campo no Linx ERP (campo DESCONTO tabela LOJA_NOTA_FISCAL).
SOLUÇÃO
Foi feito um tratamento para enviar da seguinte forma do Millennium para o Linx ERP:
Acréscimo envia para o campo ENCARGO (tabela LOJA_NOTA_FISCAL)
Desconto continua enviando para o campo DESCONTO (tabela LOJA_NOTA_FISCAL)

MILLEN-10937

CAUSA/MOTIVO
A integração de Produtos/SKU's estava enviando os SKUs mesmo que seja Novo e Inativo. Por esse motivo entrava na validação e apresentava a mensagem de erro: "Erro no de produto XXX sku XXX : Erro de Sku XXX sem preço".
SOLUÇÃO
Após análise, foi identificado que um ajuste feito em outra pendência atendeu também a situação desta, pois foi feito um tratamento na exportação para que quando o SKU for Novo e Inativo este não seja enviado mais, e por este motivo não vai entrar na validação que estava ocorrendo nesta pendência.
Foi replicado o ajuste da Branches para a versão 5.86.27 (último subrelease da versão 86 até o momento).

MILLEN-10994

CAUSA/MOTIVO
1) No método "millenium!linx.CONFIGURACOES.Alterar" a validação verificava se não havia selecionado nenhum item de integração, porém ela validava antes da inserção nesta tabela.
2) No método "millenium!linx.NOTA_FISCAL.AntesCancelarNf" a validação verifica se existe um movimento gerado com integração no Linx ERP que não esteja cancelado, caso exista, não permite cancelar a NF.
SOLUÇÃO
1) Foi feito um ajuste para validar no final do método, desse forma, verificando corretamente se foi selecionado algum item de integração ou não.
2) Foi feito um ajuste no método para passar a considerar o "Status" da NF, pois se a NF não está validada (ocorreu algum erro) o usuário precisa alterar a movimentação para depois aproveitar o mesmo número de NF.

MILLEN-10996

11651	Foi verificado que estava ocorrendo Access Violation ao importar pedido. Corrigido no if que validava se o valor era maior que zero, mesmo o objeto sendo nulo.
MILLEN-12849	O processo foi analisado e tratado, sendo feito a correção no sistema para ser possível quitar o pedido.
MILLEN-12941	Foi identificado que a correção desse caso já foi solucionada na MILLEN-7429 , então o ajustes foram passados para a versão 5.86.6.Custom.3 que é compatível com a versão do cliente 5.86.6.Custom. A dll millenium_eco.dll está anexada nesta pendência para atualização no cliente. (Obs: É de suma importância fazer backup da millenium_eco.dll atual que está no cliente antes de atualizar para a nova dll). Quanto à integração desta nota, o ajuste foi feito manualmente no Pedido e após isso a Nota foi integrada com sucesso no Linx ERP.

Atalhos

Árvore de páginas

Versões comparadas

Versão antiga 4

Nova versão Atual

Chave