Você está vendo a versão antiga da página. Ver a versão atual.

Comparar com o atual Ver Histórico da Página

« Anterior Versão 4 Atual »

5.103


PendênciaResolução
MILLEN-21067

CAUSA/MOTIVO Algumas notas fiscais não geram e-mail.

SOLUÇÃO Adicionamos tratamento forçando o tipo de campo VARCHAR(500), no select de retorno das informações da nota, fazendo para todas as utilizações do campo desta unit.

MILLEN-25176CAUSA/MOTIVO
No layout de ficha técnica, na grade do produto em quantidade de consumo do componente, o tamanho da grade fica desalinhado com o a quantidade uso da matéria prima.
Quando utilizado um campo "memo" dentro de uma macro #PIVOT, a rotina força que todas as informações fiquem na mesma linha.
Assim quando a rotina CalcTitSizes, tenta calcular "todos" os campos para predefinir um tamanho da grid, é ignorado os caracteres de enter (#13#10)
Ou seja: um campo que seria teste#13#10teste, com um total de 12 caracteres no calculo passa a ser 2

SOLUÇÃO
Criada uma nova macro: :FL (force in Line), para ser utilizada dentro da macro #Pivot, assim será feito um replace nos campos trocando os enter por 'esp|esp' (' ')
Para utilizar deve ser declarada dentro do #Pivot, e apos o campo a macro :FL - #PIVOT(CAMPO:FL)
Ajustado na FICHA TECNICA PIT BULL.ETQ no #Pivot das medidas após a lavanderia colocando a macro :C nos campos MEDIDAS.TAMANHO e MEDIDAS.MEDIDA
MILLEN-26272CAUSA/MOTIVO
O Relatório estava duplicando os valores quando os títulos eram transferidos de conta.

SOLUÇÃO
Foi feita a correção no método millenium.MOVIMENTACAO.caixa_geral_detalhado.xml e os valores passaram a exibir corretamente conforme a consulta movimentação.
MILLEN-29055CAUSA/MOTIVO
Ajustadas algumas rotinas encontradas durante os testes.

SOLUÇÃO
Rotina não estava conseguindo remover a ficha técnica quando desmarcava a flag kit.
Quando a flag kit está marcada, a rotina não estava validando se os componentes foram informados.

OBSERVAÇÕES
Sobre o erro da tela html, que mesmo em nenhum componente, informa a mensagem: produto obrigatório, será aberta uma nova issue para tratativa.
MILLEN-30210CAUSA/MOTIVO
O sistema está permitindo a alteração de pedidos de compra, quando o usuário está configurado com acesso ao Consultar de Pedido de Compra e sem acesso ao Alterar Pedido de Compra.

SOLUÇÃO
Existia uma função (IsPedidoCompraSomenteLeitura) que verificava o acesso à alteração do pedido de compra, porém a mesma estava considerando sempre o parâmetro READONLY e o mesmo não estava definido.
Em versões mais antigas, a Consulta estava vinculada somente ao processo de alteração, porém foi realizada uma alteração, para as telas HTML para disponibilizar a consulta, independente do acesso à alteração estar configurado.
MILLEN-30356CAUSA/MOTIVO
Aba pedidos do Histórico de Cliente retornando dados divergentes com relação aos pedidos de vendas para o mesmo filtro.

SOLUÇÃO
O erro ocorre devido à rotina estar fazendo o inner join com representantes e o mesmo não é obrigatório no pedido de venda. Ajustada condição da consulta no millennium.mdu para montar a consulta com left join assim retorna os mesmos dados.
MILLEN-30713CAUSA/MOTIVO
O erro ocorria em uma validação quando o diretório de remessa do gateway estava vazio.

SOLUÇÃO
Retornada mensagem de erro quando a configuração do diretório (DIRETORIO_REMESSA_GRB) for vazio.

OBSERVAÇÕES
Identificada origem do problema, ocorre no método GeraRemessaBaixa da millenium.dll porque a consulta SQL abaixo retorna o
DIRETORIO_REMESSA_GRB vazio para o lançamento 222036. O Lançamento 222036 está vinculado a conta 302 - CP-02, e essa conta não tem cadastro de DIRETORIO_REMESSA_GRB

Obs: É possível simular o erro executando o método MILLENIUM.LANCAMENTOS.EV_GERAR_REMESSA_BAIXA manualmente
 
SELECT C.DIRETORIO_REMESSA_GRB , C.NUMERO
FROM LANCAMENTOS L
INNER JOIN CONTAS C ON C.CONTA = L.CONTA_COBRANCA
WHERE ( L.LANCAMENTO IN (222036) )

 Existia uma validação desse diretório que não previa o valor vazio.
MILLEN-30731

CAUSA/MOTIVO
Sistema considerava o valor mínimo no agrupamento de valor de ICMS ao invés da soma dos valores

SOLUÇÃO
Corrigido método para apresentar a soma dos valores

MILLEN-31152CAUSA Algumas notas fiscais não geram e-mail SOLUÇÃO Adicionamos tratamento forçando o tipo de campo VARCHAR(500), no select de retorno das informações da nota, fazendo para todas as utilizações do campo desta unit.
MILLEN-31304CAUSA/MOTIVO
Por se tratar de uma entrada, o sistema está abatendo o valor do ICMS da base de pis/cofins, utilizando a alíquota do transportador e não a do destinatário.

SOLUÇÃO
Alterado para utilizar a alíquota do ICMS de saída para o destinatário.
MILLEN-31565CAUSA/MOTIVO
O comportamento do sistema não está correto. Um título pode ter sido emitido hoje e o pagamento ocorrer somente em um próximo mês.
Portanto, a contabilização da baixa deve ocorrer no momento da baixa em um período que esteja em aberto.

SOLUÇÃO
Ajustada a trava para lançamentos, permitindo que o processo seja concluído quando a data de pagamento não superar a data de fechamento. 
MILLEN-31638CAUSA/MOTIVO
Rotina estava calculando o percentual incorretamente, estava sendo calculado apenas a primeira linha.

SOLUÇÃO
Colocado o trecho que calcula o percentual dentro do loop e também tratado para que o kit = "K" seja tratado como um produto único, já que o mesmo é tratado sem componentes no pedido de venda e prefaturamento e apenas na conferência são carregados os componentes.
MILLEN-31874CAUSA/MOTIVO
Registros com valores duplicados e falta de itens da produtos_eventos em alguns lançamentos (NF).

SOLUÇÃO
Correção no método millenium.impostos.impostos_rel, para desconsiderar lançamentos de já inclusos no select da NormalIsento.
MILLEN-31942CAUSA/MOTIVO
NF complementar de frete com valores faltantes ao enviar para DOME - 5.102.3.

SOLUÇÃO
Correção no método NOTAS_FISCAIS.Listar, ajuste na função que retorna a situação da NF e ajuste no retorno de mensagem de erro da função HttpPOSTService.
MILLEN-32010MOTIVO
O PDV Omni não suportava a leitura da quantidade ao bipar um código de barras.

SOLUÇÃO
Adicionada leitura da quantidade ao bipar um código de barras.
MILLEN-32036CAUSA/MOTIVO
Valor de IPI não tributado não está sendo enviado ao DOME - 5.102.3.

SOLUÇÃO
Alterado para passar o valor do V_IPI_NC para o campo valorIPINaoTributado.
MILLEN-32242

CAUSA/MOTIVO
Sistema apresentava lentidão na consulta de ordens de produção por evento para determinados fornecedores devido à grande quantidade de movimentações para esses fornecedores.


SOLUÇÃO
Criado índice na tabela SITUACAO_OFICNA e otimizada a consulta realizada através método para evitar repetições em subconsultas.

MILLEN-32248CAUSA/MOTIVO
Não foi identificado erro na aplicação.

A koncilia implementou limites para as requisições (RATE LIMIT) e por isso o millennium estava sempre recebendo o erro 429;

POST - Enviar
90 requisições/minuto. Este limite é controlado por token de integração.

GET - Consultar
30 requisições/minuto. Este limite é controlado por token de integração.

GET - Consultar - orderextract/unresolved
6 requisições/minuto. Este limite é controlado por token de integração.

SOLUÇÃO
Criado ajuste para que o millennium trate algumas rotinas para evitar receber o erro:

Pedido de venda - Enviar - MILLENIUM!KONCILIA.PEDIDO_VENDA.ENVIAR
Pedido de venda - Cancelar - MILLENIUM!KONCILIA.PEDIDO_VENDA.Cancelar

Colocado um top 90 na consulta de pedidos pendentes para que não estoure o limite máximo do put (90)
Por usar um top, foi criada uma tabela para receber os pedidos com erros e colocar uma data de reprocessamento para 4hrs, para que assim os próximos pedidos possam ser enviados.
Caso a rotina utilize o GET, quando o pedido é enviado pela plataforma, o limite é de 30 pedidos por minutos.
Também tratamos para caso atinja rate limit, a rotina encerre para evitar o "bloqueio".
Tela de consulta: Financeiro\Receber\Integrações\Conciliação Marketplace\Baixa de Títulos

Caso não seja informado nada nos filtros (Apenas data) a rotina executa a chamada: /externalapi/orderextract/unresolveds, essa rotina aceita apenas 6 requisições por minutos, ou seja, caso retorne mais de 6 páginas, ocorre o erro do bloqueio
Adicionada tratativa para caso tome erro, mas caso exista algum retorno anterior, seja apresentado o resultado para o operador.
ex.: retornou 7 páginas, e na página 4 ocorreu erro 429, a rotina irá mostrar o resultado da página 1,2 e 3 e irá logar o erro 429 no trace;
Botão baixar

Foi colocada uma validação para caso tenha mais de 60 pedidos selecionados, ser utilizado um sleep de 1,5 seg, para que não ocorra a mensagem de bloqueio;
Foi identificado que a rotina que estava sendo usado para baixa foi descontinuada pela koncili: orderextract/resolve/
Unknown macro: {id}
Ajustamos para a rotina indicada no manual: /orderextract/resolve/batch
MILLEN-32370

CAUSA/MOTIVO
Sistema foi preparado através da pendência MILLEN-25166 para atender a várias formas de cálculo definidas para cada uma das Unidades da Federação. No entanto não foi prevista a condição para as Situações Tributárias que não destacam ICMS mas onde há a cobrança do ICMS-ST. (CST 30 e CSOSN 202).


SOLUÇÃO
Corrigido código fonte para considerar o índice de ICMS-ST nos cálculos de ST, nos cálculos da pendência MILLEN-25166 e também para os casos pré-existentes.

MILLEN-32405CAUSA/MOTIVO
Falha na validação da função checkDiscount.

SOLUÇÃO
Correção na validação da função checkDiscount e ajuste chamada do forEach.
MILLEN-32406

CAUSA/MOTIVO
Envio de CFOP no cabeçalho da nota.


SOLUÇÃO
Incluída parametrização nas configurações adicionais da vitrine, para que o usuário marque se quer ou não enviar a CFOP quando enviado o faturado para o linxio.

MILLEN-32446

CAUSA/MOTIVO
Erro de access violation na publicação de produtos.


SOLUÇÃO
Adicionado alguns controles para refazer o cache de produtos caso de algum erro.

MILLEN-32513CAUSA/MOTIVO
Erro na validação do arquivo Pagfor Banco do Brasil.

SOLUÇÃO
Alterado FLA PGFBB1-XX_REM Registro J52 Detalhe, campo de SEQ para SEQ2

PGFBB1-XX_REM.FLA
Alterações Classe TProc_001.GetVal
Incluído o registro J52
Alterado campo REGISTRO para quando modalidade = 31, acrescentar 2 ao contador de registros.
Alterado campo COD_EMPRESA, tamanho de 13 para 9.
MILLEN-32534CAUSA/MOTIVO
Melhorias no controle da paginação de produtos.

SOLUÇÃO
Se Publicar auto ligado e quantidade  = 0 . Ligar paginação com 30;
Na publicação se o "publicar auto" estiver desligado não paginar;
Ocultar flag de paginação;
Não validar flag de paginação ao desligar o publica auto.
MILLEN-32573

CAUSA/MOTIVO
PlugBoleto erro processar arquivo retorno banco do brasil não localiza títulos.

SOLUÇÃO
Removida mensagem de bloqueio quando não tinha título retornado conciliado da Tecnospeed. Agora é possível realizar baixas também de títulos não conciliados (sem ID_INTEGRACAO_GRB). Somente será baixados títulos não conciliados com CodigoMovimento = 06 e houver valor maior do que zero.

MILLEN-32603CAUSA/MOTIVO
Notas Fiscais de Serviço Eletrônica, enviadas pelo processo convencional (TecnoSpeed) estão ficando com status "Aguardando Protocolo", não sendo possível receber o protocolo das mesmas.

SOLUÇÃO
Regressão causada pela MILLEN-30980: as NFS-es não estavam sendo enviadas pelo processo tradicional.
Foi corrigido o default do parâmetro BLOQUEIA_ENVIO_NFSE_RPS no método MILLENIUM.MOVIMENTACAO.Executa.
Para solucionar nos clientes que foram atualizados na versões 5.100.17, 5.101.11, 5.102.5, 5.98.2.B4A.10 e posteriores, seguir passos a seguir:

1) Abrir a millenium.wts, disponível em c:\wts\files\apps, localizando o método MILLENIUM.MOVIMENTACAO.Executa:
2) Alterar o default do parâmetro BLOQUEIA_ENVIO_NFSE_RPS para 0 e salvar a biblioteca millenium.wts:
3) Rodar o mkupd.exe para disponibilizar a atualização nos diretórios de instalação
4) A biblioteca millenium.wts deve ser atualizada em C:\millenium e C:\wts
A partir desse momento, as notas passarão a ser enviadas normalmente.
Necessário efetivar novamente as movimentações que estiverem com as NFS-es com situação "Aguardando Protocolo" (Status = nulo).
A situação correta é "NFSe Aguardando Protocolo" (Status = -80).
MILLEN-32622CAUSA/MOTIVO
Durante o processo de autorização de NFe, no ambiente de homologação da DHL, observou-se que os dados de protocolo não foram registrados na nota, somente os dados de autorização: a nota é atualizada para status "100 - Autorizado o uso da NF-e", mas os campos de protocolo e data não são atualizados.
Mesmo problema ocorreu na pendência MILLEN-29417 e MILLEN-30543: para essas MILLENs a correção foi no campo MENSAGEMNFE.
Agora o problema estava sendo ocasionado pelo campo CERTIFICATENAME.

