Introdução

No contexto da gestão de dados de organizações e a sua relação com o Cliente/Parceiro existem atualmente várias opções disponíveis que se adequam às tarefas diárias das organizações. O Salesforce é a plataforma CRM, em sistema cloud, líder de mercado e mais completa que permite realizar a gestão de clientes e parceiros, processos de vendas, geração de leads, gestão financeira e atuar sobre muitas outras áreas da organização. A plataforma para além destas capacidades base permite a integração com entidades externas, através de API/Web Services como a certificação de documentos, pagamentos ATM e até serviços bancários.

Por forma a melhorar estas capacidades bases do Salesforce existem aplicações que podem ser adquiridas e instaladas, como é o exemplo do FinancialForce.

O FinancialForce permite a gestão de contas, geração de faturas, cash, collection cases, geração de reports e muitas outras funcionalidades fundamentais para uma boa e correcta gestão financeira de uma ou várias empresas (No site da appexchange ou do FinancialForce pode ser encontrada informação mais detalhada sobre o produto). Contudo, mesmo apesar da grande quantidade de aplicações existentes, nem sempre o que está disponível se adequa à visão e necessidade das organizações sendo necessário proceder a adaptações/implementações e melhorias ao já existente.

Neste artigo exemplificamos um caso implementado num cliente, onde se procedeu à alavancagem do FinancialForce para Cash Management automatizando processos e melhorando indicadores financeiros.

 

Conceitos Importantes

SIN – Documento que representa uma fatura;

SCR – Documento que representa uma Nota de Crédito;

Cash – Documento que representa o pagamento recebido por Débito Directo;

Cash Refund – Documento que representa a falha da tentativa de cobrança ou o levantamento de um pagamento recebido por Débito Directo;

JNL ATM – Documento que representa um pagamento recebido por Multibanco;

Alocação/Associação/Cash Matching - Operação de ligação entre dois documentos que nos indica que, p.ex o pagamento recebido(Cash) foi utilizado para pagar a fatura(SIN). Usa a API do FinancialForce CODAAPICashMatching_7_0.Match;

Desassociação – Operação de desassociação entre dois documentos que estavam anteriormente ligados como p.ex um pagamento recebido (Cash) que estava a pagar uma fatura(SIN) ao ser desassociado e fatura ficou por pagar e o pagamento disponível para pagar qualquer fatura;

 

Contexto

A organização, em exemplo, utiliza diariamente o FinancialForce para a gestão financeira de contratos celebrados entre clientes e parceiros, desde a emissão de faturas ou notas de crédito, envio para cobrança e registo de pagamentos em sistema, quer por Débito Directo ou Transferência Bancária. Face ao disponibilizado pela aplicação FinancialForce, surgiu a necessidade de melhorar e automatizar a gestão da alocação dos pagamentos recebidos tendo como principal objectivo não só a redução do trabalho manual ao nível da contabilidade, otimizando tempo e recursos, reduzir os erros humanos das ações manuais, adaptar o processo à necessidades legais atuais, e também melhorar o indicador DPD (Número de dias que um fatura está por pagar após a data de vencimento - indicador muito importante para novos investidores na empresa) dos clientes, uma vez que estes tinham faturas mais recentes pagas enquanto existiam faturas mais antigas por pagar.

 

Levantamento de Requisitos

Após uma análise dos dados e ao método de operação da organização, foi identificado que:

• A alocação de um Cash era sempre a SIN que tinha originado o pagamento;
• Para o mesmo contrato existiam SINs recentes pagas e antigas por pagar o que estava a aumentar o indicador DPD (days past due);
• Cashs e JNL ATM criados manualmente eram alocados manualmente;
• Os Cash Refunds estavam a ser associados manualmente ao Cash;
• As Notas de Crédito raramente estavam alocadas à fatura de origem(legalmente deviam estar ligados). Normalmente estavam a ser associadas a Cash Refunds onde se estava a devolver o valor da Nota de Crédito ao cliente.

 

Melhorias previstas:

• Redução do valor do indicador DPD (passar a alocar os Cash recebidos sempre às SIN mais antigas, de um mesmo contrato);
• Aumento da eficácia da equipa Financeira, libertando-a de tarefas repetitivas, aumentando a disponibilidade para se focarem na melhoria dos processos;
• Redução do processo Manual;
• Mitigação de Erros na alocação de pagamentos;
• Associação da Notas de Crédito por Cash Matching sempre à respectiva fatura;
• Cash Refund devem estar pagos (associados por Cash Matching) com o respectivo Cash que foi levantado;
• Os Cashs devem ser alocados a SINs do contrato e account do Cash.

 

