Объектно-ориентированный дизайн для платежей и счетов?
Я немного борюсь с тем, как разработать систему для отслеживания счетов и платежей. У меня сейчас есть два функционирующих объекта (Bill а также Payment), но не может договориться о том, как вести учет между ними.
По сути, мне просто нужно знать, какие конкретные счета были оплачены, и общий остаток после всего учета. Я полагаю, что я могу сделать это двумя способами:
1) Создайте отдельную таблицу учета, где я отслеживаю каждую транзакцию, сопоставляя конкретный счет с определенным платежом. Это позволило бы мне легко найти в базе данных, сколько осталось на конкретном счете. Недостатком является то, что это кажется очень сложным, так как мне нужно создавать новую запись в этой таблице каждый раз, когда создается новый объект.
2) Попытайтесь просто написать логику, чтобы на лету рассчитать, сколько осталось на конкретном счете, просматривая всю историю транзакций и ведя учет. С положительной стороны, это гарантированно всегда будет правильным, но кажется неправильным продолжать повторять одни и те же вычисления снова и снова, чтобы получить статическое значение.
Кто-нибудь сталкивался с такой проблемой в прошлом, и если да, то как вы ее решили? Есть ли лучшая практика, которую я просто скучаю?
3 ответа
Одна таблица: транзакции. Счета имеют положительное значение, платежи имеют отрицательное значение. Если хотите, вы можете указать столбец для тип_транзакции (Счет-фактура, Платеж, Кредит, Возврат), и вы даже можете использовать Rails STI для этого столбца, если вы действительно этого хотите. Другие полезные столбцы - число, тип платежа (кредит / наличные / чек / перевод), дата.
Оставшийся баланс - это просто сумма всех значений. Если баланс отрицательный, кредит должен.
Если вам действительно необходимо применить платежи к определенным счетам (я не совсем уверен, что это правильный учет), у вас может быть вторичная таблица (paid_bills), которая отображает платежи по счетам с суммой; предположительно сумма всех paid_bills.payment_id не может быть больше, чем сам платеж.
При отображении вещей для пользователей вы всегда можете поменять знак - Показать платеж в виде положительного числа, а когда форма оплаты отправит положительное число, переверните его обратно отрицательным.
Это лучший способ, который я нашел за эти годы, сохраняя при этом лучшие практики бухгалтерского учета.
Если вы можете использовать базу данных, создайте только таблицу для счетов и добавьте поле типа boolean 'paid'. Если вы хотите узнать, был ли оплачен счет, отметьте это поле, если вы хотите узнать глобальный баланс, добавьте суммы оплаченных счетов и вычтите неоплаченные.
Если нет, вы можете использовать статическую переменную в любом из этих классов, чтобы сохранить глобальный баланс. А также поле для оплаченных или нет векселей или указатель на платный объект (который будет инициализирован нулевым и будет указывать на платный объект, как только он будет создан)
- Билл Платежи has_many, то есть Платеж имеет счет Bill_id (и в вашей таблице платежей будет поле bill_id). Я бы сказал, что это единственный разумный способ смоделировать это.
- Не беспокойтесь о "продолжайте делать один и тот же расчет снова и снова". Сделайте вашу объектную модель правильной, а потом позаботьтесь об оптимизации. Процессорное время дешево; человеческих умственных способностей и умения управлять сложностью нет! Если вы действительно дойдете до того, что повторяющиеся вычисления вызывают озабоченность (что, честно говоря, маловероятно), есть множество вариантов для ускорения этого процесса без нарушения фундаментальных отношений, которые имеют эти модели.