재무 기록을 보유 할 데이터베이스를 설계 할 때 어떤 특별한 고려 사항이 필요합니까?

이 질문이 너무 광범위하지 않기를 바랍니다. 앞으로 일부 회계 및 재무 추적 시스템을 일부 응용 프로그램 (대부분 웹 기반 응용 프로그램)에 추가해야 할 수도 있지만 질문은 데스크톱 응용 프로그램에도 적용됩니다.

이제 금융 거래에 대한 간단한 기록을 작성하는 것은 이론적으로 쉽습니다. 몇 개의 열이있는 하나의 데이터베이스 테이블이 작업을 수행 할 수 있습니다. MS Access, Excel 또는 일반 ASCII 텍스트 파일조차도 거래 날짜, 계정 ID 및 달러 금액을 저장하는 데 사용될 수 있습니다. 그러나 트랜잭션 무결성을 가진 자주 백업되는 SQL 테이블조차도 심각한 재무 추적에 충분하지 않을 수 있다고 생각합니다.

"double-entry accounting"과 같은 용어가 들리고 대부분의 재무 추적 앱 (예 : Mint.com 또는 GnuCash)은 모든 것을 이중 보장하기 위해 훨씬 더 복잡한 데이터 구조 또는 프로세스를 가지고 있다는 느낌을받습니다. 데이터를 정확하게 추가하고 데이터가 손실되거나 손상되지 않도록합니다.

내 질문은 : 금융 거래를 추적하기 위해 앱을 디자인 할 때 어떤 특별한 디자인 고려 사항을 고려해야합니까? 반올림 정밀도, 패리티 검사, 감사 프로세스, 특수 백업, 보안 / 암호화, 데이터 입력 중 충돌이 발생하는 경우 데이터를 보호하는 추가 방법과 같은 잠재적 인 문제가 너무 많은 것 같습니다. ... 구체적으로 무엇을 요구해야할지 모르겠지만, 프로그래밍 산업에는 내가 알지 못하는 모범 사례가 있다는 느낌이 들었습니다. 그들은 무엇인가?

편집하다:

예상보다 더 큰 벌레 캔을 연 것 같습니다. 명확히하기 위해 특별히 두 가지 유형의 앱을 생각하고 있습니다.

1. GnuCash 또는 Quicken과 같은 "레지스트리 확인"유형의 앱은 자신의 용도로 개인 거래 기록을 유지합니다.
2. 회사와 거래하는 공급 업체 및 고객의 송장 / 신용 / 또는 "포인트"를 추적하는 앱.

아마 직접 금융 또는 (AFAIK) 수많은 금융 관련 정부 규정이 첨부되어 있지 않을 것입니다.

당신은 이것에 대한 많은 답변을 얻을 것입니다. 많은 이상 주의적 답변들도 있습니다. 나는 재무에 대한 나의 경험과 실제로 진행되는 것에서 만 대답 할 수 있습니다.

이미 대부분의 문제를 다루었습니다.

반올림 정밀도는 실제로 내 경험에별로 문제가되지 않는 경향이 있습니다. 하룻밤 사이에 자라지 않은 대부분의 대규모 금융 조직 (예 : 헤지 펀드)은 다양한 연료로 인해 분리 된 광범위한 레거시 애플리케이션을 보유하고 있습니다. 반올림 정밀도를 일관되게하지 않는 경향이 있습니다. 일반적으로 특정 오류 손익은 단순히 반올림에 허용됩니다. 실제로 많은 인력 시간이 내가 정확히 / 예상 합계와 일치 할 때 궁극적으로 '충분히 예'인 선택기가있는 인간이 근무했던 장소에서 소비됩니다. 이것은 실제 상황에 대한 대답이며, 무슨 일이 일어나지 않아야하는지 기억하십시오.

암호화-솔직하게 의존하지 마십시오. 식별되지 않은 데이터는 식별되지 않은 데이터 (즉, 모든 곳의 계정 코드, 개인 데이터는 별도)보다 물리적으로 논리적으로 분리 된 시스템에 저장합니다.

