Aviso importante!
Esta nota de versão é apenas uma prévia do próximo lançamento. Observe que os manuais do usuário e de instalação e a mídia FTP não foram atualizados.
Além disso, informamos que as correções e implementações descritas aqui podem ser alteradas, excluídas ou adicionadas antes do lançamento final.
Liberamos com antecedência para ajudar nossos clientes a planejarem a atualização do sistema.
Data de previsão de publicação: 15/08/22
Ticket | Criticidade |
📗 Implementação | 1️⃣ Relevante |
📘 Solicitação | 2️⃣ Importante |
📙 Mudança | 3️⃣ Muito importante |
Notas de versão:
📘 2️⃣ Entrada de notas fiscais - Devolução de venda (ERP-3559)
Ocorrência: O sistema não estava carregando as informações de IPI ao importar XML de nota de devolução, na tela “Entrada de notas fiscais”.
Solução: Foi feito um ajuste para que a nota de devolução mantenha as informações de IPI ao importar o XML, na tela “Entrada de notas fiscais”.
Entrada da nota após importação do XML (Imagem 1).
Local>Tela 2.2.4 - Entrada de notas fiscais
📗 1️⃣ Inconsistência na validação da atualização em massa (ERP-3424)
Na tela “Atualização Massa Digitação de Ordem”, que pode ser acessada pela tela “3.2.12 - Digitação de ordens”, foi feita uma correção para que seja possível atualizar em massa o campo do tipo de “Frete” para todas as ordens selecionadas, com a condição de que o frete seja compatível com a tabela de preço e com o status da nota. Caso haja bloqueio por incompatibilidade, será aplicado somente na ordem em questão, de forma que as demais serão atualizadas.
Quando algumas ordens não forem atualizadas, aparecerá uma mensagem (Imagem 1).
Conforme padrão da tela, itens não atualizados ficarão destacados em vermelho, com o “log” detalhado disponível no botão “+” e os atualizados serão marcados em azul.
Após atualização em massa (Imagem 2).
A ordem que se encontra em vermelho não foi atualizada com seu respectivo “log” e a ordem em azul foi atualizada com o respectivo “log” (Imagem 3).
📘 2️⃣ Inconsistência ao importar pedidos da Neogrid (ERP-3530)
Ocorrência: Ao fazer importação de pedidos Neogrid que estavam com a embalagem zerada, estava apresentando a inconsistência: “Núm. Unid. Consumo na Embalagem Pedida não informado para o item.“
Solução: Foi inserida uma correção nas telas “3.2.42 - Neogrid - integração leiaute orders e 3.5.7 - Guarani Móvel - Android - importação de dados”, quando for importar algum pedido Neogrid que esteja com a embalagem zerada, será considerado o valor “Padrão 1” para essa quantidade.
Importação de pedidos Neogrid pela tela: “3.5.7 - Guarani Móvel - Android - Importação de dados” (Imagens 1, 2 e 3).
Importação pedidos Neogrid pela tela: “3.2.42 - Neogrid - integração leiaute orders” (Imagens 4 e 5).
Observação Importante: “Assim que for validada a importação de pedidos Neogrid pela tela “3.5.7 - Guarani móvel - Android - Importação de dados” e estiver atendendo a necessidade, a tela: “3.2.42 - Neogrid - integração leiaute orders” será descontinuada.
Local>Tela 3.2.42 - Neogrid - integração leiaute orders
Local>Tela 3.5.7 - Guarani móvel - Android - Importação de dados
📘 1️⃣ Produto "semiacabado" contido no produto "acabado" não movimentava a entrada de estoque na devolução de venda (ERP-3250)
Na funcionalidade de devolução de produto semiacabado com guia de armazenagem, foi feito um ajuste para que ao realizar uma devolução, sendo total ou parcial e com a opção para movimentar WMS para itens de vendas com guia, o semiacabado do produto também constará na guia de armazenagem gerada por ocasião da devolução.
Para efetuar a configuração, será necessário que na tela “1.1.19 - Cadastro de produtos” os campos dos itens semiacabados estejam marcados da seguinte forma (Imagem 1):
Separação: “SIM”; Conferência: “SIM”; Movimenta Estoque: “Movimenta apenas no faturamento do produto acabado”. |
|---|
Ao realizar uma devolução parcial ou total, irá aparecer apenas o “semiacabado” configurado e correspondente ao produto acabado para que possa endereçar tanto no sistema ERP como no Coletor, para que retorne ao estoque WMS (Imagem 2).
📗 2️⃣ Não permitir utilizar o mesmo endereço de Picking já utilizado em outro produto (ERP-2951)
Na tela “Parâmetros :: Guarani” foi criado o parâmetro “WMS - permite utilizar o mesmo endereço de picking para mais de um produto?”. Quando estiver habilitado como “NÃO”, não permitirá colocar dois ou mais produtos no mesmo endereço de Picking, se o endereço já estiver sendo utilizado por outro produto, apresentará uma validação informando qual produto já consta nesse endereço (Imagem 1).
Se o parâmetro estiver habilitado como “SIM”, irá ter o mesmo comportamento já existente (Imagem 2).
Ao tentar associar um produto a um endereço existente em outro produto, mostrará a validação (Imagem 3).
Produto que está no endereço de Picking informado na validação (Imagem 4).
Ao associar o endereço para o mesmo produto, deverá informar uma data de validade diferente da data que já consta, sendo este um comportamento já existente (Imagem 5).
Alterando a data de validade, o sistema permitirá a associação do endereço já existente (Imagem 6).
O mesmo comportamento será validado no Coletor pelo aplicativo “Armazenagem” e “Transferência de endereço”, não sendo permitido informar um endereço existente em outro produto.
Armazenagem (Imagem 7).
Transferência de endereço (Imagem 8).
Ao desativar um endereço na tela “7.1.1 - WMS - Cadastro de depósitos (Endereços Disponíveis)” e tentar informar o endereço desativado para um produto, será apresentanda uma validação não permitindo executar esta ação pelo Coletor no aplicativo “Transf. Endereço” (Imagens 9 e 10).
Quando o produto já constar em um endereço Picking cadastrado, na Tela “1.1.19 - Cadastro de produtos” e tentar endereçar pelo Coletor no aplicativo “Armazenagem”, em um endereço diferente do que estiver no cadastro do produto, o sistema não permitirá a ação (Imagem 11).
Caso seja informado o mesmo endereço de Picking para o Pulmão, o sistema não irá barrar por se tratar de tipos de endereços diferentes.
Picking e Pulmão com o mesmo endereço (Imagens 12 e 13).
📗 2️⃣ Relatórios contábeis (ERP-3381)
Foi realizada a implementação do botão “Excluir” nas grades de filtro, permitindo ao usuário selecionar um ou mais registros para sua exclusão. Desta forma, haverá a possibilidade de escolher um ou mais registros para “Exclusão”.
Essa implementação foi desenvolvida, para que não ocorra a confusão com a funcionalidade do botão “Limpar e Limpar Tudo”:
|
Aba “Tipo Documento (Módulo)” (Imagem 1).
Aba “Conta Contábil” (Imagem 2).
Aba “Centro de Custo” (Imagem 3).
Aba lote (Imagem 4).
Aba “Filial” (Imagem 5).
Selecionando e excluindo o filtro desejado
Exclusão (Imagem 6).
Foi implementado o relatório Balancete por centro de custo, sendo agrupado por “Centro de Custo ou por Conta Contábil”.
Relatório Balancete Contábil por Centro de Custo e a opção de agrupar (Imagem 7).
Relatório gerado (Imagem 8).
No agrupamento será sempre exibido o “Centro de Custo” e quais contas movimentaram no período informado.
Balancete por “Centro de custo” agrupado por “Conta Contábil” (Imagem 9).
Relatório gerado (Imagem 10).
Esse agrupamento será exibido na mesma estrutura do Balancete por conta contábil, entretanto para as contas analíticas, serão exibidos quais centros de custos movimentaram no período informado. |
Será possível escolher a opção “Mostrar resultado” na grade para os relatório do “Balancete por centro de custo”.
Balancete por centro de custo agrupado por Centro de Custo GRID (Imagem 11).
GRID e Balancete por centro de custo agrupado por Conta Contábil GRID (Imagens 12, 13 e 14).
Foi Implementado o relatório Razão Geral por Centro de custo:
Relatório Razão Geral por Centro de custo (Imagem 15).
Relatório gerado (Imagem 16).
Relatório Razão Geral por centro de custo sempre será exibido a Conta Contábil e o Centro de Custo no cabeçalho; e no detalhe todos os lançamentos que movimentaram a conta e centro de custo. |
Será possível exibir o resultado na grid:
Razão Geral por Centro de Custo GRID (Imagem 17).
GRID (Imagem 18).
Implementado melhorias na geração dos relatórios Os relatórios:
Sofreram melhorias na exibição do logo, na dinâmica antiga cada vez que o cabeçalho era impresso, ou seja, a cada nova página, era carregada a imagem do logo novamente para o relatório, isso ocasionava dois problemas, como lentidão na exibição do relatório e se caso o relatório possuísse muitas páginas era exibida a inconsistência “Out of Memory”. Para corrigir as inconsistências foi feita uma implementação para que o logo seja carregado apenas na exibição da página, sendo assim será carregado apenas uma vez. |
📘 1️⃣ Inconsistência interna ao tentar processar débito de comissão em massa (ERP-3504)
Ocorrência: Quando tentava processar o débito de comissão em massa na tela “Débito de títulos para representantes em massa”, ocorria uma inconsistência interna. A tela não atualizava e perdia suas funcionalidades após concluir o processo.
Solução: Foi feito um ajuste para que seja possível atualizar em massa, não sendo necessário fechar a tela e abrir novamente para consultar os débitos que não foram processados (Imagem 1).
Após clicar em “OK”, a tela será atualizada automaticamente (Imagem 2).
Local>Tela 5.2.6 - Débito de títulos para representantes em massa
📘 2️⃣ Correções da importação de DI e geração da NF-e de nacionalização (ERP-3548)
Ocorrência 1: O campo “Peso Líq.” não estava sendo carregado, mesmo com a tag do XML da DI estando preenchida como “<dadosMercadoriaPesoLiquido>”.
Solução 1: Foi feito um ajuste para que o campo “Peso Líq.” seja preenchido com as informações da tag “<dadosMercadoriaPesoLiquido>” do XML.
Peso preenchido ao importar XML (Imagem 1).
Ocorrência 2: O campo “Acréscimo” estava sendo carregado indevidamente em todos os itens, com o rateio do valor de acréscimos do primeiro item. Contudo, os demais itens possuem um valor próprio de acréscimo e estes deveriam ser somados ao valor unitário.
Solução 2: Foi feito um ajuste, para que o campo “Acréscimo” seja preenchido corretamente com as informações da tag “<acrecimo><valorReais>” do XML, .
Preenchimento do acréscimo, item a item, de acordo com o XML (Imagem 2).
Ocorrência 3: Quando se tentava copiar os valores do Excel para grid no campo “Peso”, com a opção “Colar especial”, copiava somente a primeira célula. Sendo necessário que copiasse todos os valores na seguinte sequência “Excel com valores no formato: Número”, “Contabil”, “Geral”. Esta inconsistência ocorria, pois o arquivo Excel estava sendo copiado de outra máquina, ou seja, o arquivo não era local.
Solução 3: Após identificada a inconsistência, concluiu-se que a opção “Colar Especial“ está funcionando corretamente.
Ocorrência 4: Os campos “Tx. Siscomex” e “Vl. Adicionais”, somente estavam recalculando o rateio caso a base de ICMS, alíquota e valor estivessem preenchidas. Contudo, deveria ser rateado independente do ICMS, umas vez que existiam processos de importação sem ICMS.
Solução 4: Foi feito um ajuste para que os campos “Tx. Siscomex” e “Vl. Adicionais” sejam recalculados mesmo que a alíquota ICMS esteja como zero.
Campos “Taxa Siscomex” e “Adicionais” sendo recalculados após alteração em massa da alíquota ICMS 0,0% (Imagem 3).
Ocorrência 5: Os campos obrigatórios não ficavam grifados em vermelho ao importar dados para gerar a Nota Fiscal eletrônica e alguns dos campos obrigatórios estevam faltando informações, dificultando a identificação para correção.
Solução 5: Será tratado como uma melhoria para melhor atendimento das necessidades do usuário.
Ocorrência 6: O campo “Vr. ICMS” permanecia com valores, mesmo sem conter esta informação no XML da DI e também zerava a Alíquota reduzindo 100% da base de ICMS na atualização em massa.
Solução 6: Foi feito um ajustado para que o campo “Vr. ICMS” seja zerado após a atualização em massa para alíquota 0,0%, quando o ICMS estiver zero no XML.
Atualização em massa da alíquota ICMS (Imagem 4).
Recalculo após atualização em massa (Imagem 5).
Local>Tela 4.1.1 - Cadastros de notas fiscais
📘 1️⃣ Lentidão ao consultar na tela “Cadastro Ativo Imobilizado e CIAP” (ERP-3520)
Ocorrência: Estava ocorrendo uma lentidão quando realizava pesquisa na tela “Cadastro de Ativo Imobilizado e CIAP”. Levava o tempo de vinte e cinco segundos, para pesquisar trezentos e quarenta produtos.
Solução: Foi feito um ajuste quanto a performance da tela “Cadastro de Ativo Imobilizado e CIAP”. Após este ajuste, o tempo foi reduzido para um segundo (Imagem 1).
Com o intuito de melhorar a experiência do usuário:
Na tela “Cadastro de Ativo Imobilizado e CIAP”, a aba “Total Aprop. C/Componente” não estava trazendo as informações. Foi feito um ajuste para que apresente as informações corretamente. |
|---|
Aba “Total Aprop. C/Componente” (Imagem 2).
Local>Tela 10.1.18 - Cadastro de Ativo Imobilizado e CIAP
📗 3️⃣ Guarani Móvel - Android - importação de dados, vincular com o Telemarketing (ERP-3453)
Foi feita uma implementação na tela “3.5.7 - Guarani Móvel - Android - importação de dados”, para ter a opção de ao importar pedidos digitados pelo AFV, que seja vinculado ao “Telemarketing”. Desde que sigam as configurações necessárias.
1º Passo - deve-se ter configurada no sistema a origem como “Telemarketing”, esta origem deve ser feita pela tela “3.5.7 - Guarani Móvel - Android - importação de dados”, no menu Ferramentas> Origens de Pedidos> Telemarketing deve estar marcado (Imagem 1).
2º Passo - o tipo de ordem de venda, orçamento e as tabelas de preços devem estar configurados na tela de configuração do telemarketing (Imagem 2).
3º Passo - No cadastro do cliente do pedido, deve ter a configuração para aquele canal de venda do representante que seja do “Telemarketing” (Imagens 3 e 4).
Ao importar os pedidos na tela “3.5.7 - Guarani Móvel - Android - importação de dados”, para cada pedido importado (desde que atenda as configurações) será criado um “Agendamento no telemarketing” do tipo receptivo com: Data atual, Hora de início da jornada de trabalho (já cadastrada nas configurações), Motivo - “AGENDAMENTO AUTOMÁTICO” (criado este motivo nesta tarefa, para separar dos demais que o cliente utiliza) e a Observação como “Agendamento gerado via importação de pedidos” (Imagens 5 e 6). |
Se o tipo do pedido for um tipo de ordem para orçamento, irá gerar um orçamento no “Telemarketing”, sendo possível transformá-lo em venda, processo que já é feito para usuários do Telemarketing (Imagem 7).
Se o tipo do pedido for um tipo de ordem para venda, irá gerar um pedido de venda no “Telemarketing” (Imagem 8).
Na tela “14.2.1 - Telemarketing - Operação”, foram criados os campos “Tipo” e “CVI - Origem pedido”, na grade de orçamentos e pedidos (Imagem 9).
Na tela “3.2.12 - Digitação de Ordens”, na aba “Consulta” foi criado o campo “CVI - Origem pedido” na grade de consulta (Imagem 10).
Na aba “Manutenção”, em “Observações” foi criado o campo “CVI - Origem pedido” (Imagem 11).
Na tela “3.2.26 - Pesquisa de ordens” foi criado o campo “CVI - Origem pedido” na grade (Imagem 12).
Na tela “3.2.14 - Emissão de ordens”, foi criado o campo “CVI - Origem pedido” na grade (Imagem 13).
📗 1️⃣ Criar vínculo da tabela de preço para o cliente (ERP-3404)
Na tela “3.2.45 - Configuração Integração B2UD” foi criado um cadastro de “Grupos de Compradores” na aba “Compradores”, exclusivo para a integração B2B. Onde será possível criar vínculos de tabela de preço por cliente. Desta forma, informará as tabelas por cliente e também por grupo de compradores, facilitando o vínculo entre os clientes e as tabelas (Imagem 1).
