Allow recurring transactions to be split transactions

[simhnna]

Since we can have split transactions, it would be nice if recurrences could also involve multiple splits.

I'm not sure how this should be modeled though. Using the existing Transaction and Split models will end in chaos, while copying the structures seems silly.

I currently can't think of a better solution...

[roanutil]

I've been looking at how best to do this. Have you considered using a scheme like this:

class BaseTransaction(Model):
    class Meta:
        abstract = True

    **most of the fields, methods**

class Transaction(BaseTransaction):
    recurrence = ForeignKey(RecurringTransaction)

class RecurringTransaction(BaseTransaction):
    recurrence_options

class BaseSplit(Model):
    class Meta:
        abstract = True

    **most of the fields, functions**

class Split(BaseSplit):
    transaction = ForeignKey(Transaction)

class RecurringSplit(BaseSplit):
    transaction = ForeignKey(RecurringTransaction)

There would minimal to no duplication. Transactions and RecurringTransactions would function essentially the same. Same for the two Split types. Granted, this is a big change.

[simhnna]

yeah, I guess that would be possible. I have to think about it a little and probably write some code to try it out...

[roanutil]

I'm working on roughing it in. The only major thing I have left is creating a split transaction from a recurring split transaction.

[roanutil]

https://github.com/roanutil/silverstrike/tree/remodel_recurrence

It's not ready to pull. The latest Master commits aren't reflected. It's a big change and should be fleshed out before trying a pull request anyway.

Let me know what you think.

Edit: Updated branch link. Rebased on rework_currences branch. Tests in progress.

[simhnna]

I took a look at it, and I guess the way to goo is to actually use the hierarchy you proposed. However it's a rather big change and I want to get some other changes in first.

I just finished studying and started working, so now I need some other features that I have to think about implementing and will probably have to do some smaller changes to the models and such. If you want, you can open a merge request with your code and mark it WIP, so I don't forget about it being there :-)

[roanutil]

I'll open a pull request this week once the tests, migration, etc are finished. I've been short on time.

[simhnna]

BTW I'm also not very happy with how splits currently work, they are very advanced in that you have to manually supply splits that balance each other out. I would like to have the splits be more user friendly and move this to an expert mode or so, but I'm not sure yet...

I also want to implement saving goals #3 and debts #77 maybe even refunds (or transaction links) #4 Just so you know you don't have to put so much time into this refactor, since I'm not entirely sure the transaction model doesn't change significantly in the process... I want to keep the transactions as close to actual bank statements as possible which is why other things might get a little complicated

[roanutil]

I agree that the splits are less than friendly. Transaction links would handle a lot of the split cases anyway if that's the direction you take. Maybe even something like tags could be useful.

No worries on the refactor. It's been a good learning experience for me and I just don't like making a pull request or putting it down before tests and such are in place. Even if it doesn't get used. If it is used, it should be easier if complete.