財務記録を保持するデータベースを設計するとき、どのような特別な考慮事項が必要ですか？

この質問が広すぎないことを願っています。将来的には、いくつかのアプリケーション（主にWebベースのアプリケーションですが、私の質問はデスクトップアプリケーションにも関係します）にいくつかの会計および財務追跡システムを追加する必要があります。

現在、金融取引の簡単な記録を作成することは理論的には簡単です。いくつかの列を持つ1つのデータベーステーブルで作業を行うことができます。MS Access、Excel、または単なるASCIIテキストファイルでさえ、取引日、アカウントID、および金額を保存するために使用できます。ただし、トランザクションの整合性を備えた頻繁にバックアップされるSQLテーブルでさえ、深刻な財務追跡には十分な堅牢性がない場合があります。

「ダブルエントリアカウンティング」などの用語を耳にしますが、ほとんどの財務追跡アプリ（たとえば、Mint.com、GnuCash）には、すべてを確実に二重にするために、はるかに複雑なデータ構造またはプロセスが用意されているように感じます必要に応じて完全に加算され、データが失われたり破損したりすることはありません。

私の質問は次のとおりです。金融取引を追跡するアプリを設計するとき、特別な設計上の考慮事項を作成する必要がありますか？非常に多くの潜在的な問題があるようです...丸め精度、パリティチェック、ある種の監査プロセス、特別なバックアップ、セキュリティ/暗号化、データ入力中にクラッシュした場合のデータを保護する追加の方法に関する問題。 ...私が具体的に何を尋ねるべきかは本当にわかりませんが、プログラミング業界には私が何も知らない一連のベストプラクティスがあると感じています。彼らは何ですか？

編集：

予想以上に大きなワームの缶を開けたようです。明確にするために、私は特に2種類のアプリについて考えています。

1. GnuCashやQuickenなどの「レジストリの確認」タイプのアプリは、個人が使用するトランザクションを記録します。
2. 企業と取引するベンダーと顧客の請求書/クレジット/または「ポイント」を追跡するアプリ。

私は恐らく、ダイレクトバンキングや（関連する）多くの金融関連の政府規制が添付されているものは何もしないでしょう。

あなたはこれに対する多くの答えを得るでしょう、多くの理想主義者の答えも、私は財政の経験と実際に起こっていることからしか答えることができません。

あなたはすでに大部分の問題を扱っています。

丸め精度は、実際には私の経験ではあまり問題にならない傾向があります。一晩で成長していない大規模な金融機関の大部分（つまり、ヘッジファンドを除くすべて）には、さまざまな燃料のために分割されるレガシーアプリケーションの巨大な範囲があります。それらは一貫して丸め精度を行わない傾向があります。一般的に、特定のエラーの損益は、丸めのために単に受け入れられます。実際、私が働いた場所で多くの工数が費やされており、正確な/予想される合計に一致することになると、究極の「はい」に近いセレクターが選択されます。覚えておいてください、これは現実に基づいた答えであり、起こるべきことではありません。

暗号化-率直に頼らないでください。識別データを、非識別データとは物理的および論理的に別個のシステムに保存します（どこでもアカウントコード、個人データは分離）。

一般に、バックアップが必要ですが、オフラインバックアップが呼び出されることはほとんどありません。その時点で事態はひどく間違っています。通常、ウォームプロダクションコピーが必要です-ただし、これはユーザー固有のニーズによって異なります。一般的には、すべてのシステムのウォームオンサイト実動コピーと、独自の実動コピーとウォームコピーを持つ災害復旧サイトがあります。ウォームコピーは、レプリケーションなどで数分遅れる傾向があります。

監査は、これまで取り組んできたすべての金融システムの鍵です。2つの基本的な要件がありますA）データに加えられたすべての変更を、だれが、いつ、なぜ、追跡できますか？B）データの履歴状態を証明できますか？改ざんされていないということですか？

