Histórico da Página

...

Painel

titleColor	#FFB200
titleBGColor	#2C004B
title	5.103.15

Pendência	Resolução
MILLEN-31710	CAUSA/MOTIVO O processo estava pegando os valores da consulta para atualizar, em vez de pegar da tela de alteração. SOLUÇÃO Alterado para pegar as informações atualizadas na tela para salvar. OBSERVAÇÕES Após a correção, a atualização ocorreu corretamente.
MILLEN-37410	CAUSA/MOTIVO Rotina de faturamento, estava alterando o pedido, colocando o lote que foi utilizado na saída, assim caso o cliente faça um processo parcial ou tente colocar mais de um lote, ocorre erro de falta de saldo no pedido, caso seja outro lote. SOLUÇÃO Tratado para não consumir do pedido, caso o pedido não tenha lote ou os lotes não sejam iguais. Ou seja, o faturamento irá ocorrer, mas não terá alteração/consumo no pedido. Todo o processo de Alteração/consumo de Lote/Item, deve ocorrer pelo préfaturamento.
MILLEN-37502	CAUSA/MOTIVO Ao realizar a cópia de um pedido de venda, os itens não estavam sendo exibidos. O problema estava no método "MILLENIUM.PEDIDO_VENDA.Consulta_Itens", ao carregar os itens, a condição estava sendo impactada por uma alteração feita para a MILLEN-33417. SOLUÇÃO Foi necessário utilizar a macro #NULL_TO_Z para evitar que o campo "quantidadenc" ficasse com o valor nulo, durante a soma para comparação.
MILLEN-41355	CAUSA/MOTIVO Quebra de Teste na MILLEN-44188. SOLUÇÃO Foi Feita uma nova forma de correção desta ISSUE que não deve ocasionar a Quebra da ISSUE mencionada. Refazer o teste do cenário desta ISSUE e rodar o teste da MILLEN-44188.
MILLEN-42194	CAUSA/MOTIVO Sistema não identificava o pedido de compra quando selecionado o link "Copiar Produtos", em uma movimentação. SOLUÇÃO Modificado código fonte, para identificar e expor informações de Pedidos de Compra, nos casos de movimentação com Fornecedor.
MILLEN-42321	CAUSA/MOTIVO Vendas - Resumo do pedido na filial de reserva dos itens contidos no pedido - 5.104.6 Sistema não carregava os totais dos itens reservados, estoques disponíveis e próximos recebimentos. SOLUÇÃO Alterado o arquivo MDD incluindo o atributo produto.produto.produto na dash.table pai e alterada a dash.table Estoques Disponíveis o item move.quantidade_atual Revertida a alteração efetuada MILLEN-35486, conforme solicitado pelo desenvolvedor, onde enviava sempre a condição pai para todos os selects subsequentes, ignorando as condições de cada item.
MILLEN-42533	CAUSA/MOTIVO O sistema não estava considerando a célula selecionada, ao executar o andamento por código de barras por pacote. O problema ocorria na classe "TfrmAndamento.DesmembraLote", que ao validar a célula, ela não estava sendo encontrada, pois as checagens se baseavam na variável quando era alimentada por outras rotinas e processos (e não o andamento por código de barras por pacote). As alterações feitas na MILLEN-23586 mudaram a forma como o sistema validava todas as rotinas (feito em MILLEN-18552), o que acabou por desconsiderar algumas. SOLUÇÃO Feito ajuste no método "TfrmAndamento.DesmembraLote", para o sistema considerar a célula selecionada no andamento por código de barras por pacote.
MILLEN-42568	CAUSA/MOTIVO Fórmula TOTAL_LIQUIDO do movimento.mdo está descontando 2x os brindes. SOLUÇÃO Existe um subselect nesta fórmula para pegar os totais do produtos na tabela produtos__eventos, mas este subselect não estava filtrando o que era brinde e bonificado. Realizado ajuste para correção.
MILLEN-42659	CAUSA/MOTIVO O initRow da função Assistente_Lote_e não inicializava alguns campos e na ImportXML o sistema estava zerando os valores já distribuídos para os produtos da movimentação. Também existiam falhas ao desassociar e associar novamente os itens. SOLUÇÃO Inicialização de campo/colunas na initRow e validação para não zerar os valores da movimentação caso já tenham sido distribuídos. Além de correções ao desassociar e associar novamente os produtos. OBSERVAÇÕES Foram corrigidos 4 erros nessa pendência: Primeiro erro: Valores exibidos nos campos de código do fornecedor, Cfop e desconto para todos os itens.Esse erro foi corrigido a partir das versões 103.14, 104.10 e MASTER-5(105) na Eventos.dll. Segundo erro citado após importação do XML em relação a mensagem do código da Situação Tributária, ela ocorre devido à configuração da origem do produto no cadastro. No XML disponibilizado há uma movimentação interna, emitente e destinatário de dentro do Brasil, para um produto com importação direta (Origem 1). Como se trata de uma movimentação interna (dentro do Brasil) de um produto importado, não pode se usada a Origem 1, pois ela indica que o produto está sendo importado diretamente. Nesse caso deve ser usada a origem 2 que indica ser um produto importado mas adquirido no mercado interno. O terceiro e quarto erro ocorriam ao desassociar e associar novamente os produtos. Ao remover a associação, o sistema não limpava os itens relacionados e ao fazer novamente a associação o sistema não rateava o valor entre os itens relacionados.
MILLEN-42971	CAUSA/MOTIVO Sistema não calculava o desconto digitado pelo usuário no campo 'desconto' localizado na barra de totais de uma movimentação, devido às correções implementadas a partir das pendências MILLEN-24188 (soma no percentual de descontos está errado) e MILLEN-24427 (Atualizar field Acerto ao atualizar os totais). SOLUÇÃO Modificado código fonte para efetuar o cálculo nas duas opções disponibilizadas através do parâmetro 'Tipos Desconto' e, também, para efetuar o cálculo ao sair do campo 'desconto'. OBSERVAÇÕES No cadastro de Eventos, o Tipo de Desconto possui duas opções : 'Desconto sobre Desconto' e 'Desconto Simples (soma)'. O Evento indicado utiliza o 'Desconto Simples' (configuração no cadastro de Eventos). O problema reclamado na pendência ocorre somente para o 'Desconto Simples' quando digitado no campo 'Desconto'. Caso não queira aguardar a atualização da versão, o usuário (responsável TI da empresa) pode : 1- abrir a lupa de 'Desconto' e digitar o valor no grid apresentado para descontos; 2- modificar o evento para utilizar o 'Desconto sobre Desconto'.
MILLEN-43006	CAUSA/MOTIVO e-Millenium não valida limites ECF em eventos de NFC-e. SOLUÇÃO Validação do limite por CPF e limite total ao iniciar a finalização de um evento de NFC-e.
MILLEN-43009	CAUSA/MOTIVO Não foi possível validar um caso de embarque concluído sem que o pedido existisse na Intelipost, no caso do cenário o embarque está devidamente concluído e os pedidos existem na Intelipost, contudo, verificou-se que os status dos registros não estão atualizados como concluídos na tabela embarque_itens embora esteja na tabela embarque. SOLUÇÃO Para melhorar a possibilidade de interceptar o erro, ajustamos a chamada do método para que seja gravado o log de erro em um arquivo separado denominado wtsBrokerIntelipostError visto que a reciclagem do arquivo acontece de acordo com o tamanho do mesmo, conforme configuração do broker especificada no wtsconfig, erros gravados em um arquivo separado reduzem o seu tamanho diminuindo a probabilidade de ser reciclado.
MILLEN-43153	CAUSA/MOTIVO Erro na construção da trigger da tabela ipreco, nos campos com uso de expressões complexas como "CAST" e ou subselect: o validador adicionado nas trigger das views materializadas, não estava deixando que a alteração feita em alguns campos, que estão no contexto da materializada, fossem propagadas para a tabela "PRECO_TOTAL", desencadeando uma falha no método millenium_eco.produtos.precodetabela que ao listar dados paginando, acabava retornando um output um trans_id menor do que o envido no input. SOLUÇÃO ajustado view preco_total e preco_validade.
MILLEN-43414	CAUSA/MOTIVO Ao realizar o retorno da oficina, o evento está carregando o campo LOTE. Quando a OP é finalizada o sistema está gravando o lote para o produto, mesmo o produto definido para não utilizar lote. SOLUÇÃO Foi necessário ajustar a query do método "ProdutosRetorno". O sistema carregará o lote no evento de retorno, apenas para os produtos que estiverem definidos para utilizar lote. Produtos que não têm essa permissão, não carregarão o lote no evento e consequentemente o lote não será gravado para ele.
MILLEN-43481	CAUSA/MOTIVO Dentro da configuração existe um campo chamado DATA PARA TRANSFERENCIA, mesmo colocando a data no campo ao efetivar as configurações ficam em branco. SOLUÇÃO Ajustado para gravar o campo DATA PARA TRANSFERENCIA.
MILLEN-43491	CAUSA/MOTIVO Ao verificarmos se o campo enquadramento_ipi é vazio, este se tratava de um Double, porém era verificado se o mesmo é igual a vazio. SOLUÇÃO Para correção, passamos a função VarToStr para assim conseguirmos verificar se o campo é vazio.
MILLEN-43551	CAUSA/MOTIVO Ao realizar a cópia de um pedido de venda, os itens não estavam sendo exibidos. O problema estava no método "MILLENIUM.PEDIDO_VENDA.Consulta_Itens", ao carregar os itens, a condição estava sendo impactada por uma alteração feita para a MILLEN-33417. SOLUÇÃO Foi necessário utilizar a macro #NULL_TO_Z para evitar que o campo "quantidadenc" ficasse com o valor nulo durante a soma para comparação.
MILLEN-43569	CAUSA/MOTIVO O valor vinha cheio, contando os centavos como reais. Não estava fazendo o cálculo de divisão por 100, necessário ao banco Bradesco. SOLUÇÃO Regressada a divisão por 100 no campo valor no leiaute utilizado pelo Bradesco.
MILLEN-43571	CAUSA/MOTIVO: Valor da conta do lançamento não encontrada fazendo com que o sistema não identificasse a filial. SOLUÇÃO Posicionado o ponteiro no primeiro registro antes de obter o valor da conta do lançamentos.
MILLEN-43637	CAUSA/MOTIVO B4A - NF-e Status 307 Denegação: Emitente bloqueado pela UF de destino, em operação com consumidor final. SOLUÇÃO Inseridos novos códigos de denegação.
MILLEN-43653	CAUSA/MOTIVO Sistema apresenta lentidão ao bipar os produtos no andamento de produção por código de barras. Situação ocorre pelo fato do método "TProdInfo.SetCodProduto" estar sendo executado diversas vezes sem necessidade, uma vez que o código procurado, não será retornado pelos métodos de busca internos da rotina. SOLUÇÃO Foi necessário realizar uma checagem se o produto em questão está disponível para ser carregado. Se sim, ele passará pela rotina do método, senão, o método não será executado. Otimizado também o método "MILLENIUM.PRODUTOS.DADOSPARAMOVIMENTACAO", pois havia uma junção desnecessária, que estava tomando alguns segundos de processamento.
MILLEN-43654	CAUSA/MOTIVO Sistema estava fazendo o count geral de todos os registros presentes no estoque, não estava sendo feito o agrupamento necessário para contar apenas os que tivessem saldo positivo. SOLUÇÃO Ajustado o agrupamento para produto\cor\estampa\tamanho permitindo que a contagem seja feita adequadamente.
MILLEN-43729	CAUSA/MOTIVO O sistema não estava conseguindo fazer a montagem do recordset com as informações da filial devido à extensão não estar devidamente configurada. Os métodos acima listados não estavam marcados como extensão e nem apontado a trigger de ação. SOLUÇÃO Ajustados os métodos conforme estrutura de extensão do e-Millennium.
MILLEN-43759	CAUSA/MOTIVO O problema estava relacionado ao "MILLENIUM.PRODUCAO.PRODUTOS_PREFASE". Na MILLEN-5328 foi adicionado um join com a tabela "SITUACAO_PRODUCAO", para considerar o filtro de FASE para os produtos. No entanto, não foi considerado que alguns pontos que chamam o método, podem não passar a FASE. Quando não há FASE , não há necessidade de fazer o join com essa tabela, pois nesse bloco da consulta, estamos apenas checando os dados originais do produto. SOLUÇÃO Realizado tratamento para considerar o join com a tabela SITUACAO_PRODUCAO apenas quando houver FASE (funcionando da forma que era antes da MILLEN-5328).
MILLEN-43765	CAUSA/MOTIVO O Sistema não conseguiu finalizar a conferência do pré-faturamento devido à maneira como estava sendo selecionado o id do pré-faturamento, no caso da finalização não temos mais o id da coluna com o número do pré-faturamento. SOLUÇÃO Passamos a buscá-lo de dentro do método que consulta os produtos para o pré-faturamento.
MILLEN-43788	CAUSA/MOTIVO Ao enviar estoque das variações, quando o produto não tem peças, enviamos o valor "-1" para o Linxio. SOLUÇÃO Tratamento para não enviar valor negativo.
MILLEN-43829	CAUSA/MOTIVO Sistema estava entrando em uma rotina de atualização da prodfis, que não estava encontrando os campos GRADE e COD_PROD_FORNECEDOR no recordset MILLENIUM.PREFATURAMENTOS.PRODUTOS SOLUÇÃO Ajustada a procedure IncluiProduto da prodfis para verificar se os campos existem no recordset, antes de preencher.
MILLEN-43861	CAUSA Problema estava no SUBSELECT que ligava o COD_OPERACAO da tabela VOLUMES com a PREFATURAMENTOS.PREFATURAMENTO, no entanto a tabela PREFATURAMENTOS está na consulta principal, e o campo PREFATURAMENTOS.PREFATURAMENTO não está no GROUP BY. SOLUÇÃO Erro já corrigido através da pendência MILLEN-3803, apenas passado a correção para versão do cliente. O campo PREFATURAMENTO que está no GROUP BY da consulta principal é o da tabela PRODUTO_PREFAT, portanto, na subselect foi ligada a PRODUTO_PREFAT.PREFATURAMENTO. OBSERVAÇÕES Erro ocorre somente em base SQL Server.
MILLEN-43970	CAUSA/MOTIVO Na tela de baixa de seleção não tinha máscaras para formatar os números. Nas telas de listagem, os valores são formatados com apenas 2 casas decimais, mas os totalizadores utilizavam decimais dos fields fazendo a formatação divergir dos campos. SOLUÇÃO Incluímos máscaras no grid da baixa por seleção. Fixamos em duas casas decimais no formatadores.
MILLEN-44049	CAUSA/MOTIVO Inconsistência na exibição dos Cards. SOLUÇÃO Ajuste no filtro para exibição dos cards.
MILLEN-44071	CAUSA/MOTIVO Ao gerar o SPED está indicando mensagem de erro na contabilização de linhas. Sistema estava retornando o cod_nat_cc sempre 00, com isso era gerado o registro 0500 ao final dos outros, alterando a contagem das linhas. Sistema não gerava o fechamento referente so ICMS-ST a recolher do registro E250. Foi encontrado erro na geração do arquivo para os registro M200 e M600, onde o valor deveria ser a soma dos M210 e M610 respectivamente, pois o sistema só incluía 1 registro de cada para cada cod_cont. Foram encontradas NFs emitidas através do ML onde o CST PIS/COFINS estavam com 06 e após importação no e-Millennium o o CST PIS/COFINS foi trocado para 02 SOLUÇÃO 1) Feita a correção para retornar o código correto da tabela conta_contábil. 2) Inclusão do fechamento para ICMS-ST a Recolher para geração do registro E250. 3) Alterado o sistema para permitir mais de 1 lançamento para os registros M210 e M610 com alíquotas diferentes. 4) Geração dos scripts para correção dos lançamentos dos CST PIS/COFINS divergentes entre a NF do mercado livre com a do e-Millennium.
MILLEN-44140	Este erro não ocorre mais. Após análise e revisão com desenvolvedor foi identificado que a pendência MILLEN-43153 corrige este problema.
MILLEN-44154	CAUSA/MOTIVO Registro E316 com erro nos totais Difal+Fcp Sistema não estava adicionando os valores referentes ao fechamento DIFAL-FCP SOLUÇÃO Corrigido o método para inclusão dos títulos referentes ao fechamento DIFAL-FCP.
MILLEN-44155	CAUSA/MOTIVO Na importação de produtos, caso o campo REDE_LOJAS esteja preenchido está tomando erro de Unrecognized escape sequence. SOLUÇÃO Ajustada a geração do JSON que é passada na chamada de API.
MILLEN-44156	CAUSA/MOTIVO Sped ICMS - Registro 0150 com erro campo CNPJ para pessoa física. Cliente possui um endereço em outro país cadastrado, ao gerar o sped o sistema utiliza o método millenium.clientes.dados_nota, onde retorna todos os endereços cadastrados para o cliente, utilizando-se do primeiro registro para identificar o país, nesse caso retornando EUA, e nesse caso deixando o CPF em branco. SOLUÇÃO Trocada a utilização do método por um select quando o tipo do gerador for C-Cliente, onde retorna apenas o endereço de nota.
MILLEN-44157	Este erro não ocorre mais. Após analise e revisão com desenvolvedor foi identificado que a pendencia MILLEN-43153 CORRIGE este problema.
MILLEN-44171	CAUSA/MOTIVO O valor do SIT_TRIB passado para a função BuscaCFOP é associado ao CFOP do evento. Como o valor do primeiro item do XML é 20 esse valor fica vinculado ao CFOP 1.102 (do evento) e passa a ser utilizado em todos os itens da movimentação em que o CFOP foi encontrado. SOLUÇÃO Tratamento para só alterar o SIT_TRIB caso o valor obtido no XML seja vazio ou igual ao ao associado ao CFOP ou caso caso tenha modificador fiscal. Caso contrário, irá manter o encontrado no XML.
MILLEN-44188	Quebra de teste
MILLEN-44191	CAUSA/MOTIVO OMNI mandava o percentual de redução da Base de Cálculo de ICMS. SOLUÇÃO Feita a correção e o valor passou a ser calculado corretamente, conforme percentual cadastrado no Perfil de Imposto.
MILLEN-44192	CAUSA/MOTIVO Ao passarmos o valor de ORIGEM_PROD para uma variável o mesmo estava null, causando o erro em questão. SOLUÇÃO Conforme contato com desenvolvedor, no processo em questão é necessário que o campo Origem do Produto (em Produtos e Serviços > Produtos > Aba Fiscal) esteja preenchido corretamente, conforme a tabela da Sefaz, após a implementação da pendência MILLEN-36286. Para isso foi adicionada uma trava, para não permitir que o processo continue, caso a Origem do Produto não esteja preenchida.
MILLEN-44228	CAUSA/MOTIVO Erro de grafia na descrição dos módulos PullerAPI e PusherAPI nas palavras "Intermediario" e "distribuido". A forma correta é "Intermediário" e "distribuído". SOLUÇÃO Alteradas as grafias para a forma correta.
MILLEN-44236	CAUSA/MOTIVO Ajustes para rescrever a implementação do método millenium_eco.produtos.saldoDeEstoque do wts para dll, ocasionaram uma quebra na estrutura do comando do bando de dados. SOLUÇÃO Ajustado método para realizar o comando corretamente.
MILLEN-44395	CAUSA/MOTIVO O problema ocorre ao gerar os códigos de barras quando o flag "Permite que o sistema procure por código de barras inutilizados?" estiver ativado. Ao executar o método "ExistsBarCode" internamente no "TGeraBarra.Populate", este se encarrega de encontrar o próximo código de barras inutilizado que está disponível, no entanto, ao percorrer para vários itens, o método estava sempre retornando o último código disponível encontrado. SOLUÇÃO Realizado ajuste para adicionar o código inativo que foi utilizado à lista de códigos já alocados. Com isso, o sistema consegue seguir encontrando os próximos códigos disponíveis dentro do método de validação "ExistsBarCode".
MILLEN-44432	CAUSA/MOTIVO Na tela de pré-fase, o parâmetro seloficina não está realizando nenhum filtro. Verificado que esse parâmetro não tem nenhuma influência no script, desde a entrada no git. SOLUÇÃO Retirado o parâmetro da tela.
MILLEN-44541	CAUSA/MOTIVO Lentidão na ListaFaturamentos quando filtrado por pedido de venda. SOLUÇÃO Alterado consulta SQL onde foi otimizado o comando para retornar o mais rápido possível o resultado.
MILLEN-44584	CAUSA/MOTIVO Erro ao listar as parcelas. SOLUÇÃO Adicionar filtros NSU, AUTORIZACAO e NUMERO_TID no rowset de parcelas.

