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 OBSERVAÇÕES |
| 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 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. |
5.86_21
| 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. |
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) |
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 | 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. |