이중 엔트리 부기 데이터베이스 디자인

회계 소프트웨어를 만들고 있습니다. 이중 입력 부기를 시행해야합니다. 트랜잭션 당 하나의 행과 두 행의 고전적인 문제가 있습니다.

예를 들어 두 시나리오에서 어떻게 구현되는지 봅시다.

계정 Cash과 계정을 고려하십시오 Rent. 월세를 내면 $ 100를 내 Cash계좌 에서 내 계좌로 Rent이체합니다.

거래 당 한 행

한 행 시스템에서 이러한 트랜잭션은 다음과 같이 저장됩니다.

업무

 tx_id | posting_date
 1     | 23/05/2015

transaction_records

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

거래 당 2 행

두 행 시스템에서는 동일한 트랜잭션 레코드를 미러링하여 두 레코드를 모두 합산하면 균형이 0이되는 반대 레코드를 만들어야합니다.

업무

 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

문제

우선 주목하고 싶습니다 : 하나의 테이블 대신 테이블 transactions과 transaction_records테이블 이 모두있는 이유 는 분할 트랜잭션 ( Cash계정에서 두 개 이상의 다른 계정으로 $ 100을 이체하는 경우)을 처리 할 수 ​​있기 때문 입니다.

처음에는 거래 당 하나의 행으로 이것을 구현하려고 시도했지만 계정 잔액을 계산하고 실제로 데이터를 검색하는 데 어려움이 있습니다.

두 번째 시나리오에 기대어 있습니다. 그러나 몇 가지 문제가 있습니다.

• 단일 레코드를 어떻게 업데이트합니까? 내가 실수를했다고 가정하고 임대료로 $ 100를 기록하는 대신 $ 10를 기록했습니다. 나는 지금 2- transaction_records하나의 신용과 직불에 대한 금액을 $ 10의 금액으로 가지고 있습니다.
• 이제 화해를하고이 오타를 수정하고 싶습니다. 데이터베이스에서이 문제를 어떻게 해결합니까? 레코드 간 연결을 모르고 분할 된 경우 한 트랜잭션에 두 개 이상의 레코드가있을 수 있습니다. 내가 찾은 유일한 해결책 ref_id은 각 레코드 쌍에 대해 특정 레코드의 컨텍스트 내에서 "서로 반대편"인 레코드를 고유하게 식별하는 일부를 추가 하는 것 tx_id입니다.

어떤 접근 방식이 더 좋거나 간단합니까?

내 질문을 단순화하기 위해 : 계좌 A에서 계좌 B로 자금 이동을 표현하고 싶습니다. 제가 제공 한 두 가지 시나리오는 이러한 거래를 저장하는 유효한 디자인입니다. 또한 지적했듯이 둘 다 단점과 단점이 있습니다 (첫 번째 : 저장하기 쉽고 검색하기가 어렵고 두 번째는 반대입니다).

그들은 지금 당장 눈에 띄지 않는 다른 장단점이있을 수 있으므로 경험이 많은 사람들에게 의견을 묻습니다.

실제로 제안 된 단일 행 회계 스키마를 사용하면 "금액"데이터의 중복성을 도입하지 않고도 적절한 이중 입력 회계를 수행 할 수 있습니다 (항상 차변 및 대변 계정 지정).

1 행 스키마는 구성에 의해 균형을 잡는 이중 엔트리의 구현을 제공하므로 "평형을 잃는"것은 불가능합니다. 기계는 원장을 즉시 재 계산할 수 있습니다.

원장을 검색하려면 하나 대신 2 개의 선택을 수행해야합니다.

트랜잭션 분할 외에도 외환과 같은 다른 트랜잭션이 4가 아닌 2 개의 레코드로 끝날 수 있습니다. 모두 비정규 화하면 비슷한 설명으로 4 개의 트랜잭션 만 입력하면됩니다.

감사 추적을 유지하기 위해 트랜잭션의 입력 또는 수정을 막을 수 있습니다. 트랜잭션 로그를 감사하려는 경우에 필요합니다.

위의 스레드에서 CPA의 경우 "완전히 표준화 된"은 모든 회계사에서 인식 한 규칙을 의미하는 것으로 보이지만 프로그래머에게는 파생 된 데이터 나 중복 된 데이터가 없다는 의미가 다릅니다.

회계 데이터에는 금액, 거래 내역 및 거래 내역과 날짜, 일부 설명 (및 기타 첨부 파일)을 제공하는 일련의 거래가 있습니다. 원장 및 잔액은 합을 수행하여이 트랜잭션 데이터에서 파생 된 간단한 뷰입니다.

저널 회계 시스템에 대한 특정 유형의 모든 거래의 연대기 목록입니다. 다음은 간단한 영업 (계정) 저널의 원장 종이 에 대한 고전적인 프레젠테이션입니다 .

모든 라인은 단일 거래이며 총 차변 = 총 크레딧입니다. 모든 거래는 동일한 3 개의 계정에 도달합니다. 현금 판매 저널은 비슷하지만 열을 대체 할 미수금 직불 카드를 하나의 표시로 현금 직불 . 현금 지출 저널은 표시된 첫 번째 열 것 현금 신용 와 같은 추가 열 미지급금 직불 및 직원 비용 직불를 .

