Powtarzalny projekt bazy danych billingowych

Question

Piszę wniosek, w którym będzie się powtarzać fakturowanie miesięcznej (lub tygodniowej) ustalonej kwoty, która może trwać do momentu anulowania subskrypcji. Klient może zapłacić kilka okresów z góry. Może anulować subskrypcję, a następnie powrócić po pewnych nieopłaconych okresach. Potrzebuję systemu, aby dać mi znać, gdy upłynie termin.

Więc płonę mój mózg, w jaki sposób zaprojektować bazę danych (być może nie jest to problem, ale baza danych programowania jeden),

Czy ktoś się do tego typu zastosowań? jakie podejście zostało podjęte?

Answer 1

Myślę, że już to komplikujesz.

Utwórz użytkownika tabeli:

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

utworzyć subskrypcję stolik jednego użytkownika na wielu subskrypcji:

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

Tworzenie tantiemy tabeli o jeden abonament wielu płatności:

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) 

Teraz musisz zbudować kilka robotów, które będą działać codziennie w określonym czasie.

Jeśli otrzymasz wszystkich aktywnych klientów i ostatnią wypłatę każdego, dowiesz się, czy należy wygenerować nową płatność, jeśli ostatnia potwierdzona płatność została wykonana więcej niż x dni w porównaniu z faktyczną datą (zależy to od tego, czy jest opłacony z góry, opłacony z góry, itp.). Jeśli tak, wygenerował nowe zlecenie płatnicze.

Robot wyśle ​​wiadomość e-mail lub coś w tym zamówieniu (i oznacz ją jako).

Inny robot potwierdzi płatność za pomocą Twojego modelu płatności.

Oczywiście trzeba bardzo dobrze zdefiniować swój model, ponieważ każdy status użytkownika potrzebuje robota, aby wszystko działało, dopóki nie zostanie anulowane lub wysłane do sędziego z powodu braku płatności. to dużo pracy, ale nie ma nic wielkiego.

ps: jeśli będzie to bardziej złożony system, baza danych będzie się utrzymywać, będziesz mieć wszystkie potrzebne informacje, będziesz mieć dziennik każdego zamówienia, wiesz, co się stało z każdym z nich, ponieważ mają daty i status. Możesz oszacować, ile miesięcy będzie trzeba, ile zapłacisz po dniu, po dwóch, i tak dalej.

Answer 2

Myślę, że możesz próbować zbyt sprytnie zaprojektować i przemyśleć to. Jeśli myślisz o problemie biznesowym, każdy interwał płatności jest fakturą. Dlaczego nie wystarczy utworzyć tabelę faktur i pozwolić zaplanowanej pracy wstawić fakturę w określonych odstępach czasu w oparciu o okresowość każdego konta i czy jest on aktywny w tym okresie.

Posiadając faktyczny wiersz faktury, otrzymujesz fakturę, którą możesz wskazać, żądając zapłaty od klienta i śledzić status płatności indywidualnie dla każdego rachunku.

Czasami proste jest najlepsze.