Pendência | Resolução |
---|---|
MILLEN-21067 | CAUSA 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-25176 | CAUSA/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-26272 | CAUSA/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-29055 | CAUSA/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-30210 | CAUSA/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 disponbilizar a consulta, independente do acesso à alteração estar configurado. |
MILLEN-30356 | CAUSA/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-30713 | CAUSA/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-31152 | CAUSA 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-31304 | CAUSA/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-31565 | CAUSA/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-31638 | CAUSA/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-31874 | CAUSA/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 ja inclusos no select da NormalIsento. |
MILLEN-31942 | CAUSA/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 no funcao que retorna a situação da NF e ajuste no retorno de mensagem de erro da função HttpPOSTService. |
MILLEN-32010 | MOTIVO 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-32036 | CAUSA/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
|
MILLEN-32248 | CAUSA/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
|
MILLEN-32405 | CAUSA/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
|
MILLEN-32446 | CAUSA/MOTIVO
|
MILLEN-32513 | CAUSA/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, tamnho de 13 para 9. |
MILLEN-32534 | CAUSA/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 SOLUÇÃO |
MILLEN-32603 | CAUSA/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-32622 | CAUSA/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 SOLUÇÃO |
MILLEN-32675 | CAUSA/MOTIVO SOLUÇÃO |
MILLEN-32677 | CAUSA/MOTIVO SOLUÇÃO |
MILLEN-32756 | CAUSA/MOTIVO SOLUÇÃO |
MILLEN-32761 | CAUSA/MOTIVO SOLUÇÃO |
MILLEN-32798 | CAUSA/MOTIVO SOLUÇÃO |
MILLEN-32840 | CAUSA/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-36804 | CAUSA/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. |