Gestão Empresarial PME | GO UP - 5.10.3.28

Problema: ao gerar o Livro Caixa Digital do Produtor Rural (LCDPR) a partir da tela de Livro Caixa Digital do Produtor Rural (F603LPR), o sistema duplicava erroneamente o arquivo de baixa por aproveitamento de crédito.

Correção efetuada: ajustamos a rotina de geração do Livro Caixa Digital do Produtor Rural para que não duplique esses registros no arquivo.

Problema: ao gerar a Nota Fiscal de Saída, o sistema passou a não calcular os impostos agro, tanto em notas geradas via Web Service, quanto em notas digitadas manualmente pela tela de Notas Fiscais de Saída (F140GNF).

Correção efetuada: ajustamos para que ao gerar a Nota Fiscal de Saída, o sistema calcule os impostos agro se o parâmetro CalImpAgro estiver definido como S-Sim.

Problema: Ao alterar a quantidade a fixar de uma ordem de compra listada na tela de Fixação (F439FIX), o sistema s perdia nos cálculos dos royalties exibidos na parte inferior da tela.

Correção efetuada: Identificamos o processo que estava causando o problema e reparamos a situação.

Adicionamos na documentação do campo Inscrição Estadual das telas F095CAD e F070FCA, uma observação informando que não é permitido informar o caractere barra (/), no preenchimento deste campo.

Complementamos a documentação do parâmetro global NFE-OBSADICITEM, exclusivo para o GO UP, com a seguinte observação: ao utilizar esse parâmetro, na tag <infAdProd> do .XML da nota fiscal de saída serão impressos apenas os valores que correspondem ao parâmetro global, não fazendo a concatenação com uma mensagem gerada na tela F024MSG e atribuída à nota fiscal ou ao item da nota.

Ajustamos a documentação do Bloco 1 do SPED Fiscal, no tópico do Registro 1700 - DOCUMENTOS FISCAIS UTILIZADOS, substituindo as menções ao campo E660NFV.SITNEL por E660IDE.SitDoe.

Esta informação, anteriormente equivocada, causava confusão e erro no processo na geração do SPED Fiscal, pois o campo SITNEL não é alimentado na integração com a Gestão de Tributos.

Problema: a tag indJud não era gerada com a informação correta para naturezas de rendimento com obrigatoriedade no R-4010 da EFD-Reinf.

Correção efetuada: corrigimos a geração do arquivo .XML para trazer a tag indJud seguindo a configuração do dispositivo fiscal.

Problema: os registros D695, D696 e D697 não eram gerados para o perfil B do SPED Fiscal (F669EFD).

Correção efetuada: corrigimos a geração dos registros acima no arquivo do SPED Fiscal.

Complementamos a documentação da EFD-Reinf quanto aos campos-chave nas telas de cadastro e web services. No caso das telas de cadastro, inserimos a informação de que os campos-chave do .XML não são editáveis. Confira a tabela com a chave de negócio que será verificada em cada tela.

No caso dos web services, inserimos a informação de que, caso seja passado um registro com os mesmos campos-chave, o sistema vai editar o registro existente em vez de bloquear a informação. Confira a tabela com a chave de negócio que será verificada em cada web service.

A integração do R-4010 e R-4020 não reconhecia a baixa de títulos originados de nota fiscal com retenção de PIS/COFINS/CSLL/Outras quando esse título havia sofrido substituição antes de seu pagamento. Isso ocorre porque o título substituto não tem vínculo com nota de entrada, sendo reconhecido como título avulso para fins de integração da EFD-Reinf e, portanto, era integrado somente caso houvesse contribuições sociais retidas na baixa.

A fim de resolver isso, disponibilizamos o identificador de regras IMP-690REGCOMP. Quando ativo, permite que sejam integradas as baixas de títulos de notas fiscais com impostos retidos por competência cujo titulo tenha sofrido substituição.

Problema: ao carregar um bem acréscimo nas telas F670EBN e F670EBI, o campo Vida Útil Total do Bem não era sugerido conforme cadastrado na espécie.

Correção efetuada: ajustamos as telas para que a sugestão ocorra conforme o cadastro da espécie, incluindo a Vida Útil Total do Bem. Esse comportamento já ocorre com os demais campos relacionado à depreciação do bem.

