📙 3️⃣ Performance da tela “Relatório cubo comercial estático”.

Na tela “3.3.4 - Relatório cubo comercial estático”, foram feitos ajustes de scripts para melhora de performance, diminuindo o tempo de consulta.

📙 3️⃣ Exibir todas regras utilizadas na integração contábil ao consultar o Lançamento.

Na tela “Consulta de Lançamentos Contábeis”, foi adicionada a coluna "Regras Utilizadas" à tabela de lançamentos contábeis, capaz de armazenar as regras que foram aplicadas a cada lançamento contábil, fornecendo uma visão detalhada das regras envolvidas em cada transação contábil.

📗 3️⃣ Sobreposição da "Splash Screen".

Na tela de abertura do Guarani ERP, foi feita uma melhoria possibilitando a manipulação de outras janelas durante a atualização do sistema realizada pelo Agent.

📗 3️⃣ Integração API RD Station x Guarani (CRM).

O “Integrador CRM” agora possui comunicação com o “CRM da RD Station”. A integração acontece no sentido “ERP → RD Station”, enviando informações de clientes e contatos.

📗 3️⃣ Migração de projetos para Delphi 10 - validando migração GDK.

Foi feita uma atualização do projeto “Conferencia.exe” para o “Delphi” 10, sem alteração de banco. Não será necessário ativar, se manterá o comportamento de uso atual para o usuário. Sendo validada a compatibilidade com o “Conferencia.exe” topo em questões de funcionalidades, desta forma deixará adequado o código fonte/componentes internos (Imagem 1).

📗 2️⃣ Alteração no cadastro de Etiquetas - Tags no cadastro de produtos.

Na tela “1.1.19 - Cadastro de produtos”, foi adicionado um commit para garantir que o dado cadastrado seja persistido no banco quando a operação for confirmada. Ao incluir, editar e ou excluir uma Etiqueta - Tag, o sistema salvará a ação escolhida de modo que ao atualizar o cadastro do produto a ação será mantida (Imagem 1).

📗 2️⃣ Relatório de Gestão de cobrança.

Na tela “1.1.40 - Consultas personalizadas” foi feita a implementação de relatório personalizado, que terá como maior objetivo exibir recebimentos em atraso dentro de um determinado período, bem como também médias e percentuais específicos.

📗 3️⃣ Mensagem de confirmação ao atualizar em massa o “Plano Financeiro e Centro de Custo” de um produto com rateio.

Na tela “2.2.4 - Entrada de notas fiscais”, foi incluída uma mensagem de confirmação ao alterar um Centro de Custo com rateio, permitindo que ao realizar uma atualização em massa de produtos com e sem rateio de Centro de Custo, seja possível escolher atualizar os produtos no qual possui rateio ou não. Ao confirmar atualização em massa de um produto com rateio de Centro de Custo, o rateio será excluído e será aplicado apenas o Centro de custo selecionado. Caso não seja confirmada a atualização em massa de um produto com rateio de Centro de Custo, retornará para a tela “Alteração em massa de itens” para que possa ser cancelada a atualização e desmarcado o item com o rateio.

📗 3️⃣ Melhoria na tela “Gestão de royalties”.

Na tela “3.3.32 - Gestão de royalties”, foi criado o campo “Parametrização do Produto*”, que terá a função de realizar a apuração dos royalties considerando a último percentual de propriedade do produto ou considerando o percentual a cada alteração que houver no produto, referente aos processos de digitação de ordem, entrada de nota recebimento de títulos referentes às vendas (Imagem 1).

📗 1️⃣ Parâmetro para permitir alterar data de ordem duplicada.

Na tela “Parâmetros :: Guarani”, foi criado o parâmetro “Data de digitação padrão da ordem na “Duplicação de ordens“. Esse parâmetro permitirá que ao clonar uma ordem, a data de digitação seja automaticamente preenchida com a data atual. No momento da duplicação, essa data não poderá ser alterada, mas poderá ser modificada posteriormente se o parâmetro "Permite alterar a data da digitação?" estiver configurado como SIM. Desta forma, será possível escolher se a data de digitação ao clonar uma ordem deve ser a data atual ou a data original da ordem clonada, ajudando a evitar inconsistências de data e mantendo a consistência no registro das ordens.

