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.
10. Caso o lançamento recebido pelo core para ser inserido ou alterado tenha um PersonVO sem ID, o sistema deve verificar se tem o CPF/CNPJ definido e tentar procurar no BISCore a existência deste Person por esta chave. Caso não encontre, o sistema deve tentar criar esse novo PersonVO automaticamente antes de criar o lançamento.
    1. Caso ocorra um erro ao salvar o PersonVO o sistema deve retornar o problema, não persistir o lançamento se parte das informações (a associação da PJ/PF) não serão salvas adequadamente.

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.

Métodos de Fachada

Métods de CRUD

Métodos de CRUD são os métodos de Insert, Update, Delete e os métodos de find padrão do BIS. São esperados métodos de CRUD pada as seguintes entidades:

• CashFlowCategoryVO
• CashFlowAccountVO
• CashFlowStatementsVO - Este objeto valida e persiste os seguintes objetos em cascata:
  • CashFlowStatementDocVO
  • CashFlowStatementInstallmentVO

Métodos de Negócio

São métodos com lógica de negócio publicados na fachada com funções específicas diferentes do padrão do 'CRUD':

Integer importBankStatementOFXFile(byte[] ofxfile, Long idcashflowaccount) throws BISException

@param ofxfile conteúdo do arquivo OFX.
@param idcashflowaccount ID da Conta Bancária que estamos tentando importar os lançamentos.
@return Total de registros importados.

Este método recebe o conteúdo de um arquivo OFX para importa-lo como sendo o extrato de uma determinada conta bancária (CashFlowAccountVO).
Regras de negócio:

1. Caso o banco, agência e conta esteja disponível no OFX recebido, previne que o usuário importe um arquivo de extrato de um banco na conta errada.
2. Só permite a importação caso a conta ainda não tenha nenhum lançamento importado, ou caso o o arquivo OFX tenha no mínimo a data inicial 1 dia anterior ao maior registro da base. Por exmeplo: Caso na base já existam os registros de 01/01/2015 à 21/01/2015. O OFX deve no mínimo ter seu primeiro registro com a data de 20/01/2015. A ideia é prevenir que o usuário "perca" registros no meio do seu extrato.
   1. Para evitar um "gap" entre registros no passado, deve-se validar quando a data inicial do OFX for menor que a data inicial da base: se a data final do OFX é no mínimo 1 dia maior que a primeira data da base.

   O objetivo em sobrepor sempre 1 dia é que se o usuário exportar o OFX até o "dia atual", o OFX conterá apenas os registros do dia até o momento em que é exportado. Movimentações posteriores a exportação acabariam sendo perdidas se o sistema aceitar importar arquivo apenas com a presente data.

3. Os registros do OFX devem ser convertidos em objetos CashFlowBankStatementVO. E persistidos no banco. Os registros idênticos devem ser simplesmente ignorados, não causando nenhum erro.

void createCheckBook(Long idaccount, Long startnumber, Long endnumber) throws BISException

@param idaccount ID da conta em que os cheques serão associados.
@param startnumber Numeração do primeiro cheque do talão.
@param endnumber Numeração da última folha de cheque do talão.

Este método criar novas folhas de cheque no sistema. Folhas recém criadas ganham o estatus de 'NEW', que significa que a folha está disponível para emissão na empresa mas ainda não foi utilizada para nada. Uma maneira de controlar quantas folhas estão disponíveis para na empresa. Regras de Negócio:

1. O sistema só deve permitir a crição de um talão de cheques para contas do tipo 'bancárias'.
2. Validar se as folhas de cheque (mesmos números) já existem para a mesma conta bancária.

byte[] createBankDirectionFile(Lond idaccount, List<Long> idstatementinstallmentlist) throws BISException

@param idaccount ID da conta bancária que desejamos gerar o arquivo
@param idstatementinstallmentlist Lista de IDs das 'parcelas' dos lançamentos a serem pagas.

@return Conteúdo do arquivo gerado a se enviado para o banco.

