Anwendungslogik für Fakturierung und Abonnements?

Question

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).

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?

Answer 1

Eine der Anwendungen, an denen ich arbeitete, hatte dieses Problem, und wir lösten es, indem wir verfolgen, welches Abonnement ein Benutzer hatte, aber nicht Verfolgen des Ablaufdatums. Dann haben wir das Datum verfolgt, an dem sie auf ihrem Konto abgerechnet werden sollten. Wenn wir also sehen wollten, auf welchem ​​Abonnement jemand war, konnten wir einfach den neuesten Abonnementdatensatz für ihr Konto abrufen, und wenn wir das sehen wollten Wenn sie das nächste Mal in Rechnung gestellt würden, würden wir einfach ihre next_bill_date überprüfen.

Auf diese Weise können Sie die Abonnements eines Benutzers nachverfolgen und sehen, wann diese aktualisiert oder herabgestuft wurden. Ihr Abrechnungscode bleibt jedoch einfach - und Sie müssen sich keine Gedanken über Überlappungen machen (da die Abonnements keine Enddaten haben) damit umgehen).

Answer 2

Zum Nachverfolgen der Abonnementhistorie eines einzelnen Kunden würde ich sagen, dass es besser ist, neue Abonnements hinzuzufügen.

Sie sparen sich auch den Kopf, herauszufinden, warum ein Abonnement, das am 30. Januar bestellt wurde, im März ausläuft (Sie wissen, dass Februar der kürzeste Monat ist ...).

Answer 3

Ich denke nicht, dass es notwendig ist, mehrere Abonnementdatensätze für einen einzelnen Kunden zu erstellen, solange Sie nur einen einzigen Abonnementtyp haben. Wenn der Abrechnungszeitraum immer monatlich zu einem festen Preis ist, genügt es, das Abonnement-Enddatum zu ändern. Alles, was Sie wissen müssen, ist, wenn sein Abonnement abgelaufen ist, damit Sie die Rechnungsstellung stoppen können. Also, wenn er sein Abonnement verlängert, müssen Sie nur einen einzelnen Datensatz aktualisieren, damit die Abrechnung nächsten Monat fortgesetzt wird.

Auch ich denke, es wäre eine bessere Idee, unbezahlte Abonnements zu markieren, anstatt sie zu löschen. Wenn ein Kunde eine monatliche Zahlung verpassen sollte, kennzeichnen Sie das Abonnement als unbezahlt, damit die zukünftigen Rechnungen (und der Dienst) angehalten werden. Wenn sie zahlen, heben Sie die Markierung des Abonnements auf, damit die Rechnung für den nächsten Monat fortgesetzt wird.

Answer 4

Ich würde die Abonnementtabelle verwenden, um nur Abonnements zu verfolgen. Dies bedeutet, dass, wenn der Kunde sein Abonnement verlängert, ein neuer Datensatz eingefügt wird.

Darüber hinaus würde ich der Kundentabelle eine Subskriptionsdatumsendedatumspalte hinzufügen, die bei der Einfügung neuer Subskriptionen über Trigger aktualisiert wird.

Während dies eine Denormalisierung ist, ermöglicht eine solche Methode Ihrer Webanwendung, den Kundenzugriff auf den Dienst ohne Join zu überprüfen (wodurch die Belastung des Datenbankservers reduziert wird). Tatsächlich muss nur der Stapel die Tabelle des Abonnements abfragen.

Darüber hinaus könnte die Abonnements Geschichte hält nützlich

• im Streitfall mit einem Kunden
• im Fall einer Änderung in der Geschäftslogik des Unternehmens (zum Beispiel am besten Kunden Rabatt zu geben, basierend auf ihre Treue)
• für künftige Statistiken

Wenn Ihre Benutzerbasis und Abonnements Geschichte riesig mantain werden wird, Sie zu periodica entscheiden konnte lly backup, durch den Export in einem praktischen Format (ich würde immer xml verwenden, aber einige der Unternehmen, die ich mit bevorzugten csv gearbeitet).