일반적으로 백업이 필요하지만 오프라인 백업은 거의 호출되지 않습니다. 그 시점에서 상황이 잘못되었습니다. 일반적으로 웜 프로덕션 사본이 필요하지만 이는 사용자 고유의 요구에 따라 다릅니다. 일반적으로 모든 시스템의 온 사이트 프로덕션 사본과 자체 프로덕션 및 따스한 사본이있는 재해 복구 사이트가 있습니다. 웜 복사는 복제 등에서 몇 분 뒤쳐지는 경향이 있습니다.

감사는 제가 지금까지해온 모든 금융 시스템의 핵심입니다. 두 가지 기본 요구 사항이 있습니다. A) 언제, 왜, 왜 데이터에 대한 모든 단일 변경 사항을 추적 할 수 있습니까? B) 데이터의 과거 상태를 증명할 수 있습니까? 조작되지 않았습니까?

A) 운영 팀에 필요 – 시스템은 예상치 못한 100 가지 방식으로 사용되며이 정보는 확장, 임시보고, 법적 이유 및 디버깅에 필수적입니다.

B) AMEX와 Vee Vinhnee 사례를 참조하십시오. AMEX는 기록이 작성되지 않았 음을 입증 할 수 없기 때문에 40k를 징수 할 수 없었습니다. 이를 위해 일반적으로 사용되는 솔루션은 신뢰할 수있는 타임 스탬프입니다. 대규모 금융에는 거래를 보장하고 본질적으로 신뢰할 수있는 타임 스탬프를 제공하는 보증인 은행이 있습니다. 다른 보행 / 시나리오를위한 상용 제공자가 있습니다.

고려 사항은 대부분 합법적입니다 . 안전 / 신뢰성 관점에서 살펴보면 엑셀 시트가 일부 서랍의 용지보다 본질적으로 덜 안전하지 않을 수 있습니다. 액세스의 트랜잭션 무결성은 통화에 방해를받는 직원보다 우수 할 수 있습니다.

그러나 고객이 해당 제품을 사용할 수 있도록하려면 현지 법률을 준수해야합니다. 내가 독일에서 만난 것

• 기업이 서류 작업을 10 년 동안 유지해야하는 법률이 있기 때문에 보관 관련 문서 형식 . 10 년 후에는 더 이상 프로그램을 사용할 수 없습니다. 따라서 DIN / ISO 인증 방식으로 문서를 저장해야합니다 (.pdf는 독일에서는 충분할 것 같습니다)
• 감사 추적 은 종종 필요합니다. 예를 들어 수정 날짜와 함께 동일한 문서의 다른 버전을 제시해야 할 수도 있습니다.
• 'Datenschutz'(프라이버시) 때문에 저장 위치가 중요 합니다. 저장 국가에 따라 다를 수 있습니다. 이는 클라우드 기반 서비스를 약간 까다롭게 만듭니다.
• 일부 문서는 변경 불가능한 방식으로 저장해야합니다 . 이것이 정확히 어떻게 달성 되는가는 법적인 nitpicking에 주로 의존하는 것 같습니다 (종이는 불변, CD는 변할 수 있고, 근로자가 서명 한 CD는 그렇지 않습니다)

변호사, 구체적으로 또는 적어도 고객과의 긴밀한 협력 관계에 대해 반드시 변호사에게 문의해야합니다.

사람들의 돈을 다룰 때 신뢰성 요소가 놀랍게 중요해집니다. 트위터가 트윗을 잃어버린다면 그렇게 큰 문제는 아닙니다. 누군가의 신용 카드를 청구했지만 주문을 잃는 경우 조직의 누군가가 화난 고객으로부터 귀를 기울일 것입니다. 따라서 두 가지 : 1. 처음에는 그런 일이 일어나지 않기를 원하지만, 2. 아무리주의를 기울여도 결국 일어날 것이므로, 로깅 및 추적 메커니즘에 많은 에너지를 투입하고 싶습니다. 다시 돌아가서 "잃어버린"순서를 찾고 상황을 해결하는 데 도움이됩니다.

