CashFlow

Módulo responsável por gerenciar o sistema fluxo financeiro do caixa da empresa.

Requisitos

Contas Financeiras

O sistema deve gerenciar um cadastro de "Contas Financeiras" (CashFlowAccountVO). Essas contas tem a finalidade de organizar os fluxos de caixas da empresa. Seja uma conta bancária, uma conta de "caixa local", uma conta de investimentos/poupança, etc.

1. Tipos de Contas:
   1. Contas Bancárias - são usadas para gerenciar as contas correntes da empresa em bancos e tem os seguintes requisitos:
      1. devem ter o número do banco (número do banco deve ser associado ao BISBankVO), agência e conta corrente definidos obrigatoriamente.
      2. permitem a definição dos dados da PJ da agência (associando um PersonVO), incluindo o CNPJ, endereço, contato (gerente), etc.
   2. Caixa Local - usada para gerenciar as contas/caixas da empresa. Como o caixa principal, um caixa menor de responsabilidade do almoxarifado para pagamento de entregas a vista, um caixa de responsabilidade do RH para pequenos pagamentos e acertos, etc.
2. As contas devem ter um estado que defina a conta entre Ativa/Encerrada. O estado encerrado deveria ser como o estado excluído, e em UIs não deviam exibir as contas encerradas por padrão (sempre ter opção para exibi-las caso o usuário deseje). As contas não podem ser excluídas para que não se perca o histórico de movimentação da empresa. No entanto as contas encerradas devem de certa forma ser "invisíveis" durante a operação do sistema para não poluir nem confundir os usuários.
3. Toda conta deve ser associada à uma empresa, já que filiais e empresas diferentes tem contas separadas. Para simplificar a geração de relatórios e orientar as informações financeiras da administração.

Folhas de Cheque

1. Para as contas do tipo 'Conta Bancária' o sistema deve permitir que sejam cadastradas folhas de cheque. O usuário deve inserir a numeração da primeira e última folha e o sistema deve criar um objeto (CashFlowCheckVO) para cada uma das folhas de cheque.
2. Cada folha de cheque deve ter os seguintes estados:
   1. NEW: Estado inicial para as folhas de cheques recém criadas e ainda não utilizadas.
   2. EMITED: Estado que indica que a folha de cheque foi usada e deve estar associada ao pagamento de algum lançamento financeiro.
   3. COMPENSED: Este estado indica que a folha de cheque já foi compensado (Foi encontrado no extrato do banco durante a conciliação bancária).
   4. DISCARDED: Marca que a folha de cheque foi rasurada e descartada. Uma folha de cheque nesse estado nunca deve ser encontrada no Extrato do banco.
3. Cheques podem ser predatados, a data de predatado quando presente deve ser usada como a data de previsão que o saldo precisa estar na conta para planejamento financeiro.

Fundo Comprometido Quando um cheque é emitido para pagar uma conta (um lançamento financeiro), ele automaticamente é "dado baixa". Afinal, na prática o lançamento já foi pago e deixa de ser uma conta a pagar para ser uma conta paga. No entanto, enquanto o cheque não for compensado o dinheiro continuará aparecendo no extrato bancário como dinheiro. Mas para efeitos de previsão e simulação de saldo para planejamento na hora de pagar as contas é importante que o sistema saiba o quanto de cheques estão "voando" e com data para serem compensados.

Extrato Bancário

Contas bancárias costumam ter o extrato oferecido pelo banco. Atualmente há sempre a opção de baixar o extrato em algum formato de arquivo "importável" (txt, excel, csv, ofx, ofc, etc.). Por observação dos bancos que trabalho acredito que o arquivo OFX (usado pelo Money) é o mais popular que segue um formato padrão. Embora todos tenham arquivos txt, cada um usa um caracter diferente de separação de colunas, ou de formatação de valores, etc.

Inicialmente o sistema trabalhará apenas com a importação de arquivos OFX para simplificar. Informações sobre o formato podem ser encontradas em http://www.ofx.net/.

