sossoldi icon indicating copy to clipboard operation
sossoldi copied to clipboard

feat(transaction): generate past occurrences for recurring transactions

Open Ic3b3rg opened this issue 8 months ago • 3 comments

🎯 Description

This PR adds functionality to automatically generate all past transactions when a recurring transaction is created with a start date in the past.

Problem

Currently, when users create a recurring transaction with a start date in the past, the system doesn't automatically generate the transactions that should have occurred between the start date and the current date. This leads to incomplete transaction history and inaccurate financial records.

Solution

Added logic to detect when a recurring transaction's start date is in the past Implemented calculation of all dates between the start date and current date based on the recurrence pattern (daily, weekly, monthly, etc.) Automatically creates individual transactions for each calculated past date Maintains proper transaction records with correct recurring transaction relationships This enhancement improves data integrity and saves users from having to manually create past recurring transactions.

Closes: #336

📱 Changes

  • [x] Describe key changes made
  • [x] List any new features, bug fixes, or refactors
  • [x] Include additional details if necessary

🧪 Testing Instructions

Behaviour

  1. Create a new recurring transaction with a start date in the past (e.g., 3 months ago)
  2. Select different recurrence types (daily, weekly, monthly) to verify all work correctly
  3. After saving, navigate to the transactions list and verify:
  • All expected past transactions have been created
  • The dates follow the correct recurrence pattern
  • Each transaction is properly linked to the recurring transaction
  1. Verify the transactions appear correctly in reports and balance calculations
  2. Try an edge case with a long past date (e.g., 1 year ago) with different recurrence patterns

Edge Cases

  1. Test with months having different number of days (e.g., start date on 31st of a month)
  2. Test with dates spanning across leap years
  3. Verify behavior when creating a recurring transaction with both start and end dates in the past

📸 Screenshots / Screen Recordings (if applicable)

If your PR involves UI changes, please add screenshots or screen recordings here.

Platform Before After
Android
iOS

🔍 Checklist for reviewers

  • [ ] Code is formatted correctly
  • [ ] Tests are passing
  • [ ] New tests are added (if needed)
  • [ ] Style matches the figma/designer requests
  • Tested on:
    • [ ] iOS
    • [ ] Android

✍️ Additional Context

Add any other information that we might know

Ic3b3rg avatar Apr 18 '25 20:04 Ic3b3rg

I think the PR miss some files, the type argument is added in recurringtransaction but is not in the recurring transaction model, the app doesn't run with this pr actually.

lucaantonelli avatar Apr 19 '25 11:04 lucaantonelli

@fres-sudo i will delete all comments, i think that the name of functions already clear

Ic3b3rg avatar Apr 20 '25 17:04 Ic3b3rg

While working on the recurring transactions section, I noticed some behavior that does not seem correct:

  • I saw that it is possible to enter a date that is in the future versus today.
  • The end date of the recurrence does not automatically adjust to the start date, which could lead to illogical configurations.
  • When you edit a recurring transaction and change the start date to a previous day, transactions that should have occurred in that past period are not created.

I was thinking that in order to have a more consistent and correct behavior, perhaps it would be better to merge the resolution of all these issues into this same Pull Request. That way, when we apply it, all the recurring transaction logic should work as we expect.

Let me know if you agree and what you think!

Ic3b3rg avatar Apr 20 '25 18:04 Ic3b3rg

Hi @Ic3b3rg👋 We recently merged a PR that changed the folder structure, which caused some conflicts here. When you get a chance, could you take a look and resolve them?

If there’s no response in the next 15 days, we’ll consider this PR inactive and plan to close it to keep things tidy.

Thanks!

theperu avatar Aug 02 '25 10:08 theperu

Hi @theperu, due to a lot of commitments I haven’t been able to make progress on this. I tried to look into the conflicts, but something completely broke the branch even though I managed to resolve them. I’d suggest closing this PR and reopening the issue on GitHub as unassigned, since at the moment I’m not able to work on it.

Ic3b3rg avatar Aug 11 '25 13:08 Ic3b3rg