Painel

titleColor	#FFB200
titleBGColor	#2C004B
title	5.103.19

Pendência	Resolução
MILLEN-35529	CAUSA/MOTIVO Na conciliação por arquivo, dava erro ao carregar o arquivo. O erro acontecia porque, na conversão para UTF8, caracteres especiais eram substituídos por ¿. SOLUÇÃO Ajustada para tratar os caracteres especiais antes da conversão. OBSERVAÇÕES Após a correção, o arquivo carregou normalmente.
MILLEN-39215	CAUSA/MOTIVO Erro no cálculo do custo no Kardex, quando cancelada uma NF de compra. Quando estorno de entrada, o sistema estava considerando o valor do custo médio calculado para aquela ORIGEM. SOLUÇÃO Alterado para buscar o valor da mercadoria na produtos_eventos.
MILLEN-40710	Após análise, foi verificado que o erro ocorre somente no millennium 5 e como o cliente utiliza o GO, onde o processo funciona corretamente, a pendência foi devolvida.
MILLEN-40913	CAUSA/MOTIVO O sistema estava considerando a devolução de todo o pedido, mesmo que estivesse especificando os produtos devolvidos. SOLUÇÃO Foi feita a correção, os valores foram calculados corretamente, conforme a devolução informada e o valor do novo pedido.
MILLEN-43512	CAUSA/MOTIVO O sistema estava abatendo a quantidadenc mesmo quando o kit ainda não havia sido entregue totalmente, fazendo com que o saldo entregue na transação a partir do segundo faturamento ficasse maior do que a quantidade emitida. SOLUÇÃO Criada uma validação para obter o saldo dos componentes de cada kit do pedido, para decidir se a linha com quantidadenc, que abate o valor originalmente, criado deverá será apagada, caso seja um faturamento parcial do pedido. OBSERVAÇÃO O problema estava ocorrendo porque o sistema já definia o produto pai do kit como entregue no primeiro faturamento e com isso no segundo faturamento novamente era definida a entrega deste item, afetando o saldo final disponível para faturamento. A correção valerá para os novos pedidos onde o sistema só irá criar a linha abatendo a quantidadenc do produto pai do kit quando todo o kit for faturado. Para correção do pedido passado no cenário poderá ser executado o comando abaixo que irá liberar a linha citada. Quando for realizado o segundo faturamento o sistema deverá criar novamente o registro abatendo a quantidadenc DELETE FROM PRODUTO_PEDIDOV WHERE PRODUTO_PV = 2021568.0 AND PEDIDOV = 483567 AND PRODUTO = 50097 Para os novos casos, o pedido VTX-605470 fornecido no cenário poderá ser copiado. Poderão ser realizados dois pré-faturamentos dividindo os itens do kit ou se preferir poderá ser usado apenas o pedido (copiado) e para isso basta dividir o kit para filiais diferentes, isso pode ser feito via banco de dados ou usando mais de um componente do kit com filial diferente do item pai. Comportamentos esperados: Faturamento parcial do kit: Enquanto o kit não for totalmente entregue o faturamento não deve inserir a linha com quantidadenc negativa. Assim que não existir mais quantidade referente aos itens do kit com entrega pendente o "faturamento final" deve inserir a linha com a quantidadenc negativa. Para faturamentos total o comportamento anterior (inserir a linha com quantidadenc) deve ser mantido. Por favor validar pedidos com e sem kits inseridos.
MILLEN-43640	CAUSA/MOTIVO Conforme análise do cenário disponibilizado, foi constatado que ao validar se o produto já tinha sido digitado ou não, a procedure TExecutaEventoB.SelecionaProduto não considerava se o produto era ou não um subitem, fazendo assim a soma da quantidade. SOLUÇÃO Ajustada a procedure TExecutaEventoB.SelecionaProduto para que, após verificar a existência do código do produto no grid, ela faça uma validação se este registro é um subitem ou item principal. No caso de ser um subitem, ignorar o registro, fazendo a inserção de um novo, como item principal. Caso seja um registro principal, fazer a soma da quantidade.
MILLEN-45754	CAUSA/MOTIVO A constante que armazenava a quantidade de estoque do item estava incorreta. SOLUÇÃO Correção na atualização da quantidade ao clicar nos botões "<" e ">" ao editar item.
MILLEN-45758	CAUSA/MOTIVO Na tela de seleção de títulos para o borderô, a consulta demorava para retornar os dados. SOLUÇÃO Ajustado o código da consulta para obter melhor performance, alterando a junção com a view CALC_VAL_LIQ para LEFT JOIN. OBSERVAÇÕES Após o ajuste, a seleção de títulos retornou rapidamente.
MILLEN-46085	CAUSA/MOTIVO Corrigido na millen-40710. SOLUÇÃO Foi necessário rodar o DBdic na base do cliente para constatar o efeito da correção.
MILLEN-46253	CAUSA/MOTIVO No encontro de contas, não atualizava o Efetuado do título a receber. SOLUÇÃO Ajustada a validação para efetuar o título a receber corretamente e de acordo com a versão Win32. OBSERVAÇÕES Após a correção, ambos os títulos foram efetuados no encontro de contas.
MILLEN-46266	CAUSA/MOTIVO Erro de cálculo de ICMS,PIS e Cofins. Erro no cálculo de abatimento do ICMS da base de PIS e COFINS SOLUÇÃO Alterado para, quando configuração do cliente for Suframa e com desconto de PIS/Cofins, abater o icms da base do PIS e Cofins, calculando o ICMS antes do abatimento.
MILLEN-46323	CAUSA/MOTIVO Quando o pedido for encomenda, o e-Millenium salva a quantidade do item pai no campo QuantidadeNC da produto_pedidov. Com isso, a query de consulta não estava preparada para somar a quantidadeNC no Cálculo. SOLUÇÃO Query ajustada para quando o pedido for encomenda e o produto for kit, utilizar o campo quantidadeNC para calcular os valores. OBSERVAÇÕES Foram feitos testes de pedidos, na nossa base master, com produtos normais, pedidos com produtos com kits: Kits normais, kit fatura componente Pedido com promoção, pedido sem promoção, pedido com desconto no item, pedido com desconto total, Pedido com valor de frete soma emitente, pedido com valor de frete sem soma emitente.
MILLEN-46336	CAUSA/MOTIVO Notas Fiscais não estavam sendo enviadas para o Dome. SOLUÇÃO Foi alterado o SQL do método Listar para que sejam listadas as notas fiscais normais e as notas canceladas na SEFAZ.
MILLEN-46421	CAUSA/MOTIVO O valor obtido do item não estava abatendo o valor do IPI porque não estava sendo identificado o CFOP, com isso o valor usado era o preço "cheio" da tabela de preços selecionada. SOLUÇÃO Realizado ajuste para o sistema validar o parâmetro N_OPERACAO_PREV (CFOP para impostos) das configurações gerais para pedido de venda e consequentemente abater o valor do IPI, quando marcado para usar IPI embutido. OBSERVAÇÕES O problema não estava relacionado com a alteração do pedido. O problema ocorria porque, na inclusão do pedido, o valor obtido não estava usando o preço com IPI. Foi verificado que o valor do produto na tabela de preço já era 2.013,47. Anteriormente, o sistema já aplicava esse valor no preço unitário do item, o que é incorreto quando usado o preço de IPI embutido, pois o comportamento esperado é que o sistema abata o valor no preço do item para depois somar no valor da movimentação.
MILLEN-46423	CAUSA/MOTIVO O erro se dava ao apontarmos em pendingInvoiceAuthorization o objeto Sale, pois no mesmo possamos em cada payment 240 installments, o que fazia estourar o limite do store que é 5mb. SOLUÇÃO Para correção, criamos a função filterInstallments que tem como objetivos filtrar os installments levando em consideração o currentInstallmentValues que seria nesse caso o installment da venda em si, fazendo assim diminuir o número de installments de 240 para 1, que é o da venda. Além realizamos a mesma tratativa ao criarmos o invoice, para assim não carregar a quantidade de installments que estava sendo carregada.
MILLEN-46529	CAUSA/MOTIVO Quando possuímos vendas com tipo de pagamento Credito e outra forma, o Omni estava mandando como condição de pagamento Venda mista, ocasionando o cenário relatado pelo cliente. SOLUÇÃO Para correção, passamos a filtrar os tipos de pagamentos, pegado apenas aqueles que não são crédito, para que, caso seja feita a venda com Credito + Dinheiro, seja mandado a forma de pagamento Dinheiro, tendo em vista que no e-Millennium, apenas abatemos o crédito e não levamos como uma parcela. Dessa forma o millennium leva a condição de pagamento correta.
MILLEN-46618	CAUSA/MOTIVO Lentidão na consulta que grava os dados na tabela temporária. SOLUÇÃO Otimização de trecho de join na tabela produtos_prefat e produto_pedidov OBSERVAÇÃO Foi reportada a necessidade de criar o índice não clusterizado abaixo na base de dados de testes (já foi aplicado no ambiente do cliente): CREATE NONCLUSTERED INDEX USR_20240829001 ON [dbo].[pedido_venda] ([DATA_EMISSAO],[LISTA_CASAMENTO],[EFETUADO]) INCLUDE ([PEDIDOV],[DEVOLUCAO_FORNECEDOR]) Além disso, foi sugerido que o trecho da consulta com lentidão no método MILLENIUM.PEDIDO_VENDA.LISTA_DATA fosse alterado, mudando de INNER JOIN para LEFT JOIN Aplicando a alteração sugerida, o tempo total de execução variou entre 1 minuto e e 3 minutos e 10 segundos. Essa variação pode ser devido à conexão com o servidor pendências 2. O período utilizado foi de uma semana. Validação após alteração.mp4 . Também foi alinhado com o desenvolvedor para aplicar a condição and #null_to_s(ppk.saida,'') = '' no left join da produto_prefat.
MILLEN-46665	CAUSA/MOTIVO Na conferência de transferência pendente está sendo possível alterar a filial . SOLUÇÃO Os campos Filial e Filial Destino serão somente leitura. Caso necessário a alteração deve ser no movimento.
MILLEN-46711	CAUSA/MOTIVO Ao fazer o lançamento da contagem, o sistema retorna as informações do estoque atual, de acordo com os dados informados em tela. No cenário, estava sendo informado especificamente o local de estoque "SEM LOCAL" que, de fato, estava zerado se considerar o -97 e por isso o ajuste não era efetuado. Contudo, na tabela iestoques_locais o campo idlocal com valor nulo também deve ser considerado como "SEM LOCAL" e consecutivamente contabilizar esse saldo de estoque para o devido cálculo do ajuste. SOLUÇÃO Foi efetuado um ajuste no método MILLENIUM.INVENTARIOS.INCLUI_MULTI_PRODUTOS para que, ao selecionar o saldo de estoque agrupando por idlocal, este considere o registro cujo campo tiver nulo também como "sem local".
MILLEN-46841	CAUSA/MOTIVO O Sistema estava validando a Duplicidade de ajuste de uma NF referente a outro período (Junho/2023). SOLUÇÃO Esses casos de duplicidade não são simulados e não é possível saber ao certo como foram gerados, porém foi alterado o método millenium_sped.FECHAMENTOS_IMPOSTOS.Altera, para validar duplicidades de NFS de Saída, Entrada e Transferência, somente dentro do período do Fechamento atual que está sendo manipulado. Após correção, o erro não mais ocorreu.
MILLEN-46904	CAUSA/MOTIVO Sped Fiscal - Cliente Trendx Após analise, foram encontradas inconsistências na base do cliente, que resultaram nas correções efetuadas nas MILLEN-31583 e na MILLEN-38702. SOLUÇÃO Desfeitas as alterações efetuadas na MILLEN-31583 e na MILLEN-38702 e alterado para pegar o gerador da tabela mov_estoque em vez da movimento como o broker decidia.
MILLEN-46990	CAUSA/MOTIVO Ao cancelar um pedido corrente, ou seja, que não foi finalizado, o sistema não chamava o método de cancelar promoção e consequentemente não estornava os pontos de cashback. SOLUÇÃO Adicionada chamada ao método responsável por cancelar uma promoção mesmo que um pedido não tenha sido realizado.
MILLEN-47092	CAUSA/MOTIVO Ao realizar a emissão de uma nota de entrada, selecionando a empresa, a mesma somente possui a configuração de alíquota de ICMS de saída à qual nem sempre é igual ao ICMS aplicado na entrada de um produto importado. SOLUÇÃO Alteramos internamente a seleção dos dados do gerador final para considerar a empresa estrangeira. O usuário deverá cadastrar um novo Tipo de Empresa em "Utilitários/Empresa/Tipos de Empresa". Em seguida, em "Controladoria/Fiscal/Cadastros/Perfil de Impostos", cadastrar um novo perfil de impostos com o campo Estado da Filial que está realizando a importação, preencher o campo "Tipo De Empresa" com o tipo criado, em seguida preencher as devidas tributações. Feitas as configurações, na entrada da nota fiscal, utilizando a filial correspondente à configuração citada, o e-Millenium aplicará a tributação cadastrada no devido perfil de imposto.
MILLEN-47113	CAUSA/MOTIVO Alguns pedidos não atualizaram a informação de entregue no workflow. O processo de atualização do status, do lado do Millennium, depende, nesse processo, dos retornos realizados pelo gateway de frete "Mandaê". Necessário validar o método "MILLENIUM!GF_MANDAE.GATEWAY_FRETES.EMBARQUE.ENTREGA.CONSULTATRANSPORTADORA" e verificar o motivo dele não estar conseguindo retornar os dados de status para atualização no workflow. SOLUÇÃO O método "EMBARQUEENTREGAConsultaTransportadora" na classe "mandae_gateway_fretes", não estava conseguindo tratar corretamente os campos de data que são retornados pelo Json. Foi necessário ajustar as variáveis que recebem essa informação, para realizaram as validações corretamente, e consequentemente, retornar as informações de atualização de status para o e-Millennium. Após realizar as alterações e instalar o módulo "millenium!gf_mandae.minst", o sistema conseguiu atualizar o status no workflow corretamente.
MILLEN-47124	CAUSA/MOTIVO Ao carregar a interface de cadastro de cores (produtos), o sistema está duplicando o tipo de listagem de filtros. O problema ocorre por existirem duas listas com o mesmo caption, porém, uma delas foi criada para chamadas internas, não havendo necessidade de ser exibida como listagem de parâmetros na interface. SOLUÇÃO Método "MILLENIUM.CORES.LISTA2" ajustado para ser definido como o tipo "Lista Interna".
MILLEN-47127	CAUSA/MOTIVO A tela de listagem em: "Vendas > Vendas Perdidas > Aguardando Análise" não tem a opção de filtrar um período de datas (Data Inicial - Data Final). SOLUÇÃO Adicionado campo Data Inicial e Data Final para realizar o filtro de um período entre as datas.
MILLEN-47190	CAUSA/MOTIVO Erro ao efetivar pedido de venda com PAGAR.ME. Erro: 12044 SOLUÇÃO Realizado ajuste para passar o certificado na requisição Post.
MILLEN-47212	CAUSA/MOTIVO Ao carregar os registros das saídas pendentes, ocorre um erro por conta do tamanho do campo de descrição da condição de pagamento. Para essa interface, ele está limitado a 25 caracteres, sendo que suporta até 50 caracteres. SOLUÇÃO Ajustado o campo de resultado "CONDICAO" no método "MILLENIUM.VENDAS.LISTA_SAIDAS_PENDENTES", passando do tamanho de "25" para "50".
MILLEN-47231	CAUSA/MOTIVO Conforme descrito na descrição da pendência, ao emitirmos uma nota com erro, a mesma era faturada, porém, logo em seguida, aparecia a opção de cancelar a mesma. Dessa forma, não era possível emitir a nota corretamente, pois teríamos que cancelar. SOLUÇÃO Para correção, foi criada uma tratativa de erro, para chamar initSale(true) apenas se não tivermos itens em recoveryList ou tenha ocorrido algum erro ao emitir. Caso contrário, passamos false para recoverMode e chamamos a função initSale passando false também, para, dessa forma, ao emitir sem erros, não seja mostrada mais a opção de cancelamento.
MILLEN-47235	CAUSA/MOTIVO Ao importar o xml de uma NFe utilizando o botão "Importar XML" em Produção/Movimentações, o e-Millennium traz os valores "corretos" da nota fiscal e ao digitar manualmente os produtos e mão-de-obra e posteriormente importar os dados restantes do XML da NFe, o e-Millennium estaria supostamente trazendo valores "incorretos" e que ocasionava a mensagem de erro de CST ao prosseguir com a importação da nota. SOLUÇÃO Realizamos a correção do trecho na importação que ocasionava o erro trazendo então o CST com 3 caracteres. 4 - OBSERVAÇÃO A importação do XML da NFe completa, traz os dados exatamente como estão no XML, possuindo a opção de converter a CST de acordo com o tipo da empresa ou não. Já no caso da importação feita na tela de digitação da nota, essa, traz os dados já convertidos pelas regras fiscais vigentes de acordo com o tipo da empresa.
MILLEN-47240	CAUSA/MOTIVO Conforme análise do cenário disponibilizado, foi constatado que ao clicar em "Efetivar" a instância do objeto PInfo era limpa e o erro ocorria ao tentar atualizar a quantidade. SOLUÇÃO Ajustada a procedure TExecutaEventoB.AtualizaGridSaldo de maneira que somente seja atualizada a quantidade caso o objeto PInfo possua uma instância válida.
MILLEN-47265	CAUSA/MOTIVO Na exportação para Excel, dava erro ao exportar dados de lista com campos tipo Registro. Por ser retorno de um rowset, não há suporte a esse tipo de dados. SOLUÇÃO Adicionado ao filtro dos campos a serem exportados, para não selecionar os tipos Registro. OBSERVAÇÕES Após o ajuste, a exportação ocorreu sem erros.
MILLEN-47270	CAUSA/MOTIVO Na conciliação por arquivo, tags de data com erro geravam erro em conversão quando utilizando o EncodeDate. No arquivo do cenário, a tag <DTSTART> possui o valor 20240871777[-3:GMT], sendo que na conversão para Datetime o valor a ser considerado como dia era o 71, levando em conta o padrão AAAAMMDD, no qual apresentava o erro do cenário. SOLUÇÃO Adicionada validação com TryEncodeDate e trava, quando houver erros na conversão de data. OBSERVAÇÕES Após ajustes, ao tentar importar o arquivo contendo a data com erro, apresenta mensagem de erro de validação.
MILLEN-47271	O erro relatado pelo teste, foi solucionado na pendencia MILLEN-47351. Conforme testes realizados, hoje o PDV OMNI, quando se trata de TROCA ou CREDITO, sempre cria uma nova condição padrão sendo ela Crédito ou Troca. Dessa forma, este sempre as utiliza nos processos de trocas e crédito, não sendo possível pegar uma condição de pagamento criada pelo usuário, pois no caso de Crédito sempre serão exibidas como Credito/1P, conforme verificado. Referente a não aparecer o Credito/1P é necessário alterar em Utilitários./ Comercial / Condições de pagamento e alterar o tipo do Credito/1P para TODOS.
MILLEN-47290	CAUSA/MOTIVO Nota está gerando com o CST de substituição, porém com o CFOP de Não Substituição, a regra para escolha do CST inclui Estado, Tipo de Empresa, e para os casos de Transferência onde não existe (Cliente ou Fornecedor) o sistema não envia o Tipo de Empresa na pesquisa do CST. SOLUÇÃO Ajustado para que, nos casos de Transferência, o sistema pegue o campo 'Tipo de Empresa' para a pesquisa do perfil de imposto.
MILLEN-47291	CAUSA/MOTIVO Consulta referente a valor bruto e valor líquido estava divergente da consulta referente a valor bruto e valor líquido por vendedor. SOLUÇÃO Alinhamento referente à consulta do valor bruto e valor líquido geral e por vendedor. Removida subtração pelas movimentações de cancelamento ou devolução. OBSERVAÇÕES Conforme análise, os valores bruto e líquido do resumo de vendas e do resumo de funcionários não devem subtrair o valor de movimentações canceladas ou devolvidas.
MILLEN-47338	CAUSA/MOTIVO Após instalação do módulo millenium!mImpostosRetidos, ao tentar realizar uma saída simples para um fornecedor, sistema retorna seguinte mensagem: Field DESTACAR_ICMSS_RETIDO not found in dataset SOLUÇÃO Corrigido para que, antes de verificar o valor do campo DESTACAR_ICMSST_RETIDO, seja verificado se o campo existe (indexoffield). OBSERVAÇÕES Após a correção, ao realizar a emissão da nota, não é mais exibida a mensagem de erro mencionada, somente é exibida a mensagem de erro referente a ausência do certificado digital.
MILLEN-47422	CAUSA/MOTIVO Após fazer o fechamento de caixas, o sistema está permitindo alterar os títulos e não está informando sobre a conta estar fechada. SOLUÇÃO Ajuste para considerar a conta da tabela lancamentos.
MILLEN-47433	CAUSA/MOTIVO Foi identificada lentidão na consulta de dados para geração do PDF, para o MSSQL. SOLUÇÃO Correção do comando SELECT, separando as consultas para NF Avulsa e NF normal. (O processo foi acelerado para o Firebird, também).
MILLEN-47444	CAUSA/MOTIVO Rotina SetCodProduto, estava validando se o código do produto era válido, utilizando a consulta de produtos, caso não fosse encontrado, saía da função. Quando é utilizada a barra "interna" essa rotina é utilizada 2x: 1x tirando o primeiro campo e a 2 vez com todos os campos; Como a primeira bipagem da barra encontrou o produto e seguiu populando a grid, salvou na prodinfo, assim retornando o código (produto), com isso a rotina decodegrade entra na validação checkCRC e validava o primeiro campo da barra. Como checkCRC retorna zero, o sistema entende como tipo PackBarra, assim retornando a Grade do Produto. SOLUÇÃO Feita tratativa, para caso não seja um produto valido, seja devolvido -1. Assim, a rotina não irá entrar na checkCRC e seguirá na desmontagem da barra.
MILLEN-47532	CAUSA/MOTIVO Na pendência MILLEN-43600 foi realizado um ajuste no resultado do campo TOTAL que causou o erro, pois como a base era SQL Server, foi utilizado ALIAS com aspas e COALESCE, no entanto o wtsBroker já ajusta internamente as particularidades dos diferentes bancos de dados. SOLUÇÃO Realizando ajuste, retirando as aspas simples do ALIAS do TOTAL e utilizado a macro #NULL_TO_S no lugar do coalesce. Após ajuste, o relatório foi gerado.
MILLEN-47580	CAUSA/MOTIVO Campos referentes a valores monetários estavam do tipo inteiro sem decimais. SOLUÇÃO Adicionadas casas decimais aos campos referente a valores monetários.
MILLEN-47613	CAUSA/MOTIVO Função 'deepCopy' tentava observar o atributo de um valor 'undefined'. SOLUÇÃO Correção para quando o valor do parâmetro da função 'deepCopy' for 'undefined', retornar o mesmo.

Árvore de páginas

Versões comparadas

Versão antiga 3

Nova versão 4

Chave