Estratégia

  Inicialmente, foi avaliada a possibilidade de utilizar o serviço BackgroundMatchingService do FinancialForce para realizar a alocação automática entre pagamentos e faturas, no entanto após algumas validações foram identificadas algumas carências ao serviço que impediram a sua utilização:

• O serviço apenas funciona se nos documentos enviados para o mesmo, o valor a pagar e o valor de pagamento são o mesmo;
• Apenas realiza a alocação de Cash com SINs (Não é aplicável a JNLs ATM, SCR e outros);
• Não ser possível definir que a alocação entre pagamentos e faturas deva ser realizada por Account e Contrato (apenas dá para definir por account).

   Devido às carências identificadas para o serviço BackgroundMatchingService, foi decidido criar um processo automático de raíz que satisfaça todas as melhorias pretendidas. Este processo deve correr diariamente e várias vezes ao dia por forma a apanhar todos os Cash, Cash Refund, SINs, JNLs ATM e SCRs que vão surgindo no trabalho diário.

 

Abordagem implementada

            Com o recurso à linguagem Apex, linguagem de programação orientada a objectos desenvolvida pela Salesforce.com que permite a execução de fluxos e controlo de transações na plataforma Salesforce, o processo automático foi dividido em 3 Batch que correspondem a 3 fases automáticas do processo. Esta divisão em três fases permitiu não só sequenciar o processo em fases que podem ser executadas independentemente como também aumentar a velocidade/capacidade de processamento respeitando os limites do Apex (Apex Governor Limits) e do FinancialForce.

.

 

Fase 1: Batch BAM Refund

Os Cash Refund de Débito Directo passam a ser alocados automaticamente aos respectivos Cash. O montante do Cash Refund passa a ser levantado das faturas com a data de vencimento mais recente da conta/contrato para pagar as faturas que estavam a ser pagas anteriormente pelo Cash.

Sequência lógica implementada no Batch:

1. 1. Identifica todos os Cash Refunds por alocar em sistema;
   2. Identifica o Cash correspondente a cada um dos Cash Refunds;
   3. Avalia se o Cash está a ser utilizado para pagar alguma SIN:
      1. i. No caso do Cash estar a ser utilizado:
         1. Desassocia o Cash das SINs que estava a pagar;
         2. Identifica as SINs mais recentes que totalizam o valor do Cash e desassocia as SINs dos respectivos Cashs/JNLs ATM, tendo em conta a Account e o contrato do Cash. (Vai permitir nos casos que o Cash refund é relativo a um Cash que está a pagar uma SIN antiga, que na 3ª fase/batch a SIN mais antiga fique paga e as mais recentes por pagar);
2.     d. Aloca os Cash Refunds com os Cash;

 

Fase 2: Batch BAM Sales Credit Note

A Nota de Crédito passa a ficar alocada sempre à sua fatura de origem. O Pagamento que estava alocado anteriormente à fatura é usado para pagar as restantes faturas do contrato. Sequência lógica implementada no Batch:

1. 1. Identifica todas as SCRs por alocar em sistema;
   2. Identifica a SIN correspondente a cada uma das SCRs;
   3. Avalia se a SIN está paga com algum Cashs/JNLs ATM:
      1. i. No caso da SIN estar paga:
         1. Desassocia a SIN dos respectivos Cashs/JNLs ATM. (Na 3ª fase/batch o pagamento que ficou por utilizar vai ser utilizado para pagar outras faturas da mesma account e contrato);           
   4. Aloca a SCR à respectiva fatura;

 

Fase 3: Batch BAM Invoice

Os pagamentos por Débito Direto (Cash) ou Referência ATM (JNL) passam a ser alocados às fatura da conta e contrato do cliente tomando como primeira prioridade as faturas que estão em cobrança e segunda prioridade a data de vencimento mais antiga.

Sequência lógica implementada no Batch:

1. 1. Identifica todos os pagamentos Cashs/JNLs ATM disponíveis;
   2. Identifica todas as SINs (Unpaid/Part Paid) com valor por pagar ordenadas, em primeiro lugar, pelas que estão em processo de cobrança, e em segundo lugar, pela data de vencimento das mais antigas para as mais recentes;
   3. Agrupa os pagamentos e faturas por Account e Contrato;
   4. Realiza a distribuição dos Cashs/JNLs ATM pelas faturas por pagar considerando a ordenação e agrupamento das faturas dos passos anteriores;
   5. Para pagamentos para o qual não consegue identificar o respectivo contrato, caso o cliente tenha um só contrato o pagamento é alocado às faturas desse contrato, caso o cliente tenha mais do que um contrato é criado um issue para análise.

