Segmento da Empresa: Todos
Módulo: Financeiro
Rotina: Naturezas
Assunto:Naturezas Financeiras.
Conceito
Natureza nada mais é do que um plano de contas especificamente útil para classificação das receitas e despesas em regime de caixa, ou seja, pelo movimento financeiro e não contábil.
Antes de entrar nas funcionalidades oferecidas pelo Protheus, quero explicar o conceito de maneira mais ampla, pois percebo em todas as minhas implantações uma certa dificuldade de entendimento por parte de muitos envolvidos no projeto. É fundamental o entendimento do conceito para o sucesso da implantação, visto que uma vez o plano bem elaborado, o recurso é bem visto pelo gestor e de fácil utilização pelo pessoal operacional.
O setor financeiro de qualquer empresa possui pelo menos algum tipo de classificação das despesas, separando por exemplo compras de matéria prima, compras de material de uso e consumo, contas fixas (luz, água etc), impostos, adiantamentos, movimentos de caixa, pagamento de folha etc. Vamos chamar estas contas de plano de naturezas.
Com base nestas classificações (naturezas), o setor financeiro é capaz de montar algumas visões/relatórios gerenciais, por exemplo fluxo de caixa, movimento bancário por natureza, balancete etc. Em alguns casos também é necessário gerar estas informações para as holdings, em empresas multinacionais por exemplo.
Outra coisa importantíssima que precisa ficar clara é: Plano de naturezas não é e não deve ser confundido com plano de contas contábil. Plano de naturezas é exclusivamente de uso do setor financeiro e não precisa ter qualquer equivalência ou semelhança com seu primo contábil. Gestor contábil, não se preocupe, algumas contas contábeis serão sim alimentadas a partir das naturezas, mas não é necessário que o plano de naturezas reflita o contábil, uma coisa é uma coisa, outra coisa é outra coisa e é fundamental aceitar esta separação.
No próximo post trarei um pequeno roteiro de implantação das naturezas com meus toques pessoais. Além disso, algumas demonstrações de visões e relatórios para que seja possível visualizar de forma clara o objetivo da implantação deste recurso pelo gestor e analistas.
Grande abraço e até a próxima!
18 de março de 2015
28 de outubro de 2013
Base de comissão divergente em títulos baixados com multa
Hoje o cliente alegou que o sistema estava calculando comissão incorreta em alguns títulos que haviam sido baixados com multa.
Ilustrando a situação
Valor da Nota menos o IPI (F2_VALBRUT - F2_VALIPI): 24.300,00
Valor do IPI: 1.215,00
Valor do Título (E1_VALOR): 25.515,00 (valor da nota + IPI)
Base original da comissão no financeiro (E1_BASE1): 24.300,00
Até aqui está tudo certo e entendido, o problema veio ao baixar o título.
Baixa do título
O valor total baixado (E5_VALOR) foi 25.820,55, que equivale à soma do valor do título (25.515,00) e a multa aplicada ao cliente, no valor de 305,55.
Comissão gerada após a baixa do título
Valor da comissão (E3_VALCOM) = 1.475,00
Percentual (E3_PORC) = 6,00
Base (E3_BASE) = 24.591,00 (???)
A dúvida do cliente foi justamente sobre a base gerada após a baixa do título. Como o sistema chegou ao valor de 24.591,00? Na tentativa de desvendar este mistério, o usuário tentou somar a multa à base inicial de 24.300,00, tentou subtrair o IPI, tentou somar outros impostos que incidiram sobre esta nota, mas nenhuma das tentativas chegou ao valor calculado pelo sistema.
Desvendando o mistério
Acontece que o sistema calculou a proporção da multa sobre o valor do título e depois aplicou esta proporção à base original gerando a nova base em SE3.
Como assim?
Multa: 305,55.
Valor do título: 25.515,00
Base original: 24.300,00
Encontrando o proporcional da multa sobre o valor do título: 305,55 / 25.515,00 = 0,0119753
Aplicando este proporcional à base original do título: 0,0119753 * 24.300,00 = 291,00
Encontrando a base misteriosa: 24.300,00 + 291 = 24.591,00
Mistério esclarecido, resta explicar o porquê
Esta situação ocorrerá sempre que a base da comissão gerada em SE1 for diferente do valor do título e, ao executar a baixa, houver incidência de decréscimos, acréscimos, descontos, multas ou juros.
Espero ter conseguido explicar com clareza esta situação. Se você ficou com qualquer dúvida, por favor não deixe de postá-la aqui pra mim.
O Consultor
30 de setembro de 2013
Compensação de títulos NDF não funciona
Segmento da Empresa: Indústria de produtos de higiene e beleza
Módulo: Financeiro
Rotinas: Compensação de títulos a pagar
Problema 1
Após migrar para o Protheus 11, rotina de compensação de contas a pagar não está funcionando para títulos NDF (Nota de Débito de Fornecedor)
Solução
Primeiramente eu me certifiquei de que o usuário não estava cometendo nenhum tipo de erro de parametrização na rotina, fiz meus próprios testes e reproduzi o problema relatado pelo usuário.
Identificado que se tratava de um problema no sistema, eu parti para abertura do chamado, o que não adiantou muito visto que o fonte do cliente estava um ano desatualizado. A Totvs não envia patch nestas condições, eles solicitam que todo ambiente seja atualizado.
Sem poder contar muito com o chamado eu parti para investigação do problema.
Para descobrir se estamos falando de erro no programa
Utilizo a ferramenta TOP DBACCESS para monitorar as queries que uma determinada rotina executa no banco de dados. Isto mesmo, pelo DBACCESS é possível ter acesso as queries e updates que o Protheus envia para o banco dados quando se executa qualquer rotina, padrão ou customizada.
O DBACCESS geralmente está instalado no mesmo servidor do banco de dados, porém isto não é regra, varia de empresa para empresa. Basta perguntar ao administrador da TI pelo local onde ele está instalado (em qual servidor) .
Pois bem, no Protheus, acesse a rotina que você quer ter as query monitoradas, deixe pronto para executar mas não confirme.
Acesse o DBACCESS, vá na aba Usuários, localize seu usuário e a rotina que está executando e clique em Rastrear.
Volte no Protheus e confirme a rotina.
Volte no DBACCESS e salve a página que ele gerou.
O log pode ser aberto no WORDPAD ou qualquer editor de textos simples. Lá estarão todas as queries e updates executados pela função do Protheus.
Voltando ao problema
Eu parei para explicar sobre o DBACCESS porque sei que este procedimento é muito útil para identificar problemas, também para provar para Totvs determinadas falhas em rotinas.
Com o rastreamento na rotina de compensação eu confirmei que a query tinha a seguinte condição: E2_TIPO IN ('AD','PA').
Repare que o tipo de título NDF deveria estar referenciado na query. E que raio de tipo de título AD é este? (me perguntei) O tipo AD não é um tipo de título padrão do financeiro no Protheus. Isso chamou minha atenção e fui ao cadastro de Tipos de Título. O Tipo AD estava cadastrado com o camp SINAL = Diminui. Pronto, problema solucionado.
Não me pergunte por quê. mas nesta versão caso exista qualquer tipo de título cadastrado nestas condições (sinal=diminui), a rotina de compensação do contas a pagar passa a ignorar o tipo padrão NDF e o substitui por estes tipos de títulos personalizados.
Identificado isso, fiz uma rápida query contando quantos títulos a pagar haviam no sistema utilizando o tipo AD. Verifiquei que apenas 6 no ano de 2012. (cheiro de testes)
Busquei nos fontes de projeto se havia alguma referência a este tipo (Talvez existissem por conta de alguma customização). Nada.
Perguntei à toda equipe de TI se alguém conhecia ou por que havia sido criado. Nada.
Questionei também a equipe Financeira se alguém usava o tipo AD. Nada.
Ok, apaguei o registro do Tipo de Título AD, problema resolvido. O sistema voltou a compensar títulos NDF normalmente.
Não desista facilmente.
Para entender mais sobre a relação entre as rotinas de Tipos de Títulos e Compensação do contas a pagar, consulte o link: MV_CPNEG
Módulo: Financeiro
Rotinas: Compensação de títulos a pagar
Problema 1
Após migrar para o Protheus 11, rotina de compensação de contas a pagar não está funcionando para títulos NDF (Nota de Débito de Fornecedor)
Solução
Primeiramente eu me certifiquei de que o usuário não estava cometendo nenhum tipo de erro de parametrização na rotina, fiz meus próprios testes e reproduzi o problema relatado pelo usuário.
Identificado que se tratava de um problema no sistema, eu parti para abertura do chamado, o que não adiantou muito visto que o fonte do cliente estava um ano desatualizado. A Totvs não envia patch nestas condições, eles solicitam que todo ambiente seja atualizado.
Sem poder contar muito com o chamado eu parti para investigação do problema.
Para descobrir se estamos falando de erro no programa
Utilizo a ferramenta TOP DBACCESS para monitorar as queries que uma determinada rotina executa no banco de dados. Isto mesmo, pelo DBACCESS é possível ter acesso as queries e updates que o Protheus envia para o banco dados quando se executa qualquer rotina, padrão ou customizada.
O DBACCESS geralmente está instalado no mesmo servidor do banco de dados, porém isto não é regra, varia de empresa para empresa. Basta perguntar ao administrador da TI pelo local onde ele está instalado (em qual servidor) .
Pois bem, no Protheus, acesse a rotina que você quer ter as query monitoradas, deixe pronto para executar mas não confirme.
Acesse o DBACCESS, vá na aba Usuários, localize seu usuário e a rotina que está executando e clique em Rastrear.
Volte no Protheus e confirme a rotina.
Volte no DBACCESS e salve a página que ele gerou.
O log pode ser aberto no WORDPAD ou qualquer editor de textos simples. Lá estarão todas as queries e updates executados pela função do Protheus.
Voltando ao problema
Eu parei para explicar sobre o DBACCESS porque sei que este procedimento é muito útil para identificar problemas, também para provar para Totvs determinadas falhas em rotinas.
Com o rastreamento na rotina de compensação eu confirmei que a query tinha a seguinte condição: E2_TIPO IN ('AD','PA').
Repare que o tipo de título NDF deveria estar referenciado na query. E que raio de tipo de título AD é este? (me perguntei) O tipo AD não é um tipo de título padrão do financeiro no Protheus. Isso chamou minha atenção e fui ao cadastro de Tipos de Título. O Tipo AD estava cadastrado com o camp SINAL = Diminui. Pronto, problema solucionado.
Não me pergunte por quê. mas nesta versão caso exista qualquer tipo de título cadastrado nestas condições (sinal=diminui), a rotina de compensação do contas a pagar passa a ignorar o tipo padrão NDF e o substitui por estes tipos de títulos personalizados.
Identificado isso, fiz uma rápida query contando quantos títulos a pagar haviam no sistema utilizando o tipo AD. Verifiquei que apenas 6 no ano de 2012. (cheiro de testes)
Busquei nos fontes de projeto se havia alguma referência a este tipo (Talvez existissem por conta de alguma customização). Nada.
Perguntei à toda equipe de TI se alguém conhecia ou por que havia sido criado. Nada.
Questionei também a equipe Financeira se alguém usava o tipo AD. Nada.
Ok, apaguei o registro do Tipo de Título AD, problema resolvido. O sistema voltou a compensar títulos NDF normalmente.
Não desista facilmente.
Para entender mais sobre a relação entre as rotinas de Tipos de Títulos e Compensação do contas a pagar, consulte o link: MV_CPNEG
28 de setembro de 2013
Atualização de custos / Workflow de validade de Lotes
Sistema: Totvs - Protheus 11
Segmento da Empresa: Indústria Química
Módulo: Contabilidade Gerencial / Estoque e Custos
Rotina: Contabilização OFFLINE
Problema 1
Usuário relata que uma nota fiscal de entrada teve seu custo contabilizado corretamente, porém no KARDEX ela saiu com quantidade preenchida e custo igual a zero. Segundo o usuário, a TES estava configurada para atualizar estoque.
Solução
Verifiquei que a TES utilizada estava realmente configurada para gerar estoque. Esta informação seria suficiente para que o sistema levasse o custo para o Kardex. No entanto, ao checar o campo D1_CUSTO, pude confirmar que estava zerado.
Executei a rotina Refaz Custo de Entrada apenas para a nota em questão. Após executar a rotina, o campo D1_CUSTO recebeu o valor da nota.
Conclusão que cheguei foi que no momento em que o usuário digitou a nota, ele alterou antes a TES para que não atualizasse estoque, e com isso o sistema manteve zerado o campo D1_CUSTO. Após lançar a nota, o usuário alterou novamente a TES para atualizar estoque. Quando eu rodei a rotina de refaz custo de entrada, o sistema considerou a configuração atual da TES (estoque=sim) e atualizou corretamente o custo da nota.
Problema 2
Cliente solicita uma maneira de visualizar os Lotes de fabricação que estarão vencendo nos próximos 60 dias.
Solução
Desenvolvido um programa em ADVPL que gera um email no formato HTML para os destinatários contidos num parâmetro também customizado. Os dados são capturados através de uma querie SQL.
Estes dados foram validados pelo usuário final antes do início do desenvolvimento do workflow, afim de garantir o sucesso do projeto e evitar a perda de tempo no desenvolvimento de um programa que talvez viesse a se tornar obsoleto.
Dica: É muito importante no nosso trabalho confirmar de maneiras diferentes que o usuário/cliente está realmente pedindo aquilo que ele pensa estar pedindo.
Depois de validado pelo usuário, o programa foi configurado no schedule do Protheus em produção.
Segmento da Empresa: Indústria Química
Módulo: Contabilidade Gerencial / Estoque e Custos
Rotina: Contabilização OFFLINE
Problema 1
Usuário relata que uma nota fiscal de entrada teve seu custo contabilizado corretamente, porém no KARDEX ela saiu com quantidade preenchida e custo igual a zero. Segundo o usuário, a TES estava configurada para atualizar estoque.
Solução
Verifiquei que a TES utilizada estava realmente configurada para gerar estoque. Esta informação seria suficiente para que o sistema levasse o custo para o Kardex. No entanto, ao checar o campo D1_CUSTO, pude confirmar que estava zerado.
Executei a rotina Refaz Custo de Entrada apenas para a nota em questão. Após executar a rotina, o campo D1_CUSTO recebeu o valor da nota.
Conclusão que cheguei foi que no momento em que o usuário digitou a nota, ele alterou antes a TES para que não atualizasse estoque, e com isso o sistema manteve zerado o campo D1_CUSTO. Após lançar a nota, o usuário alterou novamente a TES para atualizar estoque. Quando eu rodei a rotina de refaz custo de entrada, o sistema considerou a configuração atual da TES (estoque=sim) e atualizou corretamente o custo da nota.
Problema 2
Cliente solicita uma maneira de visualizar os Lotes de fabricação que estarão vencendo nos próximos 60 dias.
Solução
Desenvolvido um programa em ADVPL que gera um email no formato HTML para os destinatários contidos num parâmetro também customizado. Os dados são capturados através de uma querie SQL.
Estes dados foram validados pelo usuário final antes do início do desenvolvimento do workflow, afim de garantir o sucesso do projeto e evitar a perda de tempo no desenvolvimento de um programa que talvez viesse a se tornar obsoleto.
Dica: É muito importante no nosso trabalho confirmar de maneiras diferentes que o usuário/cliente está realmente pedindo aquilo que ele pensa estar pedindo.
Depois de validado pelo usuário, o programa foi configurado no schedule do Protheus em produção.
Assinar:
Postagens (Atom)