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

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

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

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

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

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

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

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

6
задан Industrial 15 December 2010 в 19:11
поделиться