📗 2️⃣ Alteração na tela “Pesquisa de notas fiscais”.

Na tela "4.2.9 - Pesquisa de notas fiscais", foram adicionadas as colunas “Vr Difal FCP, Vr FCP ST Res Ant, Vr Outras Despesas e DIFAL ICMS Vr Dest”. Esses campos serão automaticamente preenchidos com os dados relevantes após a atualização, possibilitando que ao gerar a GIAST, os valores de DIFAL, FCP e FCP ST sejam destacados corretamente e integrados nas telas e relatórios relevantes. O sistema já realiza o destaque desses impostos em campo próprio seguindo as regras de negócio fiscal na NFe e no XML (Imagem 1).

📗 2️⃣ Quantidade de pedidos - Routeasy.

Na tela “4.2.17 - Roteirização - RoutEasy”, foi inserido um contador no rodapé da grade, para contar a quantidade de pedidos existentes, também será possível utilizar a funcionalidade de somatória de registros existente na grade e com isso contabilizar os registros selecionados (Imagem 1).

📗 3️⃣ Alterações Layout NF-e 4.0.

Na tela “Importação da Declaração de Importação (DI)”, foi criado o campo “DI - CPF intermediante.” Este seguirá a mesma regra do campo “DI - CNPJ intermediante”, sendo habilitado quando o “Tipo Intermediação” for “2-Por conta e ordem” ou “3-Encomenda”. Será salvo no mesmo campo que já existia para o CNPJ (NFI_DI_INTERMEDIO_CNPJ).

📗 1️⃣ Inativação de endereços em massa.

Na tela “7.1.1 WMS - Cadastro de depósitos (Endereços disponíveis)”, foi adicionada uma funcionalidade de inativação de endereços WMS através da importação de planilha nos formatos CSV e XLS, que tem por objetivo otimizar o tempo dos usuários ao inativar endereços WMS, proporcionando uma maneira mais eficiente e fácil de realizar essa tarefa. Ao acessar a tela “7.1.1 WMS - Cadastro de depósitos (Endereços disponíveis)” e realizar a importação de uma planilha CSV ou XLS com a formatação de acordo com o modelo disponibilizado, o sistema inativará automaticamente todos os endereços informados na planilha.

📗 3️⃣ Inserção da Observação de base legal em determinados produtos.

Nas telas “10.1.4 - Cadastro de Classificações Fiscais“, “1.1.19 - Cadastro de produtos“, “1.1.3 - Cadastro de clientes“ e “1.1.5 - Cadastro de empresas“, nas abas de exceção fiscal, foi adicionada a coluna “Base Legal para Destaque nas Observações do Item na NF-e“. Essa implementação permitirá ao usuário informar a base legal a nível de item, que será exibida na DANFE e na tag <infAdProd> do XML. O campo "Referência" na tela “Cadastro de clientes”, aba “Comercial”, "Produtos x Clientes" já levava a informação para a DANFE a nível de item, especificamente por cliente, era possível também inserir manualmente as informações no item. A nova função, quando combinada com as anteriores, irá concatenar as informações e trazer todas no item da DANFE caso sejam informadas.

📗 3️⃣ Desativação do Serviço Assíncrono do MDFE.

Na tela “11.1.1 - Cadastro de MDF-e”, ao transmitir um MDF-e, foi feita uma alteração na forma de envio do serviço. A partir de 30/06/2024, o envio do MDF-e passará a ser Síncrono e não mais assíncrono. A opção de envio Síncrono agora será marcada como verdadeira pelo sistema, bem como sua reposta.

📗 3️⃣ Análise e regularização do módulo MDFe.

Na tela “4.2.6 - Expedição”, foi criada uma validação de acesso ao módulo “MDF-e/CT-e”. Ao clicar na opção “Gera Manifesto de Documento Fiscal Eletrônico (MDF-e) ou Gerar Conhecimento de Transporte Eletrônico (CT-e)”, se o módulo “MDF-e/CT-e” não estiver liberado, será apresentada uma mensagem de bloqueio (Imagens 1 e 2).

📘 2️⃣ Tela de validação atrás do processo e lentidão na bipagem dos itens.

Ocorrência: No Coletor, a tela de validação ficava atrás do processo e era apresentada uma lentidão na bipagem de itens.