Por vezes, fornecedores são cadastrados sem informação no campo % IRRF, da aba Detalhes na tela de Cadastro (F095CAD). Ao gerar uma preparação na tela de Entrada de Preparação/Movimento de Caixa e Bancos (F600GEC) associada a um desses fornecedores, não haverá geração do imposto IRRF para esse título. Para evitar confusão com esse comportamento, implementamos uma mensagem de aviso na tela de Entrada de Preparação... (F600GEC), com o texto O percentual do IRRF não foi informado na tela Cadastros > Clientes e Fornecedores > Fornecedores > Cadastro (F095CAD). O Imposto de Renda não será gerado. Cancelar o processo?, a ser exibida no momento em que é feita a preparação de movimento de bancos.

Problema: ao processar a tela de Estorno Movimentos Aplicações (F6060EMA), se possuísse mais de um resgate, com valores diferentes realizado no mesmo dia, a consulta da conta interna deixava incorreto o valor do estorno do segundo resgate.

Correção efetuada: corrigimos a rotina para que o valor dos estornos de resgate sejam gerados conforme respectivo valor de resgate.

Problema: ao processar a baixa de títulos via tela de Retorno da Cobrança Escritural (F310RTB), caso esse retorno da cobrança possuísse muitos títulos, ocorria o erro Access Violation.

Correção efetuada: corrigimos um vazamento de memória na rotina, de forma que não ocorrerá o erro mencionado no retorno da cobrança escritural.

Problema: ao executar o processo automático utilizando a Rotina Sapiens 148 (Retorno da Cobrança Escritural) em conjunto com o Identificador de Regras CRE-310RTBDI01, o log de execução estava apresentando mensagem Divergência do valor cobrado pelo banco. Caso houver e-mail do sacado ou cliente cadastrado, deseja enviar e-mail informando a divergência?. Esse comportamento não deveria ocorrer, posto que mensagens de interação com o usuário não são válidas em ambiente de processo automático.

Correção efetuada: ajustamos para que, ao utilizar o Identificador de Regras CRE-310RTBDI01 e o Processo Automático configurado com a Rotina Sapiens 148 (Retorno da Cobrança Escritural) seja assumido como verdadeiro para o envio de e-mail. Desta forma, não será apresentado retorno de mensagem onde é solicitado iteração como o usuário.

Em melhoria na usabilidade de nossos sistemas e na integração entre o Gestão Empresarial | ERP e o eDocs, complementamos os pré-requisitos em relação ao EFD-Reinf, onde enfatizamos em nosso Manual do Usuário a etapa de ativação com o MogoDB para a realização da entrega do Reinf. Confira a nossa documentação e conheça os detalhes em relação ao EFD-Reinf.

o processo de integração entre o Gestão Empresarial | ERP e o eDocs pode ser conferido através deste link.

Ao importar um cupom fiscal do Gestão de Supermercado utilizando o web service com.senior.g5.co.int.varejo.nfce, porta ImportarNfce, onde houve pagamento do cheque e havia a necessidade de troco, os títulos não eram gerados conforme é devido. Foi alterada a importação do cupom fiscal para gerar os títulos adequadamente.

Atualizamos a documentação do web service Com.senior.g5.co.mcm.cpr.notafiscal, porta GravarNotasFiscaisEntrada, no tópico Importante, adicionando a informação de que o tipo de processamento 3 - Cancelamento não permite a geração de uma nota fiscal já cancelada no ERP. É fundamental que a nota fiscal esteja previamente cadastrada e fechada no sistema.

Além disso, ainda detalhamos a parametrização do sistema para realização deste processo. Para saber mais detalhes, acesse a documentação.

Problema: ao inserir um item de serviço na nota de entrada utilizando Ação SID, era apresentada a mensagem Valor máximo de retenção de INSS atingido., parando a inclusão do registro.

Correção efetuada: ajustamos para que a mensagem acima não apareça durante a execução da Ação SID.

Complementamos a documentação da tela Contratos de Venda (F160NOV) com o comportamento do sistema em relação à validade da tabela de preços. Para conferir, acesse nosso Portal.

Problema: ao utilizar a tela Contratos de Venda (F160NOV) para editar um contrato já gerado de forma incorreta, ou seja, que contenha a data do campo Inicio de Reajuste menor que a data do campo Inicio de Faturamento, o sistema exibia a mensagem de erro Início de reajuste não pode ser menor que data de início de faturamento ao se mover para qualquer aba da tela.

Correção efetuada: alteramos o processo no sistema para consistir o campo Inicio de Reajuste quando estiver inserindo uma contrato novo e estiver na aba Complemento da tela Contratos de Venda (F160NOV) ou, quando estiver editando algum campo na aba Complemento e o contrato carregado for um contrato que foi inserido incorretamente, neste caso será necessário deixar as datas coerentes.