가장 나쁜 것은 신용 카드 청구와 같은 것이지만, 그것이 무엇인지, 누구에게 속하는지 등의 기록은 전혀 없습니다.

재정적 인 측면에서, 겉으로는 불가능한 것처럼 보이는 시나리오까지도 생각하고 처리 방법을 계획해야합니다. "신용 카드를 청구했지만 데이터베이스 서버가 다운되었으므로 해당 레코드를 업데이트 할 수 있습니다." 좋아, 지금은? 청구를 무효화합니까? 사람이 나중에 고칠 수 있도록 트랜잭션을 파일에 기록 하시겠습니까? 디스크가 가득 차서 파일에 쓸 수없는 경우 어떻게해야합니까? 등

[1] 사용자와 앱에 보안 테이블을 사용하십시오 (내부 DB 사용자와 혼동하지 마십시오). 모듈, 양식, 웹 페이지 :

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

[2] 앱에서 레코드를 삭제하지 말고 상태 필드 (정수, 부울 또는 비트)를 사용하여 레코드가 "삭제됨"으로 간주됨을 나타냅니다. 당신을 앱으로 만드십시오. 삭제되지 않은 레코드 (해당 필드에 의해 삭제 된 것으로 표시됨)를 표시하고 앱에서 특별한 사례 양식을 만듭니다. 삭제 된 것으로 표시된 레코드를 표시합니다.

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

이 기능을 "가상 삭제"라고합니다. 실제 삭제를 "실제 삭제"라고하는 경우가 있습니다.

[3] 액세스와 관련된 모든 테이블의 필드를 사용하고, 레코드를 작성한 (단일) 사용자 및 레코드를 변경 한 (마지막) 사용자 및 가능하면 각 레코드가있는 모듈 또는 옵션을 추가하십시오 수정 :

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

[4] 경우에 따라 통화 또는 화폐 가치는 여러 레코드를 자세히 사용하고 헤더 레코드의 단일 값에 추가 될 때 결과에 ​​영향을 줄 수 있습니다.

현재 대부분의 데이터베이스 브랜드는 통화 또는 돈 데이터 필드를 지원합니다. 그걸 써.

특수한 상황에서 일부 사람들은 소수 자릿수 ( "십진법") 또는 문자열 값을 지원하는 고정 부동 소수점 값으로 저장합니다.

이 기술은 양날의 칼입니다. 응용 프로그램에서 이러한 종류의 평가가 필요한 경우 웹을 검색하여 올바르게 구현하는 방법에 대한 자습서를 찾으십시오.

