-1

私は、学生の請求、つまり学生からの料金徴収のためのモジュールを含む学校管理ソフトウェアに取り組んでいます。

料金は月単位（年12回）で徴収され、月額料金の合計は、クラスと月ごとに固定されたさまざまな料金の組み合わせです。料金には、授業料、バス代、印刷代などが含まれます。また、その日から月単位で定額の延滞料金が請求されますが、これは月ごとに異なる場合があります。バス料金は、特定の学生のバスのカテゴリごとに請求されます。分割払いの制度もあります。

私の現在のアプローチは次のようなものです：

月とクラス、および料金設定を含む料金設定を格納するマスター テーブル。

feeMaster
    fid  -> Primary key
    month_year -> Stores Month Year
    stu_class -> Class of Student
    tuition_fee -> Tuition fee for that class
    tuition_fee_percent -> Percentage of Tuition fee to take, defaults to 100%
    bus_fee_percent -> Percentage of bus fee
    late_fee_start -> Day of month from which to charge late fee
    late_fee -> fixed late fee on per month basis
    printing_charge -> Printing charge if any
    other_fee -> Other fee if any
    other_fee_reference -> Other fee reference

学生が料金を支払うたびに、計算が行われ、システム内で取引が行われます。トランザクションの詳細は 2 つのテーブルに格納されます。

トランザクションマスターテーブルは、トランザクションを格納するために使用されます

transMaster
    tid -> Primary key
    purpose -> purpose of transaction, monthly fee
    amount -> amount of transaction
    type -> transaction mode / cash / cheque / dd
    created -> date

このトランザクションの詳細は、別のテーブルに次のように保存されます。

studentFeeDetails
    sfid -> unique id
    tid -> transaction id from transMaster table
    fid -> fee id from fee settings table feeMaster
    tuition_fee -> calculated tuition_fee
    bus_fee -> calculated bus_fee
    printing_charge -> calculated printing_charge
    other_fee -> calculated other_fee
    late_fee -> calculated late_fee
    total_fee -> total fee calculated
    discount -> discount if given any
    amount_payable -> net amount payable
    amount_paid -> paid amount
    balance -> balance - if paid amount is greater or lesser than the original one, 
               it is stored here
    status -> status - true if partial fee else false
    created -> date of creation

これは、モジュールの現在のアーキテクチャです。関連する会計慣行がないため、会計部門に多くの問題を引き起こします。

  • 1 か月の合計支払い額を報告するために、システムは毎回、すべての学生に対して計算アルゴリズムを実行し、数字を出します。
  • クラスの保留料金を見つけるために、システムは最初にそのクラスの未収料金を確認し、studentFeeDetailsテーブルで見つかったエントリを削除して保留レポートを生成します。
  • このシステムでは、手数料の頭金を適切に分離することはできません。

現在のシステムは、前払金と残高を追跡できる適切な会計システムに変換する必要があります。

毎月、転記プロセスがすべての学生の口座からその月の料金を引き落とし、延滞料金の開始日ごとに別のプロセスが遅延料金を学生の口座に引き落とすシステムを考えています。

このアプローチにより、売掛金、保留中および受け取った手数料をチェックできます。

アプローチが正しいかどうか、そしてそれをどのように使用するかを助けてください。私はデータベーススキーマ部分とその実装にこだわっています。

4

2 に答える 2

1

電話会社のドメインでのベスト プラクティスは、これを個別の部分に細分化することです。

  • 課金イベントの仲介: 課金イベントはダウンストリーム ビジネス ロジックから生成され、データ ストア (期間、人、およびイベントごとのエントリを含む評価テーブルなど) に格納されます。あなたの場合、これは月に1回実行されます。

  • 評価: イベントごとのレートを計算します。あなたの場合、これはイベントタイプテーブルのルックアップのようです。

  • 請求: 期間ごとの評価されたイベントの累積。あなたの場合、これは請求実行であり、月に 1 回実行されます。

  • 会計: 請求結果を 1 人あたりの口座に転送し、残高を保持し、以前の請求実行と現金回収を考慮します。

  • 請求書発行: アカウント データに基づいて、それぞれの流通プロセスに入れられる請求書を生成します。

  • 現金の回収: お金を受け取ったことを確認し、それに応じて口座を調整します。これはお支払い方法によって異なります。

  • オプション: 督促: 現金回収を強制します。

ここで重要なのは、プロセス全体を透過的にして本番環境でデバッグできるようにすることです。入力と追跡可能な出力を使用して、各ステップを個別のステップにします。これはお金に関するものであり、問​​題が発生した場合に答えがないわけにはいきません。

于 2012-02-18T14:17:19.860 に答える
0

仕様にはあいまいな要件はほとんどありません。学生は部分的に支払うことができますか？手数料の半分を支払うという意味ですか？あなたは会計を扱う人々からのインプットが正確な解決策を実行する必要があるでしょう。

私がこれまで理解してきたことから、すべての種類の手数料については勘定科目表に別々の会計責任者を作成し、預金については会計責任者を作成する必要があります。これらを収入の頭の下に置いてください。入学番号と一致するアカウント番号、またはすべての学生に固有の何か他のものを使用して、すべての学生に個別のアカウント（元帳）を作成します。学生が料金を支払うとき、トランザクションIDを持つジャーナルエントリ（総勘定元帳）を作成します。このジャーナルエントリは承認される必要があります。現金回収の場合、これは現金帳が閉じられた日の終わりに発生する可能性があり、小切手/ ddの場合、これは金額が銀行に送金されるときに発生します（銀行取引明細書の調整）。

ジャーナルエントリが承認されると、投稿されます。ジャーナルは、各学生の元帳の下にあるすべてのアカウントヘッドに自動的に投稿する必要があります。支払われるアクセス金額は、学生の元帳の「保証金」の頭の下に置く必要があります。

未払い料金を計算するには、各元帳の残高を単純に加算します。合計が負の数の場合は料金が発生し、正の場合は超過額が手元にあります。

今、あなたの要件で処理されていない問題は、学生が規定された金額よりも少ない金額を支払うとどうなりますか？どのタイプの料金が部分的または会計用語で支払われたとマークされるべきであり、どのアカウントヘッドの下で負の残高を追加する必要があります。第二に、これらのさまざまな料金はどうなりますか？それらは他のアカウントに転送されますか？要するに、さらなる会計を実施するために、費用がどのように収入にマッピングされ、どの料金がどの費用にマッピングされるかを理解する必要があります。

ところで、税金が支払われているのを見ていません。学校税は無料ですか？

于 2012-02-19T00:51:32.450 に答える