5.105

5.105

Pendência	Resolução
MILLEN-16097	Conforme verificado pelo desenvolvedor, em nossa versão mais recente, com a nova capa da página inicial do sistema, o problema mencionado no cenário da pendência não existe mais.
MILLEN-22893	CAUSA/MOTIVO O erro ocorria por tenta atribuir valor de pedidov inexistente no parâmetro do LIN da chamada da tela. SOLUÇÃO Ajustado para atribuir o maxint a variável quando o parâmetro pedidov for vazio, trocando o StrToInt para StrToIntDef. OBSERVAÇÕES Após a correção , a tela abriu sem erros. Foram adicionadas duas exceções para validar se há boleto/lançamento a ser reimpresso ou enviado por e-mail nos botões de ação da tela.
MILLEN-25921	SITUAÇÃO NÃO OCORRE MAIS O bug era geral em todas as abas Anexo do sistema e foi corrigido na MILLEN-40651. A situação não ocorre mais, conforme evidência em anexo no jira.
MILLEN-26602	CAUSA/MOTIVO A configuração "Tamanho máximo descrição da classificação fiscal" possui limite, mas estava com livre digitação numérico, causando os erros evidenciados no cenário. SOLUÇÃO Alterado o tipo do campo para lista com os valores permitidos. OBSERVAÇÕES Após a alteração, a configuração ficou limitada as opções permitidas.
MILLEN-29934	ERRO NÃO OCORRE MAIS A flag "Emissão obrigatória de NF" será visível quando a flag "NF" ou a flag "Nf de devolução" estiverem habilitadas. O comportamento atual do sistema é manter o valor da flag Emissão obrigatória de NF mesmo quando as duas forem desabilitadas. 1- As duas flags podem estar habilitadas ao mesmo tempo; 2- Desabilitando a flag Nf, a Emissão obrigatória se torna invisível; 3- Salvando, reabrindo o evento e habilitando novamente a flag Nf, a flag Emissão obrigatória se mantém habilitada.
MILLEN-30233	SITUAÇÃO NÃO OCORRE MAIS A situação de dimensionamento não ocorre mais nas versões mais recentes.
MILLEN-30648	CAUSA/MOTIVO Conforme testes efetuados com base no cenário disponibilizado foi constatado que o sistema estava direcionando a impressão corretamente conforme impressora selecionada, porém, estava mantendo as configurações de página referentes a impressora padrão. SOLUÇÃO Foi efetuado um ajuste na procedure TgtPDFPrinter.PopulateCapability da unit gtPDFPrinter com a finalidade de reposicionar o ponteiro da impressora de maneira que as configurações de página acompanhem o processo.
MILLEN-31656	SITUAÇÃO NÃO OCORRE MAIS Ao clicar no botão de Adicionar Produtos na tela Produtos da Vitrine, somente com a Vitrine escolhida como parâmetro, aparece a mensagem para preencher também a Categoria da Vitrine. Preenchendo o parâmetro de Categoria da Vitrine, a tela de Adicionar Produtos abre sem erros.
MILLEN-34226	CAUSA O processo de inclusão de lotes separação pode inserir múltiplos lotes de uma só vez, mas nunca com o mesmo Código, pois utiliza o método "millenium.utils.default" para geração do código, o que garante que sempre incremente 1 nos códigos. Por exemplo, se existirem 5 pré-faturamentos, e no filtro para inclusão dos Lotes de Separação informar a Qtde Pedidos igual a 2, o processo vai incluir 3 Lotes Separação, onde 2 Lotes Separação irá ficar com 2 pré-faturamentos e o outro Lote Separação vai ficar com 1 pré-faturamento. O campo Qtde Pedidos funciona como um limite de pré-faturamentos dentro de um Lote Separação. Porém, os Lotes de Separação não ficam com os mesmos pré-faturamentos, e conforme observado na base de dados do cliente, os pré-faturamentos dos Lotes Separação com o mesmo código são iguais. Como não foi possível reproduzir o erro, resolvemos adicionar um trava no processo para não permir incluir Lotes de Separação duplicados. Outro ponto é que talvez a duplicidade ocorra pois quando excede o tempo de processamento do client ou perde a conexão, a transação é cancelada e o usuário pode efetivar novamente mesmo que o server ainda esteja em processamento, sendo assim, para evitar esse problema, adicionamos um mutex para não permitir realizar a inclusão 2 vezes. SOLUÇÃO 1- Adicionado no método 'MILLENIUM.LOTES_SEPARACAO.INCLUI' antes de realizar o insert na tabela 'LOTES_SEPARACAO', uma validação para verificar se o código gerado para o campo 'COD_LOTE_SEPARACAO' já existe, caso exista, será exibido uma mensagem de "Código Duplicado". 2- Adicionada também uma trava, utilizando mutex, para após 1 minuto de processamento, que é quando o client cancela a transação ou em caso de perda de conexão, não permitir efetivar novamente enquanto o server não finalizar o processamento, evitando assim, a falha de duplicidade. Para testar as travas foi necessário realizar alterações diretamente no fonte, já que não foi possível simular o erro, por esse motivo não será possível realizar a validação com a versão instalada em nosso ambiente.
MILLEN-34899	CAUSA/MOTIVO O código de barras não estava sendo carregado quando o parâmetro estava marcado, devido a uma falha de validação no método "TGeraBarra.AtualizaBarraLivre" da classe "GeraCodBarras". Há uma validação, onde o código inutilizado deve ser menor que o último código gerado pelo sistema. No entanto, essa validação afetava apenas o código que estava sendo exibido na interface de geração, e não atualizava o código que seria gerado para o produto (exibido na interface de códigos de barras). SOLUÇÃO Para corrigir, foi necessário realizar a validação para que atualize os campos de forma consistente, sem deixar divergências. IMPORTANTE Só serão gerados códigos inutilizados desde que sejam menores que os códigos definidos como último código de barras disponível (de acordo com as regras de geração). Necessário validar com o cliente mais cenário. OBSERVAÇÃO É importante mencionar que a interface de geração do código de barras, sofreu alterações. Alguns filtros foram realocados para a interface acessada pelo botão "Gerar Códigos para os Produtos sem Código".
MILLEN-38421	CAUSA/MOTIVO Método "MILLENIUM!WMS_COLETOR.ROTA.LISTAR" com lentidão. Conforme informado no comentário do desenvolvedor, o cliente tem grande quantidade de registros, 1,5 milhões na época do comentário, mas atualmente possui por volta de 2 milhões, e isso torna a listagem no coletor lenta. O motivo informado no comentário é porque tem um union all com o alias ORIG, que busca todos as movimentações da base, e para melhor performance, seria melhor vários left joins com o tipo_origem e origem, pra que não seja carregado 2 milhões de registros pra cada tabela (e posteriormente descartado). SOLUÇÃO Realizado ajuste sugerido no comentário do desenvolvedor. Retirado o union all do left que consulta todas as tabelas de SAIDAS, ENTRADAS, TRANSFERENCIAS, PREFATURAMENTOS, PREFATURAMENTOS_T, TRANSFERENCIAS_LOCAIS e PRODUCAO, e realizado um JOIN para cada ORIGEM e TIPO_ORIGEM, sem UNION ALL. Como o cenário da pendência não informou o processo realizado no cliente, como o Link do coletor que faz a listagem do método "MILLENIUM!WMS_COLETOR.ROTA.LISTAR", ou os parâmetros utilizados, resolvemos filtrar o método pela data do início de 2024 até a data atual, o que retorna muitos registros, mas foi suficiente para ter como parâmetro. Foi realizado teste para verificar o tempo da execução do método "MILLENIUM!WMS_COLETOR.ROTA.LISTAR", relatando uma melhoria de aproximadamente 5 minutos.
MILLEN-38752	CAUSA/MOTIVO Após análise, foi identificado que o problema estava relacionado aos valores rateados do frete nos prefaturamentos do pedido. O problema ocorria após a importação do pedido na Vtex. Ao calcular o frete, apresentou uma diferença de R$0,01 ao somarmos os valores dos prefaturamentos e comparar com o valor total do frete no pedido. Essa diferença ocorre porque está sendo utilizada filial no nível do produto, fazendo com que a rotina realize "diversas" reservas. Ao realizar uma movimentação de venda, e selecionar o prefaturamento, ocorre o erro, pois o sistema tenta criar uma parcela para o R$0,01 restante. SOLUÇÃO Foi identificado que o problema estava no core do millennium, mais especificamente no método "Reserva_estoque" da classe "millenium_pedido_venda". A query que retorna os dados para processamento dos prefaturamentos, apresentou inconsistência ao ratear valor do frete. Foi necessário implementar uma rotina que encontra a diferença de valor total com a soma das parcelas, e faz a correção no valor da última parcela do frete. Além disso, foi tratado o retorno das filiais, nessa mesma query, onde havia uma validação de encomenda para verificar se a filial utilizada seria do pedido ou do produto do pedido. Porém, nesse caso, a validação ficava apenas na flag "encomenda" desconsiderando se o produto tinha uma filial definida. IMPORTANTE Será preciso homologar diversas situações envolvendo pedidos e prefaturamentos, pois como a alteração foi no core, há necessidade de cautela. O commit será realizado apenas na versão "5_Branches", posteriormente será levado para as versões correntes. Para os testes feitos com o pedido da Vtex, será necessário realizar nova importação.
MILLEN-38998	CAUSA/MOTIVO LOGISTICA - CTE - 5.104 Sistema utilizava o campo status que deveria conter apenas o status do recebimento, para atualizar o status da NFE/CTE junto a Sefaz. SOLUÇÃO Criado o campo STATUS_SEFAZ para conter o status da NFE/CTE junto a Sefaz.
MILLEN-39211	CAUSA/MOTIVO Ao gerarmos o Recibo de encomenda, ele não levava em consideração o desconto, não exibindo o mesmo no recibo. SOLUÇÃO Para correção, passamos a somar todos os descontos possíveis (No item e no Pedido) e adicionamos um novo campo no recibo chamado Desconto, que exibe o desconto dado no pedido. Caso não tenha desconto, o campo não será exibido.
MILLEN-39486	CAUSA/MOTIVO A query ESTOQUE.EstoqueLotes estava demorando em média 1m e 12 segundos para ser executada, sendo este o maior motivo da lentidão em questão. SOLUÇÃO Para correção, foi retirado o subselect de lotes adicionando o mesmo no leftjoin, além disso foi retirado o HAVING presente, pois o ele era a maior causa da lentidão, no lugar do mesmo, adicionamos a consulta em um subselect, visando assim adicionar a cláusula WHERE ao invés de HAVING, com isso tivemos a seguinte melhora de performance: - Antes da alteração tivemos 122.700ms, após a alteração tivemos 40.000 a 34.000ms. OBSERVAÇÕES Caso seja clicado na tela enquanto as querys estiverem sendo executadas, o sistema realmente apresentará um 'travamento', tendo em vista que as querys estão sendo executada, sendo necessária a finalização das mesmas para a utilização normal do sistema. Solicitamos que sejam executados os testes necessários que fazem utilização do método Estoque.EstoqueLotes, para validar os ajustes realizados.
MILLEN-39608	CAUSA/MOTIVO Conforme verificado, foi realizada uma implementação com intuito de não limitar os resultados do LookUp. Porém, com a implementação, o sistema estava seguindo um fluxo incorreto quando o lookup possuía parâmetro, limpando os mesmos incorretamente. SOLUÇÃO Para correção, passamos a verificar se autoBindParams e canAutoBindParams são true, apenas nesse cenário realizamos a limpeza dos filtros, caso contrário apenas recarregamos o lookup. Além disso, deixamos TRUE fixo para canAutoBindParams, pois conforme validado com o desenvolvedor, este sempre deve ser true por se tratar de um LookUp.
MILLEN-39890	CAUSA/MOTIVO O problema ocorria devido às validações de origem do prefaturamento não considerarem o pedido de venda. Além disso, o campo "PROMOCAO" não estava sendo retornado pelo método de carregamento de itens do prefaturamento. Com base nesses pontos, a informação não era exibida na interface. SOLUÇÃO Necessário verificar se o prefaturamento tem como origem um pedido de venda e, realizar as devidas validações, com base nos parâmetros que foram criados para essa condição. Além disso, foi adicionado o campo "PROMOCAO" no método "MILLENIUM.PREFATURAMENTOS.Consulta_Itens".
MILLEN-40110	CAUSA/MOTIVO Conforme verificado, hoje o sistema sempre espera o código de modalide_frete, porém o OMNI envia o código apenas quando realizamos uma encomenda, pois apenas nesse cenário estaríamos enviando o produto para o cliente. Diferentemente do processo realizado pelo usuário no qual o cliente estaria no estabelecimento realizando a troca. SOLUÇÃO Para correção, passamos a verificar se a MODALIDADE_FRETE é null na tabela SAIDA e, caso seja, passamos como padrão 9 (Sem frete). Para assim mesmo que o código chegue null, seja enviado 9 como padrão.
MILLEN-40226	CAUSA/MOTIVO Erro ao fazer devolução (Cheque ou Cartão). SOLUÇÃO Removendo duplicidade do parâmetro data_compensacao no updade na lancamentos_baixa.
MILLEN-40304	CAUSA/MOTIVO Cliente - Nota Cancelada no ERP MILLENNIUM, mas autorizada na SEFAZ. A provável causa identificada é que ao emitir uma NFe, o processamento na SEFAZ estava com lentidão, com isso o usuário mandou cancelar a NF sem que o lote da mesma tivesse sido processado. SOLUÇÃO Incluída uma consulta do recibo do lote antes de efetuar o cancelamento, para saber se o lote já foi processado. Criado um módulo "millenium_nfe_FixCancel" para pegar as NFs que estão canceladas no e-Millennium, porém com status=100, e tentar efetuar o cancelamento na SEFAZ.
MILLEN-40496	CAUSA/MOTIVO Rotina de pesquisa lookup, tenta encontrar pelo código, caso não tenha resultado tenta encontrar pela descrição. Como o cliente digita primeiro um "código" que não existe, ex: 0585, a rotina vai buscar pela descrição, mas é uma consulta custosa para o banco de dados. Quando o cliente digita o código completo (que existe no banco) ex: 05857, a rotina retorna rapidamente, mas como a consulta anterior ainda estava executando, ela sobrepõe a consulta do código. SOLUÇÃO Feita uma tratativa para validar, se a consulta que está retornando é a última, assim evitará que ocorra essa sobreposição nos resultados.
MILLEN-40651	CAUSA/MOTIVO Como foi colocado um subscribe no value do recordsetfield, o evento não estava sendo disparado no primeiro post. SOLUÇÃO Alteramos o susbscribe para oncurrentchange, dessa forma detectamos quando o post ocorre e renderizamos os cards.
MILLEN-40692	CAUSA/MOTIVO FISCAL - IPI duplicado na formação do custo médio - 5.104.4.2 Sistema estava desconsiderando o total_ipi_nc, pois este já estava sendo somado ao TOTAL_IPI da nota, porém em casos de importação do xml o mesmo não ocorria. SOLUÇÃO Verificar se o total_ipi_nc já está sendo somado ao TOTAL_IPI da nota, caso já esteja o total_ipi_nc deve ser zerado.
MILLEN-40697	CAUSA/MOTIVO A situação descrita na pendência, de fato, NÃO ocorre. Sendo assim, ao realizar validações de estoque e empenho, como não era identificada a baixa do empenho, as mensagens eram exibidas ao usuário, de acordo com o parâmetro selecionado. No entanto, ao analisar o caso, foi encontrado um problema ao comparar os valores do empenho com o estoque. Foi necessário ajustar o arredondamento dos valores. SOLUÇÃO Ajustado o arredondamento das quantidades de empenho e estoque, durante a validação no método "TfrmAndamento.existsEmpenho". Sem esse ajuste, algumas comparações poderiam passar sem a validação correta, fazendo com que as mensagens de bloqueio fossem exibidas, sem necessidade.
MILLEN-40713	CAUSA/MOTIVO O sistema estava travando porque detectava uma perda com quantidade zero em um lote separado. Ele ativava a trava porque entendia que as quantidades já tinham sido processadas, mas na verdade, havia uma pendência relacionada à perda. Foi identificado também um registro faltando na tabela situacao_producao que estava quebrando a quantidade informada separadamente referente a perda SOLUÇÃO Foi efetuado o ajuste na trava da procedure RET_OFICINA, de maneira que seja considerado o lote que está sendo processado no momento da verificação, gerando comando para inserir o registro faltante na SITUACAO_PRODUCAO.
MILLEN-40726	A inclusão está sendo feita em tela HTML, por isso sem erros. Na alteração, está sendo chamada a tela Win32. Será necessário atualizar o arquivo MILLENIUM_FINANCEIRO.LIN, Financeiro\Pagar\Títulos, do cliente para que a tela HTML Alterar Título a Pagar seja habilitada. Abaixo segue como a rota deve ser feita. <link target="standard.tdataedit" _id="147" caption="Alterar Título a Pagar" order="-1" _tag="4" DEFAULTEDIT="1"> <METHOD LANCAMENTO="{$data.LANCAMENTO}">MILLENIUM.TITULOS_PAGAR.ALTERA</METHOD> <PARAM DATA="P">TIPO</PARAM> <Option>CloseOnSubmit</Option> </link> Após a alteração para a tela HTML, o código de barras salvou corretamente. Complementando o comentário do programador após a analise, o motivo do sistema não estar salvando o código de barras com os 48 caractere e por conta que esta na tela WIN32 Para o sistema ir para a tela HTML, será necessário atualizar o arquivo do seguinte diretório: C:\wts\appmap\MILLENIUM_FINANCEIRO.LIN Abrir o gerenciador depois das alterações.
MILLEN-40728	CAUSA/MOTIVO Como não tem PEDIDOV ou NOTA sendo informado, o select principal fica sem filtro e trás a base toda de pedidos. SOLUÇÃO Criada validação para executar o select principal, somente se for passado NOTA ou PEDIDOV.
MILLEN-40747	CAUSA/MOTIVO Sistema estava mostrando a mensagem de "Impresso com sucesso", mesmo não tendo um layout configurado para a impressão. SOLUÇÃO Foram efetuados ajustes na tela para que o sistema emita uma mensagem, indicando a ausência de um layout de impressão válido, quando de fato não houver um layout configurado para a impressão. OBSERVAÇÕES O botão de romaneio especificado no cenário faz a impressão conforme layout configurado e arquivo existente na pasta c:\wts\files\documentos Foi anexado um arquivo de exemplo Romaneio de Corte.lay conforme disponibilizado na documentação do sistema em: https://info.millennium.com.br/cms/central-de-downloads/millennium-business-30951/templates-56471/leditor-18018/producao-1608/196-impressao-de-documento-romaneio-de-corte É importante ressaltar que arquivo de layout é impresso em impressora matricial, portanto não é possível a sua conversão para pdf via sistema.
MILLEN-40790	CAUSA/MOTIVO Como a medida 07.02 retorna uma lista muito grande de produtos, ficava extremamente lento renderizar o checkbox para cada linha de produto. SOLUÇÃO Trocamos a renderização de cada checkbox pelo PALGRID, que melhorou a performance no carregamento da tela, como pode ser visto na imagem: inserir imagem aqui
MILLEN-40845	CAUSA/MOTIVO O campo número da nota tem limite de 10 caracteres devido ao seu tipo de campo e não permite que usuário tenha armazenado uma numeração maior do que 10 dígitos. SOLUÇÃO Aproveitado o campo NUMERO_NOTA para nos casos de NFS-e digitada uma numeração mais extensa seja armazenada. Foi criada uma parametrização que permitirá ao operador do sistema dar entrada das notas com números com mais de dígitos, acesse no link https://share.linx.com.br/pages/viewpage.action?pageId=498187793&src=contextnavpagetreemode
MILLEN-40912	CAUSA/MOTIVO Ao pesquisar endereços sem número ou bairro preenchidos, o sistema retornava erro. SOLUÇÃO Feita tratativa para possibilitar a consulta de endereço sem número ou bairro preenchidos. OBSERVAÇÕES Foi feita a alteração diretamente no arquivo linx.wts do cliente.
MILLEN-40928	CAUSA/MOTIVO Falta de ações definidas para o banco Grafeno (274). SOLUÇÃO Implementado o mapeamento das ações do banco Grafeno (274) de acordo com o manual em anexo no arquivo CnabCtrl.XML.
MILLEN-40949	Erro não ocorre mais. Foi corrigido na MILLEN-43053.
MILLEN-41021	CAUSA/MOTIVO A timeline permitia a inclusão de vários itens para inserção, conforme verificado. Com isso, o usuário incluía o primeiro item e quando salvava o segundo, se perdia e salvava o item que foi inserido primeiro. Além disso, o bug fazia com que o botão Salvar fechasse o item de edição, dando a impressão que o Salvar não estava executando nenhuma ação, logo se o usuário clicasse várias vezes, salvaria o mesmo item fazendo simular o erro descrito na pendência. Não é possível afirmar que era isso que ocorria no cliente, mas foi a única forma que permitiu simular o problema. SOLUÇÃO Para evitar o problema, fizemos um controle de edição, que não permite a criação de vários itens de inclusão simultâneos. Se o usuário tentar, o sistema avisará que não é possível incluir um novo item, até que seja salvo ou cancelado o item que está em edição.
MILLEN-41022	CAUSA/MOTIVO O sistema não atualiza o valor do FCPST quando na PRODFIS quando realizada importação de XML. SOLUÇÃO Criada estrutura para atualizar o valor do FCPST na ProdFis quando for utilizada a importação de XML.
MILLEN-41035	CAUSA/MOTIVO Com a nova barra lateral implementada recentemente, no PDV OMNI estavam sendo cortadas algumas informações do carrinho de compras. SOLUÇÃO Para correção, ao calcular o tamanho da tela passamos a levar em consideração o content-frame, que seria o tamanho da tela, sem levar em consideração a nova barra lateral, para assim ser calculado o novo tamanho da forma correta. Além disso, na versão mobile devido ao tamanho, foi necessário retirar a barra lateral, para não prejudicar a visualização.
MILLEN-41056	CAUSA/MOTIVO Pedidos não comunicam com a Intelipost, devido a falta de uma tag no JSON. SOLUÇÃO Envio de novo campo no JSON, quando enviamos o status de "Despachado".
MILLEN-41119	CAUSA/MOTIVO Query não estava respeitando o index existente na base de: PRODUTO ASC , COR ASC , ESTAMPA ASC , TAMANHO ASC , FILIAL ASC , DATA ASC SOLUÇÃO Para correção, ajustamos a query existente a fim de respeitar o index que temos criado na base de dados. OBSERVAÇÕES Caso seja da necessidade do cliente, pode ser customizado um relatório (Gerador de relatório) com as informações que consigam atendê-lo.
MILLEN-41133	CAUSA/MOTIVO O sistema não estava lendo o logotipo configurado no cadastro da Filial, somente o das Configurações Gerais, onde estava configurado o logo_incorreto. Ao deixar somente o logo desejado na pasta c:\wts\files\documentos\imagens, o sistema gerava o logo em branco porque a imagem não estava selecionada em Configurações Gerais. SOLUÇÃO Foi ajustado o sistema, que após o ajuste passa a buscar o logo na seguinte ordem: 1) Cadastro da Filial > guia Tributação > Logotipo para Danfe; 2) Configurações Gerais > Nota Fiscal Eletrônica (Documento Fiscal) > Danfe > Logotipo para Danfe; 3) Caso não tenha logo configurado nas situações acima, buscará o logo padrão da Linx.
MILLEN-41146	CAUSA/MOTIVO Ao carregar os dados dos produtos, da transferência de local de estoque, pelo método "ExecutaRegra", da classe "millenium_transferencias_locais", a query estava limitando os registros dos produtos na comparação da conferência total, por conta do filtro de divisão do usuário. SOLUÇÃO Foi necessário ajustar a query, adicionando a macro "#nofilter()". Essa macro se encarregará de desconsiderar o filtro de divisão por usuário, fazendo com que todos os registros necessários sejam retornados.
MILLEN-41170	Erro não ocorre mais. Foi verificado que já está corrigido na versão 5 master, sem uma pendência vinculada. Correção: chave do commit: cadffad761609893f4513d1bbe15a651e7a0eead Não foi possível reproduzir o cenário porque a base indicada não se encontra no diretório. Foi realizada a chamada do método, utilizando a base do teste e o erro não ocorreu. Erro no método MILLENIUM.FILIAIS.PROCURA Ao realizar o teste, verificamos que não ocorre mais erro ao importar, ele foi direto com sucesso.
MILLEN-41205	Erro não ocorre mais. Realizaram a correção referente ao problema mencionado, na versão 5_Branches e 105.beta, conforme localizado nos commits. Foram realizados teste com sucesso, conforme evidências anexadas no Jira.
MILLEN-41218	CAUSA/MOTIVO Atualmente ao pesquisarmos pelo código de barra, o sistema não está especificando qual preço usar. Diferente de quando buscávamos pelo código do produto, que passava essa especificação. SOLUÇÃO Para correção, ao buscarmos pelo código de barra, passamos o priceList, que indica qual é o preço que devemos utilizar. Dessa forma, ao realizar a busca pelo código de barra, é verificado qual o proceList e passado o valor. Foi ajustado também, quando buscamos o produto diretamente na base de dados, isso ocorre quando não temos o produto em cashe, o ajuste foi: passamos a verificar se o produto possui vários preços e se temos o proceList especificado, nesse caso, passamos o processo especificado em priceList. Caso contrário, pegamos o menor preço entre priceRegular e pricePromo.
MILLEN-41251	Corrigido na millen-41035
MILLEN-41312	CAUSA/MOTIVO Correção para em mensagens de exceção, que estão com erro de grafia na palavra "possivel", faltando o acento. Correto: possível. SOLUÇÃO Ajustada a grafia para "possível".
MILLEN-41326	CAUSA/MOTIVO Quando o operador coloca enter na senha, o sistema toma erro 401 dos correios; Também, rotina para buscar os dados de acesso, está sempre tentando validar se existem dados no header, mesmo tendo dados apenas na filial, devemos validar a filial independente. SOLUÇÃO Adicionada a função removeEnter, ao coletar o usuário e senha no banco. Foi tratado o log, para caso tenhamos erros não esperados, retornar pelo menos o código do erro no log. Foram ajustadas algumas chamadas, como: consultaCep e obterToken, ontém estava sempre esperando que tivesse informação no header, como podemos apenas informar dados de acesso na filial, devemos tratar as tabelas independentes.
MILLEN-41442	CAUSA/MOTIVO Em Consulta de Pedidos, na tela de Consulta de Volumes, não estão aparecendo os pedidos ao digitar. Verificado que o filtro do campo cod. de pedido no método, só retornaria caso o valor estivesse igual. Além disso, o componente já adicionava as %%, o que dificultava ainda mais ao retorno dos valores. SOLUÇÃO Trocado no método, o filtro do parâmetro de igual (=) pelo LIKE.
MILLEN-41454	CAUSA/MOTIVO Problema no envio dos itens da nota juntamente com o faturamento para a VTEX. SOLUÇÃO Após conversa com a VTEX foi ajustada a forma de envio, para não enviar os itens pai quando se tratar de kit.
MILLEN-41528	CAUSA/MOTIVO O campo "productid" está vindo assim "3556613" o que fez criar um novo produto, o correto para essa base é ter a máscara "PRD-" na frete ficaria assim "productid":"PRD-355613" para atualizar os produtos já existentes. SOLUÇÃO Utilizar o campo ID_EXTERNO da tabela vitrine_produtos no envio do produto, caso tenha o id_externo cadatrado na base de dados para envio e log de sku de produtos já existente.
MILLEN-41563	CAUSA/MOTIVO O sistema não buscava CFOP interestadual no método CFOP.ProcuraCfopEvento SOLUÇÃO Criada estrutura para identificar movimentação interestadual na importação de XML e busca de CFOP interestadual no método CFOP.ProcuraCfopEvento, caso parâmetro atendido.
MILLEN-41589	CAUSA/MOTIVO Erro ao importar subgrupo do Linx ERP. SOLUÇÃO Foi verificado que houve aumento do tamanho do campo do lado do Linx ERP, aumentada a quantidade de caracteres da tabela lx_produtos_subgrupo.
MILLEN-41615	Pendência já corrigida na MILLEN-40692 e testada na versão 5.104.7 Problemas no custo Para realizar um teste, usamos o XML do recebimento de compra através da SEFAZ, excluímos nota e o movimento que havia na base e refizemos a importação: Ao reimportar o XML, observamos que o relatório saiu de forma correta.
MILLEN-41687	CAUSA/MOTIVO Ao informar perdas e/ou defeitos durante o retorno da oficina, o sistema não está manipulando os campos, ocasionando erros nas quantidades calculadas. SOLUÇÃO Foi necessário ajustar a rotina em "TProd.RetornoOficina" (LibProducao) para enviar corretamente os valores de perdas e defeitos, para serem manipulados pelo servidor na classe "millenium_producao", método "Ret_Oficina". Os valores de perdas e defeitos passarão a ser utilizados para a correta atualização nas tabelas "SITUACAO_PRODUCAO" e "MOVIMENTO_PRODUCAO". Além disso, foi ajustado o log par gravar essas informações, assim como algumas melhorias em mensagens retornadas ao usuário.
MILLEN-41705	CAUSA/MOTIVO Erro ao importar produtos do Linx ERP. SOLUÇÃO Criado campo para configurar o IGNORA HASH, habilitado na tela de configuração da integração.
MILLEN-41756	CAUSA/MOTIVO Erro ao carregar campos onde era forçado um toString() sendo que o mesmo não tem valor. SOLUÇÃO Adicionada uma validação antes do toString(), para verificar se o campo não está "undefined", antes de fazer o toString().
MILLEN-41759	Corrigido na millen-41539
MILLEN-41772	CAUSA/MOTIVO Pedidos cancelados na Plataforma Jet não estão atualizando status cancelado no Millennium, deixando os pedidos em aberto. SOLUÇÃO No processamento de Status de Pedidos, a integração quando era realizada a listagem dos pedidos não estava sendo considerado os pedidos cancelados diretamente na Plataforma.
MILLEN-41886	CAUSA/MOTIVO Quando existe uma máscara no campo, o algoritmo contava o número de casas decimais de forma incorreta. SOLUÇÃO Ajustado o algoritmo para contar as casas decimais de forma correta, contando a quantidade de "0" ou "#" depois do ponto decimal .
MILLEN-41901	CAUSA/MOTIVO As query consulta_limite_credit e GetCustomerSalesStats não estavam sendo executadas corretamente, e, por isso, o histórico de clientes não estava sendo carregado corretamente. SOLUÇÃO Para correção, foram ajustadas as querys citadas acima, para seguir as regras do broker e assim serem executadas corretamente.
MILLEN-41907	CAUSA/MOTIVO Enviar id_externo da categoria. SOLUÇÃO Caso tenha ID_EXTERNO na categoria, será enviado no lugar da VITRINE_CLASSIFICACAO.
MILLEN-41952	CAUSA/MOTIVO Estavam faltando campos no GROUP BY da consulta do método "MILLENIUM.ESTOQUE.Detalhado_Data". SOLUÇÃO Adicionados os campos FORNECEDOR e ESTAMPA no GROUP BY do método. Após ajuste, o relatório foi processado com os filtros informados no cenário e o erro não ocorreu. Com os filtros informados no cenário o relatório não retornou dados, realizamos um teste filtrando apenas a data, de 2023 até a data atual.
MILLEN-42017	CAUSA/MOTIVO Foi relatado que a ordenação por id do SKU não está igual como era quando trabalhado em SOAP. SOLUÇÃO Adicionado parâmetro na vitrine chamado "Ordenação dos SKU's" para que o cliente informe como ele prefere a ordenação.
MILLEN-42020	CAUSA/MOTIVO O método ListaFaturamentos está retornando informações erradas quando a nota informada no filtro estiver em mais de uma filial. SOLUÇÃO Ajustado o SQL do método para retornar corretamente.
MILLEN-42071	Corrigido na millen-43020
MILLEN-42153	CAUSA/MOTIVO Sistema não emite GNRE via API - api/millenium_log.PICKING.faturar SOLUÇÃO Alterado para apenas enviar e emitir a guia da GNRE porém não imprimindo, com isso os campos barra_leitora e barra_digitada do lançamento são preenchidos, podendo ser incluído no borderô.
MILLEN-42157	CAUSA/MOTIVO Sistema não emite GNRE FCP - AL. Sistema estava gerando a Tag Valor tipo=12 e com valor zerado. SOLUÇÃO Quando o ValorPrincipalFCP estiver zerado, não gerar a TAG e alterado o tipo para 11 quando FCP-AL.
MILLEN-42178	CAUSA/MOTIVO O sistema está perdendo os valores inseridos e atualizados no nível de estoque para produtos/SKU. Foi verificado que o método "AtualizaPorProduto" da classe "millenium_niveis_estoque" se perdia em situações onde o produto ainda não tinha um nível de estoque cadastrado. A rotina não conseguia identificar que era necessário atualizar com os valores informados pelo usuário, por isso os valores sempre ficavam em branco. Além disso, também havia um bug ao atualizar os valores já cadastrados no nível de estoque. A rotina sempre deixava de atualizar o primeiro da fila, deixando-o com valor nulo. SOLUÇÃO Para corrigir, foi necessário ajustar alguns aspectos do método "AtualizaPorProduto" da classe "millenium_niveis_estoque". Dessa forma, a rotina compreenderá que mesmo que para o produto/SKU que ainda não tenha nível de estoque cadastrado, será necessário atualizá-lo com os valores fornecidos pelo usuário. Ajustado também o ponto em que a rotina se perdia ao atualizar os dados de produto/SKU que já tinham nível de estoque, onde sempre o primeiro da fila, ficava com valor vazio. As alterações foram nos mesmos aspectos informados acima.
MILLEN-42196	CAUSA/MOTIVO Rotina estava com altos volumes, assim ocasionando estouro de memória. SOLUÇÃO Feitas diversas tratativas na rotina de importação. Alterado o leitor de xml para um mais leve. Montada paginação para importação, agora poderá ser informado via parâmetro um limite de processamento, quando o limite for atingido a rotina irá parar o processamento, para continuar na próxima janela. Adicionada a importação de produto, para processar: preço, código de barra e estoque. Alterado para sempre salvar o timestamp, não mais no final do processamento, pois caso ocorra algum erro, o timestamp terá sido ja alterado, assim na próxima janela de processamento teremos outros produtos na fila. Como foi feito a paginação, a rotina de limpar "processamento de rotina com erro" foi retirada do escopo principal e passada para dentro dos processamentos individuais, ou seja, apenas limparemos a fila caso o produto tenha processado.
MILLEN-42222	CAUSA/MOTIVO O sistema não localizava o endereço do cliente quando o logradouro não havia sido preenchido e, consequentemente, adicionava um novo endereço vinculado ao cliente sem logradouro. SOLUÇÃO Removido filtro por logradouro na consulta do endereço do cliente.
MILLEN-42257	CAUSA/MOTIVO Recebimento de embarque de compras calcula ICMS diferente do evento [AUTO GERAL]. Sistema estava zerando o valor calculado para o ICMSST. SOLUÇÃO Corrigido para calcular o total do ICMSST apenas quando configurado para não calcular ICMSST.
MILLEN-42260	CAUSA/MOTIVO Erro de bandeira/operadora não cadastrada ao finalizar TEF mesmo com parâmetro para Cadastrar automaticamente marcado. SOLUÇÃO Quando utilizada interface de pagamento varejo não existia estrutura que inseria a rede e operadora quando o evento estava configurado para cadastro automático.
MILLEN-42353	CAUSA/MOTIVO O sistema está perdendo os valores inseridos e atualizados no nível de estoque para produtos/SKU. Foi verificado que o método "AtualizaPorProduto" da classe "millenium_niveis_estoque" se perdia em situações onde o produto ainda não tinha um nível de estoque cadastrado. A rotina não conseguia identificar que era necessário atualizar com os valores informados pelo usuário, por isso os valores sempre ficavam em branco. Além disso, também havia um bug ao atualizar os valores já cadastrados no nível de estoque. A rotina sempre deixava de atualizar o primeiro da fila, deixando-o com valor nulo. SOLUÇÃO Para corrigir, foi necessário ajustar alguns aspectos do método "AtualizaPorProduto" da classe "millenium_niveis_estoque". Dessa forma, a rotina compreenderá que mesmo para o produto/SKU que ainda não tenha nível de estoque cadastrado, será necessário atualizá-lo com os valores fornecidos pelo usuário. Ajustado também o ponto em que a rotina se perdia ao atualizar os dados de produto/SKU que já tinham nível de estoque, onde sempre o primeiro da fila, ficava com valor vazio. As alterações foram nos mesmos aspectos informados acima.
MILLEN-42361	CAUSA/MOTIVO O método "getMonth" da classe "Date" do JS retorna o índice do mês (menos 1), causando divergência na visualização do gráfico. SOLUÇÃO Adicionado mais 1 no resultado do getMonth da classe Date para combinar o valor do índice com o número do mês.
MILLEN-42373	CAUSA/MOTIVO Não aparece cadastro de endereço. SOLUÇÃO Realizado ajustado para aparecer o cadastro de endereço.
MILLEN-42396	CAUSA/MOTIVO A tela do relatório 121 - Estoques x Pedidos de Venda x Produção contém alguns erros de grafia. SOLUÇÃO Ajustadas as palavras com erros de grafia.
MILLEN-42421	CAUSA/MOTIVO Erros relacionados ao tipo da moeda e registro J52 para Banco do Brasil. SOLUÇÃO Seguindo o manual em anexo, o Banco do Brasil só aceita código 09 para moeda. Mesmo o código da leitora (posição 4, tamanho 1) contendo valor 08, será aplicado o valor 09 apenas para Banco do Brasil. Em relação ao problema do registro J52 para Banco do Brasil, identificamos que ele foi incluído na MILLEN-32513, porém ele deve se repetir após cada registro J. Registramos a issuê MILLEN-43259 para analisarmos uma forma de implementar o registro J52 corretamente. Para evitar erros de validação do arquivo no cliente, os títulos devem estar em lotes/borderô distintos. O registro J52 funciona corretamente quando existe apenas um título.
MILLEN-42428	CAUSA/MOTIVO Caracteres inválidos para formatação do json. SOLUÇÃO Adicionar tratamento scapeJson para tratar caracteres inválidos.
MILLEN-42431	CAUSA/MOTIVO O processo de envio de email por conta do Schaduler estava mandando ContentType como multipart/mixed por padrão, ocasionando o cenário descrito na pendência. SOLUÇÃO Para correção, conforme verificado no método wtssystem!messenger_mail.MESSENGER.CREATEMESSAGE caso rAttach seja EOF, devemos mandar ContentType como multipart/alternative. Tendo o método MESSENGER.CREATEMESSAGE a ser seguido, foi adicionado o ajuste mencionado acima, além disso foram vistos outros pontos a serem ajustados, para seguir a mesma lógica do método mencionado.
MILLEN-42491	CAUSA/MOTIVO Na Interface de Pagamento Varejo (Onde todas as condições são exibidas juntas em forma de botões) o sistema não estava capturando o campo PARCELA. SOLUÇÃO Foi corrigido e realizados testes onde a numeração das parcelas foi gravada corretamente.
MILLEN-42497	CAUSA/MOTIVO O OMNI estava truncando o valor do Desconto aplicado sobre a venda. SOLUÇÃO A situação onde o sistema lançava o valor de 0,01 centavo com pagamento em Dinheiro no Cupom não foi simulada. Pois enviados dados de vitrine e configuração do OMNI para realização do teste. Porém foi identificado e corrigido no OMNI o cálculo do valor do Desconto, o OMNI estava truncando o valor do Desconto, enviando na Venda desconto de 41,98 quando deveria ser um desconto de 41,99 Esse cálculo foi corrigido na tela de Desconto.
MILLEN-42510	CAUSA/MOTIVO Como o cliente utiliza mais de uma filial na integração com o Storex, o número de nota e série podem se repetir e, quando isso acontece, a venda não é integrada por ele não considerar a filial . SOLUÇÃO Alteramos o método ConsultaPorNF para considerar a filial na consulta.
MILLEN-42540	CAUSA/MOTIVO NossoNumero maior que o maxInt. SOLUÇÃO Utilizar o VALUE_STRING ao consultar/salvar o nossoNumero.
MILLEN-42577	CAUSA/MOTIVO Falha ao obter protocolo de autorização da nota para cancelamento. SOLUÇÃO Alterada lógica para buscar o IDPROTOCOLO da tabela NF, caso o retorno da Sefaz não retorne o campo nProt. OBSERVAÇÕES O problema estava ocorrendo porque o XML retornado pela Sefaz não contém a tag nProt e o sistema só estava utilizando o valor armazenado no campo IDPROTOCOLO (tabela NF) quando o status retornado na consulta da nota era 526. A partir de agora o processo será da seguinte forma: 1- Realizar a consulta na Sefaz primeiro e tentar obter as informações da tag nProt no XML retornado. 2- Se o valor retornado for vazio, o sistema vai ler o valor do campo IDPROTOCOLO da tabela NF. 3- Se, ainda sim, o valor for vazio, será exibida a mensagem "Número do protocolo de autorização não encontrado. Não será possível efetuar o cancelamento." e o processo de cancelamento será abortado.
MILLEN-42599	CAUSA/MOTIVO 295 - A data de vencimento deve ser igual à data de validade. SOLUÇÃO Identificado no manual de integração da GNRE que para correção do erro 295 deve ser informada a data de pagamento no campo data de vencimento.
MILLEN-42613	CAUSA/MOTIVO Total Express aceita apenas arquivos de envio com 500kb, qualquer coisa acima disso é descartada, assim causando erro de xml. SOLUÇÃO Feita paginação para realizar envio de 50 em 50. OBSERVAÇÃO Todo o ajuste foi feito no modulo (millenium!gf_totalexpress).
MILLEN-42616	CAUSA/MOTIVO Quando o parâmetro é do tipo boolean, era passado um valor incompatível. SOLUÇÃO Ajuste para verificar se o tipo do parâmetro é boolean e ajustar o valor para o tipo.
MILLEN-42624	CAUSA/MOTIVO O sistema estava triplicando as quantidades para cada tamanho devido ao método MILLENIUM.PRODUCAO.PRODUTOS_PREFASE não estar considerando estampa e cor na ligação com a situação produção. SOLUÇÃO Complementada a ligação da tabela situacao_producao com a tabela produtos_producao com as ligações de estampa e cor.
MILLEN-42640	CAUSA/MOTIVO Erro na publicação de produtos devido à falta de parâmetro no método execute do EXPORT SOLUÇÃO Adicionado parâmetro e validada alteração no cliente.
MILLEN-42645	CAUSA/MOTIVO O erro era causado pois no contexto do método estávamos utilizando a VARIAVEL ":VPROD" dentro de um "#EACH()" e esta variável era testada com uma condição do tipo "VPROD._EOF" causando um erro. SOLUÇÃO Realizado o ajuste no Método repassando para a DLL e tratado de outra forma a condição "VPROD._EOF" via IwtswriteData.
MILLEN-42656	CAUSA/MOTIVO Fiscal - Sistema não gera DIFAL para o estado de SE. Sistema não estava somando o fcp ao valor principal para guia unificada UF SE. SOLUÇÃO Alterado para quando guia unificada somar o fcp ao valor principal.
MILLEN-42660	CAUSA/MOTIVO O CNPJ da transportadora está gravado no banco de dados com espaço no início, e ao realizar a consulta na API "millenium_eco/pedido_venda/listafaturamentos" esse espaço influencia nas integrações do cliente. SOLUÇÃO Adicionado TRIM para o CNPJ da Transportadora, a fim de retirar os espaços em branco do valor. OBSERVAÇÕES Conforme informado no cenário: O comportamento de refletir o "espaço" do cnpj nas iterações via api ocorre para todos os demais campos cnpj, no entanto, por orientação do desenvolvedor, neste momento o ajuste deve ser feito apenas para o campo cnpj_transportadora.
MILLEN-42663	CAUSA/MOTIVO O sistema está perdendo os valores inseridos e atualizados no nível de estoque para produtos/SKU. Foi verificado que o método "AtualizaPorProduto" da classe "millenium_niveis_estoque" se perdia em situações onde o produto ainda não tinha um nível de estoque cadastrado. A rotina não conseguia identificar que era necessário atualizar com os valores informados pelo usuário, por isso os valores sempre ficavam em branco. Além disso, também havia um bug ao atualizar os valores já cadastrados no nível de estoque. A rotina sempre deixava de atualizar o primeiro da fila, deixando-o com valor nulo. SOLUÇÃO 1- Para corrigir, foi necessário ajustar alguns aspectos do método "AtualizaPorProduto" da classe "millenium_niveis_estoque". Dessa forma, a rotina compreenderá que mesmo para o produto/SKU que ainda não tenha nível de estoque cadastrado, será necessário atualizá-lo com os valores fornecidos pelo usuário. 2- Ajustado também o ponto em que a rotina se perdia ao atualizar os dados de produto/SKU que já tinham nível de estoque, onde sempre o primeiro da fila, ficava com valor vazio. As alterações foram nos mesmos aspectos informados acima.
MILLEN-42671	Erro já corrigido na millen-41901
MILLEN-42700	CAUSA/MOTIVO Falha na interpretação de um XML interestadual quando a filial tem a mesma UF definida no campo UFFIM e troca de CFOP, devido a UF do CTE. SOLUÇÃO Validação para interpretar movimentação interestadual, nos casos em que a filial tiver o mesmo estado definido no campo UFFIM (ocorre quando a filial paga o próprio CT-e) e correção em ponto que atribuía o estado do CTE, usado posteriormente no método PRODUTOS.FISCAL.
MILLEN-42757	CAUSA/MOTIVO Na mensagem de erro ao encontrar licença do Cobrebem, está a palavra "Liçenca" ao invés de "Licença". SOLUÇÃO Alterado para a grafia correta "Licença".
MILLEN-42775	CAUSA/MOTIVO Erro 295 - A data de vencimento deve ser igual à data de validade. SOLUÇÃO Identificado no manual de integração da GNRE que, para correção do erro 295, deve ser informada a data de pagamento no campo data de vencimento.
MILLEN-42794	CAUSA/MOTIVO O problema ocorria quando havia drive de QRLinx e TEF instalado no Gerenciador de periféricos. O sistema pega o primeiro TEF da Lista de drivers ordenada por ordem alfabética, neste caso o QrLinx, como esse drive não é compatível com o OMNI, causava o erro mencionado. SOLUÇÃO Foi corrigido o sistema para selecionar o Drive de TEF correto, ignorando o Drive QrLinx.
MILLEN-42826	CAUSA/MOTIVO O sistema está perdendo os valores inseridos e atualizados no nível de estoque para produtos/SKU. Foi verificado que o método "AtualizaPorProduto" da classe "millenium_niveis_estoque" se perdia em situações onde o produto ainda não tinha um nível de estoque cadastrado. A rotina não conseguia identificar que era necessário atualizar com os valores informados pelo usuário, por isso os valores sempre ficavam em branco. Além disso, também havia um bug ao atualizar os valores já cadastrados no nível de estoque. A rotina sempre deixava de atualizar o primeiro da fila, deixando-o com valor nulo. SOLUÇÃO 1- Para corrigir, foi necessário ajustar alguns aspectos do método "AtualizaPorProduto" da classe "millenium_niveis_estoque". Dessa forma, a rotina compreenderá que mesmo que para o produto/SKU que ainda não tenha nível de estoque cadastrado, será necessário atualizá-lo com os valores fornecidos pelo usuário. 2- Ajustado também o ponto em que a rotina se perdia ao atualizar os dados de produto/SKU que já tinham nível de estoque, onde sempre o primeiro da fila, ficava com valor vazio. As alterações foram nos mesmos aspectos informados acima.
MILLEN-42827	CAUSA/MOTIVO Problema 1 O OMNI estava mandando o TPAG 99 e XPag="PIX" nas vendas feitas em PIX, quando a natureza do Tipo de Pagamento era 212 Problema 2 A Sefaz a partir de Maio não aceita mais a Tag <Card> quando o tipo de Pagamento for 99 SOLUÇÃO Foi corrigido o sistema para enviar o código 17, conforme manual técnico da Sefaz.
MILLEN-42865	CAUSA/MOTIVO Na Interface varejo, ao selecionar pagamento do tipo 0 - Dinheiro, o sistema ignorava o tipo de pagamento e assumia o tipo de pagamento anterior. SOLUÇÃO Foi feita a correção no Core do sistema na Eventos.dll
MILLEN-42894	CAUSA/MOTIVO Ao enviar partidas de período contábil fechado que contém partidas de zeramento, sistema envia TipoLancamento = "N" e TipoLancamentoERP = "DESCONHECIDO". Isto causa erro na integração com Dome. SOLUÇÃO Métodos millenium!enfe!dome.CONTABIL.Enviar e millenium!enfe!dome.CONTABIL.EnviarPendentes: -tag "TipoLancamento" recebe valor 'E' quando tipo_origem = 'Z' -tag "TipoLancamentoERP" recebe valor 'ENCERRAMENTO EXERCÍCIO' quando tipo_origem = 'Z' Métodos millenium!enfe!dome.CONTABIL.Listar e millenium!enfe!dome.CONTABIL.ListarPendentes: -inserido campo TIPO_ORIGEM #NULL_TO_S(MC.TIPO_ORIGEM,PC.TIPO_ORIGEM) AS TIPO_ORIGEM -alterado campo TIPO_ERP para aplicar regra verificando primeiro a tipo_origem da tabela MOV_CONTABIL senão da PARTIDA_CONTABIL
MILLEN-42895	CAUSA/MOTIVO No momento que o sistema gera partida contábil de ZERAMENTO após o fechamento de período contábil, TIPO_ORIGEM na MOV_CONTABIL está com NULL quando deveria ser preenchido "Z" SOLUÇÃO Método millenium.PERIODO_CONTABIL.InserePatrimonio, inserido campo TIPO_ORIGEM = "Z" no INSERT da tabela MOV_CONTABIL. Antes ficava nulo.
MILLEN-42965	CAUSA/MOTIVO Erro ao importar produtos do Linx ERP. ERROR:Error reading field COD_FILIAL:List index out of bounds (-1) of LINX.PRODUTOS.LISTAR SOLUÇÃO Ajustado o código para corrigir o local de onde pega o campo COD_FILIAL.
MILLEN-42982	CAUSA/MOTIVO O parâmetro FILIAL_DESTINO só existe em evento de transferência. SOLUÇÃO Incluímos uma verificação para checar se o parâmetro existe antes de utilizar.
MILLEN-42986	CAUSA/MOTIVO Erro no envio de algumas tags JSON quando produto é kit. SOLUÇÃO 1 - Ajustado o envio das tags "sku_type", "price_type" ambas com valor 1 na parte de "custom_attributes". 2 - Alterado o JSON na parte de linkedProduct enviando a tag "price" com valor zero(0) e o campo "price_type" com valor 0.
MILLEN-42991	CAUSA/MOTIVO Erro 295 - A data de vencimento deve ser igual à data de validade. SOLUÇÃO Identificado no manual de integração da GNRE que, para correção do erro 295, deve ser informada a data de pagamento no campo data de vencimento.
MILLEN-43012	CAUSA/MOTIVO O erro era causado por uma variável do tipo "INCORRETO" que quando era repassado para o IwtsWriteData de Status de Publicação dos Produtos causava um erro. SOLUÇÃO Feita a correção do tipo da variável.
MILLEN-43042	CAUSA/MOTIVO Sistema estava tentando reaproveitar um número que já tinha sido utilizado. SOLUÇÃO Removido Notas com o erro 539 (Duplicidade de NF-e com diferença na Chave de Acesso) do processo de Reutilização de NF. Se deu erro de duplicidade é porque o número da NF já foi utilizado. OBSERVAÇÕES Para corrigir o problema em produção, foi excluído o registro da tabela NF_REUTILIZAVEIS. Não foi aplicado a dll com a correção no servidor, então o problema pode voltar acontecer até a atualização.
MILLEN-43053	CAUSA/MOTIVO O parâmetro FILIAL_DESTINO só existe em evento de transferência. SOLUÇÃO Incluímos uma verificação para checar se o parâmetro existe antes de utilizar.
MILLEN-43072	CAUSA/MOTIVO O campo "Gênero" do cadastro do cliente não permitia valores nulos. SOLUÇÃO Alteração para permitir valores nulos no campo "Gênero" do cadastro do cliente.
MILLEN-43073	Já corrigido na millen-41886
MILLEN-43202	CAUSA/MOTIVO O PDV Omni permitia alterar os itens do pedido após ser informado um desconto que requisitava a permissão de outro usuário. SOLUÇÃO Movida validação da porcentagem de desconto do usuário para ao finalizar a venda para replicar o comportamento do e-Millennium.
MILLEN-43231	CAUSA/MOTIVO Acentuação indevida na descrição do método. SOLUÇÃO Corrigida acentuação indevida na descrição do método. OBSERVAÇÕES Necessário reinstalar o módulo para atualizar os arquivos.
MILLEN-43239	CAUSA/MOTIVO Ao validar um novo produto na plataforma TRAY, não está sendo enviado as imagens. SOLUÇÃO A Tray mudou o jeito de enviar as imagens, então foi realizado um ajuste na integração para adequação de Envio das imagens através dos "EndPonint"(s) mencionados abaixo.
MILLEN-43339	CAUSA/MOTIVO O sistema não estava conseguindo finalizar a conferência de prefat devido à trava existente, que faz a consistência do processo. Estava caindo na trava porque, não estávamos considerando para consistência, a soma total dos itens dos volumes informados no prefat total da quantidade dos itens do prefat. SOLUÇÃO Para corrigir, foi necessário ajustar alguns aspectos de validação da trava para considerar a soma dos itens informados nos volumes ao total dos itens do prefat. Quando não houver volumes, o sistema continuará contabilizando apenas a quantidade.
MILLEN-43347	CAUSA/MOTIVO Erro ao importar a Classificação Fiscal está ocorrendo o erro out of memory. SOLUÇÃO Ajustado o código para filtrar cada classificação fiscal antes de loopar.
MILLEN-43348	CAUSA/MOTIVO Após análise, identificamos que para o caso relatado, os volumes estavam se repetindo ao realizar as validações no método "MILLENIUM.EMBARQUES.VALIDAOBJETO". Por algum motivo, o sistema gerou esses volumes repetidos. SOLUÇÃO Realizado um ajuste para evitar que a execução da "millenium.etiq_correios.ResolveMacros" se repita para um mesmo "VOLUME_EVENTO".
MILLEN-43357	CAUSA/MOTIVO Erro no envio de estoque onde produto está em mais de uma filial. SOLUÇÃO Ajustado módulo específico do cliente para enviar corretamente os estoques.
MILLEN-43366	CAUSA/MOTIVO Quando o limite de etiquetas no mês é alcançado, o sistema faz um tratamento para mostrar a mensagem que o saldo acabou, no entanto ele tentava obter o número do contrato de uma command que não tinha o valor no retorno. SOLUÇÃO Ajustado o command para evitar o erro de Field CA_NUMERO_CONTRATO not found.
MILLEN-43498	MOTIVO Ao criar o comprovante de fechamento de caixa, o valor correspondente à informação do valor líquido da venda estava subtraindo o valor de abertura do caixa. SOLUÇÃO Alteração para utilizar o campo que contém o valor somente dos pedidos, isto é, que não contém o valor de abertura do caixa, ao criar o comprovante de fechamento de caixa.
MILLEN-43846	CAUSA/MOTIVO Sistema executava consulta de CCE indefinidamente devido à comparação com mensagem de resposta da Sefaz ter sido modificada, por causa da catástrofe ocorrida no RS SOLUÇÃO Modificado código fonte para procurar o texto padrão "Autorizado o uso da NF-e" no campo MENSAGEMNFE no lugar do texto exato no mesmo campo. Foi aplicado comando na base de dados oficial definindo o campo MENSAGEMNFE com o valor "Autorizado o uso da NF-e". Dessa maneira não há necessidade de troca para solução do problema atual. ** A troca é necessária caso venha a ocorrer novos casos.

