# Migration Guide

This appendix is to help current users of other financial software packages in their migration to &app;. We address the conceptual differences between the layout of &app; accounts versus other software packages.

## Using Accounts vs. Categories

If you are familiar with other personal finance programs, you are already accustomed to tracking your income and expenses as categories. Since &app; is a double-entry system (refer to section 2.1), incomes and expenses are tracked in accounts. The basic concept is the same, but the account structure allows more consistency with accepted business practices. So, if you are a business user as well as a home user, &app; makes it easy to keep track of your business as well as your personal accounts.

Income and expense accounts give you the same information you would get with categories, but they also give you more flexibility in entering your transactions. In &app;, you have the option to enter transactions directly into income and expense accounts through their account registers. Other programs that use categories do not offer this option, because there is no account register for a category.

You also have the option in &app; to treat income and expense accounts exactly as you would treat categories, if you are more comfortable with that method. In Quicken and similar programs, transactions require an account and a category. Substitute an income or expense account name in &app; where you would normally enter a category name in the other programs, and the result should be the same. We will discuss transaction entry in Chapter 4 in greater detail.

## Organization of QIF Files (Discussion)

## Common Duplication Issues (Discussion)

## Checking QIF Data (Discussion)

## Converting XML &app; File

The &app; XML data file can be transformed to almost any other data format (e.g., QIF, CSV...) quite easily if one is familiar with XSLT. The &app; data file is well-formed XML, and it can therefore be run through an XSLT parser with an associated stylesheet. This allows one to transform the file to just about any format that can be designed, given a properly written stylesheet.

A few steps need to be followed. The writing of a stylesheet is a task for a different time, but if you can get one written, here’s what you need to do:

1. Copy the &app; to a working file. Modify the working file’s <gnc-v2> tag to read something like what’s below. Note that you can pretty much put anything you want in the ="..." part; I used the URL because it’s traditional (if such can be said about such a young technology!).

       <gnc-v2 xmlns:cd="http://www.gnucash.org/XML/cd"
               xmlns:book="http://www.gnucash.org/XML/book"
               xmlns:gnc="http://www.gnucash.org/XML/gnc"
               xmlns:cmdty="http://www.gnucash.org/XML/cmdty"
               xmlns:trn="http://www.gnucash.org/XML/trn"
               xmlns:split="http://www.gnucash.org/XML/split"
               xmlns:act="http://www.gnucash.org/XML/act"
               xmlns:price="http://www.gnucash.org/XML/price"
               xmlns:ts="http://www.gnucash.org/XML/ts"
               xmlns:slot="http://www.gnucash.org/XML/kvpslot"
               xmlns:cust="http://www.gnucash.org/XML/cust"
               xmlns:entry="http://www.gnucash.org/XML/entry"
               xmlns:lot="http://www.gnucash.org/XML/lot"
               xmlns:invoice="http://www.gnucash.org/XML/invoice"
               xmlns:owner="http://www.gnucash.org/XML/owner"
               xmlns:job="http://www.gnucash.org/XML/job"
               xmlns:billterm="http://www.gnucash.org/XML/billterm"
               xmlns:bt-days="http://www.gnucash.org/XML/bt-days"
               xmlns:sx="http://www.gnucash.org/XML/sx"
               xmlns:fs="http://www.gnucash.org/XML/fs"
               xmlns:addr="http://www.gnucash.org/XML/custaddr">

2. Create an XSLT stylesheet containing the transformation your desire, or obtain one that’s already written (AFAIK, there aren’t any, but I’m working on a CSV one).

3. Install an XSLT processor such as Saxon (http://saxon.sourceforge.net/) or Xalan-J (http://xml.apache.org/). Any conforming processor will do, really...

4. Run the work file and the stylesheet through the processor according to the processor’s instructions.

5. You will now have a file in the desired output format. An enterprising individual could go so far as to write a stylesheet to transform the &app; data file to an OpenOffice spreadsheet (or vice-versa, for that matter). Such things as QIF ought to be a little less work.

Benefits are that you don’t need to write a Scheme module or a new C routine to do this transformation. Anyone who knows or can learn XML and XSLT can perform this task. Not much harder, really, than writing a Web page....

Anyhow, I just wanted this tidbit to be captured somewhere permanently. The process works on &vers-stable; datafiles, and ought to work on earlier versions, too.