A semelhança do campo MENSAGEMNFE, o campo CERTIFICATENAME está tipificado como BLOB SUB_TYPE TEXT (no dicionário de dados como String de 500 caracteres) e, ao tentar acessar o mesmo com o comando "GetFieldAsString", gera a exceção "Error trying to read a field value (index=15,command=)".
Conversando com Joel José De Andrade, o mesmo disse que esse erro já ocorre há algum tempo e que já suspeitava que o campo CERTIFICATENAME teria relação com o problema.

Observação: simulando o erro, em tempo de desenvolvimento, verificamos que o problema ocorria quando existia mais de uma nota para ser protocolada e o erro era disparado quando a segunda nota era processada no método MILLENIUM_NFE.NFE.RECEBEPROTOCOLO.

Ocorrido o erro, as informações de autorização e protocolo não eram atualizadas no registro da tabela NF.
O status e mensagem são atualizados, posteriormente, via scheduler, ao chamar novamente o método millenium_nfe.NFE.RecebeProtocolo: quando o sistema encontra o XML no diretório "C:\wts\XmlDestinatario" e identifica que a nota já foi autorizada, atualiza o status e a mensagem da nota.
Por esse motivo é que apenas esses dois campos foram atualizados.

SOLUÇÃO
Em análise do arquivo de log fornecido, foi identificado, novamente, que o processo "pRecebeProtocolo : Select Status NULL or 204 (ini)" era iniciado, porém não finalizado com "pRecebeProtocolo : Select Status NULL or 204 (fim)", para a nota 1593.
wtsbroker_231009_11.txt wtsbrokerNFE_231009_11.txt

