Bug 347400

Summary:	Categories are set to current date instead of start date
Product:	[Applications] kmymoney	Reporter:	mike <michael.j.engel>
Component:	general	Assignee:	KMyMoney Devel Mailing List <kmymoney-devel>
Status:	RESOLVED FIXED
Severity:	normal	CC:	null, ralf.habacker, windu.2b
Priority:	HI
Version:	4.7.2
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:		Version Fixed In:	4.8.0

Description mike 2015-05-08 03:16:44 UTC

When creating a new file, selected categories are given the start date of (todays date). If I import any bank transactions that occurred before (todays date), I cannot assign them to categories, as the transaction date is before the categories creation date.

Reproducible: Always

Steps to Reproduce:
1.create new file
2.enter any transaction that occurred before the date of the file creation
3.attempt to assign a category to the transaction

Actual Results:  
amount shows in red and the enter button is greyed out (cannot record transaction)

Expected Results:  
I would expect the category start date to be the same of the account opening date

Comment 1 Thomas Baumgart 2015-05-10 11:48:23 UTC

*** Bug 347436 has been marked as a duplicate of this bug. ***

Comment 2 Unknown 2015-06-07 13:30:30 UTC

Hello!

I am also affected.

KMyMoney 4.7.2
KDE 4.14.8
Linux 3.16.7-7-desktop
openSUSE 13.2 (Harlequin) (i586)

- Date of the account's opening: 2015-01-01;
- Date of the transaction I try to add: 2015-05-16;
- I'm trying to add this today: 2015-06-07;

One or two transactions went through, but most of them don't.
Since I'm a beginner with this program, I can't say for sure why.

I get the error mentioned in bug: 347436

"Cannot enter transaction with postdate prior to account's opening date."

The date is displayed in red.

I'd like to up-vote this, since it makes adding transactions impossible (unless you use workarounds, of course).

Thanks,
Bartosz

Comment 3 Thomas Baumgart 2015-06-08 11:18:54 UTC

Usage of opening date information for categories has been eliminated completely. See https://bugs.kde.org/show_bug.cgi?id=313793#c41 for details. This also resolves the problem mentioned here.