이 프리젠 테이션은 수십 년 전에 개인용 컴퓨터의 가격이 저렴해질 때까지 수백 년 동안 표준이었습니다. 각 행을 간단히 확인하여 모든 트랜잭션의 균형을 쉽게 확인할 수 있다는 중요한 이점이 있습니다. 마찬가지로, 해당 거래 의 페이지를 원장 에 게시 하기 전에 총 페이지 수를 유사하게 확인할 수 있습니다. 그건입니다 일괄 처리 많은 회계 시스템에 사용되는 모델.

이 논문 모델이 문자 그대로 자동화 시스템으로 전사 될 때 심각한 단점이 있음을 쉽게 알 수 있습니다.

1. 데이터 구조는 피봇 팅 된 반면, 경험에 따르면 접힌 데이터 구조에 대해 프로그래밍하는 것이 훨씬 간단하고 (보다 강력하고 쉽게 검증 됨); 과
2. 모든 전문화 된 저널 이 다른 계정 세트에 도달 하기 때문에 이러한 각 저널 은 개별적으로 설계 및 프로그래밍되어야하며 낭비적이고 오류가 발생하기 쉬운 활동입니다.

이러한 이유 때문에 일반적으로 전문 저널 디자인을 회계 시스템에 대한 인터페이스로 사용하는 것이 좋지만 여러 저널의 숫자 저장소가 될 수있는 데이터 구조를 디자인하는 것이 좋습니다 . 현대의 RDBMS에서는 총계정 원장 및 전문 서브 리더 조차도 저널에서 인덱스 된 뷰 가 될 수 있어 전기 프로세스 (저널 트랜잭션이 잠겨 있고 계정이있는 단계) 를 코딩 하지 않아도 된다는 잠재적 이점이 있습니다. 총계는 다양한 원장에 기록됩니다.

어떤 데이터 디자인을 사용하든간에 핵심은 잔액 확인이 이루어지는 각 거래 유형 (즉 , 동등한 용지 시스템의 각 전문 분개) 에 대해 단일 전기 항목 을 갖는 것 입니다.

내 요점은 당신이 제안하는 두 가지 접근 방식이 이중 입장 부기를위한 건전한 메커니즘이라는 것입니다. 첫 번째 요점 : 저널은 매우 좋은 이유로 1 회 기록 테이블입니다. 때때로 두 개의 가상 테이블 보류 항목 및 게시 된 항목이 단일 데이터 구조에 배치되지만 IsPosted 비트는 항상 쓰기 전용이며 시스템은 게시 된 항목 레코드의 읽기 전용 특성이 유지되도록해야합니다.

회계사가 지난 800 년 동안 분개를 전기 한 방식 은 완전히 정규화되었습니다 . 종이 프리젠 테이션과 건전한 전자 프리젠 테이션의 유일한 차이점은 후자의 경우 접힌 테이블 구조가 더 편리하고, 전자의 피벗 테이블 구조는 역사적으로 고도의 병렬 처리가 요구 될 때 가장 중요했습니다. 단일 또는 소수의 전문 저널을 유지 관리합니다. 과거에는 컨트롤러 만 일반 저널에 대한 권한을 가졌습니다.

위에서 필자는 저널 항목 이 완전히 정규화 되도록 지정했음을주의하십시오 . 분개 는 각 거래 유형에 따라 분개로 그룹화 된 모든 거래의 시간순 레코드입니다. 게시물 의 분개 완벽 그 자체 정상화하면서 원장에가 별도의 노력이며, 계정에 의해 저널 모든 트랜잭션이 요약되어 항목 (원장) 또는 자세히 (하위 원장)의 중복 사본입니다. 분개와 원장 모두 독립적으로 이중 입력 부기를 사용합니다.

@Codism 모든 회계 시스템, DEB 또는 SEB는 기록 된 모든 계정에 대한 일반화 된보고 기능 을 제공합니다 . 내부적으로 하위 원장은 정의에 따라 단일 항목 부기 레코드입니다. 다른 쪽은 대차 대조표 의 해당 관리 계정 입니다. DEB 모든 자산 1 달러에 대한 정확한 기록이 보장 자산에 대한 비즈니스 요구 , 즉 자본 그것이이든 자산에서 부채 자본 (부채 일명) 또는 소유 지분은 , 그 주장은 if의 우선 순위 조직은 파산하게됩니다.

이 영역에있는 오픈 소스 소프트웨어의 보물을 살펴볼 것을 제안합니까?

" 오픈 소스 이중 엔트리 회계 소프트웨어 " 의 Google 은 몇 가지 유망한 조사 방법을 제공합니다.

여기 에서 GNU 회계 패키지 , 몇 가지 검토 사이트 ( 1 & 2 ) 및 마지막 으로 자유 소프트웨어 섹션이있는 회계 소프트웨어 위키 를 볼 수 있습니다.

F / LOSS 소스 코드와 스키마 중 일부를 살펴보면 자신의 특정 요구에 맞는 스키마 및 / 또는 소프트웨어를 작성하는 방법에 대한 힌트와 표시를 얻을 수있을 것입니다.

단일 회선 계정보다 이중 회선을 사용하는 시스템이 있습니다. 먼저 직불 측처럼 밀린 한 줄의 인스턴스가 발생하여 계정이 불균형하게되었습니다. 커밋 및 롤백에 대한 적절한 제어를 수행하지 않더라도 단일 회선 계정에서는 발생하지 않습니다. 마지막으로, DB는 두 배의 성장률로 증가하고 두 번째 줄 보내기에는 많은 중복 정보가 있으며 두 번째 계정과의 유일한 차이점입니다. 단일 회선 계정을 유지하여 해당 경로로 이동하는 것이 좋습니다 ..