Revisamos a documentação do processo de Geração de Nota fiscal de Transferência via Nota Fiscal de Saída e adicionamos a observação de que a série da nota de entrada é mantida conforme a nota de origem (saída), sendo necessário tê-la cadastrada em ambas as filiais. O sistema utiliza a mesma série da nota de saída na geração da nota de entrada tipo 11 e faz uma validação quando a série da nota não está cadastrada na filial de destino.

Problema: ao utilizar a tela Faturamento de Pedidos Agrupado (F140LOT) para gerar uma nota fiscal de saída via pedido, o sistema permitia zerar o valor do campo Max. de Itens na Nota e, ao processar a nota, era exibida a seguinte mensagem de erro: Erro no processamento do pedido nº XXXX - Valor da nota fiscal menor ou igual a zero.

Correção efetuada: alteramos o processo no sistema para que, ao utilizar a tela Faturamento de Pedidos Agrupado (F140LOT) para gerar uma nota fiscal de saída via pedido, não seja possível salvar o valor zerado no campo Max. de Itens na Nota ao sair da tela. Ao entrar na tela novamente, caso o valor estiver zerado, será informado o valor padrão de 990 para este campo.

Problema: ao utilizar a tela Notas Fiscais de Saída (F140GNF) para gerar uma nota fiscal de saída, utilizando uma forma de pagamento com o tipo igual a 13 (Troca de Mercadoria), o sistema apresentava a seguinte mensagem de erro ao gerar o arquivo XML: Forma de pagamento Troca de mercadorias não é aceita pela Sefaz. (Consulte o manual de orientações do contribuinte Sefaz).

Correção efetuada: alteramos o processo no sistema para que, quando estiver sendo utilizada a forma de pagamento com o tipo igual a 13 (Troca de Mercadoria) na nota fiscal de saída e for gerado um arquivo XML, o sistema não exiba a mensagem de erro citada anteriormente e converta o tipo de pagamento 13 (Troca de Mercadoria) informado no ERP para 99 (Outros) que será aceito pela Sefaz.

Problema: ao utilizar o botão Seleção na tela Faturamento em Grade (Análise de Embalagens) (F140FGR) para informar filtros para o campo Tipo Pedido, o sistema carregava pedidos com o tipo informado durante a seleção e também pedidos com a situação igual a 9 (Reposição).

Correção efetuada: alteramos o processo no sistema para que, ao utilizar a tela Faturamento em Grade (Análise de Embalagens) - Seleção (F140SFG) para informar filtros do tipo do pedido, sejam carregados na tela apenas os pedidos que são do tipo informado, e não carregar os pedidos do tipo 9 (Reposição) junto com eles.

Problema: em alguns casos, ocorria um erro no aplicativo ao realizar o processo de autenticação via SAML e isto impedia o login de alguns usuários.

Correção efetuada: corrigimos esse comportamento para que o login seja feito normalmente.

Atualizamos a descrição do campo Nº Ordem Compra da tela F420GOC, detalhando as informações sobre o sequenciamento e utilização de numeração das ordens de compra pelo sistema. Para saber mais, acesse a documentação.

Problema: ao importar a ordem da compra para nota fiscal de entrada com o parâmetro Tipo acerto (arredondamento) previdenciário igual a 2 - Trunca na F095CAD, o valor do item de produto retornava com um centavo de diferença entre a ordem de compra e a nota fiscal de entrada.

Correção efetuada: ajustamos a situação acima para que retorne o mesmo valor da ordem de compra na nota fiscal de entrada.

Adicionamos na documentação da tela de Nota Fiscal de Entrada Agrupada (F440GNE), a descrição do campo Base Cálc. Créd das guias Produtos e Serviços, e quais as condições do sistema para preenchimento do valor deste campo. Para saber sobre o funcionamento, acesse a documentação.

Problema: em um cenário em que tinha-se um pedido faturado por uma nota fiscal e essa possuía uma quantidade faturada maior em relação ao pedido, e, em seguida era feita uma nota fiscal de devolução para devolver a nota fiscal de saída, ao tentar reabilitar a nota fiscal de devolução, ocorria uma consistência que informava que a quantidade aberta no pedido era insuficiente para permitir a reabilitação. Verificamos que essa consistência tinha como objetivo bloquear o processo de reabilitação da nota fiscal de devolução quando o pedido já tinha sido atendido por outra nota fiscal após o fechamento da nota fiscal de devolução.

Correção efetuada: ajustamos a rotina para que mesmo que a quantidade em aberto do pedido for menor em relação a nota fiscal, caso o mesmo não tenha sido atendido por outra nota fiscal, a consistência não ocorra, permitindo assim a reabilitação da nota fiscal de devolução.

