Logika aplikacji do fakturowania i subskrypcji?

Question

Jesteśmy dopiero na etapie planowania aplikacji internetowej, która oferuje subskrypcje dla naszych klientów. Okresy subskrypcji są różne i mogą być przedłużane przez naszych klientów na czas nieokreślony, ale zawsze trwają co najmniej jeden miesiąc (30 dni).

Gdy klient podpisze górę, informacje o klientach (adres rozliczeniowy, numer telefonu i tak dalej) są przechowywane w customers stole i subskrypcja jest tworzony w subscriptions tabeli:

id | start_date |  end_date | customer_id 
-------------------------------------------------------- 
1  | 2010-12-31 |  2011-01-31 | 1 

Co miesiąc” Przejdź przez tabelę subscriptions (najlepiej cronjob) i utwórz faktury za poprzedni okres subskrypcji, które znajdują się w ich własnej tabeli - invoices. W zależności od klienta faktury są drukowane ręcznie i wysyłane pocztą lub po prostu wysyłane pocztą elektroniczną do klienta.

Ze względu na charakter naszych klientów i produktu, musimy oferować wiele różnych metod płatności, w tym przelewy i płatności kartą, dlatego niektóre faktury mogą wymagać ręcznego przetworzenia i zarejestrowania jako opłacone przez nasz personel.

Piętnaście każdego miesiąca, tabela invoices jest zapętlona, ​​a jeśli żadna płatność nie została zaznaczona dla rzeczywistej faktury, odpowiedni abonament zostanie usunięty. Jeśli zarejestrowana jest płatność, tabela end_date w tabeli subscriptions zwiększa się o kolejne 30 dni (lub co teraz oznacza nasz okres, który wybrał nasz klient).

Czy patrzymy na bóle głowy, zwiększając daty do przodu i do tyłu, aby obsłużyć niepłacących klientów i przedłużając subskrypcje? Czy byłoby lepszym pomysłem dodawanie nowych subskrypcji, gdy klienci przedłużą subskrypcję?

Answer 1

Jedna z aplikacji, nad którą pracowałem, miała ten problem i rozwiązaliśmy go, monitorując, jaki subskrypcja miał użytkownik, ale , a nie śledząc datę wygaśnięcia. Następnie śledziliśmy datę, w której miały być rozliczane na swoim koncie - jeśli więc chcieliśmy zobaczyć, na czym polega subskrypcja, możemy po prostu pobrać najnowszy rekord subskrypcji dla ich konta i jeśli chcemy zobaczyć następnym razem, gdy będą naliczane, sprawdzimy tylko ich next_bill_date.

Robiąc to w ten sposób, możesz śledzić subskrypcje użytkownika i sprawdzać, kiedy zostały uaktualnione/obniżone, ale kod rozliczeniowy pozostaje prosty - i nigdy nie musisz się martwić o nakładanie (ponieważ subskrypcje nie mają dat końcowych radzić sobie z).

Answer 2

Aby śledzić historię subskrypcji pojedynczego klienta, powiedziałabym, że lepiej jest dodawać nowe subskrypcje.

Zaoszczędzisz sobie także kłopotów z ustaleniem, dlaczego subskrypcja zamówiona na 30 stycznia wygasa w marcu (wiesz, luty jest najkrótszym miesiącem ...).

Answer 3

Nie uważam, aby konieczne było tworzenie wielu rekordów subskrypcji dla pojedynczego klienta, o ile istnieje tylko jeden rodzaj subskrypcji. Jeśli okres rozliczeniowy jest zawsze miesięczny po ustalonej cenie, wystarczy zmienić okres ważności subskrypcji. Wszystko, co musisz wiedzieć, to kiedy skończy się jego subskrypcja, dzięki czemu możesz przestać fakturować. Tak więc, jeśli rozszerza swoją subskrypcję, wystarczy zaktualizować pojedynczy rekord, aby wznowić instalację w przyszłym miesiącu.

Sądzę, że lepszym pomysłem byłoby oznaczenie niezapłaconych subskrypcji zamiast ich usunięcia. Jeśli klient nie zauważy miesięcznej płatności, oznacz abonament jako niepłatny, aby przyszłe faktury (i usługa) zostały zatrzymane. Kiedy/jeśli płacą, odlczasz subskrypcję, aby usługa/następne miesiące zostały wznowione.

Answer 4

Chciałbym użyć tabeli subskrypcji, aby śledzić tylko subskrypcje. Oznacza to, że gdy klient przedłuży swój abonament, zostanie wstawiony nowy rekord.

Ponadto dodałbym do tabeli klienta kolumnę daty subskrypcji, która ma być aktualizowana za pomocą wyzwalacza przy wstawianiu nowych subskrypcji.

Chociaż jest to denormalizacja, taka metoda umożliwi Twojej aplikacji internetowej sprawdzenie dostępu klienta do usługi bez żadnego łączenia (zmniejszenie obciążenia serwera bazy danych). Rzeczywiście, tylko partia będzie musiała przesłać zapytanie do tabeli subskrypcji.

Ponadto, zachowując historię subskrypcji może być przydatna

• w przypadku sporu z klientem
• w przypadku zmiany logiki biznesowej przedsiębiorstwa (na przykład dają najlepsze zniżki klientów w oparciu o ich wierność)
• dla przyszłych statystyk

Gdy baza użytkowników i historia subskrypcje będzie ogromny mantain, można zdecydować się na Periodica lly backup, eksportując w wygodnym formacie (zawsze używałbym xml, ale niektóre z przedsiębiorstw, w których pracowałem z preferowanym csv).