1. O sistema deve aceitar o upload de um arquivo OFX e converte-lo:
2. Ao fazer o upload o usuário deve informar a conta bancária em que este extrato deverá ser importado.
   1. A maioria dos arquivos OFX de extrato vêm com a informação da agência e conta corrente. Assim, na UI o sistema deve tentar lêr essa informação e se encontrar já sugerir ou simplesmente usar essa informação para realizar a importação. No Core, mesmo que o usuário forneça a conta em que deseja a importação o sistema deve validar e prevenir que o usuário importe o extrato de uma conta dentro de outra.
   2. O sistema deve validar se o período do extrato sendo importado coincide de alguma forma com os dados já existentes no banco de dados. De forma e evitar que o usuário importe um arquivo com poucos dias e "fiquem faltando" registros entre as importações. Ex.: Se já existe no banco a movimentação entre as datas 01/01/2015 e 25/02/2015, o sistema não deve permitir que o usuário importe um arquivo cuja data inicial seja maior ou igual à 25/02/2015. Evitando que registros fiquem sem importação. Neste caso o arquivo sendo importado deve no mínimo começar no dia 24/02/2015. Embora a validação seja "burlável" editando-se o arquivo OFX, a intenção é evitar erros do usuário não a preocupação de total imunidade a falhas.
   3. Caso os períodos do banco e do arquivo se sobreponham em parte, o sistema deve avaliar os registros 1 a 1 para evitar a inserção de dados duplicados. No final retornar a quantidade de novos registros importados (apenas para notificação do usuário).

Manipulação de Arquivo e Classe Utilitária Como a UI e o Core vão precisar extrair as informações do OFX (dados do cabeçalho e conteúdo do extrato), os métodos de manipulação do arquivo e criação dos CashFlowBankStatementVO devem ser criados em uma classe utilitária acessível por ambas as camadas.

Importação e Conciliação Automatizada No futuro podemos implementar regras de conciliação automatizadas. Mesmo que cada banco escreva de um jeito no extrato e que mesmo eles de vez em quando troquem a descrição. Seria possível permitir que o usuário criasse regras para conciliação automaticamente.Por exemplo: caso o cliente não faça controle dos seus recebíveis de cartões, tíquetes, etc., mas queira que um lançamento seja gerado automaticamente para os valores depositados constarem no seu caixa. O sistema poderia identificar o lançamento, soma-los e criar um lançamento na categoria correta de lançamento; O sistema poderia identificar automaticamente lançamentos de compensação de folhas de cheque e conciliar com o cadastro de folhas de cheque voando e marca-los como compensados, bem como validar e alertar se alguma folha rasurada foi compensada; Analisar lançamentos de boletos recebidos e dar baixa nas dívidas de contas a receber; Igualmente para a contas a pagar pagas por malote eletrônico que muitas vezes vem somadas no extrato em um lançamento único, o sistema poderia ser capaz de procurar pela data e pelos lotes gerados e conciliar o lançamento do extrato com todas as contas a pagar de uma única vez.

Contas a Pagar

O sistema deve ter uma tela para gerenciar as contas a pagar (ainda não pagas) para que seja executado o pagamento delas. Além da listagem de contas a pagar por período essa tela deve permitir que pagamentos sejam executados. Durante a execução de um pagamento o sistema deve perguntar em qual conta local o pagamento será executado.

• Pagamentos com "Conta Corrente"
  • Malote Eletrônico: Caso uma conta bancária seja escolhida devemos mostrar a opção de "Malote Eletrônico", quer permitirá a geração de malote eletrônico com todos os pagamentos suportados para aquela instituição financeira. Os pagamentos não aceitos devem ser exibidos em tela de confirmação. O arquivo do malote eletrônico não precisa ser salvo explicitamente, mas deve ser possível gera-lo novamente a partir dos dados que devem ser salvos nos fragmentos dos lançamentos.
  • Cheque: Ao escolher pagar com uma conta bancária também deve ser possível escolher a opção de pagamento com folha de cheque. Ao escolher essa opção o usuário será indagado do número do cheque para registro, além de data pré-datamento, e data de emissão (o sistema pode sugerir a data de hoje, mas o lançamento do sistema pode não estar sendo feito no momento em que o cheque foi preenchido.)

