さまざまなASRに苦しみ、自分でASRの開発に参加した人として、私はASRを評価するために見ることができる典型的なスキームの欠如に、そして自分のASRを作成する前に定期的に遭遇しました。 ネットワークにはこのトピックに関する多くの作品があり、例えば、卒業証書を書くときにこの作品を研究したことがあり
ます 。 卒業証書は卒業証書であり、それからスキームを引き抜くことは、現実に対応していないため、奇妙な職業です。
その結果、ASRでの作業でかなりの経験を積んだため、私は独自のスキームを作成することにしました。 しかし、私はまだ一人なので、他の人に見せて批判する価値があります。 ですから、彼らがこのトピックに興味を持ってくれて、他に何をする必要があるのか、どうやってやるのか教えてくれるといいのですが。 ここで公開するスキームは、すでに改良と調整が行われているだけでなく、すでに
githubからダウンロードする機会があります。 Power Architectのファイルとしても、PostgreSQLの完成したDDLファイルとしても。 参考書に記入する時間がないだけですが、すべてに時間があります。 それでは、スキームに移りましょう。
最初のステップは、回路を表す最も便利な手段として、ER図を調べることです。
ご覧のとおり、多くのテーブルがありますが、実際には機能は非常に小さいです。
また、次の機能で構成されています。
- 顧客との契約を維持し、バランスシートを維持する
- サービスの保管と保守
- 提供されるサービスの充電
- 割引き
- 支払いをする
- 契約から契約への資金移動
- 顧客の残高を別のシステムから転送するときに入力する
- 顧客請求ストレージ
- 請求書の決済
これは、サービスおよび現金会計の正確な発生のために必要な最小値です。
しかし、説明に移る前に、スキームで使用されている規則に言及する価値があります。
- すべての外部キーは、 <主キー> _ <テーブル名>という形式です。 複数の外部キーがある場合、またはそれらがテーブル自体を指している場合、 id_ <テーブル名> _ <説明の追加>またはid_ <説明の追加>の形式の名前への追加が許可されます。 例として、bill.transferテーブルの最初のケースではid_trx_from 、 id_trx_to 、2番目のケースではid_revoke、id_revokedbyです。
- お金のあるフィールドは、数値（18.4）として定義されます。
- 日付のあるフィールドには必ずdtがプレフィックスとして付けられます。
- 日付と時刻を含むフィールドには必ずtsのプレフィックスが付きます。
- 時間間隔（dtfrom、dttoまたはtsfrom、tsto）がある場合、最初の日付は常に設定され、デフォルトはnow（）になります。2番目の日付は空にすることができ、この場合、その間隔は現時点で有効と見なされます。
- 場合によっては、ディレクトリは数値主キーの代わりにテキストニーモニックキーを使用します。 このようなキーはsidとして指定されます。 これは、RDBMSコンソールを介してデータを直接操作するためにのみ使用されます。
そして今、
スライドは説明です。
参照表は次のとおりです。
- 契約（bill.contract）-使用に必要な契約の最小限の説明
- 投稿（bill.trx）-トランザクションのジャーナル。 実際、口座から受け取った、または引き出した金額。
- 使用される会計側（bill.ledgertype）-転記先（借方、貸方）を示します
- レポート期間（bill.period）-会計上の意味での期間ではないレポート。 開始日と終了日が含まれていますが、実際には常に月に等しくなります
- クライアントに発行された請求書（bill.invoice）-レポート期間にクライアントに発行されたのと同じ請求書。
これらのテーブルは請求が機能するのに十分ですが、主要なドキュメントのテーブルは便宜上追加されます。 プライマリドキュメントとは、クライアントの契約に基づいて行われるトランザクションに基づいたドキュメントを意味します。
現在、このスキームには次の主要なドキュメントがあります。
- 残高（bill.remain）-別のシステムからの着信残高。 これらのドキュメントは常に存在する必要があります。そうでない場合、別のシステムから移行する場合、移行時にクライアントの残高がどうなっていたかがわかりません。 ちなみに、これは多くのACPに影響します。開発者はバランスをとるのに十分だと考えています。 しかし、これはそうではありません。通常のシステムでは、クライアントの残高が計算値であるためです。
- 支払い（bill.payment）-顧客から受け取った資金。
- 振替（請求書転送）-ある口座から別の口座への資金の振替。 すぐに私は、彼らの不在下での資金の移動を明示的に禁止する価値があることに注意します。 つまり クライアントの残高がマイナスの場合、転送を禁止する必要があります。
- 料金（請求書）-消費または提供されるサービスの料金（事前に）
- 割引（bill.discount）-サービスの割引。 一般に、割引の表現方法に関するコンセンサスはありません。 割引は、特定の発生に対する金銭的条件で表現されるべきだと思います。 これにより、彼女との作業が簡単になります。
- VAT（bill.vat）-発生時のVATは、別個の文書として発行されます。 見越からのすべての投稿にはVATが含まれませんが、見越自体にはVATが含まれる場合があります。 たとえば、これは個人に必要です。 この場合、bill.chargeには、請求にVATが含まれているという明示的なフラグがあります。 さらに、見越取引にはVATが含まれておらず、請求の全額は2つの取引で構成されています。1つは見越伝票への転記+ VATに基づく転記です。
プライマリドキュメントには、一般的なフィールドとそれらを操作するための一般的なルールの両方があります。 一般的なフィールドから始めましょう：
- id_contract（id_contract_from、id_contract_to）-契約または契約文書を示します
- id_trx（id_trx_from、id_trx_to）-文書の投稿を示します
- id_period-ドキュメントが投稿されるレポート期間。
- ts-文書の日付
- tscreate-ドキュメントが作成された日付。
- amount-ドキュメントの量
- id_revoke-修正されたドキュメント。 これによって修正されているドキュメントを示します。
- id_revokedby-修正ドキュメント。 現在のドキュメントを修正したドキュメントを示します。
報告期間と調整された修正文書については、詳細を説明します。
報告期間。
たとえば、週末が週末になり、銀行支払いがまだ転記されていないなどの理由で、月末に2つのレポート期間が開いている場合があります。 さらに、たとえば、ドキュメントの実際の日付が2014年1月で、使用される期間が2015年6月で、2015年7月上旬に開催される場合、これは必須です。 2015年6月の期間では、作成日は2015年7月2日で、ドキュメントの日付は2014年1月です。このため、ドキュメントには実際には3つの日付があります。
修正および修正ドキュメント。
実際、システムに誤ったドキュメントが表示された場合、そのドキュメントを削除することはできません。 キャンセルのみ可能です。 つまり 誤ったドキュメントとは正反対の修正ドキュメントを作成します。 このために、これら2つのフィールドが使用されます。
id_revoke-修正ドキュメントに記入され、
id_revokedbyは修正ドキュメントに
記入されます。 別の方法、たとえばドキュメントの一部を修正したり、ドキュメントを削除することはお勧めしません。 代わりに、これらのドキュメントが同じ期間に移動する場合は非表示にします。 ドキュメントが異なる期間にある場合、非表示にする必要はありません。 また、投稿にはそのようなフィールドがなく、調整できないことに注意してください。
一般的なフィールドに加えて、プライマリドキュメントには独自の特定のフィールドがあります。
- 見越文書（請求書）-countおよびvatincluded 。 1つ目は提供されるサービスの数を示し、2つ目はドキュメントの量にVATを含めません。
- VAT文書（bill.vat） -id_chargeおよびid_vatrateは、VATおよび発生時のVATの割合を含む、発生文書を示します。
- 割引ドキュメント（bill.discount）-割引が適用された見越額を示すid_charge 。
- 残高のドキュメント（bill.remain） -sid_ledgertypeを使用すると、ドキュメント中にアカウントの使用側を指定できます。
私が考える残りのフィールドは、コンテキストと選択された名前から明らかです。 これで、プライマリドキュメントに関する会話が完了し、残りのルックアップテーブルに進みます。
テーブルには、次のルックアップテーブルが含まれます。
- 支払いの種類（bill.paymenttype）-支払いを種類別に分割します。 現金、銀行振込、支払代理人など
- 測定単位（bill.unit）-実際に使用されるサービスの測定単位。 たとえば、ディレクトリからOKEYを取得できます。 自己参照は、他を含むユニットに使用されます。
- サービス（bill.service）-契約の下で提供されるサービスの名前。
- 価格（bill.price）-サービスのコスト。 付加価値の時間間隔の変化に対応するため。
- 投稿タイプ（bill.trxtype）-プライマリドキュメントに使用される投稿のタイプとデフォルトの会計側を示します。 パーティーがデフォルトで指定されていない場合、選択はドキュメント中に行われます。 たとえば、これらは残高の文書です。
また、2つの補助テーブルもあります。
- 残高履歴（bill.balance）-転記を参照した契約の残高の変更履歴。
- レポート期間（bill.saldo）の売上高（バランス）-期間にリンクされた売上高の集計データを含むテーブル。 さまざまな分析で非常に頻繁に使用されます。
そしてそれだけです。 アンケートへの回答を気にしない場合。 結果は、シリーズの次の投稿を書くときに考慮されます:)さて、コメントで質問してください。