Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refund functionality #251

Open
letehaha opened this issue Sep 2, 2023 · 0 comments
Open

Refund functionality #251

letehaha opened this issue Sep 2, 2023 · 0 comments
Assignees
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

Comments

@letehaha
Copy link
Owner

letehaha commented Sep 2, 2023

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 new RefundTransactions 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:

CREATE TABLE RefundTransactions (  
  original_tx_id INTEGER NOT NULL,  
  refund_tx_id INTEGER NOT NULL,  
  PRIMARY KEY (original_tx_id, refund_tx_id),  
  FOREIGN KEY (original_tx_id) REFERENCES Transactions(id) ON DELETE CASCADE,  
  FOREIGN KEY (refund_tx_id) REFERENCES Transactions(id) ON DELETE CASCADE  
);  

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 of ON DELETE CASCADE.

When implementing, make sure to cover these things:

  1. Always check that the refund tx has the opposite txType to the original one. So if the original is income, then a refund can only be expense.
  2. Make sure that the "refund" amount cannot be greater than the "original" tx amount. This also leads to the point 3.
  3. When editing the amount or currency of the source transactions (original or refund), make sure that new amount is not greater than the one from the opposite transaction.
  4. When editing the 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 an autoUnlinkRefunds flag to do it under the hood on the API side.
  5. Make sure that it works correctly cross-account, when original tx is made within account_A, and refund withing account_B.

Side quests:

  1. Ability to return statistics with and without refund info. But most-likely users don't need it
@letehaha letehaha added type::enhancement New feature or request repo: frontend Related to front-end repo: backend Related to back-end need more info Requires additional details priority-3-low UX improvement Something that improves the overall UX type::epic Epic. Big issue which containes sub-issues labels Sep 2, 2023
@letehaha letehaha self-assigned this Aug 17, 2024
@letehaha letehaha removed the need more info Requires additional details label Aug 17, 2024
@letehaha letehaha changed the title Ability to exlude transaction from statistics Refund functionality Aug 17, 2024
@letehaha letehaha added priority-1-high High priority and removed priority-3-low labels Aug 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Projects
None yet
Development

No branches or pull requests

1 participant