| 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-6270 | |
| 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.
4 - 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 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-6357 | QUEBRA DE TESTE |
| 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. |