5.85

Manutenções 5.85

Pendência	Resolução
MILLEN-2095	O problema não ocorre mais. Pois, o cliente não trabalha mais com a AGV que é quem fazia a integração das notas com o Millennium.
MILLEN-2360	Foi gerado um arquivo do SPED do mês de Julho na versão Branches e o bloco K bateu com o relatório do sistema. O consultor vai enviar este arquivo para o cliente validar ainda hoje e se estiver OK pelo cliente, mandaremos uma BMSped para atualizar no cliente.
MILLEN-2466	CAUSA/MOTIVO Arquivo contém caracteres especiais não tratados. SOLUÇÃO Caracteres especiais tratados.
MILLEN-2839	Causa Sistema desconsiderava o fator de conversão para NFs de Entrada digitadas Solução Alterada DLL eventos para considerar o fator de conversão nos casos de Devolução de compra
MILLEN-2971	CAUSA/MOTIVO Usuário consegue fechar o chamado, com tarefa de aguardando a posição do gerente em aberto. SOLUÇÃO Foi ajustado o workflow para que faça uma condição de verificação para caso exista tarefas em aberto, não deixar fechar o chamado. Com isso, foi criado um evento, e ajustado o método "fecha" para incluir a chamada desse evento OBSERVAÇÕES Segue o modelo do workflow proposto para essa pendência.
MILLEN-3146	Na impressão do romaneio de oficina, não apresentava o valor da quantidade de itens. SOLUÇÃO Foi verificado que o campo sendo usado no recibo "ROMANEIO_SERVICOS.LAY" era um campo que não estava implementado, provavelmente colocada a mão. Foi ajustado para que esse campo traga as quantidades de itens utilizados.
MILLEN-3308	Produção não validando o estoque no momento da baixa de matéria prima O estoque ficou negativo, devido a flag em.: menu/produção/configurações/Produção/Aba Empenho e Baixa/Flag Bloquear empenho sem Estoque; Como esta flag esta desmarcada, ao liberar para produção, a rotina não valida o estoque e sempre efetua o empenho; Corrigido trava para não aceitar estoque negativo. Não foi possível efetuar o cenário informado na pendência, então foi criada uma nova produção.: 011799; Caso tentar alterar o empenho para 1 a mais do atual empenho, ocorrera o bloqueio do processo. Caso seja um valor menor que o empenhado ou o mesmo valor a rotina não irá travar, porque já foi efetuado o empenho, o sistema apenas irá consumi-lo.
MILLEN-3638	CAUSA/MOTIVO Ao tentar efetivar a nota de devolução compras apresentava a mensagem "NF Referenciada não localizada na base de dados". SOLUÇÃO O problema estava no Pré-Faturamento onde no método de procura não estava sendo levado em conta a qual filial pertencia o faturamento e por isso acabou associando a nota de outra filial, ocasionando a mensagem acima.
MILLEN-3655	CAUSA/MOTIVO Rotina de faturamento automático, recebeu campos que fez com que a rotina salvasse o campo json null, assim quebrando a consulta-sucesso-lote.xml SOLUÇÃO Adicionada tratativa para caso o campo esteja nulo não consultar.
MILLEN-3755	CAUSA/MOTIVO Os processos de WMS não suportam a bipagem de produto com quantidade fracionada, porém a entrada do sistema permite o faturamento fracionado. Ao fazer o faturamento automático, o sistema não consegue resolver as quantidades fracionadas na execução de regra WMS e retorna o erro citado no cenário. Conforme informação obtida com o analista Renan, a Infracommerce não utiliza o recurso de forma fracionada, mas eles não conseguem identificar o problema apenas pela mensagem de erro exibida porque não possuía nenhum tratamento específico para essa mensagem. SOLUÇÃO Criado parâmetro "Não Permite Quantidade Fracionada" nas configurações gerais de ENFe, seção "NFe". Com o parâmetro marcado, o sistema bloqueará o processo de importação de XML/faturamento XML recebimento quando houver quantidade fracionada em algum dos itens.
MILLEN-3830	CAUSA/MOTIVO Alguns XML estão chegando com alguns caracteres inválidos porque estão sem o "encode" do utf8. SOLUÇÃO Adicionado o encode no ImportarXML para ser forçado.
MILLEN-3831	CAUSA/MOTIVO Algumas linhas estavam fora da querie por não ter a data informada de atualização. Também alguns status não eram contemplados pela querie devido o status estar focado no 0. SOLUÇÃO Feito ajuste nas queries.
MILLEN-3843	Lentidão para carregar vitrine - OMNI A vitrine do cliente possuí aproximadamente dois milhões de SKU diferentes. O método responsável por consultar os produtos com estoque para adicionar na vitrine do PDV Omnichannel fazia a seleção de aproximadamente um milhão de itens com SKU diferente, sendo assim a consulta levava um alto tempo de resposta e ocasionalmente gerava um erro de "timeout". SOLUÇÃO Adicionado um limite para o método responsável pela alimentação da vitrine consulte os primeiros 50.000 itens, sendo assim, fazendo com que os produtos com diferentes SKU sejam carregados gradualmente. OBSERVAÇÕES Solução temporária, sendo alterada após implementação do catálogo alternativo que armazenará os dados utilizando ElasticSearch.
MILLEN-3857	CAUSA/MOTIVO Sistema não estava integrando a nota em questão devido a diferença entre o valor total e o valor do lançamento, diferença essa que ocorria devido ao valor do seguro não estar sendo somado ao valor total do pedido. SOLUÇÃO Ajustado de maneira a somar o valor do seguro junto com o valor total do pedido, alinhando assim com o valor do lançamento.
MILLEN-3940	CAUSA/MOTIVO Rotina está explicita que não ocorre devolução de frete na troca/devolução. SOLUÇÃO Feito ajuste para que a rotina possa devolver frete na nota e no lançamento quando o devolve_frete no tipo_chamado for integral e a devolução seja a mesma quantidade do que foi "faturado".
MILLEN-3942	Crescimento da base fora de padrão CAUSA A tabela vitrine_log está muito grande, com mais de 20 milhões de linhas. A limpeza da tabela ocorre com a tabela vitrine, quando a data de atualização é maior que 90 dias. Por algum motivo, existem diversas linhas na tabela vitrine_log que não tem mais vínculo com a vitrine. SOLUÇÃO Executar o comando (informado no Jira) na base de dados do cliente. Após o comando, será necessário executar o GBAK (BACKUP/RESTORE) para que a base seja limpa e tenha o tamanho compactado; OBSERVAÇÕES Após a rotina de correções, acompanhar se a base volta a crescer rapidamente. Atenção!!! Realizar backup da base antes de executar o script. Executar primeiramente em homologação, e somente após validação completa de dados executar em produção. Não executar em outra base de dados, por mais similar que um possível problema possa parecer. Antes de executar em produção, certificar-se de que o Broker NÃO esteja no ar. Após execução do script, limpar os caches. O Script demora menos de 25 minutos para ser executado.
MILLEN-3946	CAUSA/MOTIVO Cenário em que o lote a ser criado na rota é o mesmo número do lote que entrou no recebimento. O sistema não criava novamente o lote. SOLUÇÃO Caso seja o mesmo lote do recebimento e o lote não for da própria transferência ou for um lote sem lote origem, podemos recriá-lo. (Já havia sido feito na MILLEN-677, somente na branches).
MILLEN-3986	CAUSA/MOTIVO Sistema estava enviando a nota para o Linx independente de estar aprovada ou não, porém, quando a nota não estava aprovada o millennium não enviava o status da nota. SOLUÇÃO Modificado o processo para que a liberação do envio ocorra no momento em que ocorrer o evento "MILLENIUM.MOVIMENTACAO.EV_NOTAAUTORIZADA".
MILLEN-3987	CAUSA/MOTIVO Sistema após atualização não estava importando saldo de estoque devido a erro identificado em dois selects do método. SOLUÇÃO Ajustados os nomes dos campos nos selects.
MILLEN-4045	O programa não mostra corretamente os dados na aba configurações quando o HTML está ativado. HTML. A tela usa um recurso específico que não era suportado na implementação html. Feito ajuste para correção.
MILLEN-4058	CAUSA/MOTIVO Sistema não estava conseguindo fazer a validação das quantidades devido a quantidade negativa que estava sendo inserida no pedido de venda quando esse era do tipo devolução. SOLUÇÃO Verificado que com exceção da inserção do pedido de venda todos os demais pontos estavam tratados com valor absoluto, foi implementado o mesmo cast na comparação das quantidades.
MILLEN-4132	Problema na integração CAUSA/MOTIVO Lentidão, chamada com TOP 10 demora mais de 2 minutos para retornar SOLUÇÃO Melhoria no select da ListaPedidos
MILLEN-4227	ICMS Difal, deve sair na Tag vlICMSUFRemet O valor do diferencial de alíquotas que tenha sido recolhido pelo vendedor e destacado no campo <vICMSUFDest>, da tag <ICMSUFDest>, quando da emissão da NF-e de entrada, deverá constar no campo <vICMSUFRemet>. SOLUÇÃO Incluído o parâmetro no cadastro de Filiais (print abaixo) quando marcado irá considerar o DIFAL para o campo <vICMSUFRemet> ao invés do <ICMSUFDest>. OBSERVAÇÕES Foi liberada a versão para testes, pois como não havia base de dados e nem cenário na pendência, não foi possível efetuar os teste prévios. A base de dados está no SAAS e é necessário que seja disponibilizada um endereço de acesso para que possamos debugar os testes. Após os testes favor avisar para que seja feito o commit na versão branches
MILLEN-4264	NFCe – Valores divergentes no cupom fiscal utilizando duas formas de pagamento CAUSA/MOTIVO Quando alterava o valor de pagamento pela grid ocorria um erro que permitia um valor de pagamento errado que saia na nota SOLUÇÃO Foi bloqueada a grid DBCtrlGrid1 para não permitir valores divergentes no cupom fiscal utilizando duas formas de pgto
MILLEN-4283	Erro ao gerar Sped Fiscal Conforme orientações do programador, o consultor foi orientado, como solução temporária, a configurar através do c:\wts\wtsConfig o tempo limite de requisição ao servidor quanto o tempo para solicitar login com 840 minutos, conforme print abaixo. O arquivo do período de 01/10/2020 até 31/10/2020 foi gerado com quase 7 horas de processamento durante a noite, utilizando a base de dados do servidor HML...
MILLEN-4323	Envio de boleto não funciona CAUSA/MOTIVO Sistema ao filtrar lançamentos manuais\borderô estava no filtro do envio de boleto filtrando registros com origem is null, sendo assim como retornava eof o e-mail não era enviado. SOLUÇÃO Ajustado o método para desconsiderar a origem no momento do envio do e-mail OBSERVAÇÃO Devido ao site do cobrebem estar fora do ar não consegui fazer a geração do boleto.
MILLEN-4348	Integração MCx - Sincronização de estoque Conforme mencionado pelo programador, o saldo do produto hoje se encontra positivo com 5 em estoque. Analisado a rotina e a aplicação recebeu no dia 27/11/2020 um saldo de -26 da microvix. Como é uma data antiga, não temos mais o log para validar essa entrada. Peço para acompanhar os saldos e nos avisar quando ocorrer "divergência", para que seja possível validar os log da integração MCX.
MILLEN-4387	CAUSA/MOTIVO Produto que usa estoque infinito ficando com estoque esgotado na VTEX SOLUÇÃO Melhoria no log de estoque, para mostrar se estamos enviando estoque infinito True ou False para a VTEX OBSERVAÇÕES Não foi possível rastrear o erro, pois o produto de exemplo já se encontra com estoque infinito marcado na VTEX no momento então foi adicionado ao log, a variável que está sendo enviado na tag "unlimitedQuantity" responsável por controlar o estoque infinito na VTEX para melhorar a visibilidade caso o erro volte a acontecer.
MILLEN-4397	Conforme informado pelo programador, através da pendência BMMANU-21278 , foi feita uma correção do programa que causa o problema apontado na pendência. E também possui uma flag que faz uma verificação no cadastro. Como "legado" , pois não sabemos quando foi a atualização do cliente nesta versão , está disponível um script para apagar as linhas duplicadas.
MILLEN-4489	Problema ao copiar cadastro de transportadora Identificado que o problema só ocorre ao utilizar a standard.dll como tela no Millenium. Por ser um ponto sensível de ser alterado, preferimos migrar o cliente para utilizar a standard no formato HTML, que não estava acontecendo por sujeira na pasta wts\appmap com os arquivos de controle. Passado para o cliente testar as telas em HTML, caso necessário voltar, será necessário alterar o ponto sensível pra funcionar na standard.dll
MILLEN-4493	CAUSA/MOTIVO A Emissão de GNRE para o Rio de Janeiro agora utiliza uma nova descrição de informativo de produto que ainda não está disponível no cadastro do Millennium. SOLUÇÃO Alterado o informativo de Produto padrão do Rio de Janeiro para '89-Outros'. Adicionado no cadastro do sistema os novos valores disponíveis para GNRE no campo de descrição informativo de produto. OBSERVAÇÕES Novos informativos cadastrados: '86 - Bebidas' '87 - Energia Elétrica - Recolhimento Consumidores Livres' '88 - Veículos e Pneumáticos' '89 - Outros' '90 - Peças, Partes e Acessórios para Veículos Automotores' Para correção no cliente, não é necessário atualização. Basta realizar a execução do script em anexo script_partilha_campos_extras_9.txt. Após a execução será possível cadastrar o informativo.
MILLEN-4513	Erro no cálculo de frete CAUSA/MOTIVO O valor do frete estava sendo dobrado em notas de devolução com mais de 1 sku. SOLUÇÃO Foi alterada a rotina que calcula o valor do frete para fazer o rateio entre os itens. OBSERVAÇÕES Escolher a mesma modalidade do frete ao gerar a nota de devolução pois pode dar diferença no valor da nota
MILLEN-4523	CAUSA Os anexos do cliente, estão duplicados, existem dois anexos com cerca de 2 milhões de linhas no banco de dados, a demora ao tentar entrar na tela de cadastro é o sistema pesquisando essa quantidade. Para esta pendência trouxeram mais de uma base de dados, pois a primeira base não acontecia o problema, os anexos desse nome não estavam duplicados, eu fiz uma pesquisa geral para identificar todos os anexos duplicados no banco, foram encontrados 837 itens únicos duplicados, chegando em 11 milhões de duplicidades. SOLUÇÃO Rodar script em anexo Script Delete Duplicados Anexos.sql Script irá deletar as linhas duplicados na tabela anexo que conseguimos identificar no banco que nos foi disponibilizado. Tela após o script executado. OBSERVAÇÕES Caso ocorra novamente, será necessário validar com o cliente o cenário de cadastro de cliente que sendo utilizado, para que possamos analisar. Atenção Realizar backup da base antes de executar o script; Executar primeiramente em homologação, e somente após validação completa de dados executar em produção; Não executar em outra base de dados, por mais similar que um possível problema possa parecer; Antes de executar em produção, certificar-se de que o Broker NÃO esteja no ar. Após execução, limpar os caches; Lembrando: Utilizamos agora o DBEAVER para acesso a base firebird; Script demora menos de 10Min para ser executado.
MILLEN-4548	CAUSA/MOTIVO Sistema não estava enviando as informações de cancelamento da nota fiscal SOLUÇÃO O sistema foi ajustado de maneira a enviar as informações de cancelamento solicitadas.
MILLEN-4559	CAUSA/MOTIVO Sistema estava tomando truncate devido ao campo bairro de um cliente que estava muito longo o texto SOLUÇÃO Desenvolvida uma melhoria no sistema que consiste em identificar qual campo está excedendo o tamanho e notificar o usuário.
MILLEN-4596	Estoque não está sendo atualizado na Vtex SOLUÇÃO Correção na procedure interna "EnviaEspecificacaoSku" que estava sendo chamada e utilizada incorretamente ocasionado o erro da pendência.
MILLEN-4598	Divergência de estoque Millennium X Microvix - CAUSA/MOTIVO Pedido de Venda ao ser quitado, o saldo do produto do pré-faturamento retorna para o estoque do millenium. Enviado o comando para a microvix informando que foi cancelado e a microvix retorna com o saldo do estoque para atualizar no millenium. Identificado que neste curto período de tempo o dap automático é executado utilizando este produto que retornou do estoque na quitação antes da atualização do estoque pela microvix duplicando assim a informação do estoque. SOLUÇÃO Instalar módulo millenium!microvix.minst No cadastro da filial, extensão da Microvix, inserido campo Evento Cancelamento (ver imagem anexo) No processo de quitação do pedido de venda (método MILLENIUM.PEDIDO_VENDA.Incluir_Motivo), é chamado o método de extensão MILLENIUM.PEDIDO_VENDA.ev_produto_cancelado. Criado método millenium!microvix.PEDIDO_VENDA.ev_produto_cancelado fazendo na mesma transação uma movimentação de saída utilizando o Evento Cancelamento configurado no cadastro da filial para consumir este produto que acabou de ser quitado. Este evento obrigatoriamente deve estar configurado como Saída Simples e na Influência do Estoque = Subtrai. Com isso ao efetuar a atualização do estoque pela microvix o saldo do produto não será duplicado.
MILLEN-4647	CAUSA Não é possível incluir ou consultar os embarques pelo coletor de dados. SOLUÇÃO método MILLENIUM.EMBARQUES.LISTA Z:\modules\millenium!wms_coletor\views-HTML\Public\DoEscopo.ts
MILLEN-4648	SOLUÇÃO Pedido VTX-3611759: Efetuar configuração conforme comentário anterior. Pedido VTX-3625777: Corrigido envio do valor do frete para a Microvix. OBSERVAÇÕES Pedido VTX-3577570 consultor está avaliando diretamente com a Microvix, portanto não foi verificado.
MILLEN-4663	CAUSA/MOTIVO Erro de importação com divergência de valores, referente ao juros. SOLUÇÃO Voltar o ajuste que estava multiplicando o juros pela quantidade de parcelas, apenas resgatando o valor direto do json. OBSERVAÇÕES Conforme informado pela fbits o retorno do juros no json não deve vir rateado pela quantidade de parcelas.
MILLEN-4785	Conforme informado pelo analista. Erro no wtsBroker já resolvido e em produção no cliente. Este broker também estará disponível nos próximos releases da versão 82 e 83.
MILLEN-4848	Problema já solucionado na Millen-5133 - Após analise, foi identificado que o sistema mantem o padrão como 2 casas decimais, porém possui uma configuração, onde você pode escolher o número de casas decimais que o sistema deverá utilizar.
MILLEN-4910	Erro na transferência de local de estoque SOLUÇÃO Implementado para gerar o código da transferência no coletor.
MILLEN-4917	CAUSA/MOTIVO Não existia verificação se o local digitado era um local de colmeia nas páginas de inclusão do coletor. SOLUÇÃO Adicionada validação de Colmeia nas telas de inclusão melhorias de UX após mensagens de validação do local (limpeza do campo e foco no componente para digitação).
MILLEN-4929	MOTIVO O client entrava em uma validação onde o valor de fechamento informado e o presente no caixa eram divergentes devido à diferença entre as casas decimais. SOLUÇÃO Utilizada a função RoundFloat() para igualar as casas decimais arredondando o valor e realizar a validação adequadamente.
MILLEN-5002	CAUSA/MOTIVO Rotina traz null na consulta. SOLUÇÃO Adicionado função para trazer 0 quando nulo.
MILLEN-5059	MOTIVO O campo "Múltiplos Vendedores" em configurações do pedido de venda não estava visível. SOLUÇÃO Alteração no campo "Múltiplos Vendedores" em configurações do pedido de venda para torná-lo visível.
MILLEN-5064	CAUSA Foram realizados diversos testes e análises, e não foi possível simular o empenho negativo preso. Possivelmente a produção está com empenho preso, pois foi produzido e empenhado em filiais diferentes (00, 09). SOLUÇÃO Por gentileza, atualizar o cliente para a última versão, pois existem diversas travas e ajustes que a versão antiga não possui, que podem barrar algum possível erro manual. Rode também o comando a seguir para corrigir o problema : GRUPPO INTIMO - Corrige Empenho Completo - V5.sql Após a atualização da ultima versão o erro persistir, solicito também que seja validado com o cliente, o cenário que ele usa para produção, para que possamos analisar passo a passo o que o cliente está fazendo. OBSERVAÇÕES Atenção Realizar backup da base antes de executar o script; Executar primeiramente em homologação, e somente após validação completa de dados executar em produção; Não executar em outra base de dados, por mais similar que um possível problema possa parecer; Antes de executar em produção, certificar-se de que o Broker NÃO esteja no ar. Após execução, limpar os caches; Lembrando: Utilizamos agora o DBEAVER para acesso a base firebird. Script demora aproximadamente 10min para ser executado.
MILLEN-5098	Não , foi possível reproduzir o erro apontado na pendência. No cliente está configurado o exportador Walmart , mas o flag de processo de integração esta desligado. Em consulta direta no servidor do cliente , foi feita uma verificação nos registros de logs dos arquivos e também na vitrine_log ,e não possuem nenhum registro de erros ou de importações de pedidos. Para uma melhor analise precisamos de mais detalhes do erro , como os log´s ou exemplos de pedidos com este erro ou a forma que eles estão utilizando a integração.
MILLEN-5114	Conciliação Trademaster CAUSA/MOTIVO Alguns campos eram numéricos mas deveriam ser alfanuméricos Falha na consulta do nosso número no response da TradeMaster SOLUÇÃO Importante: O sistema apenas encontrará para conciliação o título com nosso número 00000000043000000764 (duplicata_completa_cobrebem) porque é o único com correspondente na base que já foi enviado para a trade e que está no json de resposta do endpoint de homologação. Ajustes: Alguns campos numéricos foram alterados para alfanuméricos por compatibilidade Filtraremos o endpoint de payment-reconciliation pelo ticketNumber e utilizaremos o nosso número formatado (12 caracteres com zeros à esquerda) para identificar o titulo no response Havia um campo da tabela de extensão da trademaster na base de QA que estava com o tipo date, mas deveria ser datetime. No dbdic já está correto, portanto basta ajustar via script, em anexo no Jira.
MILLEN-5126	Foi feito ajuste de acordo com "Revisão integrada do módulo TranspoFrete.docx". 1 - Acertar endereços de retira e entrega, Registro enderecoRetirada foi alterado para buscar os dados da filial 2 - Remover atributos do json da API, Foi removido os campos "criterioCalculoNaoAtendido", "fluxoTransporte" e "dataLimiteEntrega" do registro criterioSimulacao 3 - Ajustar processo que atualizar o status entregue, quando consultar o webserver da transpofrete Aguardando base de dados com o cenário com o Italo Tiago Dos Santos 4 - Revisar o processo de envio de email com os XMLs para a transportadora Após testes, os email estão sendo enviados corretamente.
MILLEN-5135	Servidor não está fazendo download de OCORREN do ftp Problema resolvido. Testes realizados no ambiente do próprio cliente.
MILLEN-5152	CAUSA/MOTIVO Busca de código de barras não exporta o valor na geração do XML. SOLUÇÃO Ajustada a busca do EAN, pois se marcado o parâmetro(Geral ou da Filial) AgrupaSKUs há três possibilidades para este caso: 1) Agrupamento de mais de um SKU com códigos de barras distintos. 2) Agrupamento de mais de um SKU com um único código de barra. 3) Um único SKU no agrupamento. Para os casos 2 e 3 o sistema irá conseguir identificar o código de barras e para o caso 1 o mesmo não consegue identificar qual o código de barras deve ser utilizado.
MILLEN-5173	CAUSA/MOTIVO Tela de Pré-Faturamento (Logística\Expedição\Pré-Faturamento) não gravava o campo obs_item na alteração/conferência. SOLUÇÃO Foi retirado o campo Observação do Grid da tela de Conferência (Ações\Conferir Pré-Faturamento), a tela é somente para a conferência das informações caso o cliente queira incluir/corrigir no Pré-Faturamento, deve ser feito pela tela de alteração 'Logística\Expedição\Pré-Faturamento(Alterar Pré-Faturamento)'.
MILLEN-5179	Relatórios Fiscais – Apuração de ICMS divergente no relatório 359 – 5. Script para ajustar a Base Causa/Motivo Foram identificadas notas de transferências, tanto na entrada quanto na saída, que estavam causando a diferença de valores entre as tabelas de produtos_eventos e notas fiscais. Solução O Script em anexo deverá ser aplicado na base do cliente para o relatório bater com o relatório da 2009. IMPORTANTE: Realizar uma cópia da base de dados. - Se possível validar primeiramente em homologação, para somente após em produção. - Parar o wtsbroker.exe para aplicação do script.
MILLEN-5181	Agrupando produtos no faturamento Motorola CAUSA/MOTIVO O agrupamento do lote estava incorreto, pois deve considerar o lote da movimentação original e o lote de terceiros (quando aplicável) SOLUÇÃO Ajustado agrupamento para utilizar os dois campos. OBSERVAÇÕES Regressão da BMMANU-25321 (Jira antigo) Necessário testar novamente ou automatizar o processo da MILLEN-3621 (também envolve esse processo) e desta pendência para evitar novas regressões.
MILLEN-5185	Pedido 281416279301 com problema no Status Na consulta do método estavam sendo referenciadas as colunas "PV.MARCA", "PV.CATALOGO", "fp.MOTIVO", das tabelas PEDIDO_VENDA e FOLLOWUP_PEDIDOS, que não existem na tabela do banco de dados. OBSERVAÇÕES Anexo wts na versão 80_3 para testes e substituição no cliente.
MILLEN-5205	CAUSA/MOTIVO A Macro View estava colocando automaticamente apelidos genéricos para os campos da sub-select, assim os campos para a select acima não estavam visíveis. SOLUÇÃO Fixado apelidos para os campos da sub-select.
MILLEN-5213	CAUSA/MOTIVO Não importa NSU SOLUÇÃO Inclusa tag "sitefUSN" para retorno do NSU OBSERVAÇÕES Tag para retorno da NSU diferente da utilizada. Foi informado que ocorre por causa do adquirente. Por este motivo foi inclusa nova tag para recuperar.
MILLEN-5215	Código de autorização PICPAY corta na integração VTEX SOLUÇÃO Expansão do tamanho nos campos de passagem do código de autenticação
MILLEN-5248	Gerenciador do Millennium não encontra o TEF – 5.80_3Gerenciador do Millennium não encontra o TEF – 5.80_3 Problema só acontece nesse cliente, mandei uma dll mais atual e não funcionou, conforme verifiquei o sistema da Cappta não está devolvendo o arquivo de resposta, quando nossa dll softexpress não encontra esse arquivo ele retorna essa mensagem de erro que o gerenciador do TEF não está ativo. foi solicitado ao cliente que entre em contato com a Cappta e nos passe o contato de um desenvolvedor. No caso tem que ser próprio o cliente porque eles pedem informações da empresa que está utilizando a automação. Aguardamos retorno do cliente, para resolução do problema.
MILLEN-5274	CAUSA/MOTIVO Categoria não é ativada e desativada dependendo se há produtos ativos. SOLUÇÃO Com ok do programador foi desenvolvido parâmetro que permite que a categoria quando sensibilizada verifique se há produtos ativos e ativar ou desativar a categoria na plataforma OBSERVAÇÕES Quando o parâmetro estiver ativo primeiro sobrescreve se a categoria estiver desativada. Independente se tiver produtos ativos a mesma irá desativar na plataforma. Caso parâmetro ativo e categoria também ativa, será verificado se há produtos ativos. Caso o parâmetro ativado seguirá processo como antes. Permanecendo como está na plataforma.
MILLEN-5288	Causa/Motivo No Store quando a venda é feita via cartão de crédito, no Millennium, a condição de pagamento será Cartão de Crédito, o que já está fazendo e o tipo de pagamento do título no financeiro será a Bandeira VISA, MASTER, ELO, etc, acrescido da quantidade de parcelas, VISA 1X, ELO 2X, etc. Este tipo de pagamento, quando não existe, é cadastrado de forma automática no momento em que o exportador processa o arquivo ,zip. Ao executar o comando de cadastro, a base do Millennium retornava erro de configuração na tabela tipos_pgtos, e após o erro o sistema assumia por padrão o Tipo 0-Dinheiro. Rodar o Dbdic novamente da versão do Millennium ou atualizar a versão do Millennium ou executar o comando em anexo no Jira..
MILLEN-5290	Erro no estoque Algumas triggers do banco de dados do cliente, referente a movimentação de estoque, estavam desligadas. Segue print dos recursos utilizados para resolver o problema foram anexados no Jira.
MILLEN-5291	CAUSA/MOTIVO Sistema não estava conseguindo localizar a série da nf devido a espaços à direita existentes na base do Linx que com o lpad aplicado deixava a string diferente uma da outra e não localizava. SOLUÇÃO Adicionada tratativa para eliminar os espaços na comparação da string.
MILLEN-5298	CAUSA/MOTIVO Os valores de desconto de juros enviados pela fbits estavam entrando em divergência entre cenários de pedidos diferentes não permitindo o cálculo correto pela integração (o valor de juros para alguns pedidos era adicionado ao valor total do pedido e, para outro pedido, não era) SOLUÇÃO Ajustado o valor do pedido com base no valor pago.
MILLEN-5314	Adicionar parcela e bandeira condição pagamento - Magento SOLUÇÃO Passar a tag CC_TYPE na BANDEIRA Passar a tag INSTALLMENS na PARCELA Adicionado o CC_TYPE + METHOD na DESC_TIPO (Descrição do pagamento) 4 - OBSERVAÇÕES Caso o CC_TYPE retorne em branco iremos continuar pegando a informação da tag METHOD Caso o INSTALLMENS retorne em branco iremos continuar passando 1 na PARCELA
MILLEN-5317	Reserva de estoque errada Após análise foi verificado que não se trata de erro, é apenas inconsistência no banco de dados. Foi criado um script para ser executado na base de dados do cliente.
MILLEN-5320	CAUSA/MOTIVO Ajustes solicitados pelo banco. SOLUÇÃO Orientação para configurações: Orientar o cliente para, no cadastro da carteira, configurar o campo "Tipo de Carteira" como "Carteira Vinculada" para sair o texto solicitado no demonstrativo. Alterações no boleto: CPF/CNPJ do Pagador foi adicionado para o banco Safra Adicionado texto solicitado no demonstrativo quando a carteira for do tipo "Vinculada" (configurada corretamente na carteira do e-Millennium) Agência/Conta no boleto já sai corretamente desde a pendência anterior, conforme comentário do analista (seguindo formatação padrão separada por barra) Questionamentos do arquivo As posições no header 027-040 e no detalhe 018-031 estão corretas. As posições 121-126 são referentes a data de vencimento no título, portanto será gerado com a data de vencimento que estiver no título do Millennium. Alterado o comportamento quando a primeira e a segunda instruções forem idênticas: enviaremos apenas a 1ª instrução conforme orientação do banco (a 2ª instrução será enviada com "00" nesses cenários).
MILLEN-5323	CAUSA/MOTIVO Internamente a configuração do campo "Margem Lucro", na aba "Acesso" estava registrada como "numérica", porém o campo deve ser do tipo "record". Internamente a configuração do "Datas p/ Pagto", na aba "Pagamento de Oficina" estava registrada de uma forma incorreta. Foi validado que esse campo não é nativo do sistema e não foi possível identificar a origem que tenha inserido esse campo. SOLUÇÃO Enviados comandos para serem aplicados na base do cliente.
MILLEN-5327	Store Api não carrega produtos com SIT_TRIB do Simples Nacional Causa/Motivo O Erro ocorre porque o campo SIT_TRIB da tabela PRODUTOS do Store estava com tamanho Varchar(3). e o valor que chegava do Millenium era um Varchar(4). Solução Foi alterado o campo na base de dados do Store e alterado os parâmetros nas versões do Store e Millenium.
MILLEN-5334	ERRO AO TRANSFERIR LOCAL DE ESTOQUE CAUSA/MOTIVO Os seguintes locais de estoque estavam duplicados na base (mesmo nome de local e mesma filial), o que poderia causar diversos erros durante o processo do WMS: R001.A002.P001 R001.A003.P001 R002.A001.P001 R002.A002.P001 SOLUÇÃO Necessário executar o comando disponibilizado acima para ajustá-los. OBSERVAÇÕES Solução já havia sido disponibilizada para o cliente na BMMANU-24834. Fazer backup da base de produção antes de executar o comando no cliente. Só deve ser utilizado para esta pendência e deve ser testado em ambiente de QA antes da sua execução em produção!
MILLEN-5335	CAUSA/MOTIVO Sistema estava enviando alguns valores indevidos para o processo de troca. SOLUÇÃO 3.1 - Unit millenium_linx_pedido_venda – Passada a função "TranslateControlaCredito" para a unit "millenium_linx_utils" 3.2 - Unit millenium_linx_utils – adicionada função TranslateControlaCredito 3.3 - Unit millenium_linx_movimentos, Método "MOVIMENTOS.ENTRADAS.ENVIAR" – Ajustado para passar as variáveis de "CONTROLE_CHAVE_VALE" e "CONTROLE_CREDITO" nos parâmetros de entrada do método "LINX.PEDIDO_VENDA.INCLUIR" 3.4 - Unit linx_tickets, método "TICKETS.INCLUIR" – Ajustado para preencher o campo VALOR_TROCA com os dados do input e não com valor zero como estava. – Ajustado para preencher as variáveis de Data apenas com o conteúdo da data sem mandar a hora. 3.5 - Unit linx_pedido_venda, Método "PEDIDO_VENDA.FATURAMENTO.INCLUIR" – Ajustado preenchimento dos campos "VALOR_TIKET", "VALOR_PAGO" para serem preenchidos com valor negativo com o valor vindo do "VALOR_TOTAL" sempre quando "TIPO_OPERACAO" = 2 – Ajustado o campo "VALOR_VENDA_BRUTA" para ser preenchido com valor zero sempre que "TIPO_OPERACAO" = 2 – Ajustado para preencher o campo "VALOR_TROCA" com valor positivo vindo do campo "VALOR_TOTAL" SEMPRE QUE "TIPO_OPERACAO" = 2 – Ajustado o campo "VALOR_TROCA" para preencher com valor = zero sempre que "TIPO_OPERACAO" for diferente 2
MILLEN-5343	CAUSA/MOTIVO Rotinas do Millennium com erro de validação ao receber o número do endereço vazio. SOLUÇÃO Feito tratamento para, além de mover o número para o complemento quando este for maior que a limitação do campo, preencher com traço evitando tanto a duplicação da informação como impedindo de ficar nulo.
MILLEN-5362	CAUSA/MOTIVO O campo bairro estava sendo truncado na integração. SOLUÇÃO Ajustado para realizar o corte da string em 200 (compatível com o cadastro do millenium), caso o valor seja maior, será adicionado na observação do pedido.
MILLEN-5365	Integração - FILA PROCESSA STATUS PEDIDOS – 5.73_162 - CAUSA/MOTIVO A listagem de contingencia estava sendo realizando a leitura de dados muito antigo degradando a performance da integração SOLUÇÃO Restringido apenas a leitura de status de contingencia para um período de 10 dias anteriores
MILLEN-5366	CAUSA/MOTIVO Não é possível inserir o registro F100 no sped contribuições. O erro ocorreu quando a versão foi migrada da 2009 para a 5, alguns campos não foram adequados as telas de HTML, perdendo sua função de preenchimento e gravação e, consequentemente, não sendo exportados para o arquivo EFD. SOLUÇÃO Para a correção foi necessário alterar a tela de inclusão/alteração de fechamento do sped para que seja incluída a informação e foi necessário "trazer" a função processos_judiciais do wts da 2009. OBSERVAÇÕES Durante os testes é muito importante que seja testado o processo inteiro, desde um fechamento de impostos com as informações dos registros adicionados até a geração do arquivo sped, verificando se os mesmos foram exportados corretamente.
MILLEN-5372	CAUSA/MOTIVO Internamente a configuração geral PREFAT_TRANSF_DAP ("Modo de Geração dos Pré-faturamentos no DAP") estava registrada como "boolean", porém o campo deve ser do tipo "varchar". SOLUÇÃO UPDATE CONFIGURACOES SET PARAM_VTYPE = 1 WHERE PARAM_NAME = 'PREFAT_TRANSF_DAP'
MILLEN-5377	O problema está na função "preco_venda" desenvolvida no relatório. Onde divide receita por quantidade, mas se quantidade for igual 0, ocorre erro matemático de divisão por 0. SOLUÇÃO Com isso, alterado a função do relatório do cliente para quando a quantidade for igual a 0, considerar valor 1. Após alteração o relatório é gerado normalmente.
MILLEN-5390	CAUSA/MOTIVO O produto GMX24-MFT-T-N4 não estava entrando no estoque após realizar um movimento de recebimento de compra (Compras\movimentações\003 - ENTRADA-COMPRAS NACIONAIS) devido ao campo 'Fator Conversão' da tela de Cadastro de Produtos (Produtos e Serviços\Produtos\ Aba Logística) que estava com valor 0. SOLUÇÃO O Campo 'Fator Conversão' da tela (Produtos e Serviços\Produtos\ Aba Logística) não pode conter o valor 0. Alteramos o sistema para não aceitar 0 no campo Fator Conversão. Para ajustar o produto GMX24-MFT-T-N4 o usuário deve localizá-lo, ir no campo Fator Conversão, verificar se o valor continua com 0 e clicar no botão "Salvar", o sistema irá salvar o campo em branco.
MILLEN-5391	O erro estava ocorrendo por incompatibilidade dos arquivos da versão. Ajustadas as dlls diretamente no servidor do cliente e o erro parou de ocorrer.
MILLEN-5395	CAUSA/MOTIVO A data de aniversário enviada no IO parou de ser enviada. SOLUÇÃO Validado campo antes de utilizá-lo.
MILLEN-5404	CAUSA/MOTIVO Na tela Financeiro/Pagar/Pagamento de Funcionários o sistema aceitava valor positivo para um lançamento do tipo 'P'. SOLUÇÃO Alterado o sistema para sempre salvar o valor como negativo na tela. Financeiro/Pagar/Pagamento de Funcionários.
MILLEN-5424	CAUSA/MOTIVO Ao abrir o relatório, apresenta um erro. SOLUÇÃO Foi verificado que a descrição de um dos itens do relatório, estava estourando o tamanho que o campo no banco de dados suportava, foi ajustado o tamanho do campo para que suporte descrições maiores.
MILLEN-5426	Cadastro do Cliente não salva CAUSA/MOTIVO Gerador estava como não nulo SOLUÇÃO Como é um campo record e dentro do mesmo já contem validações de campos obrigatórios, foi removido essa validação no cliente. OBSERVAÇÕES Adicionado os métodos para serem importados/mesclados com o wts do cliente pra que não precisar esperar uma nova versão (CLIENTE.wtsCLIENTES.Alterar.wtsCLIENTES.Incluir.wts); Atenção! Realizar backup do arquivo millenium.wts antes de executar a alteração. Executar primeiramente em homologação, e somente após validação completa de dados executar em produção. Não executar em outra wts, por mais similar que um possível problema possa parecer. Antes de executar em produção, certificar-se de que o Broker NÃO esteja no ar. Após execução, limpar os caches.
MILLEN-5433	O erro não ocorre, e assim conseguindo realizar a geração automática de pedido de compra.
MILLEN-5447	Situação não ocorre mais. Corrigida na MILLEN-5884.
MILLEN-5453	CAUSA Erro ocorria porque na consulta do método, na descrição do cliente (COD_CLIENTE + NOME) existia um CAST de 100 caracteres. No entanto, COD_CLIENTE + NOME pode conter mais de 100 caracteres. Logo, quando retornava na consulta um cliente cuja descrição ultrapasse 100 caracteres o erro ocorria. SOLUÇÃO Alterado o CAST para 140 caracteres, e adicionado um substring para exibir apenas 140 caracteres, assim, se futuramente os tamanhos dos campos aumentarem, o erro não vai ocorrer. Segue print do relatório após correção e está anexada a planilha do mesmo: TESTE.xls OBSERVAÇÕES Na descrição da pendência informa que o erro ocorre nos relatórios 234, 134 e 87. No entanto, no cenário não tem os filtros dos relatórios para simular o erro. Portanto, utilizei os filtros informados nos comentários pelo analista de testes referente ao relatório 134, onde foi possível simular o erro.
MILLEN-5460	CAUSA/MOTIVO Quitar pedido não altera os totais da tabela PEDIDO_VENDA. SOLUÇÃO Para não impactar outros processos que talvez utilizem o campo TOTAL da PEDIDO_VENDA como Total original, foi alterado o envio para o Linx ERP para calcular o valor líquido no momento do envio.
MILLEN-5465	CAUSA/MOTIVO Conversão do campo data_base da tabela negociações para o SQL Server está invertendo o dia e mês, assim quando o dia é superior a 12, o sistema da erro de conversão por não existir este mês. SOLUÇÃO Alterar o tipo do campo de 'A -Alfanumérico' para 'H - Data e Tempo' na tabela de negociação do IEditor.
MILLEN-5467	SOLUÇÃO Executar o comando CORRIGIR EMPENHO SCRIPT.sql O script irá corrigir os empenhos indevidos. OBSERVAÇÕES Foram adicionadas travas na rotina de prefaturamentos para evitar esse erro. Por isso solicito que o cliente seja atualizado para uma versão mais recente. Atenção Realizar backup da base antes de executar o script; Executar primeiramente em homologação, e somente após validação completa de dados executar em produção; Não executar em outra base de dados, por mais similar que um possível problema possa parecer; Antes de executar em produção, certificar-se de que o Broker NÃO esteja no ar. Após execução, limpar os caches; Script demora menos de 10Min para ser executado.
MILLEN-5474	CAUSA/MOTIVO O Campo Custo não estava carregando no botão 'Retorno da Oficina', pois ele multiplica o custo pela campo quantidade na ficha técnica, e neste caso campo quantidade estava em branco. Problema surgiu após a alteração da Millen-1541, onde a multiplicação pela campo quantidade foi adicionada a função. SOLUÇÃO Foi feita uma verificação para, caso o campo quantidade esteja em branco, o sistema tratar como 1.
MILLEN-5491	CAUSA/MOTIVO Na geração do Sped era enviado sempre no REGISTRO 002 - o campo CLAS_ESTAB_IND fixo com o valor '05' se a o campo da Atividade Preponderante da Filial fosse 'Industrial ou equiparado a industrial' SOLUÇÃO Criado um cadastro de Classificação de Contribuinte do IPI (Tabela 4.5.5) do Sped com os registros válidos e incluído no cadastro da filial a possibilidade de informar qual a classificação de contribuinte do IPI é a filial.
MILLEN-5502	CAUSA/MOTIVO O tamanho do campo estava incompatível com o banco de dados do Linx erp. SOLUÇÃO Bloqueado com erro explícito.
MILLEN-5503	O processo estava travado em cima da tabela VITRINE_LOG, foi feito uma limpeza da mesma, e o exportar voltou a rodar. A exportação não estava sendo atualizada pelo scheduler por estarem desabilitados alguns métodos como exemplo: [Vitrine_precos] transaction=MILLENIUM_VITRINE.VITRINE.EXPORTARPRECOS enabled=0 stime=0 etime=0 interval=1 lastrun=25/02/2021 16:49:20 Após retirada da linha enabled=0 todos os métodos de exportação funcionaram normalmente.
MILLEN-5505	Foi ajustado no servidor , retirando o loop que estava a mais. No método MILLENIUM.TROCA_DEVOLUCAO.INCLUIR no wts do servidor do cliente, foi editado manualmente, retirando um #CHECK em cima dos produtos, porém não foi retirado o loop de cima dos produtos, executando 2 vezes o loop do TROCA_DEVOLUCAO_PRODUTOS.
MILLEN-5512	CAUSA/MOTIVO Erro ao integrar parcelas no pedido de venda. SOLUÇÃO Criar a flag na vitrine para quando o desdobramento financeiro for processado externamente. OBSERVAÇÕES Por padrão a flag vem desabilitada.
MILLEN-5513	CAUSA/MOTIVO O Linx IO disponibilizou novas transportadoras. SOLUÇÃO Disponibilizado no mapeamento da integração as novas transportadoras.
MILLEN-5516	CAUSA/MOTIVO O desconto estava sendo repassado quando não deveria e o desconto rateado que deveria não estava sendo enviado. SOLUÇÃO Ajustada integração para assumir as regras indicadas pelo Linx ERP.
MILLEN-5521	CAUSA/MOTIVO O .pas responsável pela implementação do processo de kit ficou sem ser adicionado ao projeto SOLUÇÃO Adicionado .pas ao projeto.
MILLEN-5526	Erro processo transpofrete CAUSA/MOTIVO Não existe erro, foi feito uma nova opção para atender esse processo. SOLUÇÃO Foi modificado o parâmetro "Utiliza Melhor Transportadora" no cadastro do evento, foi disponibilizado as seguintes opções: Não utiliza: Não irá atualizar a transportadora Utiliza Melhor Transportadora: No faturamento do pedido de venda o sistema busca a melhor alternativa que atenda as seguintes regras: Prazo de entrega menor ou igual, Custo menor. Se houver alguma transportadora nestas condições será alterado somente a transportadora e tipo de frete. Caso o faturamento esteja sem transportadora, sempre irá buscar a transportadora. Sempre utiliza transportadora: Independente do frete do pedido, sempre irá atualizar a transportadora.
MILLEN-5529	CAUSA/MOTIVO Ao criar a Logística Reversa, o sistema enviava o valor completo da Nota Fiscal para os Correios SOLUÇÃO Alterado para que seja enviado apenas o valor dos produtos selecionados para devolução como valor_declarado da Logistica Reversa.
MILLEN-5534	Causa/Motivo O Cadastro de rede indefinido estava com dois campos nulls que precisavam de informações. Solução Como essa rede é de controle interno do sistema, em anexo comando para corrigir no cliente.
MILLEN-5549	CAUSA/MOTIVO Internamente a configuração do campo "Margem Lucro", na aba "Acesso" estava registrada como "numérica", porém o campo deve ser do tipo "record". SOLUÇÃO UPDATE CONFIGURACOES SET PARAM_VTYPE = 32 WHERE PARAM_NAME = 'MARGEM_LUCRO';
MILLEN-5557	CAUSA/MOTIVO Ao importar um XML acusava erro de sintaxe de SQL SOLUÇÃO Ajustada a function GetProduto.
MILLEN-5564	CAUSA/MOTIVO Dificuldade na leitura do campo por causa do contraste na cor padrão do componente quando está Enabled = false. SOLUÇÃO Melhoria visual nos labels e no componente da tela que era Enabled = False e foi trocado pra ReadOnly = True ter contraste com a fonte. OBSERVAÇÕES Regressão das alterações para identidade visual Linx.
MILLEN-5567	Conforme informado, a pendência foi resolvida na agência.
MILLEN-5570	Não é erro. Os pré-faturamentos não estão excluídos ou entregues, portanto a reserva não está errada. A tela de consulta de pré-faturamento considera o filtro de datas, portanto é necessário aumentar o período na consulta para exibir corretamente o pré-faturamento: As origens desses pré-faturamentos são entradas, portanto não podem ser excluídos manualmente, mas o cliente pode quitá-los se não quiser que a reserva volte para o estoque. Obs: Existe apenas uma peça do produto "IN0001108 - ADESIVO REFILADO - ACREDITAR E REALIZAR" que de fato está com empenho preso vinculado a um pré-faturamento que não existe mais na base. O comando abaixo fará o estorno dessa peça (não tem relação alguma com o cenário original citado, mas precisa ser corrigido): Fazer backup da base antes de executar o comando em anexo no Jira.
MILLEN-5572	CAUSA/MOTIVO O Valor do FCP não era carregado para a NFA. SOLUÇÃO O Valor do FCP estava vinculado ao fato de ter partilha de ICMS entre os estados e o mesmo só era checado se o campo V_ICMS_UF_DEST estivesse preenchido, para desvincular os dois conceitos foi feito o mesmo teste com o valor do FCP da UF de destino. (V_FCP_UF_DEST) OBSERVAÇÕES Anexado no chamado o xml gerado corretamente. Para a correta geração é necessário informar o percentual de 100% no campo pICMSInterPart É necessário, PARA ESSE ESTADO DE DESTINO, informar 18 no campo pICMSUFDest É necessário, PARA ESSE PRODUTO, informar 4 no campo pICMSInter
MILLEN-5579	Teste realizado, após executar o script disponibilizado na pendência MILLEN-5381 os valores de empenho foram corrigidos: Por gentileza, executar o script em anexo no Jira para correção. Atenção: Realizar backup da base antes de executar o script; Executar primeiramente em homologação, e somente após validação completa de dados executar em produção; Não executar em outra base de dados, por mais similar que um possível problema possa parecer; Antes de executar em produção, certificar-se de que o Broker NÃO esteja no ar. Após execução, limpar os caches; Script demora menos de 10Min para ser executado.
MILLEN-5605	Erro na integração de pedidos, divergência de valores do lançamento. SOLUÇÃO Tratamento em cima do lançamento com "Valor assumido pelo afiliado".
MILLEN-5606	Situação não ocorre mais. Foi corrigida na pendência MILLEN-5205. Segue método com a solução para ser mesclado no cliente: PRODUTOS.Ranking.wts
MILLEN-5607	Relatório não abre. SOLUÇÃO Foi verificado que o relatório nunca foi usado, e possuía alguns ajustes a serem feitos para que fosse executado.
MILLEN-5628	CAUSA/MOTIVO Sistema ao fazer o loop das transportadoras configuradas no download do status não estava tratando usuário e senha tomando erro ao ler um campo nulo. SOLUÇÃO Ajustado para ao fazer o loop logar qual a filial que não tem usuário e senha configurado e seguir para o próximo. Melhorado o log de envio para logar o request e response e caso a filial não tenha usuário e senha configurados fazer o log de qual filial precisa ser configurada.
MILLEN-5637	CAUSA/MOTIVO: Divergência no valor da NF 43998 na geração do sped se comparado com o valor total da nota fiscal. SOLUÇÃO: O problema estava que em algumas notas poderia não ser contabilizado o valor de um item da NF, fazendo com que o valor total ficasse divergente do valor total da NF. OBSERVAÇÕES: Correção já havia sido feita na versão branches através da pendência MILLEN-5490
MILLEN-5639	CAUSA/MOTIVO São processados vários itens em paralelo, mas o sistema não estava executando commit no banco de dados, e assim caia em um deadlock. SOLUÇÃO Foi alterado o processo para que fosse executado commit no final da transação. OBSERVAÇÕES Enviar a dll em anexo para o cliente, para que a correção seja aplicada.
MILLEN-5663	CAUSA/MOTIVO O formato dos valores de descontos enviados pela fbits estavam entrando em conflito com o formato listado em outros clientes SOLUÇÃO Contabilizado os descontos do pedido com base no valor pago.
MILLEN-5665	CAUSA/MOTIVO Inconsistência na configuração do parâmetro "Data" no relatório. SOLUÇÃO Alterado parâmetro "Data" na tela para a opção "Entre" e ajustada configuração padrão dos parâmetros do relatório para exibição correta do campo.
MILLEN-5667	CAUSA/MOTIVO Sistema ao fazer a importação das especificações do produto estava mantendo a fidelidade com o sistema Linx, excluindo assim o enriquecimento do millennium. SOLUÇÃO Ajustado para quando não estiver marcada a opção de importação das propriedades, ignorar também o relacionamento com o produto.
MILLEN-5673	Ocorria uma divisão onde o divisor era 0. SOLUÇÃO Alteração para prevenir cenários onde o divisor é 0.
MILLEN-5675	CAUSA/MOTIVO Sistema ao fazer a importação do produto estava atualizando a tabela de medidas mantendo a fidelidade com o Linx, porém perdendo as alterações efetuadas no millennium. SOLUÇÃO Ajustado para quando a integração de tabela de medidas estiver desabilitada não atualizar o relacionamento com o produto.
MILLEN-5687	CAUSA/MOTIVO O envio do atributo pertinente a atualização da imagem não estava sendo feito. SOLUÇÃO Ajustado processo para enviar o atributo e colocado o processo em thread.
MILLEN-5692	CAUSA/MOTIVO Sistema ao fazer a importação do produto estava atualizando a tabela de medidas mantendo a fidelidade com o Linx, porém perdendo as alterações efetuadas no millennium. SOLUÇÃO Ajustado para quando a integração de tabela de medidas estiver desabilitada não atualizar o relacionamento com o produto.
MILLEN-5695	CAUSA/MOTIVO Sistema ao fazer a importação do produto estava atualizando a tabela de medidas mantendo a fidelidade com o Linx, porém perdendo as alterações efetuadas no millennium. SOLUÇÃO Ajustado para quando a integração de tabela de medidas estiver desabilitada não atualizar o relacionamento com o produto.
MILLEN-5716	CAUSA/MOTIVO O status mapeado no tópico fulfillment-status estava equivocadamente adicionando um status a mais no pedido e o mesmo corresponderia ao último processado. SOLUÇÃO Retirado do processo a adição deste status.
MILLEN-5736	Rotina não passava os percentuais de ICMS para o CalculaFrete dos gateways. SOLUÇÃO Repassado os parâmetros no método. OBSERVAÇÕES Para a correção do calculo, será necessário alterar as fórmulas do esquema de frete; Esquema de frete Ir para Menu->Logistica->Estoque->Cadastro->Esquema de Frete Efetuar a busca, e alterar o esquema com código.:RN (RODONAVE); Será necessário alterar a grid.: Fórmulas auxiliares para o cálculo do Frete Remover a linha com o nome.: FRETE_TOTAL; Adicionar 2 linhas com as informações abaixo.: NOME Expressão VLR_FRETE_CALC VLR_FRETE+FAIXA_POR_NOTA+VLR_GRIS+VLR_PEDAGIO FRETE_TOTAL SE(TAXA_ICMS>7, VLR_FRETE_CALC/(0.88),VLR_FRETE_CALC/(0.93))
MILLEN-5747	CAUSA/MOTIVO A Vtex mudou o formato do e-mail listado de ...@ct.vtex.com.br para -212300130179b.ct.vtex.com.br SOLUÇÃO Ajustada integração para realizar a busca de e-mail quando contiver na string listada no campo e-mail o texto "vtex.com.br".
MILLEN-5774	Situação não ocorre mais, correção feita na versão 5_branches e estará disponível na versão 5.85.
MILLEN-5778	Devido a inserção de um condition, o filtro feito na estoques_locais já é feito nos conditions na tag principal. Como a estoques locais é um agrupamento não é necessário aplicar o Having sum. SOLUÇÃO Revertido o commit anterior, porque o filtro feito na estoques_locais já é feito nos conditions na tag principal. Como a estoques locais é um agrupamento não é necessário aplicar o Having sum, o filtro no where já inibirá os registros que não possuírem saldo/empenho_local/Recebimento_Local.
MILLEN-5784	Existem movimentações do ano de 2019 que contem SKU'S inexistes, assim ocasionando erro na trigger de reload_estoque; SOLUÇÃO Executar o comando em anexo no Jira. Script irá corrigir as movimentações indevidas da base de dados e executar o reload_estoque. OBSERVAÇÕES Após executar a rotina, o saldo do produto ficou com a quantidade real da mov_estoque. Atenção Realizar backup da base antes de executar o script. Executar primeiramente em homologação, e somente após validação completa de dados executar em produção. Não executar em outra base de dados, por mais similar que um possível problema possa parecer. Antes de executar em produção, certificar-se de que o Broker NÃO esteja no ar. Após execução, limpar os caches. Script demora menos de 20Min para ser executado.
MILLEN-5787	Um volume de dados alto na tabela vitrine_log fez o processo parar ao tentar realizar a leitura do mesmo. SOLUÇÃO Alterada a lógica de limpeza da tabela vitrine_log para retirar a carga de processamento do banco de dados.
MILLEN-5790	Conforme informação do consultor, o erro foi identificado por ele no ambiente do cliente e já está funcionando.
MILLEN-5797	Cont. da TP 41764485 - Conforme informado pelo programador, quando há alteração do preço em tabelas virtuais, o preço se torna fixo não ocorrendo mais alterações quando há modificações no cadastro da tabela virtual ou na tabela base. Foi testado criando uma tabela teste com as mesmas informações da tabela virtual informada com problema e podemos identificar que as alterações ocorreram. Também foi encontrado no log de alteração de preço que houve modificações de preço na tabela virtual.
MILLEN-5828	Conforme informado pelo programador, quando há alteração do preço em tabelas virtuais, o preço se torna fixo não ocorrendo mais alterações quando há modificações no cadastro da tabela virtual ou na tabela base. Foi testado criando uma tabela teste com as mesmas informações da tabela virtual informada com problema e podemos identificar que as alterações ocorreram. Também foi encontrado no log de alteração de preço que houve modificações de preço na tabela virtual.
MILLEN-5830	CAUSA/MOTIVO Tabela NIVEIS_ESTOQUE com registros de cor que não existiam no produto causando duplicação do relatório. SOLUÇÃO Executar o comando criado no banco de dados (já executado na base disponibilizada para testes).
MILLEN-5835	CAUSA/MOTIVO O Sistema não respeita o layout de impressão escolhido. SOLUÇÃO A chamada do método gerapdf estava desconsiderando o arquivo de layout escolhido na tela de impressão de documentos. Anexado o danfe gerado no formato A4.
MILLEN-5852	CAUSA/MOTIVO Ao clicar no faturamento, o sistema fecha. SOLUÇÃO Foi verificado que a rotina possuía um "loop infinito", fazendo com que o sistema ficasse preso. Foi acrescentada uma trava para que não fique preso, e mostre a real mensagem que o sistema quer apresentar.
MILLEN-5857	Teste ok!! O problema foi resolvido com os procedimentos listados na pendência MILLEN-5858. A diferença na geração do registro C490 se deve ao fato de valores serem gravados com duas casas decimais por produto, e quando é feita a soma dos valores do ICMS por produto pode sim gerar uma diferença entre o valor total do dia * alíquota do ICMS, porém essa diferença é aceita pelo SEFAZ, não causando a rejeição do arquivo do sped. Foi identificado que esse problema dos dados errados no resumo do ECF foi corrigido em Junho/202 e devido o cliente não estar com a dll cprnEpson.dll atualizada. Então será necessário atualizar a dll cprnEpson.zip anexo e executar o comando MILLEN-5858 comando.sql para ajustar os resumos dos dias 11/01, 18/01 e 19/01 Antes de atualizar a dll cprnEpson.dll fazer uma cópia. Qualquer problema volte a dll e nos avise, por favor. Os valores do SPED vieram corretamente (SPED em anexo SPED_TESTE.txt)
MILLEN-5858	CAUSA/MOTIVO – Na geração do Sped estava sendo calculado o valor do ICMS item a item o que gerava uma diferença no valor informado no registro C490 e o Resumo do ECF. – Fechamento com dados errados para o dia 18/01 e 19/01. SOLUÇÃO A diferença na geração do registro C490 se deve ao fato de valores serem gravados com duas casas decimais por produto, e quando é feita a soma dos valores do ICMS por produto pode sim gerar uma diferença entre o valor total do dia * alíquota do ICMS, porém essa diferença é aceita pelo SEFAZ, não causando a rejeição do arquivo do sped. Foi identificado que esse problema dos dados errados no resumo do ECF foi corrigido em Junho/202 e devido ao cliente não estar com a dll cprnEpson.dll atualizada. Então será necessário atualiza a dll cprnEpson.zip anexo e executar o comando MILLEN-5858 comando.sql para ajustar os resumos dos dias 11/01, 18/01 e 19/01. Antes de atualizar a dll cprnEpson.dll fazer uma cópia. Qualquer problema volte a dll e nos avise, por favor. OBSERVAÇÕES Não temos mais a base de dados disponível para efetuar os testes de gravação do valor do ICMS com mais de duas casas decimais, a fim de verificar se não geraria mais a diferença.
MILLEN-5868	MOTIVO Sintaxe do método millenium_omni.POS.GetCatalogSkus estava incorreta, ocasionando um erro ao realizar a chamada do método para carregar a vitrine do PDV Omnichannel. SOLUÇÃO Correção na sintaxe da query.
MILLEN-5869	Conforme comentário do programador: Após manutenção no banco de dados realizada pelo consultor e atualização de DLLs para o último release, os produtos foram processados com sucesso e os erros deixaram de acontecer.
MILLEN-5872	Teste realizado na última versão congelada 2009_129_6. O erro não ocorre mais, a etiqueta sigep foi impressa normalmente. Teste realizado em pedidos diferentes e não apresentou erro.
MILLEN-5879	CAUSA/MOTIVO Ao importar o XML para criar o recebimento o sistema está associando ao produto incorreto. SOLUÇÃO No momento de verificar se o produto já está cadastrado na base de dados, buscar pelo Código de Barras ou pelo Código do Produto do XML e quando não localizar deixar para que o usuário associe o produto desejado, conforme print em anexo no Jira.
MILLEN-5880	Após analise esta pendência trata de problema desconexo das pendência citadas (MILLEN-5348 e MILLEN-4205). Em ambas, o problema decorre de uma falha em tabelas temporárias que impediam a atualização dos preços. Segundo o relato do usuário, o problema ocorre quando é feito o cadastro de produto e de forma intermitente. Usuário relata que cadastrou 15 produtos e apenas um apresentou o erro. E para ajustar o erro ele executa a exportação de preços, que já foi ajusta nas pendência citadas anteriormente. Usuário orientado de proceder com backup da base e copiar os logs REST, broker e logexportação para que possamos analisar e identificar o problema.
MILLEN-5884	CAUSA/MOTIVO Fonte utilizada na impressão de código de barras 39 não era exibida quando o relatório era executado/renderizado no servidor via wtsreports SOLUÇÃO Alterado EmbedTrueTypeFonts de etfNone para etfSubset, necessário para renderizar fontes TrueType ao gerar PDF no server. OBSERVAÇÕES Regressão das melhorias na renderização de relatórios no servidor para o modo html.
MILLEN-5891	CAUSA/MOTIVO A geração da trigger do check no sql server estava aplicando rollback matando o beginSavePoint SOLUÇÃO Retirado o rollback.
MILLEN-5895	CAUSA Existem movimentações de prefaturamentos que já haviam sido quitados mas foram aceitas novas quitações, assim tornando o empenho negativo. SOLUÇÃO Executar o comando, em anexo no Jira. O script irá corrigir os empenhos indevidos. OBSERVAÇÕES Foram adicionados travas na rotina de prefaturamentos para evitar esse erro. Por isso solicito que o cliente seja atualizado para uma versão mais recente. Atenção * Realizar backup da base antes de executar o script; * Executar primeiramente em homologação, e somente após validação completa de dados executar em produção; * Não executar em outra base de dados, por mais similar que um possível problema possa parecer; * Antes de executar em produção, certificar-se de que o Broker NÃO esteja no ar. * Após execução, limpar os caches. Script demora menos de 10Min para ser executado.
MILLEN-5899	CAUSA/MOTIVO - Erros: Gravar na fila de envio a transação MILLENIUM!LINX.MOVIMENTOS.SAIDAS.ENVIAR duplicado; Não é possível inserir o valor NULL na coluna 'NATUREZA_OPERACAO_CODIGO', tabela 'DBELLUS.dbo.LOJA_NOTA_FISCAL'; Alterar a forma de gravação do campo SERIE nas tabelas da base do Linx SOLUÇÃO Gravar na fila de envio a transação MILLENIUM!LINX.MOVIMENTOS.SAIDAS.ENVIAR duplicado: Alterado métodos MILLENIUM!LINX.MOVIMENTOS.MovimentacaoCancelada, MILLENIUM!LINX.MOVIMENTOS.MovimentacaoExecutada e MILLENIUM!LINX.MOVIMENTOS.NotaAutorizada, centralizado todas as consultas em um novo método criado MILLENIUM!LINX.MOVIMENTOS.ExecutaEnvio. Neste método foi inserido a lógica para ordenar pelos números das notas e para não deixar duplicar o registro. Não é possível inserir o valor NULL na coluna 'NATUREZA_OPERACAO_CODIGO', tabela 'DBELLUS.dbo.LOJA_NOTA_FISCAL': Método LINX.TICKETS.Incluir, alterado para enviar no campo NATUREZA_OPERACAO_CODIGO a cfop de um dos itens da nota (tabela PRODUTOS_EVENTOS) Alterar a forma de gravação do campo SERIE nas tabelas da base do Linx: Métodos LINX.TICKETS.Incluir e LINX.NOTA_FISCAL.Incluir alterado consulta de validação da série e alterado a série que é gravada nas tabelas da Linx para ser a série que retornou da consulta especificada pelo Edson Reis no cenário da pendência porém a consulta a ser feita é esta: select fs.serie_nf from series_nf sn inner join FATURAMENTO_SEQUENCIAIS FS on fs.serie_nf=sn.serie_nf INNER JOIN FILIAIS F ON F.FILIAL = FS.FILIAL where F.COD_FILIAL = '373355' – ---variável código da filial and sn.cod_serie_sintegra='4' — variável serie emitida pelo millennium, porém sem os zeros as esquerda OBSERVAÇÕES Erros corrigidos estão relacionados a customização MILLEN-5441 (homologado em conjunto). Acompanhado testes em produção com Rafael Cintra Ferreira e foi homologado com sucesso conforme comentário anterior do mesmo.
MILLEN-5905	Não foi possível reproduzir o cenário, após apontar a base e logar no sistema, ao tentar acessar o relatório citado ocorre o erro: Ao verificar com solicitante, foi informado que o relatório é gerador, sendo assim não necessário o mdmeta. Ao rodar o dbdic o mesmo apresentou erro. Porém, conforme comentário do programador, o erro citado de código de barras foi ajustado na MILLEN-5884.
MILLEN-5916	Erro de conversão de Int to Str para SQL Server para o campo valor_pago utilizando a macro NULL_TO_S. SOLUÇÃO Alteração da macro NULL_TO_S para NULL_TO_Z para o campo valor_pago na select do método Lancamentos.NaoConciliados.
MILLEN-5917	A integração não estava enviado a informação da data final na validade. SOLUÇÃO Ajustada integração para enviar uma data fixa como data final de validade do preço.
MILLEN-5921	Não é erro da versão. CAUSA/MOTIVO Quantidade incorreta sendo apresentada no relatório criado pelo cliente. Está utilizando a função:sum(fichatecnica.quantidade * sum(situacao_producao.quantidade) {l:produto.produto,cor.cor,estampa.estampa,tamanho.tamanho,producao.producao}) SOLUÇÃO Este problema já foi corrigido utilizando a view NECESSIDADE_PRODUCAO. Foi alterada a expressão do campo Consumo Ficha. Expressão incorreta: sum(fichatecnica.quantidade * sum(situacao_producao.quantidade) {l:produto.produto,cor.cor,estampa.estampa,tamanho.tamanho,producao.producao}) Expressão corrigida: Producao.necessidade_producao OBSERVAÇÕES Segue em anexo no Jira modelo de relatório corrigido com a expressão correta.
MILLEN-5928	Na importação dos XML's não estava cadastrando o gerador quando o mesmo não existe na base de dados. SOLUÇÃO: Quando o gerador não existia na base foi ajustada a rotina que fazia a inclusão do mesmo, pois havia um parâmetro que fazia com que ele não fosse incluído.
MILLEN-5940	Existem diversos empenhos que foram feitos em uma filial e baixados de outra. Como exemplo vamos usar a produção número 016747 empenhou na filial 051 - NOHDA BRASIL INDÚSTRIA DE MODA LTDA e teve os empenhos baixados na filial 009-NOHDA COMÉRCIO DE VESTUÁRIO LTDA. SOLUÇÃO Executar o comando PATBO - Corrige Empenho Completo - V5.sql Esse erro já foi tratado partir da versão 5.82 Atenção Realizar backup da base antes de executar o script; Executar primeiramente em homologação, e somente após validação completa de dados executar em produção; Não executar em outra base de dados, por mais similar que um possível problema possa parecer; Antes de executar em produção, certificar-se de que o Broker NÃO esteja no ar. Após execução, limpar os caches. Script demora menos de 10Min para ser executado.
MILLEN-5946	Verificado que o componente da tela de passo na versão HTML está "pulando" o segundo passo e, portanto, caindo na trava do passo final da efetivação, porém não apresentou a tela para seleção de produtos. Teste realizado com sucesso na versão 5.85! O erro não ocorre, e assim conseguindo realizar a geração automática de pedido de compra.
MILLEN-5948	Existem movimentações de consignações que não tiveram a inclusão no poder de terceiro, apenas tem o registro do acerto. SOLUÇÃO Executar o comando em anexo - Corrige Poder Terceiro Consignado - V5.sql O script ajustar o produto indevido. OBSERVAÇÕES Solicito a atualização da versão do cliente para uma mais recente, pois esse erro nas movimentações de consignações já foi ajustado. ATENÇÃO Realizar backup da base antes de executar o script. Executar primeiramente em homologação, e somente após validação completa de dados executar em produção. Não executar em outra base de dados, por mais similar que um possível problema possa parecer. Antes de executar em produção, certificar-se de que o Broker NÃO esteja no ar. Após execução, limpar os caches. O script demora menos de 10Min para ser executado.
MILLEN-5959	Cores não excluídas ao clicar no botão de excluir e relatório desconfigurado. SOLUÇÃO A listagem apresentada, é uma listagem de cores atrelada ao produto selecionado. O grid é apenas uma visualização, caso queira adicionar e/ou excluir uma cor, deve-se ir no cadastro de cores para fazer a ação necessária. Foram ajustados os valores do relatório para que ficassem bem posicionados na tela, pois no momento atual estava desconfigurado. OBSERVAÇÕES As alterações comportamentais da tela, só são realizadas na versão Standard. Na versão HTML (Após o gerenciador de usuários) existem alterações para serem feitas, que ainda não foram realizadas. Informar o cliente apenas para não utilizar aqueles botões momentaneamente.
MILLEN-5965	Erro no integrador Linx ERP, não importa o produto. Solução Método linx.PRODUTOS.Listar, retirado trim() do campo ITEM_PROPRIEDADE do registro de PROPRIEDADES conforme solicitado.
MILLEN-5970	Conforme informado pelo programador: Pedido não integra devido às alíquotas diferentes que compõem o kit. Quando há componentes com alíquotas diferentes ou a alíquota do item pai é diferente da alíquota dos componentes, fica impossibilitada a integração, por divergência de valores de IPI. Há um ajuste na versão mais recente para explicitar esta falha na integração do pedido. Tornando mais claro o motivo do erro. Caso haja a necessidade de que os itens do kit possuam alíquotas diferentes será necessário pedir para customizar.
MILLEN-6014	Erro ocorre devido aos campos de CFOP retornarem fora da ordem esperada pela tela de pedido de venda. Erro será passado ao analista para que possamos corrigir. Solução Neste momento teremos que corrigir de forma paliativa. Na base de dados do cliente, devemos passar a configuração de CFOP da tela em HTML, para a tela antiga. No Jira, foram deixadas as orientações pra resolver na base do cliente. Atenção Realizar backup da base antes de executar o script. Executar primeiramente em homologação, e somente após validação completa de dados executar em produção. Não executar em outra base de dados, por mais similar que um possível problema possa parecer. Antes de executar em produção, certificar-se de que o Broker NÃO esteja no ar. Após execução, limpar os caches.
MILLEN-6023	Alteração da Vtex impactou na customização de clientes PJ. SOLUÇÃO Feito tratamento para filtrar as informações necessárias e ignorar as novas informações enviadas pela vtex. OBSERVAÇÕES Importante, a customização foi feita para o sistema antigo da Vtex, por isso feita a alteração no antigo e, ao mesmo tempo, foi refeita a customização para nova versão da Vtex.
MILLEN-6024	O PDV Omnichannel utiliza duas funções que foram removidas do arquivo "wts.client.ts", visto isso, ao realizar o "deploy" ocorria um erro porque não era possível importar essas funções. SOLUÇÃO Revert para que o arquivo "wts.client.ts" exporte a função "padStart" e "padEnd", utilizadas nos arquivos "pos.sales.services.ts" e "pos.sales.reports.ts", respectivamente.
MILLEN-6045	Cliente possui 39267 cadastros na tabela Cliente e para cada registro estava rodando um RowSet para Categoria, o que causava a lentidão. SOLUÇÃO Melhoria da consulta na select, removido um Sub Select e melhorado a condição; Removido rowset de Categorias. OBSERVAÇÕES No cenário original utilizando a base do cliente, a consulta levava em torno de 6 minutos para ser gerado (por conta do rowset) após a retirada do rowset a consulta levou em média de 80 segundos. Foi procurado no sistema todos os pontos que utilizam o método Cliente.Procura e em nenhum dos pontos encontrados era utilizado o Rowset de categorias. Se no futuro houver a necessidade de adicionar o campo categoria deverá ser feito de outra forma (Ex: Sub Select ou via método de extensão).
MILLEN-6053	Publicação de estoque com percentual de envio, retornando valor com casas decimais. SOLUÇÃO Truncar o valor para um número inteiro , ajustar a vitrine para truncar esse valor também na grid de SKU.
MILLEN-6067	Cliente perdia a filial quando é incluído um pedido desse cliente sem a filial. SOLUÇÃO Feito tratamento para apenas atualizar a filial quando for passada uma filial válida no pedido.
MILLEN-6085	A integração estava sobrescrevendo a configuração realizada pelo cliente diretamente na plataforma SOLUÇÃO Adicionado parâmetro para permitir ao cliente configurar na integração o valor desejado para o campo indicado na pendência. OBSERVAÇÕES A API não permite a busca dessa informação para evitar a alteração, por esse motivo foi aberto um campo na vitrine para permitir a configuração
MILLEN-6089	Conforme mencionado pelo programador, o cenário só acontece no cliente pois na pasta WTS foram criadas extensões para a tela Menu/Financeiro/Pagar/Títulos. Extensões: millenium!dicorpo.wts millenium!TP.wts Problema está na select do método MILLENIUM!TP.TITULOS_PAGAR.CONSULTA_PAGAR/PAGOS, onde ele está utilizando um inner da IFORNECEDORES com a LANCAMENTOS, onde esses lançamentos não tem preenchido o campo gerador_origem na tabela lançamentos. Essas extensões não foram criadas pela millennium, a manutenção delas deverá ser feita pelo analista/responsável que as criou. Realizado o teste renomeando os wts com problema e foi retornado normalmente.
MILLEN-6090	O comportamento descrito foi resolvido, conforme evidência no Jira
MILLEN-6095	O ponteiro do record estava sendo alterado deixando a integração em loop. SOLUÇÃO Corrigido ponteiro do record após sua alteração.
MILLEN-6100	Sistema estava entrando em loop no momento da abertura do caixa quando não existia um último caixa aberto. SOLUÇÃO Efetuada tratativa para que quando não houver um último caixa aberto, o sistema faça a abertura do primeiro caixa com a data da venda.
MILLEN-6117	Conforme informado pelo programador. O problema ocorria quando o id de novas movimentacao_itens coincidiam com os ids dos registros da tabela MOVIMENTACAO_ITEM_IMPOSTO.MOVIMENTACAO_ITEM que deveriam ter sido apagados, deixando os itens das movimentações com informações dos impostos duplicadas, o xml era gerado com o mesmo item duplicado, mudando somente a alíquota do ICMS e a duplicação afetava o Millennium.
MILLEN-6171	O campo recurso é pertinente apenas ao exportadorEZzcore, sendo assim foi realizada uma tratativa na integração para validar este campo apenas neste caso, evitando cadastro equivocado.

