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. A conta só pode ser encerrada se tiver o saldo zerado! Sugira que o usuário transfira o saldo para outra conta ou faça um lançamento de ajuste caso o saldo esteja errado. Ninguém encerra uma conta, seja bancária ou local e joga fora o saldo.
4. 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.

TODO Task 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.

Categoria de Lançamentos

A categoria de lançamentos tem a função de agrupar e totalizar diferentes lançamentos em grupos para simplificar relatórios de fechamentos por período e avaliação do fluxo financeiro da empresa.

1. As categorias se organizam de forma hierárquica, isto é, permite que uma categoria esteja dentro da outra. Por exemplo, podemos ter uma categoria chamada 'Receitas', e dentro categorias como 'Vendas à Vista', 'Cartões Crédito', 'Cartões de Débito', 'Encomendas e Entregas', etc.
2. As categorias devem ter uma definição se aceitam ou não que lançamentos sejam associados à elas. Categorias que não restringem a associação de lançamentos diretamente terão a função apenas de agrupas categorias filhas e exibir seu total.
3. Categorias com lançamentos anexos não podem ser excluídas.
4. Não há necessidade de desabilitar a categoria, pois basta restringir a associação de novos lançamentos à categoria para que ela não seja mais usada.
5. Não tendo movimentação dentro da categoria ou em suas filhas a categoria não deve aparecer em relatórios (impressos ou em tela).
6. Quando um lançamento é alterado, se ele já estava em uma categoria que tem restrição de associação (tendo sido associado em algum momento em que a associação não era restrita), a confirmação de alteração deve continuar permitindo que o lançamento continue na categoria restrita. A ideia é que se for necessário corrigir algum problema em lançamento passado, seja possível corrigir apenas o desejado sem cair em uma restrição do presente.

Lançamentos Financeiros

1. Os lançamentos financeiros são o registro de qualquer movimentação financeira da empresa. Podendo ser a pagar ou a receber, já efetuada ou futura.
2. O usuário de conseguir cadastrar um lançamento a pagar/receber futuro. Devendo preencher sempre a data vencimento. Mas sem a necessidade de informar de qual conta financeira será paga/recebida.
3. Ao pagar/receber a conta, torna-se obrigatório associa-la a uma conta financeira para indicar a movimentação naquela conta.
4. Um lançamento pode ter diversas parcelas com diferentes valores e datas de vencimentos. Podendo ainda ser pago de formas diferente. Ex: A primeira no dinheiro, a segunda e terceira no cheque predatado, e as outras no boleto. Por fim o usuário ainda esqueceu de pagar um dos boletos e teve que transformar o pagamento em um TED ou depósito para quitar a parcela.
5. Em alguns momentos uma compra ou venda pode ser faturada em momentos diferentes e ter mais de um documento gerador (Ex: Nota Fiscal) e ter apenas 1 pagamento somando os documentos ao fim de um período. Ex: Uma venda de móveis com entrega em 3 etapas, com 3 notas diferentes, mas apenas 1 conta para pagar. Ou ainda, o valor total dividido em 5 parcelas iguais. Neste caso o lançamento deve permitir a associação de vários documentos de origem (NF) e permitir o cadastro de vários pagamentos.
6. Todo lançamento deve estar associado à uma categoria para correta sumarização do fluxo financeiro.
7. É obrigatório definir a linha de exibição do lançamento. Mesmo que a UI ofereça essa descrição para alguns casos, como por exemplo, se o lançamento de uma conta a pagar está sendo gerada a partir de uma entrada de NFe, ou de um código de barras de conta de concessionárias, etc.
8. Mesmo não sendo obrigatório cadastrar a conta financeira de onde a conta será paga, deve ser permitido. Neste caso funcionará como uma previsão de planejamento para aquela conta específica.
9. Os lançamentos podem ser de diversos tipos. Cada tipo tem sua característica própria, como por exemplo validações diferentes, atributos obrigatórios diferentes, diferentes tratamentos para malote eletrônico, etc.. Entre os tipos de lançamentos a serem definidos:
   1. Salários: Enviado por malote eletrônico ou pago em conta local. Exige número do banco, da agência e conta corrente. Nome e CPF do funcionário. Além do tipo de pagamento: Salário, Adiantamento, Férias, 13°, Rescião Contratual, Vale Transporte, etc.
   2. Boletos de Concessionárias: Boletos de contas de consumo como telefonia, luz, gás e normalmente impostos municipais como TFA, IPTU, etc. Devem conter um código de barras válido, valor e data de vencimento.
   3. Boletos Cobrança: Boletos mais comuns associados a compras e faturamento de produtos e serviços. Exige código de barras, vencimento, valor.
   4. GPS: Guia de Recolhimento de INSS. Exige data de competência, vencimento, validade, etc. (Rever)
   5. DARF: Guia de Recolhimento de DARF/IRRF. Exige data de competência, vencimento, validade, etc. (Rever).
   6. Depósito/Transferência/TED/DOC: Pagamento por depósito em conta. Exige banco, agência e conta corrente. Se pago de uma conta bancária de mesmo banco, é uma trasnferência/depósito eletrônico, se for de banco diferente é um TED/DOC. É necessário rever a integração bancária para análise de como enviar trasnferência e TED/DOC para os bancos por malote eletrônico.

