Внедрение системы кредитных карт?
Мой сайт будет иметь кредитную систему, которая в основном работает как кредитная карта. У каждого пользователя есть неограниченный кредитный лимит, но в конце каждой недели ему приходится его погашать. Например, пользователь может совершить несколько покупок в период с 1 по 7 марта, а затем в конце 7 марта ему будет выслан счет-фактура, в котором перечислены все его покупки за неделю и общая сумма, подлежащая оплате к 14-му. Если они не окупятся, их учетная запись будет просто деактивирована, пока они этого не сделают. Я просто пытаюсь понять, как это реализовать.
У меня есть список всех их покупок, это не проблема, но я просто пытаюсь понять, что с этим делать. В конце 7-го дня я мог настроить cronjob для генерации счета-фактуры, который в основном имел бы идентификатор и дату оплаты, а затем мне понадобилась бы другая таблица "многие ко многим", чтобы связать все покупки с счетом., Затем, когда пользователь добавляет деньги на свою учетную запись, я полагаю, это применяется к их текущему счету-фактуре? А что если они не оплатят свой счет к моменту появления нового счета, так что теперь у них есть 2 выдающихся счета, как я узнаю, к какому из них применить? Или я делаю проверку cronjob для любых предыдущих неоплаченных счетов, отменяю их и добавляю новый элемент в новый счет как "баланс вперед (+ процент)"? Как бы вы применили деньги против счета? Должен ли каждый платеж быть привязан к счету, или я могу просто внести его на счет своего счета, а затем каким-то образом выяснить, что было оплачено, а что нет? Что, если они заплатят заранее, до того, как их счет будет создан? Должен ли я вычесть его из их счета из счета при получении или в конце недели, когда он должен? Есть так много способов сделать это...
Кто-нибудь может описать, какой подход они выберут?
Если кому-то интересно, моя модель Invoice сейчас выглядит следующим образом (в Django). InvoiceItems связаны с фактическими "продуктами" с помощью обратного идентификатора (FK находится на продукте, а не на счете-фактуре, разрешающем разные типы элементов (разные таблицы)), но я думаю, что я собираюсь изменить это.
class Invoice(models.Model):
user = models.ForeignKey(User, related_name='invoices')
created = models.DateTimeField(auto_now_add=True)
updated = models.DateTimeField(auto_now=True)
closed_date = models.DateTimeField(null=True, blank=True)
due_date = models.DateTimeField(default=_next_weekday())
payment_date = models.DateTimeField(null=True, blank=True) # date the invoice was fully paid
total_payments = CurrencyField(default=0)
interest_charges = CurrencyField(default=0)
@property
def days_overdue(self):
dt = self.due_date - datetime.date.today()
return dt.days if dt.days > 0 else 0
@property
def item_total(self):
return self.items.filter(amount__gt=0).aggregate(t=Sum('amount'))['t'] or Decimal('0.00')
@property
def daily_interest(self):
return _round((self.item_total - self.total_payments) * settings.INTEREST_RATE/Decimal('365.242199'))
@property
def subtotal(self):
return self.item_total + self.interest_charges
@property
def tax(self):
return _round(self.subtotal * settings.GST)
@property
def total(self):
return self.subtotal + self.tax
@property
def balance_owing(self):
return self.total - self.total_payments
@property
def is_paid(self):
return self.payment_date != None
@property
def is_open(self):
return self.closed_date == None
@property
def is_overdue(self):
return not self.is_paid and self.due_date < datetime.date.today()
class InvoiceItem(models.Model):
invoice = models.ForeignKey(Invoice, related_name='items')
created = models.DateTimeField(auto_now_add=True)
updated = models.DateTimeField(auto_now=True)
description = models.CharField(max_length=200)
trans_date = models.DateTimeField(verbose_name='transaction date')
amount = CurrencyField()
У меня есть crontab, который запускается в полночь каждую ночь, чтобы добавить процентные платежи ко всем просроченным товарам, а счета отправляются по почте каждую пятницу утром.
1 ответ
То, что вы описываете здесь, является в основном решением между бухгалтерским учетом открытых позиций и бухгалтерским балансом.
В учете открытых позиций каждый счет остается "открытым", в то время как он имеет задолженность, а платежи относятся к отдельным счетам, которые они оплачивают. Это облегчает обработку таких вещей, как проценты - например, если вы начисляете проценты только на балансы старше 30 дней, вам нужно знать, какие счета имеют непогашенные остатки старше 30 дней.
Форвардный учет сальдо аналогичен платежам по кредитным картам, когда существует единовременное сальдо, которое переносится вперед, и платежи производятся на основе этого общего баланса, а не отдельных счетов.
Обновление для уточнения
Учет открытых позиций подходит для сложных процессов выставления счетов, например, когда к определенным счетам-фактурам прикреплены только некоторые продукты. Например, застройщик покупает несколько десятков продуктов, но они должны выставляться отдельно по трем разным строительным проектам.
Учет открытых позиций также используется, когда вам необходимо отслеживать каждый отдельный счет-фактуру для целей оплаты и разрешения споров. Например, у здания есть строитель для клиента. Иногда поставляемый товар является неправильным или неисправным, поэтому застройщик оплачивает все другие счета (включая более свежие), за исключением того, который отслеживается и обрабатывается отдельно - возможно, оплачивается при поставке заменяющих товаров или, возможно, получает кредит-ноту против счет-фактура.
В бухгалтерском учете форвардного баланса вы бы справились с этой ситуацией, просто применив кредит к счету в целом, а затем повторно добавив транзакцию, когда будет поставлен товар-заменитель. Любые проценты, начисленные на баланс, также могут быть возвращены на счет.
Упрощенно, вот способ, которым вы могли бы настроить их в своей базе данных:
Учет открытых позиций
Вам нужны следующие таблицы:
Client [ClientId, Name, AccountBalance]
Product [ProductId, Description, Cost]
Invoice [InvoiceId, ClientId, Date, TotalAmount, Outstanding]
InvoiceItem [InvoiceId, ProductId, Quantity, Amount]
Receipt [ReceiptId, Date, TotalAmount]
ReceiptItem [ReceiptId, InvoiceId, Amount]
Клиент получает счет, созданный при покупке товара. Для каждого купленного товара создается позиция счета-фактуры для этого товара с указанием купленного количества и суммы. Когда счет обновляется, непогашенный остаток счета является суммой счета, и остаток на счете клиента обновляется (может быть рассчитан на лету, но проще и быстрее, если поддерживается автоматически). Когда клиент оплачивает один или несколько счетов, создается квитанция, и пункты квитанции распределяются для каждого оплачиваемого счета. Непогашенный остаток по счету обновляется в соответствии с балансом счета клиента. Обратите внимание, что переплаты должны рассматриваться отдельно. Процентные платежи взимаются со следующего счета-фактуры (или отдельного счета-фактуры) как элемент счета-фактуры (это может быть пользовательский продукт).
Бухгалтерский баланс
Вам нужны следующие таблицы:
Client [ClientId, Name, AccountBalance]
Product [ProductId, Description, Cost]
Invoice [InvoiceId, ClientId, Date, Amount]
Transaction [TransactionId, ClientId, InvoiceId, ProductId, Date, Quantity, Amount]
Когда продукт приобретен, на счету клиента выполняется транзакция, показывающая количество продукта, а также обновляется сумма и остаток на счете клиента. Когда квитанция сделана, снова сделка сделана на счете клиента, и баланс счета клиента обновлен. Переплаты и процентные платежи - это тоже транзакция. Во время выставления счета вы просто захватываете все транзакции (покупки, квитанции, процентные платежи и т. Д.), Которые не распределены по счету, и добавляете их в свой новый счет. Счет-фактура не отображается в списке транзакций, он просто для удобства отслеживания транзакций, которые были выставлены, и для предоставления вашим клиентам ссылочного номера при оплате. Вы также можете отслеживать поступления в этой модели.
Другие соображения
- Это не учитывает проводку в Главную книгу, которая будет представлять собой совершенно другой набор таблиц. Это только для управленческого учета, а не финансового учета.
- На практике между клиентом и счетом может быть таблица проектов для отслеживания каждого из клиентов отдельных проектов с вами.
- Это действительно просто, чтобы дать вам представление. Без сомнения, для полной реализации потребуется больше таблиц и полей.
Что касается того, что происходит, если они не оплачивают свой счет, когда наступает время для выставления счетов, в любой из систем это не имеет значения - вы не возвращаетесь назад во времени и не изменяете предыдущие учетные записи. Все, что происходит сейчас, переходит на новый счет. Конечно, совершенно уместно иметь в новом инвойсе строку с надписью "Ранее непогашенный остаток", в которой указана сумма, которую они уже должны (или кредит за переплату).
Вы также захотите иметь возможность составить выписку по счету, которая не является счетом-фактурой, это просто письмо, напоминающее им, что у них есть непогашенные остатки. Это используется, когда не нужно создавать новый счет-фактуру, но клиенту необходимо напомнить об остатке средств на своем счете.
Я предпочитаю учёт открытых позиций для моих систем, но с вашего баланса описания, похоже, хорошо подходят.