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

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

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

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

Answer 3

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

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

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

Кроме того, может быть полезно вести историю подписок

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

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

Answer 4

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

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