Contas a Receber

1. Gestão dos recebíveis da operadora de cartão
2. Recebimento de Boletos Emitidos

Fluxo de Caixa

Tipo do Lançamento

De acordo com o tipo de lançamento o sistema deve se comportar das seguintes maneiras:

• UNIQUE: No caso de pagamento único, o sistema permite que sejam anexadas guias ao lançamento, e não ao fragmento único que representa o pagamento. No entanto, deverá permitir a anexação de recibo ao fragmento.
• INSTALLMENTS: No caso de parcelamento, o sistema permite que sejam anexadas guias ao lançamento, e não à nenhum dos fragmentos. Também deve permitir a anexação de comprovantes em cada fragmento.
• MONTHLYREPETITION e ANNUALREPETITION: O sistema não deve permitir anexar guias ao lançamento. Guias/Documentos de origem, assim como os comprovantes, devem ser associados aos fragmentos.

Conciliação Bancária

A conciliação bancária tem a finalidade de sincronizar as informações oferecidas pelo banco (extrato bancário), com as informações (lançamentos) disponíveis no sistema e associadas a contas do tipo "Conta Corrente". Para isso o sistema deve executar as seguintes tarefas:

• Importar Extrato Bancário: O sistema deve permitir a importação de formatos comuns usados pelos bancos. Deve guardar os dados importados ignorando os trechos repetidos, e organizar de “forma continua” as informações do extrato bancário. Deve ainda ser capaz de “informar” se perceber que períodos de datas não foram importados, por exemplo o usuário esqueceu pulou algum trecho.
• Mapear Lançamentos: O sistema deve oferecer uma ferramenta que permita mapear os lançamentos de extrato com os lançamentos do sistema. A intenção é verificar todos os lançamentos ocorridos no extrato com os lançamentos locais utilizados no fechamento da empresa. O mapeamento entre lançamentos do extrato e do sistema deve ser do tipo 1:N, ou N:1 pois podemos ter:
  • múltiplos pagamentos no sistema e um único lançamento no extrato, como boletos pagos em malote eletrônico; e,
  • ter um único lançamento no sistema para múltiplos no extrato, como por exemplo os créditos de cartões de crédito de um periodo que não são controlados no sistema, e o usuário simples soma todos para realizar um único lançamento de crédito mensal.

  Em cada mapeamento múltiplo vamos chamar o lado "1" do relacionamento com o owner do relacionamento para facilitar buscas e validações evitando que mapeamentos N:N sejam feitos. A ideia não é exibir esse campo para o usuário, mas que as UIs possam gerencia-lo sozinho permitindo apenas que o usuário ao fazer o mapeamento escolha como seus lançamentos serão associados.

  • Status do Mapeamento:
    • NONE: Significa que nenhum mapeamento foi feito ainda entre aquele lançamento e o extrato bancário.
    • INCOMPLETE: Significa que algum mapeamento já foi feito entre os lançamentos e o extrato, mas os valores não estão batendo.
    • VALIDATING: Mostra que o sistema fez os mapeamentos estão completos e praticamente OK, mas ainda precisa de alguém com acesso os valide. A ideia é que depois de validados (auditados) alguém sem permissão de auditoria não possa mais edita-lo ou excluí-los. Mapeamentos automáticos feitos pelo sistema, quando ficarem completos devem ser definidos como VALIDATING, enquanto que se o mapeamento automático ficar incompleto ele deve ser definido como INCOMPLETE.
    • AUDITED: Define que o mapeamento foi auditado e está pronto e validado em definitivo.

---

Entidades

CashFlowCategoryVO - Categorias de Lançamentos

• As categorias de lançamentos são usadas para totalizar os lançamentos por grupos de interesse, de forma a mostrar relatórios de fluxo de caixa.
• As categorias devem ter uma estrutura hierárquica, de forma que o usuário possa criar sua árvore da maneira como achar conveniente ter os totais e subtotais.