Analisando o log do broker, foi possível observar o erro "Error trying to read a field value (index=15,command=)" no método millenium_nfe.nfe.RecebeProtocolo:

À semelhança da MILLEN-29417 e MILLEN-30543, adicionamos tratamento forçando o tipo de campo VARCHAR(500), no select de retorno das informações da nota, fazendo para todas as utilizações do campo desta unit.
MILLEN-32674

CAUSA/MOTIVO
Faturamento de pedido retirado em loja (PICKUP).

SOLUÇÃO
Adicionado implementação para que seja possível faturar um pedido com retirada em loja.

MILLEN-32675

CAUSA/MOTIVO
Foi verificado que não era erro mas sim o modo de utilização adotado pelo cliente.

SOLUÇÃO
Correção na integração para considerar o campo Políticas comerciais na lista de Campos não atualizáveis que não tinha.

MILLEN-32677

CAUSA/MOTIVO
Erro na publicação de preços.

SOLUÇÃO
Ao enviar os preços das lojas estava enviando as datas de validade do "preço por" sem ter preço promocional. Adicionada lógica para enviar o "preço por" juntamente com as datas de validade quando o cliente tiver alguma promoção cadastrada.

MILLEN-32756

CAUSA/MOTIVO
Sistema gerava NF de transferência com diferença entre o preço aplicado no item e o total apresentado para a NF, causando rejeição pela Sefaz.
Essa diferença era motivada por uma situação aparentemente imprevista na ADR MILLEN-23884.

SOLUÇÃO
Corrigido código fonte para não recalcular o campo PRECO_APLICADO nesses casos. O recálculo desse campo já é ignorado há muito tempo para o parâmetro "Desconto Avançado" (aba "Preços e Descontos" do cadastro de Eventos).