A）運用チームに必要です。システムは予想外の100の方法で使用されます。この情報は、拡張、アドホックレポート、法的理由、デバッグに不可欠です。

B）AMEX対Vee Vinhneeのケースを参照してください-AMEXは、記録が作成されていないことを証明できなかったため、40kを徴収できませんでした。これに一般的に使用されるソリューションは、信頼できるタイムスタンプです。大規模な金融機関には、取引を保証する保証銀行があり、信頼できるタイムスタンプを本質的に提供します。他の一連の生活/シナリオ用に、このための商用プロバイダーがあります。

考慮事項はほとんど合法的なものです。安全性/信頼性の観点から見てみると、Excelシートは本質的に、ある引き出しにある紙のシートよりも安全性が低いとは限りません。Accessのトランザクションの整合性は、呼び出しによって中断される店員よりも優れている場合があります。

ただし、顧客がそれを使用できるようにするには、現地の法律に準拠する必要があります。（ドイツで）出会ったいくつかのこと

• ストレージ関連のドキュメント形式、企業が10年間書類を保管しなければならない法律があるため。10年後、あなたのプログラムはもう利用できなくなっているかもしれません。したがって、DIN / ISO認定の方法でドキュメントを保存する必要があります（ドイツでは.pdfで十分なようです）
• 多くの場合、監査証跡が必要です。たとえば、同じ文書の異なるバージョンを変更日とともに提示する必要がある場合があります。
• 「Datenschutz」（プライバシー）のため、保管場所は重要です。保管国によって異なる場合があります。これにより、クラウドベースのサービスは少し複雑になります。
• 一部のドキュメントは、変更不可能な方法で保存する必要があります。これがどのように正確に達成されるかは、主に合法的なニッチピッキングに依存するようです（論文は不変であり、CDは変更可能であり、労働者によって署名されたCDはそうではありません）

詳細については、弁護士に明確に連絡するか、少なくとも顧客と緊密に連携して作業する必要があります。

あなたが人々のお金を扱っているとき、信頼性の要因は驚くほど重要になります。Twitterがツイートを失ったとしても、それほど大したことではありません。誰かのクレジットカードに請求しても注文を失った場合、組織内の誰かが怒っている顧客から耳を貸そうとします。そのため、次の2つのことを行う必要があります。1。そもそもそれが発生するのは望ましくありませんが、2。どんなに注意を払っても最終的には発生するので、ロギングとトレースのメカニズムに多大なエネルギーを注ぎたいそれは戻って「失われた」注文を見つけ、状況を修正するのに役立ちます。

絶対に最悪なのは、たとえばクレジットカードの請求をすることですが、その目的や所有者などについては記録がありません。

財務面では、一見非常にありそうもないシナリオでさえ考えて、それらを処理する方法を計画する必要があります。「クレジットカードに請求しましたが、対応するレコードを更新する前にデータベースサーバーがダウンします。」OK チャージを無効にしますか？人間が後で修正できるように、トランザクションをファイルに記録しますか？ディスクがいっぱいで、ファイルに書き込めない場合はどうでしょうか？等

[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]場合によっては、複数のレコードを詳細に使用し、ヘッダーレコードで単一の値に追加すると、通貨または金額の値が結果に影響する場合があります。

ほとんどのデータベースブランドは、現在、通貨または通貨のデータフィールドをサポートしています。これを使って。

いくつかの特別な状況では、いくつかの人々はそれらをいくつかの小数桁をサポートする固定浮動小数点値に格納します（「10進数」）、または文字列値として。

これらの技術は両刃の剣です。アプリケーションでそのような精度が必要な場合は、Webを検索して、適切に実装する方法のチュートリアルを探してください。

