Filtered account report

[Mike or Penny Novack]

On 1/16/2018 6:07 PM, AC wrote:
>
> Yes except that's not how things started or ended up.  Many of the
> transactions are from before GnuCash so they are historical records that
> imported that way.  Second, I really wasn't paying attention to the
> interest in any way other than to record it for record keeping as part
> of a transaction mainly because I was more interested in the portion of
> the payment that went to the principal and tracking the remaining amount
> of payoff.
>
> There were already over 500 transactions at the time I imported into
> GnuCash for the first time.  So it's a bit off base to suggest I should
> have "paid attention" when setting up the CoA when I didn't have a CoA
> due to the original software.  I was lucky enough to get it to import
> with few errors as is.
I thought I was clear enough that this situation is something that we 
ALL had to keep alert for to prevent it from happening. To PREVENT this. 
Obviously not going to help in retrospect for any particular person. For 
example, I now tell people "keep your backups in a separate location" 
--- that did not help me with backups I made before our 2006 house fire. 
I was not being critical that you had not done the separation for 
whatever reason. Sometimes these things are completely beyond our 
control to have foreseen << like a change in tax codes >>

However, you raised another issue, when should we import data from 
another package and when maybe not (create a new set of books under 
gnucash going forward). Factors I would take into account:
1) Is the old package still available on my machine to (re)produce 
historical reports and for viewing historical data? If not, obviously 
you want to import. But if so, you have a choice, and decide based on 
how hard to use the old system for that purpose vs how hard to clean up 
after import.
2) How changed would be your CoA now from your CoA then.
3) Do you have the necessary skills to write a program to modify the 
file being imported.

FIXING the sort of problem you had really a matter for a pro. For 
example, you describe being able to parse externally. Getting the 
computer to do that, parse*, create a batch of correction transactions 
(writing  a special ad hoc program to do that) and bringing in that 
batch is precisely the sort of thing I used to get paid to do. Except it 
would have not been 500 but 5000 or even 50,000 so would have taken a 
whole army of folks sitting at their terminals to do the corrections by 
hand. IF faced with your (initial) problem and realizing that the data I 
was about to import had these transactions all going to one interest 
account but I wanted them separated, I would have written something to 
alter the .cvs or whatever before the import. But not expecting you to 
<< you didn't do this sort of thing for your living; I did >>

I should perhaps add that USUALLY even I cannot see in advance that I 
should split an account. When the first "not quite fitting" transaction 
appears, it might seem an oddball case, so you ignore. It is when 
several others appear you realize not so oddball after all. So even I 
have to correct a few transactions. For example, one of the 
organizations existed more than a decade before the first fixed asset, 
and then several more years before there was a second << and so the need 
to split >>

Michael D Novack


* If you can look at them and tell which, then presumably a program 
could be written to do the same thing.