MILLEN-32761

CAUSA/MOTIVO
O erro ocorria pois o cliente utiliza a configuração de desagrupa cores juntamente com grade única e no envio da publicação do estoque para a integração JET estava considerando o ID do SKU de forma errada.

SOLUÇÃO
Correção no envio do estoque para verificar se a opção de desagrupa cores está marcada e se possuir grade única então considerar o ID_EXTERNO corretamente.

MILLEN-32798

CAUSA/MOTIVO
Sistema somente previa a utilização de CSTs com informação completa das tags de ICMS (CST 00, por exemplo), devido a uma parte do código q zerava essas tags.

SOLUÇÃO
Corrigido código para somente zerar as tags de CST se forem informadas.

MILLEN-32840CAUSA/MOTIVO
Quanto utilizado algum parâmetros para que o cliente não entre nos filtros do usuário, não é respeitado e o filtro é aplicado.

SOLUÇÃO
Na conversão de tela para o htmls, passou a usar a tabela ICLIENTES, a rotina do gerenciado de usuários, estava aplicando as validações apenas na tabela CLIENTE, passado também a tabela ICLIENTES, para não quebrar códigos legados.
MILLEN-36804CAUSA/MOTIVO
Erro ao enviar partidas com muitos geradores (parceiros) - 5.102.3.
Solicitada alteração da quantidade de registros de 5000 para 100 por lote, pois a transação passou a ser síncrona.

SOLUÇÃO
Alterado para enviar lotes de 100 registros por vez.


5.103.8


PendênciaResolução
MILLEN-39390CAUSA/MOTIVO
Valores apresentados com mais de duas casas decimais na grid do pagfor.

SOLUÇÃO
Ajustado a quantidade de casas decimais.


5.103.10


PendênciaResolução
MILLEN-41251Corrigido na millen-41035


5.103.11


PendênciaResolução
MILLEN-39211CAUSA/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-39890CAUSA/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-40110CAUSA/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-40226CAUSA/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-40304CAUSA/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 millennium, porém com status=100, e tentar efetuar o cancelamento na SEFAZ.
MILLEN-40692CAUSA/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-40697CAUSA/MOTIVO
A situação descrita na pendência, de fato, NÃO ocorre. Como podemos ver na imagem abaixo, ainda havia saldo de empenho a baixar:
colocar imagem aqui
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:
 colocar imagem aqui
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-40728CAUSA/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-40747CAUSA/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-40912CAUSA/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-40928CAUSA/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-41021CAUSA/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-41022CAUSA/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-41035CAUSA/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-41133CAUSA/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-41146CAUSA/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-41218CAUSA/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-41251Corrigido na millen-41035
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-41528CAUSA/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-41589CAUSA/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-41615Pendê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-41705CAUSA/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-41759Corrigido 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-41893CAUSA/MOTIVO
Validação N > 0 espera valor INTEIRO.

SOLUÇÃO
Convertida a soma dos campos para inteiro.


5.103.12


PendênciaResolução
MILLEN-41893CAUSA/MOTIVO
Validação N > 0 espera valor INTEIRO.

SOLUÇÃO
Convertida a soma dos campos para inteiro.


5.103.13


PendênciaResolução
MILLEN-22893CAUSA/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-25921SITUAÇÃ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-26602CAUSA/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-30648CAUSA/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-34226CAUSA
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 permitir 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-38421CAUSA
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-38998CAUSA/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-39608CAUSA/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-40496CAUSA/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-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-40845CAUSA/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-40949Erro não ocorre mais.
Foi corrigido na MILLEN-43053.
MILLEN-41119CAUSA/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-41442CAUSA/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-41563CAUSA/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-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-41901CAUSA/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-41907CAUSA/MOTIVO
Enviar id_externo da categoria.

SOLUÇÃO
Caso tenha ID_EXTERNO na categoria, será enviado no lugar da VITRINE_CLASSIFICACAO.
MILLEN-41952CAUSA/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-42071Corrigido na millen-43020
MILLEN-42153CAUSA/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-42157CAUSA/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-42178CAUSA/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-42196CAUSA/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 já 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-42222CAUSA/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-42257CAUSA/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-42260CAUSA/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-42353CAUSA/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-42361MOTIVO
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-42373CAUSA/MOTIVO
Não aparece cadastro de endereço.

SOLUÇÃO
Realizado ajustado para aparecer o cadastro de endereço.
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 issue 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-42428CAUSA/MOTIVO
Caracteres inválidos para formatação do json.

SOLUÇÃO
Adicionar tratamento scapeJson para tratar caracteres inválidos.
MILLEN-42491CAUSA/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-42497CAUSA/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-42540CAUSA/MOTIVO
NossoNumero maior que o maxInt.

SOLUÇÃO
Utilizar o VALUE_STRING ao consultar/salvar o nossoNumero.
MILLEN-42577CAUSA/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-42599CAUSA/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-42613CAUSA/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-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-42656CAUSA/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-42660CAUSA
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-42663CAUSA/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-42671Erro já corrigido na millen-41901
MILLEN-42700CAUSA/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-42775CAUSA/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-42826CAUSA/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-42827CAUSA/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-42865CAUSA/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-42894CAUSA/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-42895CAUSA/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-42965CAUSA/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-42991CAUSA/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-43042CAUSA/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-43073Já corrigido na millen-41886
MILLEN-43347CAUSA/MOTIVO
Erro ao importar a Classif Fiscal está ocorrendo o erro out of memory.

SOLUÇÃO
Ajustado o código para filtrar cada classif fiscal antes de loopar.


5.103.14


PendênciaResolução
MILLEN-39486CAUSA/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-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-42431CAUSA/MOTIVO
O processo de envio de e-mail por conta do Scheduler 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-42624CAUSA/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-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-43072CAUSA/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-43202CAUSA/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-43231CAUSA/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-43339CAUSA/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-43498MOTIVO
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.103.15


PendênciaResolução
MILLEN-31710CAUSA/MOTIVO
O processo estava pegando os valores da consulta para atualizar, em vez de pegar da tela de alteração.