乾杯。[キティに開いたマグロ缶を与えることを忘れないでください。

あなたはあなたの質問にタグを付けましたsecurityが、あなたは主に一貫性と信頼性について話しているので、方程式のその部分に答えようとします：

• データベーストランザクションを使用して、バッチ操作の整合性を確保します。最も基本的な例は、2つのアカウント間の振替です。1つのアカウントから金額が差し引かれ、もう1つのアカウントに貸方記入されます。トランザクションを使用して、部分的な転送が発生しないようにします（一方だけが変更されます）。
• 精度DECIMALを上げるには、floatの代わりにtypeを使用してください。計算ははるかに遅くなりますが、ほとんどの財務計算は非常に基本的なため、感じる必要はありません。
• アップタイムにはレプリケーションを使用し、バックアップにはホットコピーを使用します。回復のためにLVMスナップショットも調べる必要があります

私が見る考慮事項のいくつかは、内部統制を考慮する必要があるということです。つまり、テーブルに対するアクション（挿入/削除/更新）へのすべてのアクセスは、ストアドプロシージャ（動的SQlなし）を介して行われる必要があるため、テーブルはシステム管理者以外の誰に対してもテーブルに対する書き込みまたは削除権限を直接許可しません。また、誰かが新しい会社を作成してからその会社にアイテムを請求することを許可しない内部統制を考慮する必要があります（詐欺のルート）。このようなアクションでは、常に2つの異なる役割の人々が承認する必要があります。また、ある人がデータを入力し、別の人が費用を承認しない限り、小切手を切らないでください。

すべてのテーブルには、監査レコードを作成するトリガーが必要です。不正行為を防止し、もしそれがいつ誰がいつアクションを実行したかを正確に判断することを目的としています。

金融アプリケーションでは、ユーザーインターフェイスには表示されない多くのバックエンドプロセスに関心があります。あなたの最初の懸念は、詐欺を防ぐことです。したがって、誰も気付かない多くのチェックがバックエンドで行われます。

GAAP（米国では、他の国は独自の会計基準を持っています）を熟読し、CPAをコンサルタントにしないと、会計慣行が間違っている可能性があるため、あらゆる種類の金融アプリケーションに取り組むことはありません。これは非常に技術的な分野であり、必要な知識がなくても、この分野でソフトウェアを作成しようとするビジネスはありません。

会計はしばしば検証に関するものです。これを覚えていて、各エンティティ間の関係を理解し​​ている限り、間違えるのはかなり難しいです。

私はできるだけ多くのチェックをリストしようとしますが、常にいくつかのチェックを逃します。あなた自身の掘削を始めるのに十分であることを願っています。

合計借方==合計クレジット。これは、アカウントのセット全体について話しているのか、単独のトランザクションのみについて話しているのかに関係なく当てはまります。集計されない場合は、どこかに少なくとも1つの投稿を見逃しています。これが総勘定元帳のバランスです。

売掛金（管理勘定への借方）==合計請求額（すべての請求可能金額の合計）-受け取った合計（受け取ったすべての支払いの合計）。これは、実際の物理的および有形のドキュメント用語でのトランザクションの合計が総勘定元帳（二重入力）とどのようにバランスを取るべきかの例です。

銀行残高（銀行の明細書による）==その口座の総勘定元帳合計+受け取っていない小切手-預け入れていない小切手-銀行に入金されていない小切手元帳。

ご覧のとおり、すべての取引、サブ元帳、さらには在庫は総勘定元帳と直接結びついています。

単体テストを実行している場合は、チェック対象を知っている限り、トランザクションを挿入/更新するたびにこれらの残高が存在することを確認するテストを非常に簡単に実行できます。

もちろん、チェック/集計するバランスはもっとありますが、必要な作業の要点を把握する必要があります。基本的に、物理的な文書、総勘定元帳明細、銀行取引明細書など、すべてが他のすべてとバランスを取ります。それは完璧なバランス、またはあなたが丸めに対処するのが面倒な場合には、完璧に近いはずです。

開発中に実行できるチェックが多いほど、何かがおかしくなる確率は低くなります。

ところで、あなたが丸めを扱うとき、フロートの代わりに小数で行くようにしてください。：P