Solução: Foi retirada a consulta que era feita na quantidade em aberto do item, desta forma se o checkout do local de estoque estiver "DESATIVADO" ou se o checkout estiver optado como "DEPOIS DO FATURAMENTO", esta consulta não será realizada, melhorando a performance na conferência de saída do Coletor.

📘 2️⃣ Guia de armazenagem bloqueando alterações no tipo de endereço.

Ocorrência: No endereçamento do item na armazenagem do “Coletor”, não estava permitindo a alteração de tipo de endereço.

Solução: Foi feito um ajuste para permitir que o tipo de endereço seja alterado ao registrar a armazenagem de um item. Sendo assim, ao abrir o item no Coletor, será apresentado o endereço padrão,mas haverá a possibilidade de alteração conforme a necessidade (Imagens 1, 2 3 e 4).

📘 3️⃣ Inconsistência na abertura do integrador SysPDV.

Ocorrência: Estava ocorrendo uma mensagem de inconsistência ao abrir o integrador SysPDV.

Solução: Foram feitos ajustes para melhorar a integração e assim que não volte a ocorrer a mensagem de inconsistência.

📘 1️⃣ Nomenclatura desatualizada na aba Tributação da Tela 1.1.3-Cadastro de Clientes

Ocorrências: Algumas telas do sistema estavam com a nomenclatura divergentes, onde estava sendo apresentado o regime de tributação como “SUPER SIMPLES” ao invés de SIMPLES NACIONAL.

Solução: Foram realizados ajustes nas nomenclaturas utilizadas no sistema para garantir consistência e clareza. As telas que apresentavam nomenclaturas divergentes foram devidamente corrigidas.

📘 2️⃣ Valor da cotação com mais de duas casas decimais.

Ocorrência: Na tela “Cotação de compra”, o campo valor só aceitava duas casas decimais mesmo o cadastro do fornecedor estando com seis casas decimais.

Solução: Foi feito um ajuste na tela “Cotação de compra” no campo valor, para respeitar a quantidade de casas decimais do cadastro de fornecedores, pois o pedido de compra e entrada de nota já aceitam seis casas decimais após a virgula.

📘 2️⃣ Estoque comprado negativo em alguns produtos

Ocorrência: Foi identificado que havia uma inconsistência no registro do estoque comprado, onde os valores não estavam sendo registrados corretamente.

Solução: Foi feita uma correção no estoque comprado de todos os clientes para prevenir a recorrência dessa inconsistência desta forma, foi liberado um script de correção na próxima atualização do sistema para que o estoque comprado seja registrado corretamente, corrigindo o saldo atual e prevenindo problemas futuros (Imagens 1 e 2).

📘 3️⃣ Aviso ou bloqueio quando for inserido caracteres especiais no campo “Ped.Cliente” em Digitação de Ordens.

Ocorrência: Quando era preenchido o campo "Ped Cliente" com caracteres especiais ao digitar ordens, ocorria uma inconsistência ao faturar e transmitir a ordem, devido a SEFAZ não aceitar alguns desses caracteres.

Solução: Foi feito um ajuste e agora é possível usar caracteres especiais no campo "Ped Cliente" que a SEFAZ não aceita, o sistema tratará esses caracteres na hora de gerar e emitir a NF-e. Desta, forma, eles serão convertidos ou removidos, conforme necessário para evitar inconsistências e garantindo que tudo esteja conforme os requisitos da SEFAZ (Imagens 1, 2 e 3).

📘 1️⃣ Sistema solicitando restauração de corte já efetivado.

Ocorrência: Digitação de ordens bloqueava item que possuísse corte com embalagem diferente para o mesmo pedido, mesmo que o corte já fosse efetivado ou já tivesse pedido gerado.

Solução: Foi realizado um ajuste para que sejam bloqueados apenas itens com cortes “Não efetivados“ (Imagens 1 e 2).

📘 1️⃣ Valor incorreto de pedido sem itens.

Ocorrência: O valor do pedido não era zerado quando todos os itens eram cortados no “Coletor e Conferência”.

Solução: Foi realizado um ajuste para que o valor do pedido seja zerado quando todos os itens estiverem cortados no “Coletor e Conferência”.

📘 2️⃣ Peso líquido indevido na importação de DI.

