Внедрение систем кредитной карты?
Мой сайт будет иметь систему кредита, которая в основном работает много как кредитная карта. У каждого пользователя есть неограниченный кредитный лимит, но в конце каждой недели, они должны заплатить его. Например, пользователь мог бы сделать несколько покупок между 1-го и 7-го марта, и затем в конце 7-го марта, они будут посланы по электронной почте счет, который перечисляет все их покупки в течение недели и общего количества, которое должно 14-м. Если они не заплатили его, их учетная запись просто деактивируется, пока они не делают. Я просто пытаюсь перенести голову, как реализовать это.
У меня есть список всех их покупок, это не проблема, но я просто пытаюсь выяснить, что сделать с ним. На конце 7-го дня я мог настроить cronjob для генерации счета, который будет в основном иметь идентификатор, и дата истечения срока, и затем мне была бы нужна другая many-many таблица для соединения всех покупок со счетом. Затем, когда пользователь добавляет деньги к их учетной записи, я предполагаю, что это применяется против их текущего выдающегося счета? И что, если они не заплатили свой счет к тому времени, когда новый счет вращается, поэтому теперь у них есть 2 выдающихся, как я знаю, чтобы применить его против? Или я осуществляю cronjob проверку для каких-либо предыдущих выдающихся счетов, отменяю их и добавляю новый объект к новому счету как "баланс вперед (+interest)"? Как Вы применили бы деньги против счета? Каждая оплата должна была бы быть связана со счетом, или я мог просто внести ее к их кредиту учетной записи и затем так или иначе выяснить то, что было заплачено и что не имеет? Что, если они платят заранее, прежде чем был сгенерирован их счет? Я вычитаю его от их кредита из счета на поколение, или в конце недели когда его должное? Существует столько способов сделать это...
Кто-либо может описать то, что приближается, они взяли бы?
Если кто-либо заинтересовал, моя модель 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 дней.
Учет сальдо вперед похож на учет платежей по кредитным картам, когда есть единовременный остаток, который переносится вперед, и платежи производятся по этому общему остатку, а не по отдельным счетам.
Обновление для уточнения
Учет по открытым позициям хорош для сложных процессов выставления счетов, например, когда к определенным счетам прилагаются только некоторые товары. Например, строитель покупает несколько десятков товаров, но счета за них должны быть выставлены отдельно для трех разных строительных проектов.
Учет по открытым позициям также используется, когда необходимо отслеживать каждый отдельный счет-фактуру для целей оплаты и разрешения споров. Например, у поставщика строительных материалов есть строитель для клиента. Иногда поставляемые товары оказываются неправильными или бракованными, поэтому строитель оплачивает все остальные счета (включая более поздние), кроме этого, который отслеживается и рассматривается отдельно - возможно, оплата производится при поставке запасных товаров, а возможно, выставляется кредит-нота против счета-фактуры.
В бухгалтерском учете по методу "сальдо вперед" вы бы разрешили эту ситуацию, просто применив кредит к счету в целом, а затем повторно добавив операцию, когда будут поставлены заменяющие товары. Любые проценты, начисленные на остаток, также могут быть сторнированы по счету.
Упрощенно, вот как вы можете настроить это в вашей базе данных:
Open Item Accounting
Вам нужны следующие таблицы:
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]
При покупке продукта на счете клиента выполняется транзакция, показывающая количество продукта и сумму, а также обновляется баланс счета клиента. При получении чека на счете клиента снова производится транзакция, и баланс счета клиента обновляется. Переплаты и выплаты процентов - это тоже просто транзакция. Во время выставления счета вы просто берете все транзакции (покупки, квитанции, процентные платежи и т.д.), которые не отнесены к счету-фактуре, и добавляете их в новый счет-фактуру. Счет-фактура не отображается в списке транзакций, он нужен только для удобства отслеживания транзакций, по которым был выставлен счет-фактура, а также для того, чтобы клиенты могли указывать его номер при оплате. Возможно, вы также захотите отслеживать квитанции в этой модели.
Другие соображения
- Здесь не учитывается проводка по главной книге, которая будет представлять собой совершенно другой набор таблиц. Это только для управленческого учета, а не для финансового.
- На практике между клиентом и счетом-фактурой может существовать таблица проектов для отслеживания каждого из индивидуальных проектов клиента.
- Это очень упрощенно, просто чтобы дать вам представление. Для полной реализации, несомненно, потребуется больше таблиц и полей.
Что касается того, что произойдет, если они не оплатят свой счет, когда придет время выставлять счет, в любой системе это не имеет значения - вы не вернетесь в прошлое и не измените предыдущие бухгалтерские проводки. Все, что происходит сейчас, включается в новый счет-фактуру. Конечно, вполне уместно иметь в новом счете-фактуре строку "Ранее непогашенный остаток", которая показывает сумму, которую они уже должны (или в кредит за переплату).
Вы также захотите иметь возможность подготовить выписку из счета, которая не является счетом-фактурой, а просто напоминает им о том, что у них есть неоплаченные остатки. Это используется, когда нет необходимости генерировать новый счет, но клиенту нужно напомнить о балансе его счета.
Для своих систем я предпочитаю учет по открытым позициям, но, судя по вашему описанию, учет по сальдо вперед вполне подходит.