Preambuła
Moim celem jest stworzenie kodu wielokrotnego użytku dla wielu projektów (a także opublikowanie go na github) w celu zarządzania subskrypcjami. Wiem o rozłożonych i powtarzających się dostawcach faktur, ale nie o to chodzi w tym module. Powinien to być po prostu pomocnik do obliczania salda konta, łatwe powiadomienia o odnowieniu subskrypcji i obsługa obliczeń cen.
Są kraje, w których nie można korzystać z rozliczeń cyklicznych, ponieważ dostawcy lub możliwości płatności mają słabą lub zerową obsługę lub są zbyt drogie (mikropłatności). Są też ludzie, którzy nie chcą korzystać z cyklicznych rozliczeń, ale płacą rachunek ręcznie / wystawiają fakturę pod koniec roku. Dlatego nie sugeruj, aby usługi PayPal były regularnie rozliczane, powtarzalne lub podobne.
Sytuacja
Załóżmy, że masz model, który może subskrybować plan subskrypcji (np User
.). Ten model ma pole, w którym jest przechowywany identyfikator planu subskrypcji, który jest obecnie subskrybowany. Tak więc przy każdej zmianie planu zmiana jest rejestrowana.
Istnieje model (np. SubscriptionPlanChanges
) Z następującymi polami rejestrującymi wspomniane zmiany:
subscriber
odnoszący się do modelu subskrybującego (User
w tym przypadku)from_plan
definiowanie identyfikatora planu, który model miał przed zmianąto_plan
definiowanie identyfikatora planu, który model wybrał terazcreated_at
to pole daty i godziny przechowujące zmianęvalid_until
przechowuje datę, aż aktualna subskrypcja jest ważnapaid_at
to także pole daty i godziny określające, czy (i kiedy) subskrypcja została opłacona
Oczywiście ten układ jest dyskusyjny.
Pytanie o saldo konta
Kiedy użytkownik zmienia swój abonament, muszę porównać pola planu, uzyskać ceny i obliczyć potrącenie dla nowego planu na podstawie aktualnego planu valid_until
i jego ceny. Powiedz: Subskrybowałeś rok planu A, ale po 6 miesiącach uaktualniasz do planu B, więc otrzymujesz odliczenie połowy zapłaconej ceny za 6 miesięcy planu A.
Zastanawiam się: jeśli użytkownik np. Przełączy się na bezpłatny abonament, ma kredyt, który można odliczyć, jeśli użytkownik chce ponownie przełączyć. Czy umieścisz w pamięci podręcznej tę wartość w dodatkowym polu, czy za każdym razem obliczysz wszystkie rekordy związane z tym użytkownikiem? Czy mógłbyś dodać / zmienić coś w układzie tabeli?
Pytanie łatwego zrozumienia
Kiedy nadejdzie okres subskrypcji, użytkownik zostanie powiadomiony i będzie mógł odnowić subskrypcję, płacąc ponownie. Najłatwiejszym sposobem jest po prostu aktualizacja paid_at
i valid_until
nowe opcje subskrypcji. Nie jestem jednak pewien, czy przechowujesz wszystkie dane, które mogą być potrzebne, na przykład historię płatności / subskrypcji.
Inną opcją byłoby utworzenie dodatkowego rekordu dla tego, gdzie from_plan
i to_plan
mają ten sam identyfikator (symbolizując w ten sposób „brak zmian”). Ale czy nie przeszkadzałoby to w jakikolwiek sposób obliczać salda konta?
Jeśli ktoś mógłby skierować mnie w dobrym kierunku na temat logiki obsługującej takie subskrypcje, byłbym bardzo wdzięczny.
AKTUALIZACJA
Dziękujemy za pomoc. Myślę, że moje pytanie było zbyt niejasne, więc postaram się uściślić, używając mniej abstrakcji. Niestety nie udało mi się jeszcze rozwiązać mojego problemu.
Przypadek A
User
może wybrać Subscription Plan A
. Obecnie przechowuje to w SubscriptionPlanChange
celu śledzenia. Po np. 5 miesiącach User
uaktualnia swoją subskrypcję do Subscription Plan B
. Więc płaci cenę za nową subskrypcję, odejmując cenę abonamentu za niewykorzystane 7 miesięcy.
Przypadek B
Po 3 miesiącach User
wycofuje się do swojego Subscription Plan A
. Nie musi płacić, ale otrzymuje za to saldo, dzięki czemu pod koniec subskrypcji pobiera saldo od swojej nowej subskrypcji.
Przypadek C
User
może wybrać plan subskrypcji dla usługi podrzędnej, która ma niezależne plany subskrypcji. To samo Case A
i Case B
może dotyczyć subskrypcji tej usługi podrzędnej.
_Case D_
Użytkownik anuluje jedną ze swoich subskrypcji. To powoduje doładowanie jego równowagi.
Moje pytanie (przynajmniej obecnie) zależy głównie od tego, jak właściwie przechowywać te dane, aby móc odtworzyć historię subskrypcji do analizy biznesowej i obliczyć salda, uzyskać zaległe płatności na podstawie subskrypcji itp.
Nie jestem również pewien, czy saldo powinno być przechowywane np. W samym modelu użytkownika, czy też nie jest przechowywane, ale można je obliczyć w dowolnym momencie na podstawie przechowywanych danych / historii.
Należy zwrócić uwagę na kilka rzeczy, choć nie sądzę, że powinny one wprowadzać problemy:
- To nie musi być
User
, może być cokolwiek, dlategoSubscriber
jest polimorficzny Plans
niekoniecznie muszą to być plany, ale mogą być npMagazines
. wspomniane. To co mam opisane sprawie C i Przypadek D .
źródło
Odpowiedzi:
Niestety odpowiedź na skomplikowany problem jest zwykle skomplikowana. Radzę ci zapisać tylko istotne informacje, a następnie użyć modelu, aby skonstruować większy obraz.
Innymi słowy, twoja tabela SubscriptionPlanChanges będzie zawierała następujące informacje dla swojego klucza:
W ten sposób zezwalasz na wiele planów dla tego samego subskrybenta, które mogą się pokrywać. Inne pola obejmują:
Zauważ, że nie ma „planu z” ani „planu do”. Chociaż możesz je mieć, informacje są zbędne i można je obliczyć samodzielnie (przechowywanie takich informacji oznacza, że masz dodatkowe zadanie, aby zachować spójność). Kiedy zaczyna się nowy plan, zamiast modyfikować istniejące plany, zostawiasz je i po prostu dodajesz nowy rekord. Jeśli po nowym planie istnieje inny nakładający się plan, możesz zdecydować, że chcesz go usunąć (w ten sposób bardziej intuicyjnie). Kiedy ładujesz te plany dla subskrybenta, sortujesz je według daty ważności od.
Po uzyskaniu tego, obliczenie kredytu użytkownika jest stosunkowo proste. Jeśli dwa plany nie mogą się pokrywać, po prostu weź mniejszą z dwóch dat między datą „ważna do” poprzedniego planu i „aktualną od” bieżącego planu, aby ustalić datę końcową. Data początkowa to większa z dwóch dat między datą „ważna od” a datą „płatna do” (jeśli jest zdefiniowana). Płatność (lub kredyt) można następnie obliczyć na podstawie stawki pomnożonej przez przedział czasu między wyżej wymienionymi datami rozpoczęcia i zakończenia tego planu.
W ten sposób możesz teoretycznie obliczyć wszystko, co musisz wiedzieć. Odradzałbym próbę zapisywania obliczonych wartości, ponieważ zmieniłyby się one po zmodyfikowaniu, dodaniu lub usunięciu istniejącego rekordu.
Odmiany sposobu obliczania tych wartości można zarządzać, dodając dodatkowe pole typu. W swoim kodzie możesz stworzyć specjalne moduły do zarządzania logiką obliczania poszczególnych planów, aby utrzymać główny algorytm względnie wolny od skomplikowanych obliczeń. Jeszcze lepiej, jeśli uda Ci się utworzyć moduł obsługi dla przypadku, w którym nie określono żadnego typu, więc wystarczy zadzwonić do odpowiedniego modułu obsługi zgodnie z jego typem, aby wykonać dowolne obliczenia, których potrzebujesz.
Mam nadzieję, że to odpowiada na twoje pytanie.
źródło
valid_until
była moja terminologiapaid_until
. Nie ma maksymalnej długości abonamentu.Oprócz powyższej odpowiedzi stworzyłbym tabelę z kredytami, w której kredyt byłby równy bieżącej walucie. Ilekroć użytkownik przełącza się na tańszą alternatywę, niewykorzystane saldo pojawia się jako kredyty. Ilekroć użytkownik musi coś zapłacić, najpierw wykorzystasz kredyty i poprosisz o płatność tylko wtedy, gdy kredyty się wyczerpią lub nie będą istnieć. Jeśli korzystasz z tej alternatywy, utwórz tabelę jako listę transakcji, aby móc odtworzyć scenariusz użycia, jeśli kiedykolwiek dojdzie do sporu. Przykład:
Identyfikator, identyfikator użytkownika, data transakcji, kredyt (dodatni, gdy użytkownik przyznaje kredyty, a ujemny, gdy użytkownik korzysta z kredytu)
Wystarczy zsumować kredyty, aby użytkownik pokazał mu saldo.
Mam nadzieję, że to ci się przyda ...
źródło