2012-06-15 6 views
7

月額(または毎週)固定金額の定期請求を伴うアプリケーションを作成しています。契約がキャンセルされるまで継続することができます。 お客様は事前に複数の期間を支払うことができます。 予約を取り消して、未払いの期間の後に戻ってくることができます。 期間が過ぎているときに私に知らせるためには、システムが必要です。定期的な請求データベースの設計

だから私は

は、いずれかのアプリケーションのこの種のようになってきた、(おそらくデータベースの問題はなく、プログラミングものではありません)データベースの設計方法で私の脳を燃やしていますか?どのようなアプローチが取られていますか?

答えて

2

私はあなたがそれを複雑にしていると思います。

テーブルのユーザーを作成します。

pk id_user 
nm_user 
fl_status (active, canceled, pendent, etc) 

は、多くのサブスクリプションへの表サブスクリプション一人のユーザーを作成します。

pk id_payment 
fk id_subscription 
fl_type (card, payment order, something else) 
fl_status (generated, sent, confirmed, canceled because of subscription canceled, canceled because of something else, etc) 
dt_generated 
dt_sent 
dt_confirmed 
dt_canceled 
[I think you will need another fields to follow and confirm the payment, but it depends of your payment model) 

pk id_subscription 
fk id_user 
fl_type (maybe there are different subscriptions, with different prices) 
dt_in 
dt_out 

を多くの支払いをテーブルの支払い1つのサブスクリプションを作成します。今では、いくつかの特定の時間に毎日実行するいくつかのロボットを構築する必要があります。

アクティブなクライアントとそれぞれの最終支払いを取得した場合、最後に確認された支払いが実際の日付と比較してx日以上経過した場合に新しい支払いを生成する必要があるかどうかを知ることができます前払い、後払いなど)。はいの場合は、新しい支払い注文を生成します。

ロボットが注文したメールや何かを送信します。

別のロボットがお支払いモデルを使用して支払いを確認します。

もちろん、各ユーザーのステータスには支払いがないためにキャンセルされるか、裁判官に送られるまで、ロボットが状況を維持する必要があるため、モデルを非常によく定義する必要があります。それは大変な仕事ですが、大きな問題はありません。

ps:より複雑なシステムになると、データベースは持続し、必要なすべての情報を得ることができます。すべての注文のログがあります。状態。あなたは、あなたが持っている予定日数、1日後、2日後に何人が支払うかを見積もり、月々に計算することができます。

+1

私は支払いを請求書と支払いテーブルに分け、これはOKと思われる以外のより標準的なフィールド名( 'id'、 'subscription_id'など)を使用します。 Agile Toolkitは、さまざまなデータベース設計レイアウト(http:// agiletoolkit)を処理できます。org/learn/understand/model/add – romaninsh

4

私はあなたがデザインであまりにも巧妙になりすぎてそれを思慮深くしようとしている可能性があると思います。ビジネス上の問題について考えると、各支払い間隔は事実上請求書になります。インボイステーブルを作成し、各アカウントの周期性とその期間中にアクティブであるかどうかに基づいて、スケジュールされたジョブに一定の間隔でインボイスを挿入させるだけではどうでしょうか。

実際の請求書行を持つことで、顧客からの支払いを求めるときに参照できるInvoiceIDが得られ、各請求ごとに個別に支払い状況を追跡できます。

時には単純ですが最適です。

関連する問題