Логика приложения для выставления счетов и подписок?

Question

Мы только на стадии планирования веб-приложения, которое предлагает подписки для наших клиентов.Периоды подписки могут варьироваться и могут быть продлены нашими клиентами на неопределенный срок, но всегда составляют не менее одного месяца (30 дней).

Когда клиент регистрируется, информация о клиенте (платежный адрес, номер телефона и т. Д.)хранятся в таблице customers, а в таблице subscriptions создается подписка:

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

Каждый месяц мы будем циклически проходить по таблице subscriptions (предпочтительно cronjob) и создавать счета дляпрошедший период подписки, который размещен в собственной таблице - invoices.В зависимости от клиента счета-фактуры распечатываются вручную и отправляются по почте или просто отправляются клиенту по электронной почте.

В зависимости от характера наших клиентов и продукта, мы должны предложить различные варианты оплаты, включаябанковский перевод и платежи по карте, поэтому некоторые счета могут потребоваться обрабатывать вручную и регистрировать как оплаченные нашими сотрудниками.

15-го числа каждого месяца таблица invoices проходит циклически, и если для фактического счета-фактуры не было отмечено никакой оплаты, соответствующая подписка будет удалена.Если зарегистрирован зарегистрированный платеж, end_date в таблице subscriptions увеличивается еще на 30 дней (или на то, что сейчас наш период выбрал наш клиент).

Смотрим ли мы на головные боли, увеличивая даты вперед иназад, чтобы справиться с неоплачиваемыми клиентами и продлением подписки?Было бы лучше добавить новые подписки, поскольку клиенты продлевают свою подписку?

Answer 1

У одного из приложений, над которым я работал, была эта проблема, и мы решили ее, отслеживая, какая подписка была у пользователя, но не отслеживая дату истечения срока действия.Затем мы отслеживали дату, на которую они должны были быть выставлены на счет в их учетной записи - поэтому, если мы хотим узнать, на какую подписку кто-то подписался, мы могли бы просто получить последнюю запись подписки для их учетной записи, и если мы хотим увидетьв следующий раз, когда им будет выставлен счет, мы просто проверим их next_bill_date.

. Делая это таким образом, вы можете отслеживать подписки пользователя и видеть, когда они обновили / понизили рейтинг, но ваш код выставления счетаостается простым - и вам никогда не придется беспокоиться о совпадениях (потому что у подписок нет конечных дат).

Answer 2

Я не считаю необходимым создавать несколько записей подписки для одного клиента, если у вас только один тип подписки.Если расчетный период всегда ежемесячный по фиксированной цене, достаточно будет изменить дату окончания подписки.Все, что вам нужно знать, это когда у него заканчивается подписка, чтобы вы могли прекратить выставлять счета.Поэтому, если он продлит подписку, вам нужно будет обновить только одну запись, чтобы оплата возобновилась в следующем месяце.

Кроме того, я думаю, что было бы лучше пометить неоплаченные подписки, а не удалять их.Если клиент пропустил ежемесячный платеж, пометьте подписку как неоплаченную, чтобы будущие счета (и услуги) были остановлены.Когда / если они платят, вы отменяете подписку, чтобы возобновить счет за обслуживание / последующие месяцы.

Answer 3

Я бы использовал таблицу подписок, чтобы отслеживать только подписки. Это означает, что когда клиент продлевает свою подписку, вставляется новая запись.

Кроме того, я бы добавил в таблицу клиентов столбец даты subscription_end, который будет обновляться с помощью триггера при вставке новых подписок.

Несмотря на то, что это денормализация, такой метод позволит вашему веб-приложению проверять доступ клиентов к сервису без какого-либо соединения (уменьшая нагрузку на сервер БД). Действительно, только пакет должен будет запросить таблицу подписки.

Более того, полезно хранить историю подписок

• в случае спора с клиентом
• в случае изменения бизнес-логики предприятия (например, предоставить скидку лучшим клиентам в зависимости от их точности)
• для будущей статистики

Когда ваша база пользователей и история подписок станут огромными для обслуживания, вы можете периодически выполнять резервное копирование, экспортируя в удобный формат (я бы всегда использовал xml, но некоторые предприятия, с которыми я работал, предпочитали csv).

Answer 4

Для отслеживания истории подписок одного клиента я бы сказал, что лучше добавлять новые подписки.

Вы также избавите себя от головной боли при выяснении, почему подписка, заказанная 30 января, истекает в марте (знаете, февраль - самый короткий месяц ...).