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.
_______________________________________________
gnucash-user mailing list
gnucash-user@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
