Ir para o final dos metadados
Ir para o início dos metadados

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 38 Próxima »

Data de publicação: 16/11/23

📗 Melhorias

[Menu Comuns]

 Clique para expandir/recolher

📗 3️⃣ Inserida a paginação ao exportar produtos para planilha Excel.

Melhoria interna

Na tela “1.1.19 - Cadastro de produtos”, foi adicionada a paginação na exportação do arquivo “CSV”. A partir de agora ele será trabalhado em cada página de forma separada, ou seja, gerará o arquivo página por página, o que limitará o espaço ocupado na memória. Sendo assim, ao iniciar o processo de exportação será fechada a consulta de produtos, liberando os “mb” utilizados inicialmente. E ao finalizar o processo de exportação será fechada a consulta de exportação, liberando os “mb” que estavam sendo utilizados, desta forma, fará com que o processo de exportação ocorra normalmente (Imagem 1).

Exportando arquivo “CSV” (Imagem 2).

Salvando o arquivo “CSV” sem inconsistências (Imagem 3).

Arquivo “CSV”, devidamente salvo (Imagem 4).

Arquivo “CSV”, exportado com sucesso (Imagem 5).

📗 3️⃣ Ajustando numeração NFS-e e busca de chaves sem uso da lupa.

SUP-93601

Nas telas que possuem os campos “Plano financeiro” e “Centro de custo”, foram feitas alterações. Agora, será possível digitar o código destes campos.

  • Campo “Plano financeiro”.

Tela “1.1.9 - Cadastro de produtos”, aba “Classificação” (Imagem 1).

Tela “1.1.3 - Cadastro de clientes”, aba “Dados Gerais” (Imagem 2).

Tela “1.1.9 - Cadastro de fornecedores (geral)”, aba “Comercial” (Imagem 3).

Tela “1.1.25 - Cadastro de fornecedores (despesas)”, aba “Comercial” (Imagem 4).

Tela “2.1.4 - Cadastro de fornecedores (compras), aba “Comercial” (Imagem 5).

Tela “3.1.10 - Cadastro de representantes, aba “Comercial” (Imagem 6).

Tela “1.1.28 - Cadastro de Transportadoras”, aba “Comercial” (Imagem 7).

Tela “1.1.17 - Cadastro de motoristas”, aba “Comercial” (Imagem 8).

  • Campo “Centro de custo”.

Tela “1.1.9 - Cadastro de fornecedores (geral)”, aba “Comercial”;

Tela “1.1.25 - Cadastro de fornecedores (despesas)”, aba “Comercial”;

Tela “2.1.4 - Cadastro de fornecedores (compras), aba “Comercial”;

Tela “3.1.10 - Cadastro de representantes, aba “Comercial”;

Tela “1.1.28 - Cadastro de Transportadoras”, aba “Comercial”;

Tela “1.1.17 - Cadastro de motoristas”, aba “Comercial” (Imagem 9).

[Menu Comercial - Compras]

 Clique para expandir/recolher

📗 2️⃣ Cálculo do estoque na tela “Sugestão de Compra”.

SUP-94031

Na tela “2.2.11 - Sugestão de Compra”, foram feitas alterações para que ao pesquisar o produto para gerar a sugestão de compra e configurar o campo "Estoque und compra" com a opção “NÃO”, será realizado o cálculo dos totalizadores "Estoque Atual, Comprado, Vendido e Saldo" (Imagem 1).