SOLUÇÃO
Alterado para pegar as informações atualizadas na tela para salvar.

OBSERVAÇÕES
Após a correção, a atualização ocorreu corretamente.
MILLEN-37410CAUSA/MOTIVO
Rotina de faturamento, estava alterando o pedido, colocando o lote que foi utilizado na saída, assim caso o cliente faça um processo parcial ou tente colocar mais de um lote, ocorre erro de falta de saldo no pedido, caso seja outro lote.

SOLUÇÃO
Tratado para não consumir do pedido, caso o pedido não tenha lote ou os lotes não sejam iguais. Ou seja, o faturamento irá ocorrer, mas não terá alteração/consumo no pedido. Todo o processo de Alteração/consumo de Lote/Item, deve ocorrer pelo préfaturamento.
MILLEN-37502CAUSA/MOTIVO
Ao realizar a cópia de um pedido de venda, os itens não estavam sendo exibidos. O problema estava no método "MILLENIUM.PEDIDO_VENDA.Consulta_Itens", ao carregar os itens, a condição estava sendo impactada por uma alteração feita para a MILLEN-33417.

SOLUÇÃO
Foi necessário utilizar a macro #NULL_TO_Z para evitar que o campo "quantidadenc" ficasse com o valor nulo, durante a soma para comparação.
MILLEN-41355CAUSA/MOTIVO
Quebra de Teste na MILLEN-44188.

SOLUÇÃO
Foi Feita uma nova forma de correção desta ISSUE que não deve ocasionar a Quebra da ISSUE mencionada.
Refazer o teste do cenário desta ISSUE e rodar o teste da MILLEN-44188.
MILLEN-42194CAUSA/MOTIVO
Sistema não identificava o pedido de compra quando selecionado o link "Copiar Produtos", em uma movimentação.
SOLUÇÃO
Modificado código fonte, para identificar e expor informações de Pedidos de Compra, nos casos de movimentação com Fornecedor.
MILLEN-42321CAUSA/MOTIVO
Vendas - Resumo do pedido na filial de reserva dos itens contidos no pedido - 5.104.6
Sistema não carregava os totais dos itens reservados, estoques disponíveis e próximos recebimentos.

SOLUÇÃO
Alterado o arquivo MDD incluindo o atributo produto.produto.produto na dash.table pai e alterada a dash.table Estoques Disponíveis o item move.quantidade_atual
Revertida a alteração efetuada MILLEN-35486, conforme solicitado pelo desenvolvedor, onde enviava sempre a condição pai para todos os selects subsequentes, ignorando as condições de cada item.
MILLEN-42533CAUSA/MOTIVO
O sistema não estava considerando a célula selecionada, ao executar o andamento por código de barras por pacote. O problema ocorria na classe "TfrmAndamento.DesmembraLote", que ao validar a célula, ela não estava sendo encontrada, pois as checagens se baseavam na variável quando era alimentada por outras rotinas e processos (e não o andamento por código de barras por pacote). As alterações feitas na MILLEN-23586 mudaram a forma como o sistema validava todas as rotinas (feito em MILLEN-18552), o que acabou por desconsiderar algumas.

SOLUÇÃO
Feito ajuste no método "TfrmAndamento.DesmembraLote", para o sistema considerar a célula selecionada no andamento por código de barras por pacote.
MILLEN-42568CAUSA/MOTIVO
Fórmula TOTAL_LIQUIDO do movimento.mdo está descontando 2x os brindes.
SOLUÇÃO
Existe um subselect nesta fórmula para pegar os totais do produtos na tabela produtos__eventos, mas este subselect não estava filtrando o que era brinde e bonificado. Realizado ajuste para correção.
MILLEN-42659CAUSA/MOTIVO
O initRow da função Assistente_Lote_e não inicializava alguns campos e na ImportXML o sistema estava zerando os valores já distribuídos para os produtos da movimentação. Também existiam falhas ao desassociar e associar novamente os itens.

SOLUÇÃO
Inicialização de campo/colunas na initRow e validação para não zerar os valores da movimentação caso já tenham sido distribuídos. Além de correções ao desassociar e associar novamente os produtos.

OBSERVAÇÕES
Foram corrigidos 4 erros nessa pendência:
Primeiro erro: Valores exibidos nos campos de código do fornecedor, Cfop e desconto para todos os itens.Esse erro foi corrigido a partir das versões 103.14, 104.10 e MASTER-5(105) na Eventos.dll.

Segundo erro citado após importação do XML em relação a mensagem do código da Situação Tributária, ela ocorre devido à configuração da origem do produto no cadastro.
No XML disponibilizado há uma movimentação interna, emitente e destinatário de dentro do Brasil, para um produto com importação direta (Origem 1).
Como se trata de uma movimentação interna (dentro do Brasil) de um produto importado, não pode se usada a Origem 1, pois ela indica que o produto está sendo importado diretamente. Nesse caso deve ser usada a origem 2 que indica ser um produto importado mas adquirido no mercado interno.

O terceiro e quarto erro ocorriam ao desassociar e associar novamente os produtos. Ao remover a associação, o sistema não limpava os itens relacionados e ao fazer novamente a associação o sistema não rateava o valor entre os itens relacionados.
MILLEN-42971CAUSA/MOTIVO
Sistema não calculava o desconto digitado pelo usuário no campo 'desconto' localizado na barra de totais de uma movimentação, devido às correções implementadas a partir das pendências MILLEN-24188 (soma no percentual de descontos está errado) e MILLEN-24427 (Atualizar field Acerto ao atualizar os totais).
SOLUÇÃO
Modificado código fonte para efetuar o cálculo nas duas opções disponibilizadas através do parâmetro 'Tipos Desconto' e, também, para efetuar o cálculo ao sair do campo 'desconto'.