As categorias devem ter os seguintes campos:

• Nome: Nome da categoria dada pelo usuário.
• Categoria Pai: A categoria pai define onde essa categoria será utilizada.
• Permite Lançamento: Define se essa categoria permite que sejam colocados lançamentos nela ou se não. Categorias que não permitem o lançamento direto nela podem ser usadas como categorias pais apenas para a sumarização das categorias abaixo dela.

  • Em caso de alteração, que proíba novos lançamentos na categoria, os lançamentos antigos continuarão lançados sem problema.

    Categorias com lançamentos e lançamentos filhos devem ter os totais das filhas e dela própria sumarizados. Mesmo que sejam exibidos separados de alguma forma.

TODO Task Lançamentos Esperados

CashFlowStatementVO - Lançamentos Financeiros

• Os lançamentos financeiros são usados para registrar as movimentações financeiras das empresa. Qualquer saída ou entrada de dinheiro deve ter um lançamento correspondente.
• Um lançamento financeiro pode representar tanto uma conta já paga/recebida quanto um lançamento futuro de recebimento/pagamento.

Os lançamentos devem possuir os seguintes atributos e relacionamentos:

• Empresa: Indicando à qual empresa esse lançamento pertence. [Obrigatório]
• Categoria: Categoria de pagamentos, para sumarização dos pagamentos.
• Beneficiário/Pagador: Associa uma Pessoa como Beneficiário/Pagador ao lançamento. Não deve ser obrigatório, mas permitir a associação para facilitar a busca dos pagamentos/recebimentos por cliente, fornecedor, funcionário, etc. (PersonVO)
• Documento(s) de Origem: Permite a associação de documentos que geraram o lançamento, como NFe, Guias de Impostos, Contas de Consumo, etc. Pode ser uma maneira de arquivar a guia (como arquivo binário, ou como referência para o cadastro da NFe no sistema). Algumas vezes um mesmo lançamento de pagamento (por exemplo mesmo boleto, ou mesma transferência) pode abrange a união de vários Documentos de Origem, por isso um lançamento deve permitir a associação de múltiplos documentos.
• Operação do Lançamento: Define a operação desse lançamento: [Enum]
  • DEBIT: Uma saída, valor removido do caixa: conta a pagar como um boleto de fornecedor, pagamento de salário, etc.
  • CREDIT: Uma entrada, valor removido do caixa: conta a receber como um boleto emitido para um convênio, recebíveis de cartões de crédito e débito, etc..
  • FUNDTRANSFER: Transferência de fundos entre uma conta e outra.
• Tipo do Lançamento: Permite definir alguns tipos diferentes de lançamentos: [Enum]
  • UNIQUE Define um pagamento único. Como o pagamento de uma nota avista, um serviço de conserto prestado, etc.
  • INSTALLMENTS Define que é um pagamento parcelado. Como uma nota com o valor dividido em 3 vezes em 3 boletos, ou um pagamento de maquinário em várias parcelas.
• Nome de Exibição: Descrição 'curta' dado pelo usuário para descrever o lançamento. Este nome que será usado para exibir em telas e relatórios (como extratos das contas) que permita que o usuário identifique o pagamento.
• Observações: Campo que permita que o usuário escreva qualquer detalhamento mais específico sobre o lançamento.

CashFlowStatementInstallmentVO - Parcelas do Lançamento

O objeto "parcela do lançamento" indica as informações sobre o pagamento. Como um mesmo lançamento pode conter pagamentos parcelados e serem pagos de formas diferentes as informações sobre pagamentos ficam um objeto separado. Para lançamentos sem parcelamento (pagamento único) deve conter apenas "uma parcela" associada.

