Bug 416080 - Kmymoney: distinction between date of record and date of movement
Summary: Kmymoney: distinction between date of record and date of movement
Status: REPORTED
Alias: None
Product: kmymoney
Classification: Applications
Component: database (show other bugs)
Version: 5.0.7
Platform: Fedora RPMs Linux
: NOR wishlist
Target Milestone: ---
Assignee: KMyMoney Devel Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-10 11:55 UTC by René
Modified: 2020-01-10 12:51 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description René 2020-01-10 11:55:42 UTC
Hello everybody,

I am not sure to address the correct list. I would like to a feature wish about Kmymoney and not a bug.

The issue concerns the Reconciliation process. I very frequently meet a difficulty in this process when the date of a record is very close to the initial date of a a reconciliation period provided by my bank. 

Account records are registered with their date of emission (the date of the signature of a check, or the date when a transfer is made). My account is debited later, few days later for transfer or credit card payment, and very often two or three weeks later for checks.

When I reconciliate a check payment, I have to go backward in my account to change the date and record the emission date in the record note. There is a loss of information unless printing the final listing of the reconciliation of the previous period.

The reconciliation list provided by banks include two fields: 

* Emission Date, which the date of the check emission, the date of the credit card payment, or the date of the transfer request, and

* Value Date (Date de Valeur in French), which is the date when the bank account is debited or credited.

It would be interesting that such a second field is added to the account file, filled in by default with the first field and displayed in color(red for example) when the corresponding record is not yet reconciliated, and reset in a standard color when it is reconciliated.

This issue is related for Kmymoney versions for both Debian 10, and Fedora 31.

If this is not the right forum, please redirect me to the right one.

Many thanks for your attention.

René Cluzel
Comment 1 Thomas Baumgart 2020-01-10 12:24:05 UTC
I turned this into a wish list item because we currently do not differentiate between the booking date and value date even though the software maintains a date when the transaction has been entered into the data pool. This field though is not accessible to the user.
Comment 2 René 2020-01-10 12:51:21 UTC
Thank you for your reply.

Looking forward to solving this issue.

Regards.

René Cluzel


Le vendredi 10 janvier 2020 à 12:24 +0000, Thomas Baumgart a écrit :
> https://bugs.kde.org/show_bug.cgi?id=416080
> 
> Thomas Baumgart <tbaumgart@kde.org> changed:
> 
>            What    |Removed                     |Added
> -------------------------------------------------------------------
> ---------
>            Severity|normal                      |wishlist
> 
> --- Comment #1 from Thomas Baumgart <tbaumgart@kde.org> ---
> I turned this into a wish list item because we currently do not
> differentiate
> between the booking date and value date even though the software
> maintains a
> date when the transaction has been entered into the data pool. This
> field
> though is not accessible to the user.
>