Thiết kế cơ sở dữ liệu thanh toán định kỳ

Question

Tôi đang viết một ứng dụng liên quan đến việc lập hóa đơn định kỳ hàng tháng (hoặc hàng tuần) và có thể kéo dài đến khi đăng ký bị hủy. Khách hàng có thể thanh toán trước một vài giai đoạn. Anh ấy có thể hủy đăng ký và sau đó quay lại sau một số khoảng thời gian chưa thanh toán nhất định. Tôi cần thông báo để cho tôi biết khi nào thời hạn quá hạn.

Vì vậy, tôi đốt não của tôi về cách thiết kế cơ sở dữ liệu (có thể không phải là một vấn đề cơ sở dữ liệu nhưng một lập trình một),

Có bất kỳ một đến loại này của các ứng dụng? cách tiếp cận nào đã được thực hiện?

Answer 1

Tôi nghĩ rằng bạn đang làm phức tạp hơn.

Tạo một người dùng bảng:

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

Tạo một thuê bao bàn mà một người sử dụng nhiều thuê bao:

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

Tạo thanh toán bảng một thuê bao với nhiều khoản thanh toán:

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) 

Bây giờ bạn sẽ cần phải xây dựng một vài robot sẽ chạy hàng ngày tại một số thời điểm cụ thể.

Nếu bạn nhận được tất cả khách hàng đang hoạt động và thanh toán cuối cùng của mỗi khách hàng, bạn sẽ biết thanh toán mới có được thực hiện không nếu ngày thanh toán được xác nhận cuối cùng được thực hiện nhiều hơn x ngày so với ngày thực tế. là trả trước, trả sau, v.v.) Nếu có, hãy tạo một lệnh thanh toán mới.

Một rô-bốt sẽ gửi một email hoặc một thứ gì đó có thứ tự (và gắn cờ sau đó là).

Robot khác sẽ xác nhận thanh toán bằng cách sử dụng mô hình thanh toán của bạn.

Tắt khóa học, bạn cần phải xác định mô hình của mình rất tốt vì mỗi trạng thái người dùng cần rô bốt để giữ cho mọi thứ diễn ra cho đến khi bị hủy hoặc gửi tới thẩm phán vì thiếu thanh toán. đó là rất nhiều việc phải làm, nhưng không có vấn đề gì lớn cả.

ps: nếu nó trở thành hệ thống phức tạp hơn, cơ sở dữ liệu sẽ tồn tại, bạn sẽ có tất cả thông tin bạn cần, bạn có nhật ký của mọi đơn đặt hàng, bạn biết điều gì đã xảy ra với mỗi đơn hàng vì chúng có ngày và trạng thái. Bạn có thể ước tính, hàng tháng, bạn sẽ có bao nhiêu ngày, số tiền sẽ trả sau một ngày, sau hai ngày, v.v.

Answer 2

Tôi nghĩ bạn có thể đang cố gắng quá thông minh với thiết kế và đánh lừa nó. Nếu bạn nghĩ về vấn đề kinh doanh, mỗi khoảng thời gian thanh toán là một hóa đơn hiệu quả. Tại sao không chỉ tạo bảng hóa đơn và để công việc được lên lịch chèn một hóa đơn vào các khoảng nhất định dựa trên chu kỳ của mỗi tài khoản và liệu nó có hoạt động trong khoảng thời gian đó hay không.

Bằng cách có hàng hóa đơn thực tế, bạn nhận được InvoiceID mà bạn có thể tham chiếu khi tìm kiếm thanh toán từ khách hàng và theo dõi trạng thái thanh toán riêng lẻ cho từng thanh toán.

Đôi khi đơn giản là tốt nhất.