Que considerações especiais são necessárias ao projetar bancos de dados para armazenar registros financeiros?

15

Espero que esta pergunta não seja muito ampla. No futuro, talvez seja necessário adicionar alguns sistemas de contabilidade e acompanhamento financeiro a alguns aplicativos (principalmente aplicativos baseados na Web, mas minhas perguntas também pertencem aos aplicativos de desktop).

Agora, criar um registro simples de transações financeiras é teoricamente fácil. Uma tabela de banco de dados com algumas colunas poderia fazer o trabalho. Até mesmo o MS Access, o Excel ou até mesmo um arquivo de texto ASCII simples poderiam ser usados para armazenar datas de transação, IDs de conta e valores monetários. No entanto, sinto que mesmo uma tabela SQL com backup com integridade transacional pode não ser robusta o suficiente para um acompanhamento financeiro sério.

Eu ouço termos como "contabilidade de dupla entrada", e tenho a impressão de que a maioria dos aplicativos de rastreamento financeiro (por exemplo, Mint.com ou GnuCash) tem uma estrutura ou processo de dados muito mais complicado para fazer Certifique-se de que tudo se encaixe perfeitamente, exatamente como deveria, e que nenhum dado seja perdido ou corrompido.

Minha pergunta é: Ao criar um aplicativo para rastrear transações financeiras, que considerações especiais de design devem ser feitas? Parece que pode haver tantos possíveis problemas ... problemas com precisão de arredondamento, paridade verificações, algum tipo de processo de auditoria, backups especiais, segurança / criptografia, maneiras extras de proteger os dados no caso de uma falha na entrada de dados ... Eu realmente não sei o que devo perguntar especificamente, mas recebo a sensação de que a indústria de programação tem um conjunto de boas práticas das quais nada sei. O que são eles?

Editar:

Parece que eu abri uma lata de worms maior do que eu esperava. Para esclarecer, estou pensando especificamente em dois tipos de aplicativos:

  1. Aplicativos do tipo "Verificar registro", como o GnuCash ou o Quicken, que mantêm um registro de transações individuais para uso próprio.
  2. Aplicativos que rastreiam faturamento / crédito / ou "pontos" para fornecedores e clientes que lidam com uma empresa.

Eu provavelmente não farei nenhum banco direto ou (AFAIK) qualquer coisa que tenha uma tonelada de regulamentações governamentais relacionadas a finanças.

    
por Joshua Carmody 15.06.2011 / 16:06
fonte

7 respostas

10

Você terá muitas respostas para isso, tenho certeza, muitas respostas idealistas também, eu só posso responder a partir da minha experiência com finanças e o que realmente acontece.

Você já cobriu a maioria dos problemas.

Precisão de arredondamento tende a não ser realmente um grande problema na minha experiência. A maioria das grandes organizações financeiras que não cresceram da noite para o dia (ou seja, tudo, exceto os fundos de hedge) têm uma enorme variedade de aplicativos legados que são divididos devido a vários combustíveis. Eles tendem a não fazer precisão de arredondamento de forma consistente; geralmente, um certo erro e perda é simplesmente aceito para arredondamentos. Na verdade, muitas horas-homem são gastas em lugares onde trabalhei em humanos, onde os seletores finais "sim, que são próximos o bastante" quando se trata de combinar somas exatas / esperadas. Lembre-se, esta é uma resposta baseada na realidade, não o que deveria acontecer.

Criptografia - não confie nisso francamente. Armazene os dados de identificação em um sistema fisicamente e logicamente separado dos dados não identificados (por exemplo, código de conta em todos os lugares, dados pessoais separados).

Geralmente, enquanto os backups são necessários, os backups off-line raramente são chamados - as coisas correram mal nesse ponto. Cópias de produção aquecidas são geralmente necessárias - no entanto, isso dependerá de suas necessidades específicas. Na prática geral, temos uma cópia de produção calorosa no local de todos os sistemas E um site de recuperação de desastres com sua própria produção e cópias quentes. Cópias quentes tendem a ficar alguns minutos atrasadas na replicação, etc.

A auditoria é a chave para todo sistema financeiro em que trabalhei. Você tem 2 requisitos fundamentais A) Você pode acompanhar todas as alterações feitas nos dados, por quem, quando e por quê? B) Você pode provar o estado histórico de seus dados? Que não foi adulterado?

A) é necessário para as equipes de operações - seu sistema será usado de 100 maneiras que você nunca esperou, e essas informações são vitais para expansão, relatórios ad-hoc, motivos legais e depuração.

B) Veja o caso AMEX vs. Vee Vinhnee - onde a AMEX não conseguiu coletar 40k devido a eles, pois eles não podiam provar que seus registros não foram inventados. A solução geralmente usada para isso é a estampagem de tempo confiável. Grandes empresas financeiras têm bancos garantidores que garantem as transações e, portanto, fornecem inerentemente carimbo de hora confiável. Existem provedores comerciais para isso em outras esferas da vida / cenários.

    
por 15.06.2011 / 16:33
fonte
6