Considerando os valores apresentados, foram feitos os cálculos:

  • Resultado para o totalizador “Estoque Atual” = Vr Custo Final ((2.090,40) / Unidade (120 CX) * Estoque Atual (102) = 1.776,84

  • Resultado para o totalizador “Comprado” = Vr Custo Final ((2.090,40) / Unidade (120 CX) * Comprado (147,876) = 2.576,00

  • Resultado para o totalizador “Vendido” = Vr Custo Final ((2.090,40) / Unidade (120 CX) * Vendido (0,00) = 0,00

  • Resultado para o totalizador “Saldo” = Vr Custo Final ((2.090,40) / Unidade (120 CX) * Saldo (249,876) = 4.352,84

 

Se ao pesquisar o produto para gerar a sugestão de compra, o campo "Estoque und compra" for configurado coma opção “SIM”, serão realizados os cálculos dos totalizadores "Estoque Atual, Comprado, Vendido e Saldo" (Imagem 2 e 3).

  • Resultado para o totalizador “Estoque Atual” = Vr Custo Final * Estoque Atual (0,85) = 1.776,84 (Como está considerando “Estoque und compra” com a opção “SIM”, ou seja, considerando o estoque por embalagem, o valor "quebrado" de 0,85 será referente ao cálculo de: “Estoque Físico do Produto”, no caso, 102/Unidade (120 CX). O resultado, então, seria 0,85. Ou seja, 102/120)

  • Resultado para o totalizador “Comprado” = Vr Custo Final ((2.090,40) * Comprado (1,2323) = 2.576,00

  • Resultado para o totalizador “Vendido” = Vr Custo Final ((2.090,40) * Vendido (0,00) = 0,00

  • Resultado para o totalizador “Saldo” = Vr Custo Final ((2.090,40) * Saldo (249,876) = 4.352,84

Com o ajuste, agora o cálculo será realizado mesmo que o valor do estoque atual seja menor que 1.

📗 2️⃣ Clicando na lupa de “Rateio Padrão Centro de Custo”.

Melhoria interna

Na tela “2.2.8 - Manutenção das ordens de compra”, foi feito um ajuste para que somente seja aberta a tela quando estiver sendo inserida/alterada alguma ordem de compra, assim como acontece com alguns outros campos desta mesma tela, como “Cobrança”, “Classificação Gastos”, entre outros (Imagem 1).

📗 2️⃣ Totalizador de coluna na tela “Entrada de notas fiscais”.

SUP-91854

Na tela “2.2.4 - Entrada de notas fiscais”, foi implementado um totalizador para a coluna “Valor total” pertencente à grade das notas consultadas (Imagem 1).

📗 3️⃣ Validação “Tipo de Ordem x Classificação de Gastos”.

SUP-92979

Na tela “2.2.8 - Manutenção das ordens de compra” em (pedido de compra), foi implementada uma validação entre a “Classificação de gastos e Tipo de ordem do pedido de compra”, que irá operar mediante algumas configurações e configurações.

Para a validação ocorrer, será necessário que ao executar as funcionalidades do pedido de compra, o parâmetro CM_ORIGEM_CLASS_GASTOS deverá ser configurado como “ORIGEM', desta forma, o sistema ativará a validação entre a “Classificação de gastos e Tipo de ordem do pedido de compra” (Imagem 1).

  • Para que o sistema faça a validação entre a “Classificação de gastos e Tipo de ordem do pedido de compra”, deverão seguir algumas “Condições”:

Condição 1: Caso a classificação de gastos, esteja configurada para “PERMITIR” requisição de materiais com a opção “SIM” (Imagem 2).

Caso o “Tipo de ordem”, esteja configurado para “NÃO” movimentar estoque, o sistema deverá restringir a “INCLUSÃO e ALTERAÇÃO” de ordem de compra, a “GERAÇÃO e ALTERAÇÃO” de pedido filho. Desta forma, o sistema também fará a restrição ao gerar a ordem de compra, através da “Sugestão de compra, Requisição de pedido de compra e Cotação de materiais” (Imagem 3).

Considerando a configuração mencionada envolvendo a configuração do parâmetro e a Condição 1, será possível visualizar a restrição que o sistema fará ao tentar “INCLUIR” uma “Ordem de compra” (Imagem 4).

Obs.: Com o tipo de ordem optado para “NÃO” movimentar estoque e a classificação de gastos, para “PERMITIR” requisição de materiais optada como “SIM”, ou seja, o “Tipo de ordem” está NEGATIVO e a “Classificação de gastos” POSITIVA, o sistema fará a restrição.

Condição 2: Caso a “Classificação de gastos” esteja configurada para “PERMITIR” requisição de materiais com a opção “NÃO” (Imagem 5).

Caso o “Tipo de ordem”, esteja configurado para “SIM” movimentar estoque, o sistema deverá restringir a “INCLUSÃO e ALTERAÇÃO” de ordem de compra, a “GERAÇÃO e ALTERAÇÃO” de pedido filho. Desta forma, o sistema também fará a restrição ao gerar a ordem de compra, através da “Sugestão de compra, Requisição de pedido de compra e Cotação de materiais” (Imagem 6).

Obs.: Com o tipo de ordem optado para “SIM” movimentar estoque e a classificação de gastos, para “PERMITIR” requisição de materiais optada como “NÃO”, ou seja, o “Tipo de ordem” está POSITIVO e a “Classificação de gastos” NEGATIVA, o sistema fará a restrição.

Considerando a configuração mencionada envolvendo a configuração do parâmetro e a Condição 2, será possível visualizar a restrição que o sistema fará ao tentar “INCLUIR” uma “Ordem de compra” (Imagem 7).

  • Se a classificação de gastos estiver configura para “PERMITIR” requisição de materiais optada por “SIM” e o tipo de ordem estiver configurado para “NÃO” movimentar estoque, o sistema fará a restrição.

Invertendo a condição:

  • Se a classificação de gastos estiver configura para “PERMITIR” requisição de materiais optada como “NÃO” e o tipo de ordem estiver configurado para “SIM” movimentar estoque, o sistema também fará a restrição.

Condição 3: Caso a classificação de gastos esteja configurada para “PERMITIR” requisição de materiais optada como “NÃO” (Imagem 8).

Caso o “Tipo de ordem”, esteja configurado para “NÃO” movimentar estoque, o sistema deverá prosseguir com a “INCLUSÃO e ALTERAÇÃO” de ordem de compra, a “GERAÇÃO e ALTERAÇÃO” de pedido filho. Desta forma, o sistema irá prosseguir com a geração de ordem de compra, através da “Sugestão de compra, Requisição de pedido de compra e Cotação de materiais” (Imagem 9).

Considerando a configuração mencionada envolvendo a configuração do parâmetro e a Condição 3, será possível visualizar inclusão da ordem de compra sem restrição (Imagem 10).

Condição 4: Caso a classificação de gastos esteja configurada para “PERMITIR” requisição de materiais com a opção “SIM” (Imagem 11).

Caso o “Tipo de ordem”, esteja configurado para “SIM” movimentar estoque, o sistema deverá prosseguir com a “INCLUSÃO e ALTERAÇÃO” de ordem de compra, a “GERAÇÃO e ALTERAÇÃO” de pedido filho. Desta forma, o sistema irá prosseguir com a geração de ordem de compra, através da “Sugestão de compra, Requisição de pedido de compra e Cotação de materiais” (Imagem 12).

Considerando a configuração mencionada envolvendo a configuração do parâmetro e a Condição 4, será possível visualizar inclusão da ordem de compra sem restrição (Imagem 13).

Obs.: Caso o “Tipo de ordem”, esteja configurado para “SIM” movimentar estoque e a classificação de gastos está para “PERMITIR” requisição de materiais optada como “SIM”, ou seja, o tipo de ordem está POSITIVO e a classificação de gastos também é POSITIVA, o sistema não fará a restrição.

  • Se a classificação de gastos estiver configura para “PERMITIR” requisição de materiais com a opção “SIM” e o tipo de ordem estiver configurado para “SIM” movimentar estoque, o sistema irá prosseguir com a inclusão da ordem de compra.

Invertendo a condição:

  • Se a classificação de gastos estiver configura para “PERMITIR” requisição de materiais com a opção “NÃO” e o tipo de ordem estiver configurado para “NÃO” movimentar estoque, o sistema prosseguirá com a inclusão da ordem de compra.

 

Exemplo de como seria o comportamento ao gerar uma ordem de compra, através de tela “Sugestão de compras”, quando as configurações citadas estiverem para restringir a “INCLUSÃO e ALTERAÇÃO” de ordem de compra, bem como a “GERAÇÃO e ALTERAÇÃO” de pedido filho (Imagem 14).

Quando o parâmetro CM_ORIGEM_CLASS_GASTOS estiver configurado como “FINANCEIRO”, o sistema irá ignorar a restrição entre “Classificação de gastos e Tipo de ordem”, quando na “INCLUSÃO e ALTERAÇÃO” de ordem de compra, bem como a “GERAÇÃO e ALTERAÇÃO” de pedido filho (Imagem 15).

▶️ Vídeo de apresentação da melhoria:

[Menu Comercial - Vendas]

 Clique para expandir/recolher

📗 2️⃣ Customização na tela “Emissão de Ordens”.

SUP-93988

Na tela "3.2.14 - Emissão de Ordens" foram incluídas duas colunas na grade:

  • "Prazo médio": Esta coluna fornecerá informações sobre o prazo médio relacionado a cada ordem;

  • "Condição de venda": Esta coluna indicará a condição de venda associada a cada ordem (Imagens 1 e 2).

Foram feitas alterações nas nomenclaturas de algumas colunas:

  • "TPP_ES" foi alterado para "Tipo de emissão";

  • "GRA_PEDIDO_IMPORTADO_NF" foi alterado para "Pedido importado (XML)";

  • "GRA_CONFIRMADO" foi alterado para "Faturado" (Imagem 3).

Agora, nestas colunas serão exibidos os valores "SIM" ou "NÃO", facilitando a visualização e a tomada de decisões relacionadas às ordens (Imagem 4).

📗 2️⃣ Nota de reentrada gerada pela tela “Fechamento de Ordens”.

Melhoria interna

Na tela "4.1.1 - Cadastro de notas fiscais”, foi feito um ajuste para que quando a nota de reentrada, gerada através da exclusão de uma digitação de ordem (Cancelamento), for pesquisada e salva, não seja duplicado o campo “NFI_QUANTIDADE_DEV” da tabela “NFITENS”, referente à nota vinculada à digitação de ordem que foi cancelada, originando a nota de reentrada (Imagens 1 e 2).

Quantidade devolvida referente à digitação de ordem que foi excluída (Cancelada), ao salvar várias vezes a nota de reentrada gerada por esta exclusão de digitação de ordem, sem duplicidade (Imagem 3).

📗 1️⃣ Permissão de inserção de cidade com mais de 30 (trinta) caracteres.

SUP-94033/SUP-94036

Na tela "3.5.7 - Guarani móvel - Android - importação de dados”, foi feito um ajuste no recebimento pelo “Integrador WS” de pedidos de clientes. Agora, no campo “Cidade”, ao inserir uma nomenclatura que possuir mais de 30 caracteres, serão desconsiderados os caracteres que ultrapassarem esta quantidade limite (Imagem 1).

Na tela “3.5.7 - Guarani móvel - Android - importação de dados”, o campo “Cidade” deverá ser preenchido manualmente quando, ao realizar a importação, no arquivo do pedido a nomenclatura da cidade estiver abreviada (Imagem 2).

📗 3️⃣ Inserção de ICMS no XML em nota de “Remessa”.

SUP-92242/SUP-92434/SUP-93637

Foi criada a tela “Cadastro Motivo Desoneração ICMS”, que permitirá informar o tipo de cálculo do motivo. Esta tela será exibida preenchida com os motivos que já estavam cadastrados, por padrão o campo “Tipo Cálculo“ estará optado como “Destaca“.

Tela “Cadastro Motivo Desoneração ICMS” (Imagem 1).

A tela “Cadastro Motivo Desoneração ICMS” será aberta através da tela “10.1.3 - Cadastro de CFOP” ao clicar no botão “Opções” e na tela “Motivo de Desoneração ICMS”, na aba “Manutenção” ao clicar no botão “Opções”, escolher a opção “Cadastro motivos para desoneração de ICMS”.

Caminho para abrir a nova tela (Imagem 2).

Nesta nova tela, será permitido cadastrar um motivo de desoneração do ICMS, também será possível selecionar o tipo de cálculo que será aplicado, podendo ser:

  • Destaca: Será subtraído o valor do ICMS desonerado do valor total da nota fiscal;

  • Destaca e Soma na NFe/NFCe: Somará o valor do ICMS desonerado no valor total da nota fiscal.

Opções do campo “Tipo Cálculo” (Imagem 3).

Regra 1: Quando a opção “Tipo Cálculo” da tela “Cadastro Motivo Desoneração ICMS” estiver optada como “Destaca“ e na tela “Cadastro de clientes”, a opção “Crédito estímulo ICMS” estiver optada, ao realizar o pedido da “Remessa”, será feita a subtração do valor do campo “Vr Desc Impostos” pelo campo “Total Pedido”. (Este procedimento já está sendo feito atualmente).

Tela “Cadastro Motivo Desoneração ICMS” com o campo “Tipo Cálculo” optado como “Destaca” (Imagem 4).

Tela “Cadastro de clientes” com a opção “Crédito estímulo ICMS” optada (Imagem 5).

Pedido de “Nota de Remessa” (Imagem 6).

Na nota fiscal, o valor será subtraído do total da nota, e no XML as tags <vICMSDeson> e <vNF> apresentarão os respectivos valores. Nota Fiscal gerada (Imagem 7).

Arquivo XML (Imagem 8).

Regra 2: Quando o campo “Tipo Cálculo” da tela “Cadastro Motivo Desoneração ICMS” estiver com a opção “Destaca e Soma na NFe/NFCe“ selecionada, e na tela “Cadastro de clientes” a opção “Crédito estímulo ICMS” estiver optada, ao realizar o pedido da “Remessa”, será feita a subtração do valor do campo “Vr Desc Impostos” do campo “Total Pedido”.

Tela “Cadastro Motivo Desoneração ICMS” com o campo “Tipo Cálculo” optado como “Destaca e Soma na NFe/NFCe” (Imagem 9).

Tela “Cadastro de clientes” com a opção “Crédito estímulo ICMS” optada (Imagem 10).

Pedido de “Nota de Remessa” (Imagem 11).

Na nota fiscal, o valor não será subtraído do total da nota, e no XML a tag <vICMSDeson> enviará o valor, mas a tag <vNF> apresentará o valor total da nota. Nota Fiscal gerada (Imagem 12).

Arquivo XML (Imagem 13).

A tela “4.1.1 - Cadastro de Notas Fiscais” também foi alterada. Quando uma nota for incluída manualmente, será verificado se a combinação de CFOP e “Situação Tributária” possuem um motivo cadastrado e qual o tipo de cálculo vinculado à este motivo. Desta forma quando os campos “Vr Crédito ICMS” ou “Vr Crédito ICMS Suframa” forem preenchidos, o valor somado destes campos irá compor o campo “ICMS Desonerado”.

“Nota Manual” quando o campo “Tipo Cálculo” estiver optado como “Destaca“ (Imagem 14).

“Nota Manual” quando o campo “Tipo Cálculo” estiver optado como “Destaca e Soma na NFe/NFCe“ (Imagem 15).

▶️ Vídeo de apresentação da melhoria:

📗 2️⃣ Ajuste na tela “Digitação de ordens”.

SUP-95252

Na tela “3.2.12 - Digitação de ordens” foram alteradas as propriedades do menu suspenso, que apresentam o tipo de ordem via tabela de consultas, na aba “Manutenção” quanto na aba “Consulta”. Dessa forma, o conteúdo do combo se ajustará ao tamanho do texto, sendo possível também ajustar o tamanho manualmente caso necessário (Imagens 1 e 2).

[Menu Financeiro - Receber]

 Clique para expandir/recolher

📗 1️⃣ Liberação de ordens em massa.

SUP-92243

Na tela “5.2.16 - Liberação de ordens”, foi implementada uma opção para liberação das ordens em massa. Nesta tela, foi adicionada a aba “Desbloqueio de crivos em massa”.

Foi criado um evento de usuário para que esta aba seja exibida, por padrão ela estará optada como “NÃO” (Imagens 1 e 2).

Ao liberar, a aba será exibida (Imagem 3).

Ao tentar liberar ordens de clientes ou grupos econômicos diferentes, será exibida uma mensagem informando que este comportamento não será permitido (Imagem 4).

Ao liberar ordens do mesmo grupo econômico, mas com clientes diferentes, será validado e desbloqueado (Imagens 5 e 6).

▶️ Vídeo de apresentação da melhoria:

[Menu Financeiro - Pagar]

 Clique para expandir/recolher

📗 3️⃣ Tela “Lançamentos a pagar” informando emissão incorretamente.

SUP-94519/SUP-93864/SUP-94021/SUP-95188/SUP-93992

Nas telas “6.2.6 - Lançamentos a pagar, 6.2.1 - Autorização de pagamentos e 6.2.7 - Pagamento de contas”, foi adicionado o campo “Data emissão da NF”.

Tela “6.2.1 - Autorização de pagamentos” (Imagem 1).

Tela “6.2.6 - Lançamentos a pagar” (Imagem 2).

Tela “6.2.7 - Pagamento de contas” (Imagem 3).


📘 Solicitações

[PDV]

 Clique para expandir/recolher

📘 2️⃣ Mensagem na tela de transmissão de Nota Fiscal PDV.

SUP-96615

Ocorrência: Uma inconsistência estava ocorrendo ao transmitir ou tentar abrir, uma nota com observação de cliente SUFRAMA no PDV. Esta inconsistência estava ocorrendo por conta do campo observação da base legal que vinha preenchida do cadastro de clientes, desta forma, a base legal não era levada para emissão de notas fiscais no PDV e ainda apresentava a inconsistência ao tentar emitir uma nota fiscal.
Solução: Foi feito um ajuste nos campos observações na emissão de nota fiscal feita direto pelo PDV, aumentando o campo observação e levando o preenchimento da base legal, para a emissão da nota no PDV (Imagens 1, 2 e 3).

Local>Tela Digitação de Nota Fiscal Eletrônica

Local>Tela Emissão de Notas Fiscais Eletrônicas

[Menu Comercial - Compras]

 Clique para expandir/recolher

📘 1️⃣ Filtro por número de requisição de compra não funcionando.

SUP-96479

Ocorrência: A inconsistência estava ocorrendo devido a forma com que os filtros foram criados, considerando o conteúdo digitado como texto ao enviar para a consulta no banco. Desta forma, o filtro por número de requisição de compra, não estava funcionando.

Solução: Foi feita uma correção para considerar o código digitado, como inteiro (Imagem 1).

Local>Tela 2.2.16 - Requisição de Pedido de Compra

📘 2️⃣ Sugestão de compras duplicando quantidades ao gerar pedido de compra.

SUP-96438 e SUP-96663

Ocorrência: Sugestão de compras estava repetindo as quantidades para todos os itens ao gerar pedido de compra, quando o parâmetro da tela “Multiempresa“ estava configurado como “NÃO“.

Solução: Foi realizado um ajuste na necessidade do item, que ao gerar pedido de compra com o parâmetro "MultiEmpresa" marcado como "NÃO" na “Sugestão de compras” deverá seguir o comportamento normal.

Gerando pedido de compra através da tela de sugestão de compra, quando o campo “Multiempresa“ estiver configurado como “NÃO”. O pedido foi gerado com a quantidade correta informada em cada produto, na coluna “Necessidade“, na tela de “Sugestão de compra” (Imagens 1 e 2).

Local>Tela 2.2.11 - Sugestão de Compra

Local>Tela Geração do pedido de compra

Local>Tela 2.2.8 - Manutenção das ordens de compra

[Menu Comercial - Vendas]

 Clique para expandir/recolher

📘 1️⃣ Inconsistência ao utilizar o relatório na tela “Relatório de vendas (feirinha)”.

SUP-96308

Ocorrência: Estava sendo apresentada uma inconsistência ao gerar o relatório de vendas com produtos de feirinha. Era comparado o produto escolhido na consulta “pro_referencia” (produto escolhido na tela) com “pro_codigo” (consulta no banco), gerando uma inconsistência caso houvesse alguma letra no produto da referência escolhida.

Solução: Foi feito um ajuste para que seja utilizado o código do produto para realizar a consulta (pro_codigo escolhido X pro_codigo no banco) (Imagem 1).

Local>Tela 3.3.18 - Relatório de vendas (feirinha)

📘 1️⃣ Relatório Royalties.

SUP-96342

Ocorrência: Na listagem de itens a serem processados na tela “Relatório de apuração de royalties” estavam sendo repetidos, somente os produtos que continham código de barras adicionais

Solução: Foi corrigido para que a consulta seja pelo código de barras adicional, desta forma, o produto não irá se repetir independente da quantidade de códigos adicionais que existam.

Produto com os três códigos: código de barras adicionais, Ean 13 e Dun 14 (Imagem 1)

Pesquisando pelo código de barras “Ean 13”, o item não duplicou mesmo tendo código de barras adicionais (Imagem 2).

Pesquisando pelo código de barras “Dun 14”, o item não duplicou mesmo tendo código de barras adicionais (Imagem 3).

Pesquisando pelo código de barras adicionais (Imagem 4).

Local>Tela 3.3.8 - Relatório de apuração royalties

Local>Tela 1.1.19 - Cadastro de produtos

📘 Em “Manutenção de ordens”, não era permitido alocar peças de quantidades exatas.

SUP-95514

Ocorrência: A quantidade de volumes do pedido não estava atualizando, quando alocava peças na pela “Manutenção de ordens”, pois o processo de alocação de peças ocorria à partir da opção “Alterar quantidade”.

Solução: Foi corrigido para sempre rodar a procedure, caso exista peça alocada no pedido, independente se houve alteração na quantidade.

Fazendo a alocação de peças (Imagem 1).

Atualização da peça alocada (Imagem 2).

Conferindo na digitação de ordem (Imagem 3).

Local>Tela 3.2.21 - Manutenção das ordens

Local>Tela 3.2.12 - Digitação de ordens

📘 3️⃣ Emissão de ordens apresentando divergência nos logs de impressão.

SUP-94103

Ocorrência: Algumas ordens estvam apresentando o campo Separação como “SIM”, porém não aparecia nenhuma informação de impressão no log e nem na rastreabilidade da ordem. Sendo assim, ao gerar impressões, o registro do log não era visível e a persistência estava acontecendo antes da geração do novo registro, tornando o último registro um “registro fantasma”, que desaparecia assim que o sistema fosse encerrado.

Solução: Foi adicionado ao fim do processo de impressão, uma chamada da rotina de validação de dados, garantindo que os registros sejam persistidos na base. Desta forma, o processo de persistência passará a ocorrer após as impressões, garantindo que todos os registros gerados sejam inseridos no banco, evitando “registros fantasmas”, ou seja, registros criados em sessão e nunca persistidos (Imagem 1).

Verificando o log de impressões, contendo somente um registro (Imagem 2).

Realizando para a ordem escolhida uma impressão “Modelo Padrão”, que por regra do sistema deverá gerar registro de log (Imagem 3).

Acessando os logs de impressão novamente, agora observando um novo registro, referente a impressão (Imagem 4).

Usuário acessando o sistema e selecionando a mesma ordem nos prints anteriores (Imagem 5).

Ao acessar o log de impressões será possível visualizar dois registros: um antigo em 10/10/23 e outro mais recente, realizado por outro usuário em 14/11/23, que refere-se ao processo (Imagem 6).

Local>Tela 3.2.14 - Emissão de ordens

[Menu Faturamento]

 Clique para expandir/recolher

📘 2️⃣ Sistema validando estoque incorretamente ao faturar romaneio.

SUP-96337

Ocorrência: Ao realizar o faturamento, o sistema validava o estoque incorretamente. Este comportamento ocorria quando o parâmetro para checkout estava optado como “ANTES DO FATURAMENTO” e o romaneio possuía ordens com configurações diferentes em seus tipos (exemplo: tipo de ordem que integrava checkout e tipo de ordem que não integrava checkout).

Solução: Foi realizado um ajuste na verificação do estoque ao confirmar o faturamento. Serão validadas as ordens quando o checkout não for antes do faturamento, ou quando o checkout for antes do faturamento, mas o tipo de ordem não integrar checkout. Também foi inserido um log de operações para exibir as ordens em que o tipo de ordem estará optado como “NÃO” movimentar estoque (Imagem 1).

Local>Tela 4.2.6 - Expedição
Local>Tela Log de Operações

📘 2️⃣ Inconsistência ao importar DI.

SUP-96467

Ocorrência: Estava ocorrendo uma inconsistência ao importar a DI, quando associada com pedido de compra.

Solução: Foi feito um ajuste para realizar os cálculos, apenas dos itens que constam no pedido de compra que foi utilizado na importação da DI.

Ao iniciar uma nova entrada para a importação da DI (Imagem 1).

Utilizando um pedido de compra (Imagens 2 e 3).

Selecionando a DI que será vinculada ao pedido de compra selecionado (Imagens 4 e 5).

O sistema realizou a importação da DI, selecionada (Imagem 6).

Local>Tela 4.1.1 - Cadastro de notas fiscais

Local>Tela Importação da Declaração de Importação (DI)

Local>Tela Manutenção do pedido de compra

[Menu Financeiro - Receber]

 Clique para expandir/recolher

📘 2️⃣ Impressão de boletos não considerando a quantidade de cópias escolhidas.

SUP-96340

Ocorrência: Ao realizar a impressão de boletos, a quantidade de cópias optadas não estava sendo considerada, devido a instância do componente ser criada duas vezes, mas somente na segunda o boleto era enviado efetivamente para a impressão, ficando a primeira instância responsável por recuperar as configurações optadas.

Solução: Foi feito um ajuste para que seja considerada a quantidade de cópias optada no processo de impressão do boleto (Imagens 1, 2 e 3).

A quantidade efetiva de cópias será gerenciada pela impressora física, desta forma, não será realizada emulando em impressoras PDF.

Local>Tela 5.2.15 - Manutenção de contas a receber

📘 2️⃣ Ao selecionar títulos para junção, o sistema apresentava uma mensagem de falha.

SUP-96166 e SUP-96540

Ocorrência: Estava ocorrendo uma inconsistência, ao realizar a junção de títulos na tela “Lançamentos a pagar”.

Solução: Foi feito um ajuste para verificar se o objeto existe e criá-lo se necessário antes de utilizar. Desta forma, ao fazer a junção de títulos não ocorrerá mais a mensagem de falha de segmentação (Imagens 1 e 2).

Local>Tela 6.2.6 - Lançamentos a pagar

📘 2️⃣ Nova funcionalidade de devolução não gerando praça correta.

SUP-96448

Ocorrência: Foi criada uma nova funcionalidade "gerar título a pagar do valor total disponível", na tela “Manutenção de contas a receber, mas foi verificado pela tela “Gerar Título”, que sempre gerava o título para a praça 1(um).

Solução: Foi feito um ajuste para respeitar a praça do título original, sendo 1(um) ou 3(três) (Imagens 1 e 2).

Local>Tela Contas a Pagar

Local>Tela 5.2.15 - Manutenção de contas a receber

📘 2️⃣ Contas a receber diferente da venda no PDV.

SUP-96400

Ocorrência: O valor apresentado no contas a receber era diferente da venda realizada no caixa.

Solução: Foi realizado um ajuste na geração das parcelas do PDV quando o pagamento for realizado com mais de um cheque, ou quando o pagamento for realizado em cheque e com outra forma de pagamento (Imagem 1).

Local>Tela 5.2.15 - Manutenção de contas a receber

[Menu WMS]

 Clique para expandir/recolher

📘 2️⃣ Tela “WMS - Inventário” apresentando inconsistência ao criar um inventário e selecionar os locais de estoque.

SUP-96215

Ocorrência: A tela “WMS - Inventário” estava apresentando uma inconsistência ao transferir peças em massa, devido ao uso de um componente que não havia sido instanciado. Este componente era uma consulta responsável por recuperar o código do endereço da peça para realizar a transferência.

Solução: Foi feito um ajuste para que seja possível realizar a conclusão de uma transferência com sucesso (Imagens 1, 2 e 3).

Local>Tela 7.2.5 - WMS - Inventário
Local>Tela Manutenção e transferências em massa
Local>Tela 1.1.19 - Cadastro de produtos

[Menu Contábil]

 Clique para expandir/recolher

📘 3️⃣ Integração contábil com inconsistência.

SUP-95319

Ocorrência: Ao fazer a integração contábil do módulo fiscal notas de saída, o sistema estava gerando uma inconsistência: insufficient memory for this operation”.

Solução: Foram feitos ajustes e implementado um “select” ao início da integração carregando o plano de contas em memória e a validação da exigência passará a ser validada com o plano de contas carregado em memória, não sendo realizada a consulta no banco de dados. Também foi alterada a lógica de lançamento de “PARTIDA e CONTRA PARTIDA” sendo separado em dois componentes, desta forma o consumo da memória tenderá a diminuir e o desempenho aumentará, uma vez que removerá processamento desnecessário (Imagens 1 e 2).

Local>Tela 9.2.1 - Contábil - Integração

[Menu MDF-e/CT-e]

 Clique para expandir/recolher

📘 2️⃣ Cadastro de CT-e ultrapassando o limite de caracteres permitidos.

SUP-96376

Ocorrência: Ao transmitir CT-e estava sendo apresentada uma inconsistência, tag “<prodPred> -Produto Predominante” ultrapassando o limite de caracteres permitidos (60).

Solução: Foi realizado um ajuste, para limitar a tag “<proPred> - Produto Predominante” com 60 caracteres na transmissão do CT-e.

“Produto Predominante” com descrição com mais de 60 caracteres (Imagem 1).

CT-e transmitido (Imagem 2).

Descrição do produto no DANFE (Imagem 3).

Tag “<prodPred>” no XML (Imagem 4).

Local>Tela 11.1.2 - Cadastro de CT-e
Local>Tela 11.2.1 - Manutenção de conhecimentos de transporte (CT-e)
Local>Tela DANFE
Local>Tela XML

[Menu Manifestação do Destinatário]

 Clique para expandir/recolher

📘 2️⃣ Inconsistência ao consultar NF-e na “Sefaz” em “Manifestação do destinatário”.

SUP-95648

Ocorrência: Ao consultar NF-e estava sendo apresentada uma mensagem de inconsistência, mesmo quando a consulta era realizada normalmente.

Solução: Foi adicionada uma melhoria no retorno da consulta por NSU, para que ao identificar novos documentos, a mensagem apresentada na grade seja de sucesso, uma vez que existem dois tipos de consultas no serviço (consulta por último NSU e consulta por NSU), em qualquer uma das duas que apresentar sucesso ao retornar documentos, a mensagem será condizente com o sucesso da consulta.

Quando houver uma consulta bloqueada, será apresentada uma mensagem que auxiliará na tomada de decisão e esclarecerá o motivo da inconsistência na consulta (Imagem 1).

Local> Tela 16.2.1 - Manifestação do Destinatário


Índice:

Legendas dos tipos de tickets
Legendas da criticidade do ticket
?? Mudança
📗 Melhoria
?? Solicitação
1️⃣ Relevante
2️⃣ Importante
3️⃣ Muito importante

Feedback

Qual é o seu nível geral de satisfação com essas notas de versão?

Clique aqui para responder

  • Sem rótulos