Em todas as fases do processo foram introduzidas validações, que no caso de falha criam um issue de análise para a equipa responsável, que permitem identificar interações manuais imprevistas como desassociações manuais entre pagamentos e faturas e erros de outros processos que já existiam mas que nunca tinham sido validados/identificados que possam afetar o algoritmo como é o exemplo de:

• Valor do pagamento recebido diferente do que foi a cobrança;
• Pagamento recebido sem estar associado a nenhuma cobrança;
• Pagamentos disponíveis sem faturas por pagar;
• Cash Refund de um pagamento que não existe no sistema;
• Notas de Crédito que não estão associadas a faturas.

 

Para o registo de todas as associações/desassociações realizadas pelo processo foi criado um novo objecto customizado (Cash_MatchingRef__c) que ao longo do algoritmo é preenchido com informação relevante por interação, que vai permitir não só ter um histórico das ações realizadas como aumentar a performance da pesquisa das associações para a realização da sua desassociação. Temos como exemplo os seguintes campos no objecto:

• Referência de Associação;
• Referência de Desassociação;
• Id do pagamento;
• Valor utilizado do pagamento;
• Account;
• Contrato;

 

Demonstração Funcional da Implementação

Cash Refund

Exemplo de Cash Refund para Cash 1 no valor de 200€ que estava a pagar a fatura SIN1.

 

• Antes da implementação do novo algoritmo

O Cash 1 para o qual foi realizado o levantamento (Cash Refund 1) era desassociado da fatura que estava a pagar SIN 1 ficando a mesma por pagar. Como neste caso existia uma fatura mais recente que a SIN 1 ia aumentar o DPD.

 

• Depois da implementação do novo algoritmo

O Cash 1 para o qual foi realizado o levantamento (Cash Refund 1) é desassociado da fatura que estava a pagar SIN 1, o mesmo valor é desassociado das faturas mais recentes Cash 2 e esse pagamento é utilizado para pagar a fatura SIN1. Neste caso ficamos sempre com as faturas mais antigas pagas reduzindo assim o DPD.

 

 

Sales Credit Note

Exemplo de uma Nota de Crédito para a SIN 1.

• Antes da implementação do novo algoritmo

Ao ser criada  Suma Nota de Crédito(SCR 1) para uma fatura(SIN 1) se a fatura já estivesse paga (Cash 1) era criado manualmente um Cash Refund 1 para devolver o dinheiro ao cliente.

 

 

• Depois da implementação do novo algoritmo

Ao ser criada uma Nota de Crédito(SCR 1) para uma fatura (SIN 1) a fatura é desassociada dos seus pagamentos, paga com a Nota de Crédito e os pagamentos que anteriormente estavam afectos à fatura são utilizados para pagar outras faturas do contrato do cliente(SIN 2 e SIN 3) reduzindo assim o DPD, a interação manual e deixam de ocorrer devoluções de dinheiro para o cliente tendo faturas em dívida.

 

Invoices

Exemplo de um pagamento de 250€ recebido

 

• Antes da implementação do novo algoritmo

Ao receber um pagamento quer por Débito Direto (CSH 2) quer por Referência ATM (JNL ATM) o mesmo era sempre alocado à fatura (SIN 2) que deu a sua origem, podendo existir faturas mais antigas por pagar (SIN 1) aumentando assim o DPD.

 

 

• Depois da implementação do novo algoritmo

Ao receber um pagamento quer por Débito Directo (CSH 2) quer por Referência ATM (JNL ATM) o mesmo vai ser alocado às faturas por ordem crescente da data de vencimento, neste caso, do cash 2 de 250€ foi utilizado 200€ para pagar a SIN1, ficando totalmente paga, e os restantes 50€ para pagar uma parcela da SIN2. Com esta lógica vamos ter o indicador DPD sempre com o menor valor possível.

 

 

Conclusão

Com o algoritmo implementado foi realizada a alavancagem do FinancialForce para a gestão automática de pagamentos, conseguindo não só colmatar todas as necessidades da organização de melhorar o indicador DPD, libertar a alocação de recursos manuais, e automatizar todo o processo de pagamentos como também identificar erros e falhas contabilísticas existentes em sistema (~>500). Atualmente o algoritmo implementado é fundamental para as operações contabilísticas do sistema.

 

Referências

1. Community Financial Force(https://erp.force.com/community)
2. Automating Cash Matching (http://developer.financialforce.com/technical-reference/automating-cash-matching/)
3. Accounting API Developer's Reference (https://help.financialforce.com/accounting-api/15X/Default.htm)

 

#Salesforce #FinancialForce # CashManagement #worldIT