Este método gera um arquivo com as instruções de pagamento/recebimento para ser enviado ao banco correspodente. Regras de Negócio:

1. O método deve validar se a conta passada é uma conta bancária.
2. Para abstrair a implementação da geração de arquivo de cada banco deve-se usar o pattern de "Factory". Este deve devolver a implementação da interface 'BankDataManager' de acordo com o número de banco passado, ou uma exceção de que o número de banco passado. No objeto recebido chamar o método da interface com a mesma assinatura deste método para obter o arquivo gerado corretamente.

UI Vaadin

Este tópico registra as definições para a UI padrão do BIS. Com telas e requisitos.

Conta à Pagar

O sistema deve ter uma tela de entrada de contas a pagar similar a um "wizard", permitindo que passo a passo o usuário faça os lançamentos desejados respondendo apenas os campos necessários, sem que tenha que enfrentar uma tela poluída de opções que o deixem perdido. Ao entrar na opção que deseja inserir uma nova conta a pagar o sistema deve primeiro filtrar o tipo de lançamento. Dependendo do tipo selecionado a UI deve automatizar algumas ações para agilizar o preenchimento.

• Nova Conta a Pagar
  Nova Conta a Pagar

Conta à Pagar Originada de NFe

Ao dar entrada de uma conta à pagar originada de uma NFe, o sistema deve questionar pela chave de acesso da NFe já que é um identificador único do documento. Como alternativa o sistema deve permitir filtrar pela série/número e/ou CNPJ do emissor, exibindo uma lista das NFes encontradas. Dependendo dos filtros aplicados há a possibilidade de encontrar mais do que uma ocorrência, já que é possível que série e número do documento se repita para diferentes fornecedores, ou se filtrar só pelo CNPJ várias NFes sejam enontradas.

1. A lista deve ser organizada inicialmente por data de emissão decrescente. Exibindo as mais recentes primeiro.
2. Ao selecionar a NFe e confirmar a UI já deve validar se a NFe selecionada já está associada a outro lançamento. Cada NFe só deve ter um lançamento de pagamento. Caso o lançamento seja encontrado, notificar e questionar se gostaria de editar o lançamento já existente. A ideia é não permitir que o usuário complete todo o lançamento para só depois validar que este documento já está lançado.
3. Se não paramos em validação, criar um novo lançamento e avançar para a tela de edição do lançamento com as seguintes condições:
   1. A tela de edição não permitirá que a associação dessa NFe seja desfeita, embora permita a associação de outras NFes (para o caso de múltiplas NFes em um mesmo boleto)
   2. A tela deve ler as informações dos campos de "Faturamento" para obter o valor e a as parcelas. Com essas informações já gerar os objetos de parcelamento.
   3. Obter o PersonVO pelo CNPJ da empresa e já deixar associado ao lançamento. Também desabilitar o campo para que não seja possível alterar/remover a associação do fornecedor.
      1. Caso o PersonVO com o CNPJ não exista a UI deve gerar um novo objeto e já preenche-lo com todas as informações encontrada na NFe. Posteriormente ao confirmar o lançamento o Core deverá fazer o cadastro do PersonVO no BISCore antes de persistir o lançamento.

Cuidado com os Totais O sistema em geral deve tomar cuidado com os totais apresentados na NFe e os valores a pagar. A NFe pode apresentar um valor no seu campo total e nem por isso é o valor correto a ser pago. Isso porque produtos em uma mesma NFe podem ter CFOP diferentes, alguns de venda, outros de troca, brinde, amostra, comodato, etc.. Talvez no futuro seja "legal" criar algum sistema que valide o CFOP e o valor sendo pago, mesmo que só para um alerta, já que algumas notas são pagas em dinheiro e nem sempre o recebedor se atenta (ou se quer sabe) sobre o CFOP bonificado no meio da nota. Permitindo que o entregador aja de má fé e não seja descoberto. O problema é gerenciar os milhares de CFOPs existentes.