• Origin Account: Quando o lançamento for um pagamento ou transferência de fundos, é obrigatório associar a conta para indicar de onde foi tirado o valor para pagamento/transferência.
• Recipient Account: Quando o lançamento for um recebimento ou transferência de fundos, é obrigatório associar à uma conta para indicar para onde foi o valor recebido.
• Lançamento: Associa a parcela ao lançamento.
• Documento de Origem: É possível anexar o documento de origem da dívida, seja uma NFe já existente no sistema, seja a digitalização de uma guia de impostos.
• Comprovante de Pagamento: Permite anexar o documento (arquivo) com o comprovante de pagamento.
• Cheque: Caso o pagamento seja feito com folha de cheque, a associação ao objeto que representa a folha de cheque deve ser informada.
• Dados Bancários: Em caso de pagamento com depósito, transferência essa associação é obrigatória. Assim como a informação do PersonVO (o destinatário do pagamento). Para pagamentos com boletos o Person é obrigatório, mas a informação bancária não. A informação bancária pode ser obtida de alguns boletos automaticamente.
• Espécie de Lançamento: Define o tipo de conta a pagar ou receber (não usado para lançamentos do tipo FUNDTRANSFER, neste caso sempre lançar OTHER)
  • PAYROLL: Pagamento de folha de pagamento. (Somente Débito)
  • PUBLICSERVICES: Boletos de concessionárias de serviços como telefonia, luz, gás, etc.
  • PAYMENTSLIP_DARF Guia de pagamento de DARF
  • PAYMENTSLIP_GPS Guia de pagamento de GPS
  • BOLETOS: Boletos de pagamentos em geral
  • DEPOSIT: Lançamento de depósitos
  • OTHER: Lançamentos manuais para outros pagamentos e recebimentos. Por exemplo, pagamentos sem nota de pequenos consertos, vales, etc.
  • Estatus do Lançamento: Define o "passo" ou estado em que o lançamento se encontra:
    • PLANNED: O pagamento está planejado (lançado no sistema) e aguardando para pagamento/recebimento.
    • SENT: Estado usado para contas que são pagas por malote eletrônico, ou cobranças por geração de boleto, e indicam que já foram incluídas em um lote para enviar para o banco. Neste estado a conta já deve estar associada à uma conta bancária.
    • ERROR: Estado usado para contas que foram enviadas ao banco por malote eletrônico e retornaram com algum tipo de erro da instituição bancária.
    • PAID: Estado indicando que o lançamento já foi realizado. Isto é, o pagamento efetuado ou o recebível em caixa. Neste estado a associação da conta é obrigatória.
• Mensagem do Malote Eletrônico: Mensagem(ns) recebida do sistema bancário ao tentar pagar uma conta, enviar um pagamento de salário, gerar um boleto, etc.. Por malote eletrônico.
• Data de Vencimento: Data máxima para pagamento sem penalidades de multas, juros e protestos. Obrigatório
• Data de Execução: Data em que a ação de pagamento/recebimento realmente ocorreu.
• Data de Compensação: Data em que o valor realmente entrou no caixa. Normalmente a data é uma duplicata do valor de 'data de execução', no entanto para recebíveis de cartões, boletos, e cheques depositados essa data pode ser diferente da data de execução devido ao processo de compensação. Este campo nunca deve ser nulo para lançamentos 'executados' (que já ocorreram). Em casos de compensação imediata, duplicar o valor de 'data de execução' para simplificar consultas do banco de dados.
• Valor Original: Valor do lançamento. (Seguindo sempre a convenção de que todo pagamento é salvo como valor negativo no banco, e todo recebimento é salvo como valor positivo. - Nos casos de lançamentos de transferência de fundos, sempre lançar o valor positivo)
• Valor Multas: O valor de multas é aplicado para contas pagas com atraso ou outros acréscimos.
• Valor Descontos: O valor de descontos concedidos nos boletos que devem ser decrescidos do valor original do boleto.
• Valor Final: O valor final é o valor que realmente entrou ou saiu da Conta. Esse valor pode ser diferente do original devido a multas, descontos, taxas de recebíveis, etc.
• Campos do Malote Eletrônico: Abaixo está a relação de alguns campos usados no malote eletrônico.
  • Mensagem de Retorno: Campo de texto livre para salvar a mensagem de retorno do banco. Esta mensagem é usada pelo sistema apenas para exibição para o usuário.
  • Número de Lote: Identificador do lote de pagamento gerado pelo sistema. Quando o arquivo de lote é gerado o sistema deve definir o ID do Lote único para identificar o arquivo gerado. Esse id deve ser salvo para referência futura do retorno e para regerar o arquivo caso o usuário deseje.
  • Data de Geração do Lote: Define a data de geração do lote.
  • ID Pagamento: Todo pagamento enviado para em um malote eletrônico deve ter um ID único "na vida". Que não deve ser repetido preferencialmente nem em outros arquivos de Lote. Para evitar conflitos caso pagamentos de um mesmo lote tenham retorno em lotes diferentes. Esse ID é normalmente usado pelo sistema do banco.
  • Número Validação: Número de validação retornado pelo banco ao autorizar um pagamento. Diferente para cada sistema bancário.