As considerações são principalmente legais . Se você olhar apenas de uma perspectiva de segurança / confiabilidade, uma folha de excel pode não ser inerentemente menos segura que uma folha de papel em alguma gaveta. A integridade transacional do Access pode ser melhor do que a de um funcionário que é interrompido por uma chamada.

Mas, para que seus clientes possam usá-lo, você deve seguir as leis locais. Algumas coisas que eu encontrei (na Alemanha)

  • Formatos de documentos para material de armazenamento , porque existem leis que as empresas devem manter sua documentação por 10 anos. Em 10 anos, talvez o seu programa não esteja mais disponível. Portanto, você tem que armazenar documentos de uma maneira certificada DIN / ISO (.pdf parece ser suficiente na Alemanha)
  • As trilhas de auditoria geralmente são necessárias, por exemplo, talvez seja necessário apresentar versões diferentes do mesmo documento, com datas de modificação.
  • Localização dos assuntos de armazenamento , por causa do 'Datenschutz' (privacidade), que pode ser diferente no país de armazenamento. Isso torna os serviços baseados em nuvem um pouco complicados.
  • Alguns documentos devem ser armazenados de forma não mutável . como exatamente isso é conseguido parece depender principalmente de erros legais (um artigo é imutável, um cd é mutável, um cd assinado por um trabalhador não é)

Você deve entrar em contato com um advogado para obter detalhes específicos ou pelo menos trabalhar em parceria com um cliente.

    
por 15.06.2011 / 16:24
fonte
3

Fatores de confiabilidade se tornam surpreendentemente importantes quando você está lidando com o dinheiro das pessoas. Se o Twitter perde um tweet, não é um grande negócio; Se você cobrar do cartão de crédito de alguém, mas perder o pedido, alguém em sua organização receberá uma bronca de um cliente irritado. Então, duas coisas: 1. Você não quer que isso aconteça em primeiro lugar, mas 2. isso acontecerá eventualmente, não importa o quão cuidadoso você seja, então você quer colocar MUITA energia no tipo de mecanismos de registro e rastreamento. que o ajudará a voltar e encontrar a ordem "perdida" e corrigir a situação.

A pior coisa é ter, por exemplo, uma taxa de cartão de crédito, mas nenhum registro de tudo, ou a quem pertence, etc.

Para assuntos financeiros, você realmente precisa pensar em cenários aparentemente super improváveis e planejar como lidar com eles: "Cobramos o cartão de crédito, mas o servidor de banco de dados está inativo antes que possamos atualizar o registro correspondente. " OK, e agora? Anula a carga? Registrar a transação em um arquivo para que um ser humano possa consertá-lo depois? Ok, e se o disco estiver cheio e você não puder gravar no arquivo? Etc., etc.

    
por 28.10.2011 / 20:04
fonte
3

[1] Use tabelas de segurança (não confunda com os usuários internos de D.B.) para usuários e para seu aplicativo. módulos, formulários, páginas da Web:

User = {userID, username, pwd, email1, email2}
Modules = {moduleID, moduleTitle, moduledescription}
ModulesPerUser = {modulesperuser, userID, moduleID}

[2] Não exclua registros no seu aplicativo. Use um campo de status, talvez inteiro, talvez booleano ou bit, que indique que o registro é considerado "excluído". Faça você app. mostrar registros que não são excluídos (marcados como excluídos, por esse campo) e criar alguns formulários especiais, onde o aplicativo. mostra os registros marcados como excluídos.

anytable = {anytableID, anytablefield1, anytablefield2, ..., bool anytableisdeleted }

Esse recurso é chamado de "exclusão virtual". A exclusão real é chamada frecuentemente de "exclusão física".

[3] Use campos em todas as tabelas relacionadas ao acesso, armazene o usuário (único) que cria o registro e o (último) usuário que alterou o registro, e o datetime, se possível, adicione o módulo ou a opção onde cada registro foi modificado:

AnyTable = {anytableID, anytablecreateuserID, anytablecreatedatetime,
anytableupdateuserID, anytableupdatedatetime,
moduleID, anytablefield1, anytablefield2, ..., anytableisdeleted }

[4] Em alguns casos, valores monetários ou monetários podem afetar os resultados, quando usados vários registros em um detalhe e, adicionados em um único valor, em um registro de cabeçalho.

A maioria das marcas de banco de dados suporta atualmente um campo de dados de moeda ou dinheiro. Use-o.

Em algumas circunstâncias especiais, algumas pessoas as armazenam em um valor flutuante fixo que suporta vários dígitos decimais ("decimal") ou até mesmo como valores de string.