건배. [고양이에게 열린 참치캔을주는 것을 잊지 마십시오.

질문에 태그를 달았 security지만 대부분 일관성과 신뢰성에 대해 이야기하고 있으므로 방정식의 해당 부분에 대답하려고합니다.

• 배치 트랜잭션의 무결성을 보장하기 위해 데이터베이스 트랜잭션을 사용하십시오. 가장 기본적인 예는 두 계정 간의 이체입니다. 한 계정은 금액이 차감되고 다른 계정은 차감됩니다. 트랜잭션을 사용하여 부분 전송이 발생하지 않도록하십시오 (한 쪽만 변경됨).
• 정밀도를 높이려면 DECIMAL수레 대신 유형을 사용하십시오 . 계산은 훨씬 느리지 만 대부분의 재무 계산은 매우 기본이므로 느끼지 않아야합니다.
• 가동 시간에는 복제본을 사용하고 백업에는 핫 카피를 사용하십시오. 또한 복구를 위해 LVM 스냅 샷 을 조사해야합니다

내가 본 몇 가지 고려 사항은 내부 통제를 고려해야한다는 것입니다. 즉, 테이블에 대한 모든 작업 액세스 (삽입 / 삭제 / 업데이트)는 저장된 프로세스 (동적 SQ1 없음)를 통해 이루어져야하며 시스템 관리자를 제외한 모든 사람에게 테이블에 대한 쓰기 또는 삭제 권한을 테이블에서 직접 허용하지 않습니다. 또한 누군가가 새 회사를 만든 다음 해당 회사에 품목을 청구 할 수없는 내부 통제 (계정 사기)를 고려해야합니다. 이와 같은 행동을하려면 항상 두 가지 역할을 가진 사람들이 승인해야합니다. 또한 한 사람이 데이터를 입력하고 다른 사람이 비용을 승인하지 않으면 수표를 잘라서는 안됩니다.

모든 테이블에는 감사 레코드를 작성하는 트리거가 있어야합니다. 사기를 방지하고 언제 누가 조치를 취했는지 정확하게 판단하기 위해 노력하고 있습니다.

재무 응용 프로그램에서는 사용자 인터페이스에서 볼 수없는 많은 백엔드 프로세스에 훨씬 더 관심이 있습니다. 첫 번째 관심사는 사기를 방지하여 백엔드에서 아무도 모르는 많은 점검을하는 것입니다.

GAAP (미국의 경우 다른 국가에는 자체 회계 표준이 있음)를 철저히 읽지 않고 잘못된 회계 관행으로 인해 CPA를 컨설턴트로 두지 않으면 어떤 종류의 재정적 적용도 다루지 않을 것입니다. 이것은 고도의 기술 분야이며 필요한 지식이없는 사람은이 영역에서 소프트웨어를 만들려고 시도하지 않습니다.

회계는 종종 검증에 관한 것입니다. 이것을 기억하고 각 엔티티 사이의 관계를 이해하는 한, 잘못 이해하기는 어렵습니다.

나는 가능한 한 많은 수표를 나열하려고 노력할 것이다. 그러나 일부는 항상 그리워 할 것이다.

총 차변 == 총 크레딧, 이는 전체 계정 세트에 대해 또는 하나의 거래에 대해 개별적으로 이야기하는 경우에 해당됩니다. 집계하지 않으면 어딘가에 하나 이상의 게시물이 누락 된 것입니다. 총계정 원장의 균형이 유지되는 방식입니다.

매출 채권 (관리 회계 순 차변) == 청구 된 총계 (청구 가능한 모든 금액의 총계)-수령 한 총계 (수령 된 모든 지불금의 총계). 실제 물리 및 유형 문서 조건의 총 거래가 총계정 원장 (이중 입력)과 어떻게 균형을 이루어야 하는지를 보여주는 예입니다.

은행 잔고 (은행 명세서에 따름) == 해당 계정에 대한 총계정 원장 총계 + 입금되지 않은 수표-은행에 입금되지 않은 수표-은행 / 현금 계정이 총재와 집계하는 방법의 예 원장.

보시다시피, 모든 거래, 하위 원장, 재고도 총계정 원장에 직접 연결됩니다.

단위 테스트를 수행하는 경우 검사 할 항목을 알고있는 한 트랜잭션을 삽입 / 업데이트 할 때마다 이러한 잔액이 존재하는지 확인하는 테스트를 매우 쉽게 실행할 수 있습니다.

물론 점검 / 탈리 할 잔고가 더 많지만 필요한 작업의 요점을 파악해야합니다. 본질적으로 모든 것이 실제 문서, 총계정 원장 항목, 은행 명세서 등 다른 모든 것과 균형을 이룹니다. 그것은 완벽한 균형이거나 반올림을 처리하기에 게으른 경우에 가깝습니다.

개발하는 동안 수행 할 수있는 검사가 많을수록 문제가 발생할 가능성이 줄어 듭니다.

BTW, 반올림을 다룰 때 수레 대신 소수점을 사용하면 많은 두통을 덜 수 있습니다. :피