Объектно-ориентированный дизайн для платежей и счетов?

Question

Я немного борюсь с тем, как проектировать систему для отслеживания счетов и платежей. В настоящее время у меня есть два функционирующих объекта (Bill и Payment), но не могут рассчитывать на способ отслеживания учета между ними.

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

1) Создайте отдельную таблицу учета, в которой я отслеживаю каждую транзакцию, сопоставляя конкретный законопроект с конкретным платежом. Это позволило бы мне легко найти в базе данных, сколько осталось на конкретном счете. Недостатком является то, что это похоже на большую сложность, поскольку мне нужно создать новую запись в этой таблице всякий раз, когда создается новый объект.

2) Постарайтесь просто написать логику, чтобы вычислить на лету, сколько осталось на конкретном Билле, просматривая всю историю транзакций и делая учет. С положительной стороны это гарантировано всегда будет правильным, но кажется неправильным продолжать делать один и тот же расчет снова и снова, чтобы получить то, что должно быть статическим значением.

Кто-нибудь сталкивался с таким вызовом в прошлом, и если да, то как вы его решили? Есть ли какая-то лучшая практика, которую я просто пропустил?

Answer 1

Один стол: сделка. Счета имеют положительное значение, платежи имеют отрицательное значение. Вы можете указать столбец для параметра transaction_type, если хотите (счет-фактура, оплата, кредит, возврат), и вы даже можете использовать Rails STI в этом столбце, если вам действительно нравится . Другие полезные столбцы - number, payment_type (credit/cash/check/eft), дата.

Остальное равновесие - это просто сумма всех значений. Если баланс отрицательный, кредит должен.

Если вам действительно необходимо применить платежи к конкретным счетам (практика, которую я не совсем уверен в правильном учете), у вас может быть дополнительная таблица (paid_bills), которая отображает платежи по счетам с суммой; предположительно сумма всех платных_баллов.payment_id не может быть больше, чем сама оплата.

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

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

Answer 2

Если вы можете использовать базу данных, создайте только таблицу для счетов и добавьте поле типа boolean 'paid'. Если вы хотите узнать, оплачен ли счет, проверьте это поле, когда вы хотите узнать глобальный баланс, добавьте суммы оплаченных счетов и вычтите невыплаченные.

Если нет, вы можете использовать статический var для любого из этих классов, чтобы сохранить глобальный баланс. А также поле для уплаченных или не о переводных или указатель на платном объект (который будет обнуляются и будет указывать на платный объект, как только это будет создано)

Answer 3

• законопроекта HAS_MANY платежей, таким образом, платеж has_one Bill (и ваша таблица платежей будет иметь поле bill_id). Я считаю, что это единственный разумный способ моделирования этого.
• Не беспокойтесь о том, что «продолжайте делать одни и те же вычисления снова и снова». Получите свою объектную модель правильно, а затем подумайте об оптимизации позже. Время CPU дешево; умственная способность человека и способность управлять сложностью не являются! Если вы действительно дойдете до того момента, когда этот повторный расчет является предметом озабоченности (а это, откровенно говоря, маловероятно), есть множество вариантов для его ускорения без нарушения фундаментальных отношений, которые имеют эти модели.