OBSERVAÇÕES
No cadastro de Eventos, o Tipo de Desconto possui duas opções : 'Desconto sobre Desconto' e 'Desconto Simples (soma)'.
O Evento indicado utiliza o 'Desconto Simples' (configuração no cadastro de Eventos).
O problema reclamado na pendência ocorre somente para o 'Desconto Simples' quando digitado no campo 'Desconto'.
Caso não queira aguardar a atualização da versão, o usuário (responsável TI da empresa) pode :
1- abrir a lupa de 'Desconto' e digitar o valor no grid apresentado para descontos;
2- modificar o evento para utilizar o 'Desconto sobre Desconto'.
MILLEN-43006CAUSA/MOTIVO
e-Millenium não valida limites ECF em eventos de NFC-e.

SOLUÇÃO
Validação do limite por CPF e limite total ao iniciar a finalização de um evento de NFC-e.
MILLEN-43009CAUSA/MOTIVO
Não foi possível validar um caso de embarque concluído sem que o pedido existisse na Intelipost, no caso do cenário o embarque está devidamente concluído e os pedidos existem na Intelipost, contudo, verificou-se que os status dos registros não estão atualizados como concluídos na tabela embarque_itens embora esteja na tabela embarque.

SOLUÇÃO
Para melhorar a possibilidade de interceptar o erro, ajustamos a chamada do método para que seja gravado o log de erro em um arquivo separado denominado wtsBrokerIntelipostError visto que a reciclagem do arquivo acontece de acordo com o tamanho do mesmo, conforme configuração do broker especificada no wtsconfig, erros gravados em um arquivo separado reduzem o seu tamanho diminuindo a probabilidade de ser reciclado.
MILLEN-43153

CAUSA/MOTIVO
Erro na construção da trigger da tabela ipreco, nos campos com uso de expressões complexas como "CAST" e ou subselect: o validador adicionado nas trigger das views materializadas, não estava deixando que a alteração feita em alguns campos, que estão no contexto da materializada, fossem propagadas para a tabela "PRECO_TOTAL", desencadeando uma falha no método millenium_eco.produtos.precodetabela que ao listar dados paginando, acabava retornando um output um trans_id menor do que o envido no input.

SOLUÇÃO
ajustado view preco_total e preco_validade.

MILLEN-43414CAUSA/MOTIVO
Ao realizar o retorno da oficina, o evento está carregando o campo LOTE. Quando a OP é finalizada o sistema está gravando o lote para o produto, mesmo o produto definido para não utilizar lote.

SOLUÇÃO
Foi necessário ajustar a query do método "ProdutosRetorno". O sistema carregará o lote no evento de retorno, apenas para os produtos que estiverem definidos para utilizar lote. Produtos que não têm essa permissão, não carregarão o lote no evento e consequentemente o lote não será gravado para ele.
MILLEN-43481CAUSA/MOTIVO
Dentro da configuração existe um campo chamado DATA PARA TRANSFERENCIA, mesmo colocando a data no campo ao efetivar as configurações ficam em branco.

SOLUÇÃO
Ajustado para gravar o campo DATA PARA TRANSFERENCIA.
MILLEN-43491CAUSA/MOTIVO
Ao verificarmos se o campo enquadramento_ipi é vazio, este se tratava de um Double, porém era verificado se o mesmo é igual a vazio.

SOLUÇÃO
 Para correção, passamos a função VarToStr para assim conseguirmos verificar se o campo é vazio.
MILLEN-43551CAUSA/MOTIVO
Ao realizar a cópia de um pedido de venda, os itens não estavam sendo exibidos. O problema estava no método "MILLENIUM.PEDIDO_VENDA.Consulta_Itens", ao carregar os itens, a condição estava sendo impactada por uma alteração feita para a MILLEN-33417.

SOLUÇÃO
Foi necessário utilizar a macro #NULL_TO_Z para evitar que o campo "quantidadenc" ficasse com o valor nulo durante a soma para comparação.
MILLEN-43569CAUSA/MOTIVO
O valor vinha cheio, contando os centavos como reais.
Não estava fazendo o cálculo de divisão por 100, necessário ao banco Bradesco.

SOLUÇÃO
Regressada a divisão por 100 no campo valor no leiaute utilizado pelo Bradesco.
MILLEN-43571CAUSA/MOTIVO:
Valor da conta do lançamento não encontrada fazendo com que o sistema não identificasse a filial.

SOLUÇÃO
Posicionado o ponteiro no primeiro registro antes de obter o valor da conta do lançamentos.
MILLEN-43637CAUSA/MOTIVO
B4A - NF-e Status 307 Denegação: Emitente bloqueado pela UF de destino, em operação com consumidor final.

SOLUÇÃO
Inseridos novos códigos de denegação.
MILLEN-43653CAUSA/MOTIVO
Sistema apresenta lentidão ao bipar os produtos no andamento de produção por código de barras. Situação ocorre pelo fato do método "TProdInfo.SetCodProduto" estar sendo executado diversas vezes sem necessidade, uma vez que o código procurado, não será retornado pelos métodos de busca internos da rotina.

SOLUÇÃO
Foi necessário realizar uma checagem se o produto em questão está disponível para ser carregado. Se sim, ele passará pela rotina do método, senão, o método não será executado. Otimizado também o método "MILLENIUM.PRODUTOS.DADOSPARAMOVIMENTACAO", pois havia uma junção desnecessária, que estava tomando alguns segundos de processamento.
MILLEN-43654CAUSA/MOTIVO
Sistema estava fazendo o count geral de todos os registros presentes no estoque, não estava sendo feito o agrupamento necessário para contar apenas os que tivessem saldo positivo.

SOLUÇÃO
Ajustado o agrupamento para produto\cor\estampa\tamanho permitindo que a contagem seja feita adequadamente.
MILLEN-43729CAUSA/MOTIVO
O sistema não estava conseguindo fazer a montagem do recordset com as informações da filial devido à extensão não estar devidamente configurada.
Os métodos acima listados não estavam marcados como extensão e nem apontado a trigger de ação.

