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!
Mostrando postagens com marcador protheus. Mostrar todas as postagens
Mostrando postagens com marcador protheus. Mostrar todas as postagens
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
24 de setembro de 2013
Implantação do SIGALOJA
Um dia de implantação do SIGALOJA é sempre sinônimo de um dia cansativo, mas apesar disso, este foi vitorioso.
Basicamente tive que solucionar uma séries de pequenos problemas no módulo, testar, treinar o usuário e deixar o ambiente pronto para validação.
Sim, tudo em um dia.
Lista de problemas/tarefas e as respectivas soluções
Problema 1: Ao digitar o orçamento, não vir preenchido o cliente padrão e nem o vendedor padrão.
Solução: Configurar parâmetros: MV_VENDPAD, MV_CLIPAD e MV_LOJAPAD
Problema 2: Erro ao incluir produto, TABELA DE PREÇO INVÁLIDA.
Solução: Configurar MV_TABPAD como 1 ao invés de 001.
Problema 3: Cliente solicita aumentar casas decimais do preço unitário para que imprima com 4 no cupom fiscal.
Solução: Aproveitei que iria mexer nisso e aumentei o tamanho dos campos de quantidades e valores, pois notei que todos estavam com tamanho de 11 ou menos. Para isso precisei corrigir com atenção não deixando nenhum campo de fora nas tabelas SL1, SL2, SLQ, SLR e SL4.
Para que o cupom respeitasse a quantidade de casas decimais do preço unitário do orçamento, foi necessário configurar os parâmetros conforme a lista abaixo:
MV_RNDDES com .F.
MV_LJTPDES com 2
MV_LJAJDES com .T.
MV_ARREFAT com N
Problema 4: Cliente reclama que terá que digitar novamente no SIGALOJA todos os preços já cadastrados nas tabelas de preço do faturamento. Isso é assim porque a estrutura de tabela de preços do faturamento é uma e a do LOJA é outra.
Solução: A fim de facilitar ao máximo a vida do usuário, desenvolvi uma customização simples onde o usuário digita nos parâmetros de 1 à 10 quais tabelas de preço do Faturamento ele quer trazer para o Loja. Ao confirmar, o programa lê as tabelas DA0 e DA1 e faz a gravação nos campos correspondentes em SB0.
Cliente ficou bem satisfeito com a solução.
Problema 5: Cliente alega que possui uma regra de preenchimento de TES que funciona no faturamento e gostaria de personalizar o loja para funcionasse igual. Ele precisa que ao digitar um orçamento de vendas, o sistema preencha a TES correta de acordo com o produto.
Solução: Criar o gatilho. No entanto o problema é que criar gatilho no SIGALOJA não é tão simples. O campo LR_PRODUTO está em um acols e o LR_TES em outro, por isso não basta referenciar o campo de memória na criação do gatilho, simplesmente não funciona assim. Porém como quase nada é impossível no Protheus, eu resolvi da seguinte maneira:
CAMPO: LR_PRODUTO
CONTRA DOMÍNIO: LR_TES (Isso é inútil porque o gatilho do loja não respeita isso)
REGRA: aColsDet[n,aScan(aHeaderDet,{|x|alltrim(x[02])=="LR_TES"})]:=SB1->B1_XTES (aqui está o pulo do gato)
Explicando a REGRA: A expressão ”aColsDet[n,aScan(aHeaderDet,{|x|alltrim(x[02])=="LR_TES"})]” é o mesmo que seria escrever M->LR_TES em outros módulos. Porém no SIGALOJA o modo convencional não funciona.
Eu precisei passar para ao gatilho a posição exata do campo LR_TES no acols, que no caso é o acolsDet. A variável “n” me diz em que linha estou posicionado no acols. Para concluir, eu atribuí a isso o conteúdo do campo customizado B1_XTES.
Validei com o usuário e funcionou perfeitamente.
Treinamentos passados ao usuário
- Treinado na digitação do orçamento no Retaguarda;
- Treinado na importação do orçamento no PDV;
- Treinado na geração e cancelamento do cupom fiscal no PDV;
- Treinado na geração da Nota sobre Cupom;
Dica: Nos meus treinamentos de implantação eu procuro sempre utilizar um software de gravação de tela para que o próprio usuário possa consultar posteriormente. Utilizar o AutoScreenRecorder que é free e recomendado pelos consultores Totvs.
Ao final do dia, o sistema ficou pronto para ser validado pelo usuário e, se não surgirem mais problemas, semana que vem estaremos virando o SIGALOJA em produção.
Basicamente tive que solucionar uma séries de pequenos problemas no módulo, testar, treinar o usuário e deixar o ambiente pronto para validação.
Sim, tudo em um dia.
Lista de problemas/tarefas e as respectivas soluções
Problema 1: Ao digitar o orçamento, não vir preenchido o cliente padrão e nem o vendedor padrão.
Solução: Configurar parâmetros: MV_VENDPAD, MV_CLIPAD e MV_LOJAPAD
Problema 2: Erro ao incluir produto, TABELA DE PREÇO INVÁLIDA.
Solução: Configurar MV_TABPAD como 1 ao invés de 001.
Problema 3: Cliente solicita aumentar casas decimais do preço unitário para que imprima com 4 no cupom fiscal.
Solução: Aproveitei que iria mexer nisso e aumentei o tamanho dos campos de quantidades e valores, pois notei que todos estavam com tamanho de 11 ou menos. Para isso precisei corrigir com atenção não deixando nenhum campo de fora nas tabelas SL1, SL2, SLQ, SLR e SL4.
Para que o cupom respeitasse a quantidade de casas decimais do preço unitário do orçamento, foi necessário configurar os parâmetros conforme a lista abaixo:
MV_RNDDES com .F.
MV_LJTPDES com 2
MV_LJAJDES com .T.
MV_ARREFAT com N
Problema 4: Cliente reclama que terá que digitar novamente no SIGALOJA todos os preços já cadastrados nas tabelas de preço do faturamento. Isso é assim porque a estrutura de tabela de preços do faturamento é uma e a do LOJA é outra.
Solução: A fim de facilitar ao máximo a vida do usuário, desenvolvi uma customização simples onde o usuário digita nos parâmetros de 1 à 10 quais tabelas de preço do Faturamento ele quer trazer para o Loja. Ao confirmar, o programa lê as tabelas DA0 e DA1 e faz a gravação nos campos correspondentes em SB0.
Cliente ficou bem satisfeito com a solução.
Problema 5: Cliente alega que possui uma regra de preenchimento de TES que funciona no faturamento e gostaria de personalizar o loja para funcionasse igual. Ele precisa que ao digitar um orçamento de vendas, o sistema preencha a TES correta de acordo com o produto.
Solução: Criar o gatilho. No entanto o problema é que criar gatilho no SIGALOJA não é tão simples. O campo LR_PRODUTO está em um acols e o LR_TES em outro, por isso não basta referenciar o campo de memória na criação do gatilho, simplesmente não funciona assim. Porém como quase nada é impossível no Protheus, eu resolvi da seguinte maneira:
CAMPO: LR_PRODUTO
CONTRA DOMÍNIO: LR_TES (Isso é inútil porque o gatilho do loja não respeita isso)
REGRA: aColsDet[n,aScan(aHeaderDet,{|x|alltrim(x[02])=="LR_TES"})]:=SB1->B1_XTES (aqui está o pulo do gato)
Explicando a REGRA: A expressão ”aColsDet[n,aScan(aHeaderDet,{|x|alltrim(x[02])=="LR_TES"})]” é o mesmo que seria escrever M->LR_TES em outros módulos. Porém no SIGALOJA o modo convencional não funciona.
Eu precisei passar para ao gatilho a posição exata do campo LR_TES no acols, que no caso é o acolsDet. A variável “n” me diz em que linha estou posicionado no acols. Para concluir, eu atribuí a isso o conteúdo do campo customizado B1_XTES.
Validei com o usuário e funcionou perfeitamente.
Treinamentos passados ao usuário
- Treinado na digitação do orçamento no Retaguarda;
- Treinado na importação do orçamento no PDV;
- Treinado na geração e cancelamento do cupom fiscal no PDV;
- Treinado na geração da Nota sobre Cupom;
Dica: Nos meus treinamentos de implantação eu procuro sempre utilizar um software de gravação de tela para que o próprio usuário possa consultar posteriormente. Utilizar o AutoScreenRecorder que é free e recomendado pelos consultores Totvs.
Ao final do dia, o sistema ficou pronto para ser validado pelo usuário e, se não surgirem mais problemas, semana que vem estaremos virando o SIGALOJA em produção.
23 de setembro de 2013
Error log no financeiro
Hoje eu dei continuidade em um chamado aberto semana passada. Dados abaixo:
Segmento da Empresa: Industrial
Módulo: Financeiro
Rotina: Contas a Receber.
Problema: Após migrar para o Protheus 11, ao tentar cancelar uma baixa no contas a receber, o sistema apresenta o error log: TYPE MISMATCH ON - F070FATFOR (fina440.prx) 17/06/2013.
Solução: A Totvs enviou um patch de correção. Para baixar-lo, acesse o chamado THOKR5 através do site do suporte da Totvs. O patch atualiza a rotina FINA440 trazendo o fonte para a data: 07/08/13.
Após aplicar o patch, o problema foi resolvido.
Dica do consultor:
Muitas vezes a Totvs se recusa a enviar um patch de correção alegando que a data do nosso fonte está muito antiga em relação à data mais atual do mesmo.
Caso você tenha qualquer problema ou erro na rotina FINA440, e caso seu fonte seja anterior à 07/08/13, recomendo que baixe este patch que atualizará somente o fonte. Caso seu problema seja nele, ele certamente será resolvido.
Segmento da Empresa: Industrial
Módulo: Financeiro
Rotina: Contas a Receber.
Problema: Após migrar para o Protheus 11, ao tentar cancelar uma baixa no contas a receber, o sistema apresenta o error log: TYPE MISMATCH ON - F070FATFOR (fina440.prx) 17/06/2013.
Solução: A Totvs enviou um patch de correção. Para baixar-lo, acesse o chamado THOKR5 através do site do suporte da Totvs. O patch atualiza a rotina FINA440 trazendo o fonte para a data: 07/08/13.
Após aplicar o patch, o problema foi resolvido.
Dica do consultor:
Muitas vezes a Totvs se recusa a enviar um patch de correção alegando que a data do nosso fonte está muito antiga em relação à data mais atual do mesmo.
Caso você tenha qualquer problema ou erro na rotina FINA440, e caso seu fonte seja anterior à 07/08/13, recomendo que baixe este patch que atualizará somente o fonte. Caso seu problema seja nele, ele certamente será resolvido.
Assinar:
Postagens (Atom)