5.105.3

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 e-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-45753	CAUSA/MOTIVO No cenário do cliente, temos pedidos que são provenientes de Marketplace, estamos falando de um cancelamento que não partiu do cliente e estamos falando sobre 2 fluxos distintos e que possuem suas características. SOLUÇÃO Realizado um ajuste após testes feitos no cliente, para utilização da nova configuração no envio de cancelamento, para quando o pedido for de origem por MarketPlace.
MILLEN-45754	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-46091	Durante os testes, foi verificado que o tempo para as informações aparecerem varia, de acordo com pc, conexão da internet e estado do servidor, o que pode causar uma breve lentidão e se o usuário clicar na tela novamente, durante esse carregamento, o erro será exibido. Como nos comentários anteriores a pendência foi corrigida em outras MILLEN. Realizamos o teste novamente e funcionou corretamente, por isso a pendência foi concluída.
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-46463	CAUSA/MOTIVO Sistema não estava enviando a base do FCP quando havia ICMS Desonerado. SOLUÇÃO Feita a correção e o erro não mais apresentou.
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 e-Millennium leva a condição de pagamento correta.
MILLEN-46592	O Sistema não estava calculando a comissão pois o parâmetro Não Gera Comissão estava ligada, porém estava Invisível no cadastro do Evento, por uma falha na Regra de Visibilidade associada ao parâmetro Gera Financeiro. No Cadastro do Tipo de Comissão, também não estavam informados os Percentuais de Geração da Comissão para Pedido e Pronta Entrega, esses campos são necessários para calcular a comissão. Também havia uma falha onde o sistema sempre estava lendo o Fator de Entrega do Pedido, mesmo quando a movimentação não tenha pedido. SOLUÇÃO Foram corrigidas as questões destacadas e a comissão foi gerada corretamente.
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-46881	CAUSA/MOTIVO Havia uma extensão no cliente que alterava o código do funcionário. Nos testes de importação da funcionário através do método MILLENIUM!APDATA.API.CONSULTAFUNCIONARIO e com a base do cenário, apresentou erro de código duplicado ao inserir o cargo. SOLUÇÃO Método MILLENIUM!APDATA.API.CONSULTAFUNCIONARIO alterada rotina que carrega o COD_CARGO, COD_CLIENTE e COD_FUNCIONARIO de chamada ao método millenium.utils.default() para DataPool.GetCounter('') para a inclusão de cargos, clientes e funcionários.
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-46953	CAUSA/MOTIVO Sistema só calculava corretamente o troco correto quando o valor do troco era maior que o valor da venda. SOLUÇÃO Foi feita a correção, como o cliente está em go-live já atualizado em produção no cliente.
MILLEN-46990	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-47097	CAUSA/MOTIVO Envio das partidas contábeis (métodos millenium!enfe!dome.CONTABIL.Enviar e millenium!enfe!dome.CONTABIL.EnviarPendentes) ao Dome estava lento devido à ligação com geradores nos métodos de lista. SOLUÇÃO Inserido campo GERADOR_ORIGEM na tabela MOV_CONTABIL; Atualizado view SALDO_CONTABIL; Disponibilizado campos no gerador de relatórios; Alterada implementação dos métodos de contabilização para gravar a informação do GERADOR_ORIGEM na tabela MOV_CONTABIL (lancamentos,movimentações e baixas); Alterado método millenium.PERIODO_CONTABIL.InserePatrimonio para gravar os registros na MOV_CONTABIL agrupando somente pelos campos MC.CONTABILIZACAO, MC.FILIAL, MC.CONTA, MC.CENTRO_CUSTOS, alterado campo DATA para utilizar a DATA DO FECHAMENTO, atualizado campos PERIODO_CONTABIL e CENTRO_CUSTOS conforme solicitado; Alterados métodos do dome (millenium!enfe!dome.CONTABIL.PARCEIRO.Listar,millenium!enfe!dome.CONTABIL.Listar,millenium!enfe!dome.CONTABIL.ListarPendentes) para efetuar ligação do gerador direto pelo campo GERADOR_ORIGEM da tabela MOV_CONTABIL Alterado método millenium!enfe!dome.CONTABIL.PARCEIRO.Listar para não carregar dados de parceiro para registros que zeram (MC.TIPO_ORIGEM <> 'Z')(fechamento de período contábil que transfere resultado para o patrimônio líquido) Inserido script (script_update_gerador_mov_contabil) no dbdic para atualizar GERADOR_ORIGEM da tabela MOV_CONTABIL.
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-47146	CAUSA/MOTIVO Cliente solicitou a impressão, na tag <infAdProd>, da Data de Fabricação do Lote, quando marcada a propriedade "Imprimir a Data do Lote na obs item da NFe". SOLUÇÃO O usuário deve marcar os parâmetros Gerais/cadastro Filial : "Exibir Lote na descrição do Produto" - para diferenciar os lotes de cada item. Caso contrário os diferentes lotes serão agrupados por Produto. "Imprimir a Data do Lote na obs item da NFe" - para exibir as informações requeridas na tag <InfAdProd>. No arquivo CfopNaoDevol.ini foram criadas duas propriedades, na seção [LOTE] : "TextoFabricacao", default FABRICACAO "NotShowLoteEmInfAdProdIfExibeNaDescricao", default F Definir o valor T para a propriedade "NotShowLoteEmInfAdProdIfExibeNaDescricao" fará com q o sistema não exiba o número do lote na tag <InfAdProd>, desde q o parâmetro Geral/cadastro Filial "Exibir Lote na descrição do Produto" esteja marcado. Essa propriedade ser para evitar a repetição do número na impressão/visualização da NFe.
MILLEN-47177	CAUSA/MOTIVO Mensagem de erro estava sendo validada erroneamente na função pos do delphi. SOLUÇÃO Ajustado uso da função, add mais uma condição de erro.
MILLEN-47179	CAUSA/MOTIVO Quando existiam duas matérias primas iguais, com consumos diferentes na mesma série, o sistema não entendia e ignorava esta matéria. SOLUÇÃO Validado o consumo também.
MILLEN-47180	CAUSA/MOTIVO A EZcore, para algumas criações de variação, não estava retornando o id da mesma de forma síncrona, isso acabava fazendo a integração criar o produto sem o vínculo com a variação de cor que, depois disso, não consegue ser refeita. SOLUÇÃO Suspenso o processo de criação/atualização do produto quando este cenário ocorrer.
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. 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-47280	CAUSA/MOTIVO Não estava sendo enviado para o pedido de venda o valor correto do desconto nos campos V_ACERTO e ACERTO, fazendo o desconto ficar zerado no pedido de venda. SOLUÇÃO Para correção, foi ajustado o filtro de sale.promotions onde foi alterado o filtro e.items?.length === 0 para !e.items?.length pois caso não possua itens com o operador ? length se torna undefined e na comparação "0 não é igual a undefined", não retornando os descontos, conforme ocorria no cenário. OBSERVAÇÕES Conforme testes realizados em versões anteriores, hoje apenas apresentamos a porcentagem do desconto no pedido de venda, tendo em vista que o saldo é zero pois já foi entregue. Dessa forma, a tela não apresenta o valor, porém isso já ocorria em versões anteriores. Esse cenário surgiu da 105.beta, por isso será commitado apenas na 105.3.
MILLEN-47287	CAUSA/MOTIVO Produto não exibido no site, segundo o pessoal da fbits por que eles não estavam vinculados a uma categoria principal. SOLUÇÃO Ajustada integração para indicar um categoria como principal.
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	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-47292	CAUSA/MOTIVO Especificações definidas para uma cor, sendo exibidas no site, em produto que não é desta cor. SOLUÇÃO Ajustado o envio para respeitar a cor, estampa e tamanho do sku que estiver sendo processado.
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-47509	CAUSA/MOTIVO Ao fazer um pedido com produtos com SKU carregados parcialmente, ocorria um erro ao preencher os dados para emissão do cupom. SOLUÇÃO Correção para recarga de SKUs não mapeados antes de faturar.
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-47598	CAUSA/MOTIVO Termo incorreto DEMONSTRATIVO_PADRAO SOLUÇÃO Alteração do termo incorreto DEMONSTRATIVO_PADRAO (correto: DEMONSTRACAO_PADRAO).
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

5.105