![]() |
Max2: Data Export |
[ < Prev | Contents | Next > ] |
[ Data Export ]
The transaction export function creates a comma-separated value (CSV) file containing the non-binary fields of a selected set of transactions. This allows additional analysis outside Max2 and, potentially, import of the data into other systems.
Here is the start of an exported file open in OpenOffice.org:
A normal transaction selector is used to select the transactions to be exported. Transactions from more than one month can be exported in one operation. Computed fields (those found by the charging rules) cannot (yet) be exported. Also, binary fields (such as account records) are not exported.
After the transaction selector form has been shown, a list of the transaction types which can be selected (irrespective of whether any transactions of those types actually will be selected) and a list of the combinations of the fields in each of these transaction types are displayed.
This form is largely left over from program debugging but does give a useful indication of the fields which will be present in the output file.
Then the options form is shown:
This allows the output file name to be set and also allows a choice of date formats. There are two separate date forms which can be chosen (both are selected by default). You can select to have neither date though you will be asked to confirm you really want this. The first is a single column containing the date in ISO 8601 format (year, month and (for daily transactions) day). There is an option to prefix this date with a '#' character to prevent spreadsheets from interpreting it as a number. The second has the year, month and day in separate columns (with the day column containing zero for start of month transactions).
The output file starts with a header row indicating the columns which are present. The various date fields, when present, are always at the start in the order noted above. If the transaction selector is set to allow a selection of deleted transactions then the date column are followed by a "state" column. This is set to "DELETED" for deleted transactions and left blank for transactions which are not deleted. There is then a transaction type column then columns for each of the transaction fields. The order of the transaction fields should not be considered to be well defined - the column headers should be used to identify the associated fields.
[ < Prev | Contents | Next > ] |