| 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. |