Esta técnica é uma espada de dois gumes. Se o seu aplicativo exigir esse tipo de presicionismo, pesquise na Web por um tutorial sobre como implementá-lo corretamente.

Felicidades. [não se esqueça de dar uma lata de atum aberta para o gatinho, ou um upvote de um ano para o outro]

    
por 15.06.2011 / 23:05
fonte
2

Você marcou sua pergunta com security , mas está falando principalmente sobre consistência e confiabilidade, então tentarei responder a essa parte da equação:

  • Use as transações do banco de dados para garantir a integridade das operações em lote. O exemplo mais básico é uma transferência entre duas contas - uma conta é deduzida da quantia e a outra é creditada. Use transações para garantir que uma transferência parcial nunca aconteça (apenas um lado é alterado).
  • Para precisão, use o tipo DECIMAL em vez de floats. Os cálculos são muito mais lentos, mas você não deve sentir isso, pois a maioria dos cálculos financeiros é muito básica
  • Use replicação para uptime e hotcopies para backup. Você também deve procurar em instantâneos do LVM para recuperação
por 15.06.2011 / 16:43
fonte
2

Algumas das considerações que vejo são que você deve levar em conta os controles internos. Isso significa que todo acesso para ações contra tabelas (Insert / delete / update) deve ser feito através de procs armazenados (e sem SQl dinâmico) para que nenhuma tabela permita a gravação ou exclusão de direitos diretamente na tabela para qualquer pessoa, exceto um administrador do sistema. Você também tem que contabilizar os controles internos que não permitem que alguém crie uma nova empresa e, em seguida, cobrar itens para essa empresa (uma rota de fraude). Ações como essa sempre exigirão que pessoas em dois papéis diferentes aprovem. Além disso, os cheques não devem ser cortados a menos que uma pessoa insira dados e outra aprove a despesa.

Todas as tabelas devem ter gatilhos que criam registros de auditoria. Você está olhando para evitar fraudes e se isso acontece para determinar exatamente quem tomou as ações quando.

Em aplicativos financeiros, você está muito mais preocupado com muitos processos de back-end que nunca são vistos pela interface do usuário. Sua primeira preocupação é evitar fraudes e, portanto, muitas verificações de que ninguém está ciente são feitas no back-end.

Eu não faria uma aplicação financeira de qualquer tipo sem ler o GAAP (nos EUA, outros países têm seus próprios padrões contábeis) e ter um CPA como consultor, pois práticas contábeis incorretas podem levar à prisão. Este é um campo altamente técnico e alguém sem o know-how necessário não tem nenhum negócio tentando criar software nesta área.

    
por 28.10.2011 / 20:52
fonte
1

A contabilidade é geralmente sobre verificação. Desde que você se lembre disso e entenda a relação entre cada entidade, é muito difícil errar.

Tentarei listar o maior número possível de checagens, mas invariavelmente vou sentir falta de algumas. Espero que seja o suficiente para você começar a cavar.

Total de débitos == Total de créditos, isso é verdadeiro se você estiver falando sobre o conjunto de contas INTEIRO ou apenas uma transação isolada. Se isso não acontecer, você perdeu pelo menos uma postagem em algum lugar. É assim que o Razão se equilibra.

Contas a receber (débitos líquidos para a conta controladora) == Total faturado (soma total de todos os valores faturáveis) - Total recebido (soma total de todos os pagamentos recebidos). Este é um exemplo de como os totais das transações em termos reais de documentos FÍSICOS e tangíveis devem ser balanceados com o Razão (entrada dupla).

Saldo bancário (de acordo com seu extrato bancário) == Seu total de contabilidade para essa conta + os cheques recebidos que não são depositados - quaisquer cheques emitidos que não estejam depositados. Este é um exemplo de como contas bancárias / em dinheiro são contabilizadas. com o Razão Geral.

Como você pode ver, todas as transações, sub-registros, até mesmo ações, são vinculadas diretamente ao Razão.

Se você está fazendo testes unitários, é muito fácil executar testes que garantam que esses saldos existam sempre que você inserir / atualizar transações, desde que você saiba o que verificar.

É claro que existem mais saldos para verificar / contabilizar, mas você deve obter a essência do trabalho necessário. Essencialmente, tudo se equilibra com tudo o mais, seja documentos físicos, itens do Razão, extratos bancários. É suposto ser um equilíbrio perfeito, ou em casos em que você é preguiçoso para lidar com o arredondamento, quase perfeito.

Quanto mais verificações você puder realizar enquanto estiver desenvolvendo, menores serão as chances de você ter algo errado.

BTW, quando você lida com o arredondamento, tente ir com decimais em vez de carros alegóricos, isso vai lhe poupar muita dor de cabeça na estrada. : P

    
por 28.10.2011 / 17:59
fonte