Feature Request: Add distinction between "Effective Date" and "Transaction Date" for better expense prediction

[SunFlowerOwl]

Describe the feature

I would like to propose the addition of a distinction between two key date fields in the accounting application: "Effective Date" and "Transaction Date." The "Transaction Date" would represent the actual date the financial transaction occurred (e.g., the day the payment or invoice was processed), while the "Effective Date" would reflect when the transaction or expense has an impact on the financial records (e.g., the day the expense becomes due or the day it is actually applied in the books).

Why is this feature important?

Why is this feature important? This distinction is crucial for improving the accuracy and performance of expense prediction algorithms. In many financial scenarios, the transaction date does not always correspond to the date when the financial impact is felt. For example, a payment could be made today (transaction date), but it might only affect the account balance at the beginning of the next month (effective date). By separating these two dates, we can provide a more accurate and realistic input for predictive models that forecast cash flow, future expenses, and financial trends.

Additionally, it will allow for better reporting and more accurate financial analysis, as users will be able to track when the financial impact of a transaction truly occurs, rather than simply when the transaction was processed.

Additional context, screenshots, and relevant links

To implement this, we can introduce two separate date fields in the relevant tables:

Transaction Date - This field will store the actual date when the transaction is made or recorded.
Effective Date - This field will store the date when the financial effect of the transaction is realized.

We could set the Transaction Date as the default date for all transactions, but allow users to specify a different Effective Date if applicable. Both fields would be optional but can be filled when necessary.

The implementation would likely require updating existing transaction forms, reports, and potentially the predictive algorithms to take both dates into account.