Gestão Empresarial | ERP - 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: na validação do movimento de estoque, o Gestão Empresarial | ERP apresentava a seguinte mensagem de erro: Safra XXX não cadastrada na empresa X ou está inativa ou não integra com Gestão Safra, impedindo a utilização da rotina mesmo quando não havia a integração com o Gestão Safra.

Correção efetuada: ajustamos as rotinas que geram movimentos de estoque para a correção do erro.

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.

Alguns clientes podem achar vantajoso efetuar a integração contábil de maneira personalizada, com base em tabelas criadas pelo próprio usuário. Para tornar isso possível, implementamos um conjunto de identificadores de regras, cujo nome inicia com CTB-645IC, seguido do código do módulo afetado e o nível de seu escopo. Quando esses identificadores estão cadastrados e ativos, serão executados os códigos SQL declarados nas variáveis disponibilizadas, ao invés das rotinas padrão do sistema. Adicionamos a documentação sobre o CTB-645ICCOD, que faz a integração personalizada no módulo de gestão de compras. Existem 3 identificadores específicos desse módulo, o CTB-645ICCOD01, que afeta no nível dos dados gerais; o CTB-645ICCOD02, que afeta no nível dos itens; e o CTB-645ICCOD03, que afeta no nível dos rateios.

Problema: a documentação do identificador de regras GER-075CNDPD01 informava indevidamente que a tela F075DPE era afetada pelo uso deste identificador, além das telas F075DPO e F714DEM, que realmente são impactadas.

Correção efetuada: removemos a menção da tela F075DPE na documentação do identificador, mantendo apenas as telas corretas (F075DPO e F714DEM).

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.

Problema: na tela de Baixa por Substituição/Negociação do Contas a Receber (F301SUB), ao utilizar o identificador de regras CRE-301INVCR01, a variável VSTnsMcr do identificador não apresentava a transação que fosse informada no campo Transação da tela.

Correção efetuada: corrigimos a rotina de execução dos identificadores de regras CRE-301INVCR01 e CPA-501INVCR01 para carregar corretamente as respectivas variáveis de contas a receber (VSTnsMcr e VSCotMcr) ou do contas a pagar (VSTnsMcp e VSCotMcp) de acordo como indicado na documentação.

Liberamos a nova integração com o ERP Banking da senior X Platform, que permite a cobrança dos títulos do Gestão Empresarial | ERP por meio de QR Code PIX.

Acesse o nosso portal de documentação e confira a Integração ERP XTended x ERP Banking, junto das informações de uma nova tela para o processo, identificador de regra e processo automático envolvidos nessa novidade!

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 realizar transferências de depósito no Gestão de Armazenagem | WMS Alcis as mesmas ficavam como Aguardando Processamento no Monitor logística, sendo necessário reenviar pelo WMS Alcis.

Correção efetuada: alteramos o sistema para que não ocorram erros na integração de transferência de depósitos.

Problema: ao retornar a separação, após envio para o Gestão de Armazenagem | WMS, para o ERP com quantidade do produto, porém sem série informada e o produto ser controlado por série, o produto era excluído da pré-fatura.

Correção efetuada: alteramos o processo no sistema para que não ocorram erros no retorno da separação durante integração com o Gestão de Armazenagem | WMS e retorno para o ERP.

Problema: a documentação de Importação de CEPs do e-DNE, mencionava que é possível realizar a atualização, porém no FAQ no final da página era informado que não é possível atualizar, apenas importar o que causava uma falha da interpretação sobre o que a rotina realmente permite.

Correção efetuada: ajustamos o tópico Com essa importação, os cadastros que já possuem um CEP informado serão atualizados?, da FAQ, informando que esse processo de importação de CEPs, não atualiza os CEPs que já estão em cadastros existentes, como o de cliente, fornecedor, etc. A inserção/atualização só irá ocorrer nas tabelas Tabelas - Cep (E008CEP) e Tabelas - Cidades para RAIS - SIG (E008RAI).

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.

Problema: ao realizar a integração através de processo automático configurado para utilização pelo sapienssrv, os registros ficavam com asituação Aguardando Exportação mas não era exportado ao WMS.

Correção efetuada: alteramos o sistema para que não ocorram erros e os registros sejam exportados ao WMS corretamente.

Complementamos a documentação do campo Opção da tela F910GPR indicando que ele filtra, na geração de O.P.s, apenas os produtos que têm a opção de roteiro informada. Isso a nível de operação do roteiro. Para filtrar a nível de estágio, é preciso utilizar o identificador de regras PCP-910DSSRO01. Ao usá-lo, você deve definir o sufixo do estágio e da sequência do roteiro (operação). A consulta via botão de pesquisa mostra somente as opções de roteiros que têm estágio/operação externa vinculado a fornecedores. Caso contrário, não será retornado nada na consulta.

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.

Complementamos a documentação da tela F135TVC, no box de Observação, informando que, quando há mais de um veículo informado, e consequentemente, a carga original informada no cabeçalho e o romaneio ligado à mesma são cancelados e geradas novas cargas, o sistema gera um novo romaneio para a nova carga, e, ao consultar a nota fiscal via tela F141CNS, serão apresentadas duas linhas para a mesma nota fiscal. Este comportamento ocorre, pois o sistema consulta os dois romaneios gerados para as duas cargas.

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.

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.

Complementamos a documentação da tela F420OPS e do identificador de regras CPR-420EMAOC01, clarificando que o identificador só é acionado se no processamento desta tela a caixa de seleção Enviar e-mail para o fornecedor após processar esteja marcada. Este mesmo comportamento, também se aplica a outras telas que permitem ativar a opção de envio de e-mail da ordem de compra.

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: na documentação de Leiautes NF-e e NFC-e, no grupo JA - Detalhamento Específico de Veículos novos, na coluna Origem da tabela, era informado que a tag era gerada através do identificador VEN-140NEVNV01, porém esta informação não estava correta.

Correção efetuada: corrigimos a documentação deste grupo, substituindo todas estas menções pelo identificador VEN-140NEITE01, que é de onde vêm as informações dos respectivos campos do leiaute.

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.