Ocorrência: Ao importar uma DI na tela "Cadastro de notas", o peso total líquido estava diferente do valor presente no XML.

Solução: Foi feito um ajuste para que o campo de peso total líquido seja preenchido corretamente, conforme o valor presente no campo <cargaPesoLiquido> do XML. Isso garante que os dados estejam corretos e em conformidade (Imagens 1 e 2).

📘 1️⃣ Valor do relatório de contas pagas por tipo de baixa com valor divergente.

Ocorrência: No “Relatório de contas a pagar”, os valores no resumo estavam indevidos ao imprimir o relatório. Isso ocorria porque o fornecedor não estava sendo devidamente associado ao título, baixa de pagamento e parcela, resultando em duplicidade no agrupamento e nos totais.

Solução: Foi feita uma correção para que o fornecedor seja corretamente vinculado ao título, baixa de pagamento e parcela. Agora, o relatório mostrará os valores corretamente agrupados e o somatório final estará correto e consistente com os valores detalhados no relatório.

📘 1️⃣ Alterando nomenclatura de "Centro custo" para "Plano Financeiro" em algumas telas.

Ocorrência: Algumas telas do sistema ainda estavam com a nomenclatura antiga que antes era “Centro de custo” e agora passou a ser “Plano Financeiro”.

Solução: A nomenclatura foi alterada nas telas “6.3.5 - Relatório de contas a pagar e 6.3.3 - Relatório de pagamento de compras” para “Plano Financeiro” e na impressão dos relatórios (Imagem 1).

📘 1️⃣ Relatório de contas a pagar trazendo um plano financeiro que não corresponde.

Ocorrência: No “Relatório de contas a pagar”, o plano financeiro exibido na grade não correspondia ao plano financeiro registrado na “Entrada de notas fiscais”. Isso causava uma discrepância, fazendo com que o plano financeiro não fosse apresentado corretamente na tela de “Lançamentos a pagar”.

Solução: O sistema foi ajustado para sempre utilizar o plano financeiro especificado no título do contas a pagar. Assim, se um plano financeiro diferente for adicionado na "Entrada de notas fiscais" e no "Contas a pagar", o relatório agora respeitará e exibirá o plano financeiro adicionado no contas a pagar, garantindo a consistência das informações.

📘 1️⃣ Cubagem sendo alterada incorretamente.

Ocorrência: Em “Cadastro de produtos”, havia uma inconsistência no cálculo do volume (cubagem) da “Dimen. unid. de venda”. O cálculo deveria considerar as dimensões da embalagem e dividir o resultado pela quantidade da própria embalagem. No entanto, quando a cubagem da unidade de venda era alterada, o sistema revertia para a opção original, que considerava as dimensões da unidade e dividia pelo volume da embalagem. Dessa forma, as alterações feitas nos campos da unidade de venda não eram consideradas, tornando-as indiferentes.

Solução: Foi feito um ajuste para que o cálculo do volume (cubagem) seja feito devidamente com base nas dimensões informadas para a unidade de venda. Agora, o sistema sempre considerará essas dimensões, sem reverter para a opção anterior de cálculo. Isso significa que qualquer alteração feita nos campos da unidade de venda será aplicada corretamente, independentemente das dimensões da embalagem (Imagem 1).

📘 2️⃣ Arquivo SPED ICMS/IPI sem o registro 1100.

Ocorrência: Tela “Declaração de Exportação” validando a inclusão da própria nota na grid: “Nota já informada em declaração de exportação!”.

Solução: Foi realizado um ajuste para que a validação seja realizada somente quando a nota estiver adicionada em outra declaração.

📘 2️⃣ Alterando o comportamento no número de caracteres da GNRE.

Ocorrência: Quando o campo "Protocolo GNRE" era preenchido com mais de 30 caracteres, ocorria uma inconsistência, devido o máximo permitido que era de 30 caracteres.

Solução: Foi feito um ajuste para que, se o usuário preencher esse campo com mais de 30 caracteres, na geração da GNRE a mensagem seja automaticamente cortada para incluir apenas os primeiros 30 caracteres. Assim, será evitada a inconsistência e garantido que o processo ocorra normalmente (Imagens 1, 2 e 3).

Âncora
indice indice

Índice:

Voltar ao topo