Design de banco de dados de contabilidade de entrada dupla

Estou criando software de contabilidade. Preciso aplicar a contabilidade de dupla entrada. Eu tenho o problema clássico de uma linha por transação versus duas linhas.

Vamos dar um exemplo e ver como isso seria implementado nos dois cenários.

Considere conta Cashe conta Rent. Quando pago meu aluguel mensal, transfiro US $ 100 da minha Cashconta para mim Rent.

Uma linha por transação

Em um sistema de uma linha, essa transação seria armazenada como:

transações

 tx_id | posting_date
 1     | 23/05/2015

transaction_records

 id | tx_id | credit_account | debit_account | amount
 1  | 1     | Cash           | Rent          | 100.00

Duas linhas por transação

Em um sistema de duas linhas, eu teria que espelhar o mesmo registro de transação para criar um registro oposto que, ao somar os dois, obteria saldo zero.

transações

 tx_id | posting_date
 1     | 23/05/2015

transaction_records

id  | tx_id | type   | account | amount
1   | 1     | credit | Cash    | 100.00
2   | 1     | debit  | Rent    | 100.00

O problema

Antes de mais, gostaria de observar: a razão pela qual tenho as tabelas transactionse transaction_records(em vez de uma tabela) é poder lidar com transações divididas (um caso em que transfiro US $ 100 da Cashconta para duas ou mais contas diferentes).

No começo, tentei implementar isso com uma linha por transação, mas é difícil calcular o saldo da conta e recuperar os dados.

Estou inclinado para o segundo cenário; no entanto, também tem alguns problemas:

• Como atualizo um único registro? Supondo que cometi um erro e, em vez de gravar US $ 100 pelo meu aluguel, registrei US $ 10. Agora tenho 2 transaction_records- um para crédito e outro para débito, ambos com valor de US $ 10.
• Agora faço minha reconciliação e quero corrigir esse erro de digitação. Como eu consertaria isso no banco de dados? Não conheço a conexão entre registros e, no caso de uma divisão, uma transação pode ter mais de 2 registros. A única solução que encontrei é adicionar alguns ref_idpara cada par de registros que os identificarão exclusivamente como sendo os "lados opostos um do outro" dentro de um contexto específico tx_id.

Qual abordagem é melhor / mais simples?

Para simplificar minha pergunta: quero representar um movimento de fundos da conta A para a conta B. Os dois cenários que forneci são projetos válidos para armazenar essa transação. Como também apontei, os dois têm vantagens e desvantagens (primeiro: mais fácil de salvar, mais difícil de recuperar; segundo, o oposto).

Eles podem ter outros prós / contras que não vejo no momento, por isso peço uma opinião de pessoas mais experientes.

De fato, o esquema contábil de linha única proposto permite fazer uma contabilidade de entrada dupla adequada (para sempre especificar a conta debitada e creditada) sem introduzir a redundância dos dados da "quantia".

O esquema de uma linha fornece uma implementação de uma entrada dupla que se equilibra por construção, para que seja impossível "perder o equilíbrio". A máquina pode recalcular os livros em tempo real.

Você deve selecionar 2 em vez de um para recuperar um livro.

Observe que, além da divisão de transações, existem outras transações, como câmbio, que podem terminar com 2 registros em vez de 4. Tudo depende se você desnormalizar um pouco, basta digitar 4 transações com descrição semelhante.

Você pode impedir a entrada ou modificação de qualquer transação para manter uma trilha de auditoria, isso é necessário se você quiser auditar o log de transações.

Parece que no tópico acima, para o CPA, "totalmente normalizado" parece significar regras reconhecidas por todos os contadores, enquanto que para o programador tem um significado diferente, não há dados derivados ou redundantes armazenados.

Tudo o que há para os dados contábeis é um conjunto de transações que fornecem o valor e as contas das quais e para as quais eles fluem, juntamente com a data, alguma descrição (e outros anexos). Razões e saldos são visualizações simples derivadas desses dados transacionais, efetuando somas.

Um diário é uma lista cronológica de todas as transações de um tipo especificado para um sistema de contabilidade. Aqui está uma apresentação clássica em papel de livro de uma simples revista de vendas (por conta):

Observe que cada linha é uma única transação, com Débitos totais = Créditos totais; e que toda transação atinge as mesmas três contas. Um diário de vendas à vista seria semelhante, mas substituirá a coluna Débito de contas a receber por uma denominada Débito em dinheiro . Um diário de desembolsos em dinheiro teria uma primeira coluna denominada Crédito em dinheiro e colunas adicionais como Débito em contas a pagar e Débito de despesas com funcionários .