SOLUÇÃO
Ajustados os métodos conforme estrutura de extensão do e-Millennium.
MILLEN-43759CAUSA/MOTIVO
O problema estava relacionado ao "MILLENIUM.PRODUCAO.PRODUTOS_PREFASE". Na MILLEN-5328 foi adicionado um join com a tabela "SITUACAO_PRODUCAO", para considerar o filtro de FASE para os produtos. No entanto, não foi considerado que alguns pontos que chamam o método, podem não passar a FASE. Quando não há FASE , não há necessidade de fazer o join com essa tabela, pois nesse bloco da consulta, estamos apenas checando os dados originais do produto.

SOLUÇÃO
Realizado tratamento para considerar o join com a tabela SITUACAO_PRODUCAO apenas quando houver FASE (funcionando da forma que era antes da MILLEN-5328).
MILLEN-43765CAUSA/MOTIVO
O Sistema não conseguiu finalizar a conferência do pré-faturamento devido à maneira como estava sendo selecionado o id do pré-faturamento, no caso da finalização não temos mais o id da coluna com o número do pré-faturamento.

SOLUÇÃO
Passamos a buscá-lo de dentro do método que consulta os produtos para o pré-faturamento.
MILLEN-43788CAUSA/MOTIVO
Ao enviar estoque das variações, quando o produto não tem peças, enviamos o valor "-1" para o Linxio.

SOLUÇÃO
Tratamento para não enviar valor negativo.
MILLEN-43829CAUSA/MOTIVO
Sistema estava entrando em uma rotina de atualização da prodfis, que não estava encontrando os campos GRADE e COD_PROD_FORNECEDOR no recordset MILLENIUM.PREFATURAMENTOS.PRODUTOS

SOLUÇÃO
Ajustada a procedure IncluiProduto da prodfis para verificar se os campos existem no recordset, antes de preencher.
MILLEN-43861CAUSA
Problema estava no SUBSELECT que ligava o COD_OPERACAO da tabela VOLUMES com a PREFATURAMENTOS.PREFATURAMENTO, no entanto a tabela PREFATURAMENTOS está na consulta principal, e o campo PREFATURAMENTOS.PREFATURAMENTO não está no GROUP BY.

SOLUÇÃO
Erro já corrigido através da pendência MILLEN-3803, apenas passado a correção para versão do cliente.

O campo PREFATURAMENTO que está no GROUP BY da consulta principal é o da tabela PRODUTO_PREFAT, portanto, na subselect foi ligada a PRODUTO_PREFAT.PREFATURAMENTO.

OBSERVAÇÕES
Erro ocorre somente em base SQL Server.
MILLEN-43970

CAUSA/MOTIVO
Na tela de baixa de seleção não tinha máscaras para formatar os números. Nas telas de listagem, os valores são formatados com apenas 2 casas decimais, mas os totalizadores utilizavam decimais dos fields fazendo a formatação divergir dos campos. 

SOLUÇÃO
Incluímos máscaras no grid da baixa por seleção. Fixamos em duas casas decimais no formatadores.

MILLEN-44049CAUSA/MOTIVO
Inconsistência na exibição dos Cards.

SOLUÇÃO
Ajuste no filtro para exibição dos cards.
MILLEN-44071CAUSA/MOTIVO
Ao gerar o SPED está indicando mensagem de erro na contabilização de linhas.
**Sistema estava retornando o cod_nat_cc sempre 00, com isso era gerado o registro 0500 ao final dos outros, alterando a contagem das linhas.
**Sistema não gerava o fechamento referente so ICMS-ST a recolher do registro E250.
**Foi encontrado erro na geração do arquivo para os registro M200 e M600, onde o valor deveria ser a soma dos M210 e M610 respectivamente, pois o sistema só incluía 1 registro de cada para cada cod_cont.
**Foram encontradas NFs emitidas através do ML onde o CST PIS/COFINS estavam com 06 e após importação no e-Millennium o o CST PIS/COFINS foi trocado para 02

SOLUÇÃO
1) Feita a correção para retornar o código correto da tabela conta_contábil.
2) Inclusão do fechamento para ICMS-ST a Recolher para geração do registro E250.  
3) Alterado o sistema para permitir mais de 1 lançamento para os registros M210 e M610 com alíquotas diferentes.
4) Geração dos scripts para correção dos lançamentos dos CST PIS/COFINS divergentes entre a NF do mercado livre com a do e-Millennium.
MILLEN-44140Este  erro não ocorre mais.
Após  análise e revisão com desenvolvedor foi identificado que  a pendência MILLEN-43153 corrige este problema.  
MILLEN-44154CAUSA/MOTIVO
Registro E316 com erro nos totais Difal+Fcp
Sistema não estava adicionando os valores referentes ao fechamento DIFAL-FCP

SOLUÇÃO
Corrigido o método para inclusão dos títulos referentes ao fechamento DIFAL-FCP.
MILLEN-44155CAUSA/MOTIVO
Na importação de produtos, caso o campo REDE_LOJAS esteja preenchido está tomando erro de Unrecognized escape sequence.

SOLUÇÃO
Ajustada a geração do JSON que é passada na chamada de API.
MILLEN-44156 CAUSA/MOTIVO
Sped ICMS - Registro 0150 com erro campo CNPJ para pessoa física. Cliente possui um endereço em outro país cadastrado, ao gerar o sped o sistema utiliza o método millenium.clientes.dados_nota, onde retorna todos os endereços cadastrados para o cliente, utilizando-se do primeiro registro para identificar o país, nesse caso retornando EUA, e nesse caso deixando o CPF em branco.

SOLUÇÃO
Trocada a utilização do método por um select quando o tipo do gerador for C-Cliente, onde retorna apenas o endereço de nota.
MILLEN-44157Este  erro não ocorre mais.
Após  analise e revisão com desenvolvedor foi identificado que  a pendencia MILLEN-43153 CORRIGE este problema.
MILLEN-44171CAUSA/MOTIVO
O valor do SIT_TRIB passado para a função BuscaCFOP é associado ao CFOP do evento. Como o valor do primeiro item do XML é 20 esse valor fica vinculado ao CFOP 1.102 (do evento) e passa a ser utilizado em todos os itens da movimentação em que o CFOP foi encontrado.