5.85_22

Pendência	Resolução
MILLEN-7692	CAUSA/MOTIVO Não Conseguia copiar ou recortar imagens. SOLUÇÃO Ajustado para validar o tipo TSynPicture além dos tipos pré-existentes na lib mediaman.
MILLEN-8517	CAUSA/MOTIVO O código do valor, para o estado de Alagoas, está sendo validado errado na SEFAZ. Em caso de Fundo de Combate a Pobreza o valor principal deve ter o valor 12 e nos outros casos valor 11. SOLUÇÃO Foi adicionada uma exceção para tratar do caso do estado de Alagoas.
MILLEN-9007	SOLUÇÃO Foi verificado que o cliente possui dois tipos de pagamentos cadastrados para o mapeamento do tipo "master" que está vinculado ao pedido, sendo que um dos tipos cadastrados já estava com a data de validade vencida. Quando era realizada a consulta do tipo de pagamento na procedure de inclusão do pedido estava retornando também o tipo de pagamento que já estava vencido causando o erro da pendência. Foi feita a correção para considerar também a data de validade do cadastro de tipo de pagamento na consulta.
MILLEN-9959	CAUSA/MOTIVO Skus ainda não criados da plataforma estavam sendo redirecionados para publicação de estoque seguinte em cada fluxo de estoque, provocando uma lentidão no carregamento de dados de estoque e consequentemente no envio do estoque para plataforma. SOLUÇÃO Alterado o processo para que o sku seja redirecionado para o estoque dentro do fluxo de envio de produtos quando a informação de data de envio é colocada no sku pela primeira vez.

5.85_25

Pendência	Resolução
MILLEN-9384	CAUSA/MOTIVO Solicitava para informar peso em quebra. SOLUÇÃO Ajustado para quando não tiver produto então não validar peso.
MILLEN-10773	CAUSA/MOTIVO Devido a nova situação no arquivo Json referente ao Ajuste do tipo 8, que foi incluído neste, ocorreu o erro por não estar implementado no importaLancamentos, quando o pagamento for vale. SOLUÇÃO Para a solução desta pendência foram implementadas uma validação quando o valortotal for diferente de zero e uma varredura no arquivo Json para buscar o valor do ajuste do tipo 8.

5.85_27

Pendência

Resolução

MILLEN-10873

CAUSA/MOTIVO
Lentidão ao publicar produto, foi desenvolvida uma tela para outro cliente que permite fazer a publicação pontual de um produto na plataforma VTEX, verificamos no log que ocorreu a lentidão no mesmo ponto.
SOLUÇÃO
Foi realizado um ajuste no processo de publicação das especificações do SKU. Esse ajuste faz uma correção na forma de manipular as informações de uma select e também foi implementada uma melhoria na consulta das especificações do SKU na VTEX , verificando se já possui o valor da especificação na VTEX.

Atalhos

Árvore de páginas