Wir sind gerade in der Planungsphase einer Web-App, die Abonnements für unsere Kunden anbietet. Die Abonnementszeiten variieren und können von unseren Kunden auf unbestimmte Zeit verlängert werden, betragen jedoch immer mindestens einen Monat (30 Tage).Anwendungslogik für Fakturierung und Abonnements?
Wenn ein Kunde meldet sich, die Kundeninformationen (Rechnungsanschrift, Telefonnummer und so weiter) in einem customers
Tabelle gespeichert und ein Abonnement ist in der subscriptions
Tabelle erstellt:
id | start_date | end_date | customer_id
--------------------------------------------------------
1 | 2010-12-31 | 2011-01-31 | 1
Jeden Monat stellen wir‘ ll durch die subscriptions
Tabelle (vorzugsweise Cronjob) durchlaufen und Rechnungen für die vergangene Abonnementsperiode erstellen, die in einer eigenen Tabelle untergebracht sind - invoices
. Je nach Kunde werden die Rechnungen manuell ausgedruckt und per Post versandt oder per E-Mail an den Kunden gesendet.
Aufgrund der Natur unserer Kunden und des Produkts müssen wir eine Vielzahl verschiedener Zahlungsalternativen anbieten, einschließlich Überweisung und Kartenzahlungen, daher müssen einige Rechnungen manuell bearbeitet und von unseren Mitarbeitern bezahlt werden.
Die 15. jeden Monat, die invoices
Tabelle durchlaufen werden und wenn keine Zahlung für die tatsächliche Rechnung markiert wurde, wird das entsprechende Abonnement entfernt. Wenn eine Zahlung registriert ist, wird die end_date
in der subscriptions
Tabelle um weitere 30 Tage erhöht (oder was jetzt unser Zeitraum, den unser Kunde gewählt hat).
Suchen wir nach Kopfschmerzen, indem wir Daten nach vorne und hinten inkrementieren, um nicht zahlende Kunden abzuwickeln und Abonnements zu verlängern? Wäre es eine bessere Idee, neue Abonnements hinzuzufügen, wenn Kunden ihr Abonnement verlängern?
Glaubst du nicht, dass es Probleme mit Überschneidungen zwischen neuen/alten Abonnements geben wird? – Industrial