ERP COMPILE

Naturezas Financeiras ... o que são, de onde vem, do que se alimentam e como se reproduzem?

2015-03-18T16:24:00.003-03:00

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!

Base de comissão divergente em títulos baixados com multa

2013-10-28T22:08:00.003-02:00

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

Compensação de títulos NDF não funciona

2013-09-30T11:00:00.000-03:00

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

Atualização de custos / Workflow de validade de Lotes

2013-09-28T18:11:00.002-03:00

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.

Implantação do SIGALOJA

2013-09-24T12:48:00.000-03:00

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.

Error log no financeiro

2013-09-23T11:20:00.003-03:00

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.