• Código de Barras: Valor do Código de barras da guia de pagamento dos pagamentos que dispõe de código de barras.
• Representação Numérica: Numeração da representação numérica do código de barras. Quando o usuário digita 1 ou outra informação o sistema deve gerar a outra automaticamente.

CashFlowAccountVO - Contas

Contas são usadas para lançar as entradas e saídas financeiras da empresa. Facilitando o controle dos saldos e valores financeiros da empresa.

Cada conta cadastrada deve ter os seguintes atributos:

• Nome: Para o usuário nomear e identificar a conta.
• Tipo da Conta:
  • Conta Local: Usada para lançamento manuais de caixas locais.
  • Conta Bancária: Usada para controle de contas bancárias como corrente ou conta investimento. Esse tipo de conta permitirá a conciliação de extrato bancário, bem como a exportação de “malote eletrônico” (CNAB?) para envio de pagamentos para o banco. Para contas bancárias temos os seguintes atributos adicionais:
    • Banco: Número do banco (listagem já pré existente do sistema, por causa do PersonBankDataVO).
    • Agência: Agência da conta.
    • Número da Conta: Número da conta corrente.
    • Contato Agência: Permite anexar um contato (PersonVO) da agência.
    • Contato do Gerente: Permite anexar um contato (PersonVO) do gerente da conta.
  • [VERSÃO FUTURA] Cartão BNDES: Usada para controlar compras e fluxo do cartão BNDES. (Para Implementação Futura)
  • [VERSÃO FUTURA] Cartão de Crédito: Usada para controlar e registrar fluxos de pagamento em cartão de crédito. (Para Implementação Futura)
  • [VERSÃO FUTURA] Administradoras de Cartão: Conta com a função de gerenciar os lançamentos de vendas com cartão de crédito. Para calcular taxas e saber o saldo de recebíveis, taxas e etc.. Ao receber no banco, marcamos como "Transferência de Fundos" entre as contas de administradoras e do extrato bancário.
  • [VERSÃO FUTURA] Conta Aplicação: Conta usada para gerenciar os fundos de aplicações da empresa.

CashFlowBankStatementVO - Extrato Bancário

Este objeto representa um lançamento do extrato bancário, oferecido pela instituição financeira (banco).

Atributos do objeto:

• Conta Bancária: Todo lançamento obrigatoriamente deve estar associado à uma conta (CashFlowAccountVO) do tipo 'Conta Bancária'.
• Operação: Define o tipo da operação: Crédito ou Débito.
• Valor: Valor da operação financeira. Toda a operação de crédito deve ter o valor positivo, todo débito deve manter o valor negativo.
• Linha de Exibição: Descrição como exibida pela instituição financeira.
• ID Lançamento: Os extratos bancários costumam (não é regra) ter um ID que identifica aquele lançamento, permitindo que o sistema reconheça o lançamento do banco com os já existentes no sistema evitando duplicatas. Na ausência desse ID a tríade Data + Descrição + Valor deve ser usada para reconhecer o lançamento. (Embora em casos raros possa existis o lançamento exatamente igual no extrato).