(some) institutions credit my account when I initiate payment. My checking account does not post until the funds are actually withdrawn. There are times when this can be up to 5 days (depending on time of day and day of week). Reproducible: Always Example: Transfer funds from Checking to CC, 24Dec2014. Credit Card posts the credit same day (24Dec2014) Checking posts the the debit (29Dec2014) Currently I have been forcing the Credit Card(s) to use the same date as Checking. Of course, this causes the dates of CC payment transactions to not match their actual statements. Can we get a mechanism that will allow a transaction to have two different dates?Example: Transaction date - post date whereas: Post date == the account currently viewed in the ledger Transaction date == the account on the 'other side' of the currently viewed transaction
The issue is understood. The problem is, that accounting wise a transaction can have only one date (OK, banks operate with two, one for processing and one for the actual value-change). And this date is the same in both accounts. The referenced wishlist item has some more details on that (I guess). Currently you can handle this manually by creating two separate transactions through a third account. This is how I do it. If it happens repeatedly, using scheduled transactions reduces the burdon. *** This bug has been marked as a duplicate of bug 135198 ***
My apologies for not spotting it as a duplicate. Creating a a third (float) account seems like a convoluted and tiresome way for a user to resolve this and for me, scheduling simply will not work. It would seem easier to resolve as a 'split' within the date field.
Think of a transaction as an atomic entity, in that it represents one or more transfers of funds between accounts. For proper bookkeeping, it all has to happen at once. If you allow different splits to have different timestamps, you are essentially making money disappear or appear out of nowhere for a period of time. For large companies, the "float" account is what "accounts payable" and "accounts receiveable" represent. Perhaps there might be a way to simplify the use of a float account from the perspective of the user, but I don't think it would be simple to implement. Perhaps we need to add this issue to the FAQ.
Sorry, but I have to disagree as I have the statements to prove it. This is not hypothetical. This is real world. I feel that one of us is over-thinking this. According to their respective statements one account shows one date, a different account shows another,...... for the same transaction. This is an `issue` in the software because we are referencing against the date and not the transaction#. The transaction # should be the binding element not the date. We already know that a transaction can be split across multiple accounts. It would appear that although KMM assigns a transaction # it actually uses the date for reference. If KMM used the Transaction # for reference instead, each side could have a different date. As such, each side can/may perform any (additional) calculations using the date referenced on it's side respective of the transaction, such as interest. Example: [as viewed by Checking] transaction# (assigned by KMM)|trans_date | post date| transaction| amount 1234567890 |24dec14 | 29dec14 | to CC |too much [as viewed by CC] transaction# (assigned by KMM)|trans_date | post date| transaction| amount 1234567890 29dec14 | 24dec14 |from checking|never enough all that has occurred is a 'perspective' has been assigned to each side held together by the transaction # instead of by the date. Much like one side sees a credit and the other showing a debit. As far as interest calculations go, my CC balance is reduced on 24dec and interest charged on the payment amount stops then, but checking balance is not reduced until the 29th therefor collecting interest until then.
It's not overthinking, it's thinking differently. One of the tenets of KMM is to follow good accounting practice, including double entry bookkeeping. Money can't appear or disappear; it moves from one place to another. What you are asking for is certainly possible, but I'm pretty sure the KMM developers are not going to do it. I don't know for sure, but I don't think any of the other financial applications do it either. There are (almost) always differences between transaction and posting dates: when you write a check vs. when the recipient credits the amount to your account vs. when it clears your bank. It might be possible for KMM to add a second date to all splits, keeping a single transaction date for the internal bookkeeping and allowing you to use the other for sorting and display. A whishlist for that could be reasonable, and I think it is different from the float account requested by bug 135198. This might be done by KMM keeping not only the transaction date, which could remain the same for all splits, but a separate clearing date for each split.
I understand what you are saying, but it is theoretical not actual. In a perfect world that's how it would be. We do not live in that perfect world. My examples above are actual. If my CC company want's to credit my account 5 days before it leaves my checking account, that's their issue/problem not mine (unless of course the payment 'bounces'). Having the CORRECT dates (according to my account's statement) in my ledger on a per account basis is. As you yourself have stated, this sort of thing goes on all the time. The fact of the matter is, if i can't keep the dates correct in the ledger, then the ledger begins to fail in usefulness. The double-entry would, in fact, still exist. There would be no obfuscation (or the chance for more errors) via a (user edited) float account, as the transactions would be `glued` in KMM by the transaction#. As a secondary result, interest calculations would gain accuracy (see comment 4) OR (as you are suggesting?) A background float account could be created (transparent to the user), and in my scenario when dates do not match have a simple popup "dates don't match, should KMM float it -> y/n". leaving it otherwise transparent to the user unless they go digging for it. "<snip> It might be possible for KMM to add a second date to all splits, keeping a single transaction date for the internal bookkeeping...". this causes me to ask 2 questions: 1). which date would be driving the bus, as one of them would be incorrect. 2). although miniscule, would it not affect interest calculations (not that I care personally). What started all this was I reconciled my checking 3 weeks ago. than about 2 weeks ago I reconciled my VISA. When I sat down yesterday to reconcile my Checking, it was FUBAR. Although I have not found it yet, I am (fairly) sure that I have entered a transaction on the VISA side that tossed my checking, because I did not pick up on a (incorrect) date. This is becoming an all too regular SNAFU for me. Jack, thanks for taking the time to engage in dialog on this. I originally submitted this as a wishlist item to which it was marked as duplicate to bug 135198. I hope the devs get some usefulness out of our conversation.
Ah - if you had a problem with reconciliation, there is something goin on other than simply the issue of dates not being what you think they should be. Transaction state (unmarked, cleared, reconciled) is separate for each split. I have plenty of checking transactions cleared in the bank account and unmarked in the credit card account (in that case on-line bill pay, where the bank removes the money as soon as they send it) or the other way around. I've never had a problem with reconciling such accounts, as long as I clear the transaction when the institution for that account does - which is different for the different splits. I suspect your issue is not simply that the date is incorrect (as you see it) but that a transaction was inappropriately marked or not marked as cleared. See if you can find the issue (or prevent it in the future) keeping that in mind. As far as I can tell, the only way that a split date actually affects reconciliation is that the process only takes into account splits with dates on or before the date of reconciliation.
'Incorrect' dates were not the source of the problem(s), I was. However 'correct' dates would have made it easier to locate them. I was able to get the checking account reconciled. There was not something going on. There were SEVERAL somethings going on. Of course, almost all of them involved a data entry error. 1). The data entry for the CC took place via import, then I proceeded to reconcile that particular account, thus reconciling the other side of the transaction. This would create the `inappropriate marking`in Checking that you mentioned. 2). Then I would manually enter data for the checking account. Creating duplicates in some instances, primarily because I was not paying close enough attention (only looking at the data entry widgets, never referencing the ledger itself). As a matter of coincidence(?) 4 things were going on: 1). several of the transfers were for the same amount. Repeats. Making it much harder to find the errant duplicates. 2). because of the holidays they occurred within a day or two of each other. 3). the `date errors` errors we have been discussing. Once the duplicates were finally located, things shook out rather easily. - It seems that I am just going to have to resign myself to declaring that as far as dates go, my checking account drives the bus (because they charge the highest fees if I screw up) regardless of how wrong as that date may be on the other side of the transaction. It also seems that if I am going to continue using KMM (or any other fin.app.) I should do my transfers on weekdays as opposed to Friday nights or over the weekend. This would go a long way towards eliminating any apparent `posting lag` and/or `erroneous dates`.
> 1). The data entry for the CC took place via import, then I proceeded to reconcile that particular account, thus reconciling the other side of the transaction. This would create the `inappropriate marking`in Checking that you mentioned. Something seems wrong here. Reconciling an account, should not change the state of that transaction in the other account. All my credit cards do online updates, and depending on timing, the payment transaction may get marked cleared and then reconciled in either account first, which does not cause any problems in the other account. In fact, you can get a pop-up message when you try to edit a transaction in one account if the split of that transaction has already been reconciled in the other account. Over the next cycle of activity, please note if this is really happening, as I don't think it should.
Jack, You were correct, I was most definitely WRONG.
Not a problem. Problems that just go away or weren't really there can be annoying for a bit, but once you understand what actually happened, it's easier to go forward.