Conciliação Bancária

A conciliação bancária tem a finalidade de sincronizar as informações oferecidas pelo banco (importado no sistema através de arquivo), com os lançamentos do sistema. Essa sincronização é a forma de garantir que todos os lançamentos bancários estão corretamente lançados na contabilidade da empresa. Ajudando a encontrar falhas de lançamentos e diferenças de caixa. Com o adendo de que lançamentos bem feitos resultam em dados mais confiáveis.

1. O sistema deve oferecer uma interface que permita mapear as 'parcelas' dos lançamentos do sistema com os registros presente no extrato da conta bancária. O mapeamento entre o lançamento e o registro bancário é feito através de outro objeto: o 'CashFlowStatementInstallmentBankStatementVO'.
2. O mapeamento entre lançamentos do extrato e do sistema deve ser do tipo 1:N, ou N:1 pois podemos ter:
   1. múltiplos lançamentos no sistema e um único lançamento no extrato, como boletos pagos em malote eletrônico; e,
   2. 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 período 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.
3. O sistema jamais deve permitir que uma 'conciliação bancária' seja do tipo N:N.
4. Ao validar os valores do mapeamento o sistema deve garantir que o status do objeto seja definido adequadamente.

Contas a Pagar & Receber

O sistema deve ter uma UI que permita o usuário prever as contas que tem a pagar e receber em alguma forma de "timeline" que facilite a visualização dos saldos das contas dia a dia. Com a previsão do à pagar e o à receber, salientando os dias em que o saldo previsto está no vermelho, ou no "amarelo" quando o saldo previsto não é vermelho mas está muito perto do vermelho. O calculo do valor do amarelo deve ser vinculado proporcionalmente aos valores de contas a receber com algum índice de inadimplência (a brotar de algum lugar no futuro) ou na média dos valores a receber. Pois se alguma conta a receber não entrar, por atraso ou qualquer outro problema a previsão vai por água abaixo.

1. Mesmo sem a UI idealizada ainda, ao definir que os pagamentos serão feitos em uma conta do tipo 'bancária' a UI deverá exibir a opção de "Pagar por Malote Eletrônico". Ao escolher essa opção a UI deve enviar para o Core a solicitação de gerar o arquivo de Lote passado a coleção de IDs dos lançamentos que serão pagos por malote eletrônico, uma lista de mesmo tamanho e mesma ordem com as datas de pagamento planejadas e de qual conta o pagamento será realizado. Para gerar o arquivo o core deve validar:
   1. Se os pagamentos ainda não estão pagos, nem em estado de 'enviado' em algum lote anterior.
   2. Validar se todos os pagamentos foram solicitados no malote eletrônico são suportados por aquele banco. Caso algum não seja o sistema deve abortar e retornar exceção. Para que fique o mais claro que algum pagamento não será enviado no malote e não deixar um pagamento sem ser feito.
   3. Validar se todas as datas de vencimento são do dia atual ou futura.
2. O sistema deve permitir que um arquivo de lote possa ser baixado mais de uma vez, caso o usuário "perca" o arquivo, mas só no mesmo dia. Impedir que o usuário baixe o arquivo de lote do dia anterior para evitar que o usuário tente enviar para o banco um arquivo de lote com datas de pagamento possivelmente erradas.

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 Como forma de auxiliar o usuário a "não esquecer de pagar as contas", no futuro as categorias podem ter regras de 'lançamentos esperados'. Essas regras serviriam para registrar que alguns lançamentos são esperados dentro dessa categoria, assim quando o lançamento não existir o sistema poderia notificar que falta o lançamento. Muito útil por exemplo para mensalidades, contas de consumo ou qualquer outra que tenha alguma frequência quinzenal, mensal, anual, etc. O sistema poderia avaliar não só se há o lançamento para ajudar a encontrar erros da contabilidade (seja falta do lançamento seja lançado na categoria errada), como também avisar antes do vencimento que nem o lançamento como "contas a pagar" foi realizado até o momento.

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.
  • FUNDFIX: Lançamento usado para fazer correções de caixa em últimos casos. Quando não se encontra mais o problema, ou mesmo para correções de "imperfeições monetárias" como arredondamentos dos centavos durante os pagamentos em moeda.
• 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).

CashFlowStatementInstallmentBankStatementVO - Conciliação Bancária

Este VO de nome pomposo representa a associação entre o lançamento financeiro do sistema e o extrato bancário. Além dos mapeamentos entre os objetos, este VO tem apenas mais 1 atributo: Status do Mapeamento.

• NONE: Significa que nenhum mapeamento foi feito. No banco esse estado é definido pela ausência do Vo de mapeamento.
• INCOMPLETE: Significa que algum mapeamento já foi feito entre os lançamentos e o extrato, mas os valores não estão batendo.
• DONE: Mostra que o mapeamento está completo e "satisfeito" quanto aos valores.