Problema: na tela F440GNE, caso o usuário reabilitasse uma nota fiscal que tinha contagem com divergência, a rotina zerava a contagem efetuada (E440ICT), porém não eliminava as divergências apontadas (E440CDV). Porém, se a contagem fosse refeita, não haveriam divergências encontradas, mas a distorção da contagem anterior permanecia. Ao excluir a nota fiscal, a contagem também era refeita, entretanto, as divergências permaneciam.

Correção efetuada: corrigimos o sistema para que elimine também as divergências da contagem, ao reabilitar uma nota ou excluir.

Problema: na tela F000INE, era apresentado duas vezes o campo do depósito na grade de itens de produto.

Correção efetuada: alteramos a tela para que apresente apenas uma vez o campo do depósito na grade.

Problema: ao realizar o cancelamento de ordem de compra com itens de produto através da função CancelaSaldoOrdemCompra, quando a ordem de compra ainda estava na situação 9 - Não Fechada, o item da ordem de compra era cancelado, porém a solicitação de compra gerada pela ordem de compra não tinha a quantidade cancelada atualizada.

Correção efetuada: alteramos a rotina de cancelamento da ordem de compra através desta função para que atualize a quantidade cancelada da solicitação de compra de produto vinculada à ordem de compra, da mesma forma como já é atualizado para solicitações de compra de itens de serviço.

Problema: ao executar uma atualização de estoques ou valorização das transferências, seja por tela ou web service (síncrono ou assíncrono), os registros de logs gravados na tabela Estoques - Fechamento dos Estoques (E215FES) não ficavam corretos, dificultando a análise em casos onde a rotina não executava por completo.

Correção efetuada: ajustamos o sistema para que os registros de logs sejam gravados corretamente na tabela E215FES, permitindo uma melhor análise na tela F215CFE.

Problema:quando o inventário indicava para bloquear movimentação, itens que eram inseridos no inventário através da contagem, não tinham a movimentação bloqueada.

Correção efetuada: ajustamos a rotina para que, ao inserir um item no inventário através da contagem, seja respeitado o bloqueio de movimentação indicado no cabeçalho do inventário.

Problema: o web service de terceiro não retornava as informações de tipo array, quando o agente Java está habilitado.

Correção efetuada: adicionamos tratamento para nodes do tipo array na rotina, utilizada pelo agente Java.

Ao importar um cupom fiscal do Gestão de Supermercado utilizando o web service com.senior.g5.co.int.varejo.nfce, porta ImportarNfce, onde houve pagamento do cheque e havia a necessidade de troco, os títulos não eram gerados conforme é devido. Foi alterada a importação do cupom fiscal para gerar os títulos adequadamente.

Atualizamos a documentação do web service Com.senior.g5.co.mcm.cpr.notafiscal, porta GravarNotasFiscaisEntrada, no tópico Importante, adicionando a informação de que o tipo de processamento 3 - Cancelamento não permite a geração de uma nota fiscal já cancelada no ERP. É fundamental que a nota fiscal esteja previamente cadastrada e fechada no sistema.

Além disso, ainda detalhamos a parametrização do sistema para realização deste processo. Para saber mais detalhes, acesse a documentação.

Problema: o web service de terceiro não retornava as informações de tipo array, quando o agente Java está habilitado.

Correção efetuada: adicionamos tratamento para nodes do tipo array na rotina, utilizada pelo agente Java.

Problema: as extrações que faziam algum tipo de ranking do ERP para o Analytics ERP estavam com problema de ordenação, e em alguns casos poderiam apresentar a classificação da informação errada.

Correção efetuada: ajustamos todos os comandos SQLs que fazem algum tipo de rank durante o processo de extração de dados do ERP para o Analytics ERP, para que sejam apresentado os dados corretos. Seguem os widgets ajustados em cada Analytics:

• Compras: Top Produtos (20), TOP Fornecedores (20), TOP Compradores (20);
• Faturamento: Faturamento cliente e Faturamento por representante;
• Fiscal: Top 10 Fornecedores, Top 10 Clientes, Top 10 itens entrada, Top 10 itens saída, Top 10 CFOP entrada e Top 10 CFOP saída;
• Produção: Parada recursos, Motivo de Parada de recursos, Variação de consumo comprados - Top 20, Variação de consumo acabados - Top 20 e SKU mais Refugado;
• Vendas: Vendas por Produto/Serviço, Vendas por Família, Vendas por Cliente e Vendas por representante.