Refund functionality #251
Labels
priority-1-high
High priority
repo: backend
Related to back-end
repo: frontend
Related to front-end
type::enhancement
New feature or request
type::epic
Epic. Big issue which containes sub-issues
UX improvement
Something that improves the overall UX
Motivation
There's a common case when some transactions have opposite "refund" transactions that should not be included in the income/spending statistics.
Suggested implementation
Do not touch
Transactions
table at all, let users do whatever they want. Create a newRefundTransactions
table that will simply map "original" transactions to "refund" ones. It allows to easily support complex DB querying, multiple refunds, indexing, and data normalization. The suggested structure is:This structure also allows to not bother much when transactions are editing, or removed. Editing requires only checking for the
txType
change (more info below), and the deletion doesn't require any move at all because ofON DELETE CASCADE
.When implementing, make sure to cover these things:
income
, then a refund can only beexpense
.amount
orcurrency
of the source transactions (original or refund), make sure that new amount is not greater than the one from the opposite transaction.txType
of the source transactions (original or refund), throw an error on the API level and ask the client to unlink refund transactions first. Consider adding anautoUnlinkRefunds
flag to do it under the hood on the API side.Side quests:
The text was updated successfully, but these errors were encountered: