This is a proposal to add an option to include scheduled transactions in transaction panels.

Motivation

The transaction panels (mmCheckingPanel) currently show only entries in the CHECKINGACCOUNT_V1 table, while the scheduled transactions panel (mmBillsDepositsPanel) shows only entries in the BILLSDEPOSITS_V1 table. This simplifies the implementation, since each panel needs to deal with only one type of transactions.

From the user's point of view, a single list containing both executed and scheduled transactions, in a selected period from past to future, gives a better overview. It also makes the processing of transactions more convenient, since a single interface can provide the functionality which is curretly separated in two interfaces.

The transaction panels are most suitable for the display and processing of each individual transaction, either executed or scheduled, either in the past or in the future. They should give options to select any desirable combination. On the other hand, the report panels (mostly) present aggregate information, and they should also give options to select any combination between executed and scheduled transactions, or between past and future.

This issue proposes a fusion between (already executed) transactions and future executions of scheduled transactions, in one panel. Another issue will propose a similar fusion in the report panels.

Implementation

• Define a new class, which represents either a transaction or an execution of a scheduled transaction. A single scheduled transaction unrolls to one or more executions, which differ only in the execution time (TRANSDATE). This class contains a member field which represents the repetition number, starting from 1 for executions of a scheduled transaction, and set to 0 for transactions. This field discriminates between the two cases.

• A database typically contains only a limited number of scheduled transactions, however the list of their executions may be large, depending on the frequency and the selected period. In order to improve efficiency, an execution of a scheduled transactions is represented by the execution date, the repetition number, and a link to the original scheduled transaction.

• The transactions and the scheduled transactions are fused together as follows: a list of transactions is generated as before; a list of scheduled transactions is generated, if this options has been selected; a list of executions is generated and sorted by date. The two lists (transactions and executions of scheduled transactions) are then processed in parallel; in each iteration the one with the smaller date (TRANSDATE) is selected and stored.

• Once a single list of fused transactions is available, most of the interface functionality is the same for all, however several actions must differentiate between a transaction and an execution of a scheduled transaction.

Task list

• new(#6860), part 1: show scheduled transactions in mmCheckingPanel #6861
• new(#6860), part 2: fix Model_Checking::(amount, balance) #6873
• new(#6860), part 3: duplicate scheduled transaction to transaction #6878
• new(#6860), part 4: add scheduled transaction features #6880
• new(#6860), part 5: merge master and fix conflicts #6981
• new(#6860), part 6: fix bug in account_flow #6983
• new(#6860), part 7: add custom fields in scheduled transactions #7081
• new(#6860), part 8: add notes for scheduled transactions #7084