5.103

5.103

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 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-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 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 Federeçã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-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 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-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 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-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 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-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.

Árvore de páginas

5.103