SOLUÇÃO
Tratamento para só alterar o SIT_TRIB caso o valor obtido no XML seja vazio ou igual ao ao associado ao CFOP ou caso caso tenha modificador fiscal. Caso contrário, irá manter o encontrado no XML.
MILLEN-44188Quebra de teste
MILLEN-44191CAUSA/MOTIVO
OMNI mandava o percentual de redução da Base de Cálculo de ICMS.

SOLUÇÃO
Feita a correção e o valor passou a ser calculado corretamente, conforme percentual cadastrado no Perfil de Imposto.
MILLEN-44192CAUSA/MOTIVO
Ao passarmos o valor de ORIGEM_PROD para uma variável o mesmo estava null, causando o erro em questão.

SOLUÇÃO
Conforme contato com desenvolvedor, no processo em questão é necessário que o campo Origem do Produto (em Produtos e Serviços > Produtos > Aba Fiscal) esteja preenchido corretamente, conforme a tabela da Sefaz, após a implementação da pendência MILLEN-36286. Para isso foi adicionada uma trava, para não permitir que o processo continue, caso a Origem do Produto não esteja preenchida.
MILLEN-44228CAUSA/MOTIVO
Erro de grafia na descrição dos módulos PullerAPI e PusherAPI nas palavras "Intermediario" e "distribuido". A forma correta é "Intermediário" e "distribuído".

SOLUÇÃO
Alteradas as grafias para a forma correta.
MILLEN-44236CAUSA/MOTIVO
Ajustes para rescrever a implementação do método millenium_eco.produtos.saldoDeEstoque do wts para dll, ocasionaram uma quebra na estrutura do comando do bando de dados.
SOLUÇÃO
Ajustado método para realizar o comando corretamente.
MILLEN-44395CAUSA/MOTIVO
O problema ocorre ao gerar os códigos de barras quando o flag "Permite que o sistema procure por código de barras inutilizados?" estiver ativado. Ao executar o método "ExistsBarCode" internamente no "TGeraBarra.Populate", este se encarrega de encontrar o próximo código de barras inutilizado que está disponível, no entanto, ao percorrer para vários itens, o método estava sempre retornando o último código disponível encontrado.

SOLUÇÃO
Realizado ajuste para adicionar o código inativo que foi utilizado à lista de códigos já alocados. Com isso, o sistema consegue seguir encontrando os próximos códigos disponíveis dentro do método de validação "ExistsBarCode".
MILLEN-44432CAUSA/MOTIVO
Na tela de pré-fase, o parâmetro seloficina não está realizando nenhum filtro.
Verificado que esse parâmetro não tem nenhuma influência no script, desde a entrada no git.

SOLUÇÃO
Retirado o parâmetro da tela.
MILLEN-44541CAUSA/MOTIVO
Lentidão na ListaFaturamentos quando filtrado por pedido de venda.
SOLUÇÃO
Alterado consulta SQL onde foi otimizado o comando para retornar o mais rápido possível o resultado.
MILLEN-44584CAUSA/MOTIVO
Erro ao listar as parcelas.

SOLUÇÃO
Adicionar filtros NSU, AUTORIZACAO e NUMERO_TID no rowset de parcelas.


5.103.19


PendênciaResolução
MILLEN-35529CAUSA/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-39215CAUSA/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-40710Após análise, foi verificado que o erro ocorre somente no millennium 5 e como o cliente utiliza o GO, onde o processo funciona corretamente, a pendência foi devolvida.
MILLEN-40913CAUSA/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-43512CAUSA/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-43640CAUSA/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-45754CAUSA/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-45758CAUSA/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-46085CAUSA/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-46253CAUSA/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-46266CAUSA/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-46323CAUSA/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-46336CAUSA/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-46421CAUSA/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-46423CAUSA/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-46529CAUSA/MOTIVO
Quando possuímos vendas com tipo de pagamento Credito e outra forma, o Omni estava mandando como condição de pagamento Venda mista, ocasionando o cenário relatado pelo cliente.

SOLUÇÃO
Para correção, passamos a filtrar os tipos de pagamentos, pegado apenas aqueles que não são crédito, para que, caso seja feita a venda com Credito + Dinheiro, seja mandado a forma de pagamento Dinheiro, tendo em vista que no e-Millennium, apenas abatemos o crédito e não levamos como uma parcela. Dessa forma o millennium leva a condição de pagamento correta.
MILLEN-46618CAUSA/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-46665CAUSA/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-46711CAUSA/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-46841CAUSA/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-46904CAUSA/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-46990CAUSA/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-47092CAUSA/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-47113CAUSA/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-47124CAUSA/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-47127CAUSA/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-47190CAUSA/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-47212CAUSA/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-47231CAUSA/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-47235CAUSA/MOTIVO
Ao importar o xml de uma NFe utilizando o botão "Importar XML" em Produção/Movimentações, o e-Millennium traz os valores "corretos" da nota fiscal e ao digitar manualmente os produtos e mão-de-obra e posteriormente importar os dados restantes do XML da NFe, o e-Millennium estaria supostamente trazendo valores "incorretos" e que ocasionava a mensagem de erro de CST ao prosseguir com a importação da nota.

SOLUÇÃO
Realizamos a correção do trecho na importação que ocasionava o erro trazendo então o CST com 3 caracteres.

4 - OBSERVAÇÃO
A importação do XML da NFe completa, traz os dados exatamente como estão no XML, possuindo a opção de converter a CST de acordo com o tipo da empresa ou não.
Já no caso da importação feita na tela de digitação da nota, essa, traz os dados já convertidos pelas regras fiscais vigentes de acordo com o tipo da empresa.
MILLEN-47240CAUSA/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-47265CAUSA/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-47270CAUSA/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-47271O 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-47290CAUSA/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-47291CAUSA/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-47338CAUSA/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-47422CAUSA/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-47433CAUSA/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-47444CAUSA/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-47532CAUSA/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-47580CAUSA/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-47613CAUSA/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.
  • Sem rótulos