Essa apresentação foi padrão por centenas de anos até que os computadores pessoais se tornaram acessíveis algumas décadas atrás. Ele tem uma vantagem significativa de verificar facilmente se todas as transações são equilibradas simplesmente verificando cada linha. Da mesma forma, antes de postar uma página dessa transação nos Ledgers, os totais da página podiam ser verificados da mesma forma. Esse é um modelo de processamento em lote usado em muitos sistemas de contabilidade.

É fácil ver que esse modelo de papel tem desvantagens significativas quando literalmente transcrito para um sistema automatizado:

1. A estrutura de dados é dinâmica, enquanto a experiência mostra que é muito mais simples (também mais robusto e mais facilmente verificado) programar em uma estrutura de dados dobrada; e
2. Como todo periódico especializado atinge um conjunto diferente de contas, cada um desses periódicos deveria ser projetado e programado separadamente, uma atividade desperdiçada e propensa a erros.

Por esses motivos, geralmente é recomendável usar o design de periódicos especializados como interface para o sistema de contabilidade, mas projetar uma estrutura de dados que possa ser o repositório numérico de vários periódicos. Em um RDBMS moderno, isso tem a vantagem potencial de que o Razão , e até os sub-livros especializados , possam se tornar Exibições Indexadas no Diário, eliminando completamente o requisito de codificar um Processo de Postagem (a etapa em que uma transação do Diário está bloqueada e tem sua conta totais transcritos para os vários livros contábeis).

Qualquer que seja o design de dados final, a chave é ter uma única entrada de lançamento para cada tipo de transação (ou seja, cada diário especializado no sistema de papel equivalente) em que são feitas verificações de saldo.

O que quero dizer é que as duas abordagens que você propõe são mecanismos doentios para a contabilidade de entradas duplas. Primeiro ponto: os diários são tabelas de gravação única por boas razões. Às vezes, as duas tabelas virtuais Entradas Pendentes e Entradas Publicadas são colocadas em uma única estrutura de dados, mas o bit IsPosted é sempre somente gravação e o sistema deve garantir que a natureza somente leitura dos registros de Entradas Publicadas seja mantida.

A maneira como os contadores lançaram lançamentos contábeis nos últimos 800 anos é totalmente normalizada . A única diferença entre uma apresentação em papel e uma apresentação eletrônica sólida é que uma estrutura de tabela dobrada é mais conveniente no último caso, enquanto uma estrutura de tabela dinâmica no primeiro, que historicamente era mais significativa quando o processamento altamente paralelo era desejado - ou seja, muitos funcionários cada manter um número único ou pequeno de periódicos especializados. Somente o Controlador historicamente tinha permissões para o Diário Geral.

Observe com atenção que, acima, especifiquei que as Entradas no diário são totalmente normalizadas; As entradas do diário são um registro cronológico de todas as transações, agrupadas em diários específicos para cada tipo de transação. O lançamento de lançamentos contábeis no Razão é um empreendimento separado e, embora totalmente normalizado por si só, é uma cópia redundante dos lançamentos contábeis manuais, em que todas as transações são resumidas (Contabilidade geral) ou detalhadas (Sub contabilidade) por conta. Os diários e os livros contábeis empregam a contabilidade de entrada dupla independentemente.

@Codism Qualquer sistema contábil, DEB ou SEB, fornece relatórios generalizados para todas as contas registradas . Observe que, internamente, um sub-razão é, por definição, um registro contábil de entrada única; o outro lado é a (s) conta (s) de controle correspondente (s) no balanço. O DEB garante que, para cada dólar do ativo, exista um registro preciso da reivindicação de negócios sobre o ativo , ou seja, o patrimônio no ativo, seja um patrimônio de dívida (também conhecido como passivo) ou um patrimônio de propriedade , e da prioridade dessas reivindicações, se o organização se torna insolvente.

Posso sugerir que você dê uma olhada no tesouro do software de código aberto que existe nesta área?

Um Google do " software de contabilidade de entrada dupla de código aberto " oferece vários caminhos promissores de investigação.

Você pode olhar o pacote de contabilidade GNU aqui , alguns sites de revisão ( 1 e 2 ) e, finalmente, o wiki do software de contabilidade com uma seção sobre Software Livre.

Tenho certeza de que, examinando alguns dos códigos-fonte e esquemas do F / LOSS, você poderá obter boas dicas e indicações de como escrever esquemas e / ou software que atendam às suas necessidades particulares.

Eu tenho um sistema que faz linhas duplas e seus muitos desafios do que ter contas de linhas únicas. Primeiro, encontrei instâncias de apenas uma linha sendo empurrada como o lado do débito, resultando em uma conta desequilibrada. Mesmo se não estiver fazendo controles adequados de confirmação e reversão, isso não aconteceria em uma única linha de contas. por fim, seu banco de dados cresce em uma taxa de crescimento dupla, sua segunda linha de envio terá muitas informações duplicadas, a única diferença sendo a segunda conta. Aconselharia reter, conta de linha única, estou indo para essa rota ..