An import file consists of a mixture of format strings and import records. A format string is, in loose terms, a data definition that allows the importer to interpret the records that follow it in the file. A format is in effect until another format is encountered. There can be as few as a single format string at the beginning of an import file if all records have the same layout, or as many as necessary if the import file contains records of different types and layouts.
Format strings can define either comma-delimited or fixed-length record layouts. These can be mixed in the same import file.
Each format string or record is terminated with a carriage return/line feed <CRLF>.
The order in which records are imported can be important. You should always organize the data to be imported in a "top-down" arrangement. For example, when importing an account that has a report name specified, that report has to be imported first. Similarly, the accounts to which transactions post must be imported before the transactions that post to them.
Each notes line is specified on a separate import file line and is appended to the end of an object's existing notes.
If the end of a record is reached before the fields in the format string are exhausted, the remaining fields are skipped. The result is that missing fields are set to empty or zero.
Any fields that are not specified in the format string are set to empty or zero.
If however, you omit a required field such as the cross account for a transaction, the import will encounter an error. A record of the error will be appended to the log file, and a copy of the import record (and the current format string) will be written to the unprocessed file.
The same format is used for both simple (one credit and one debit) and complex transactions (One credit and many debits). To determine whether a given record is connected to the previous transaction, the import looks at the last key, which is a character string comprised of the contents of the ACCT, DATE, REF and DESC fields. If the key is the same, the record is added as a complex item to the current transaction.
The field length limits of NewViews for DOS no longer apply. For example, a description field in NewViews for DOS was limited to 30 characters, but there is no practical limit to its length in NV2.
In NewViews for DOS, transactions are simple (one account is debited, one account is credited) or complex (multiple debits & credits.) Here are two example simple transactions in a sales journal:
@ACCTLEDG(ASCII):ACCT,DATE(-1),REF,DESC,AMT,XACCT
"SOME_ACCOUNT",31121992,"123-XYZ","Daily Sales",-123.45,"SALES-1"
"SOME_ACCOUNT",31121992,"123-XYZ","Bank Deposit",123.45,"BANK"
The transactions credit the SALES-1 account $123.45 and debit the BANK account $123.45. These would be entered as 2 separate lines on the journal (perfectly acceptable.) The same two transactions could be combined into what we call a distribution:
@ACCTLEDG(ASCII):ACCT,DATE(-1),REF,DESC,AMT,XACCT
"SOME_ACCOUNT",31121992,"123-XYZ","Daily Sales",-123.45,"SALES-1"
"SOME_ACCOUNT",31121992,"123-XYZ","Daily Sales",123.45,"BANK"
Here, since the ACCT, DATE, REF, & DESC fields are identical, the transaction is entered as a distribution (again, perfectly acceptable.)
When the ACCT, DATE, REF, & DESC fields (the transaction "key") are identical from one record to the next, the transaction is assumed to be a continuation of the previous record and they are placed in a distribution (which can have an unlimited number of records.) In cases where you want to force the import to break the records into separate transactions even though the key is the same, an additional field can be used in the import file:
@ACCTLEDG(ASCII):ACCT,DATE(-1),REF,DESC,AMT,XACCT,KEY
"SOME_ACCOUNT",31121992,"123-XYZ","Daily Sales",-123.45,"SALES-1",0
"SOME_ACCOUNT",31121992,"123-XYZ","Daily Sales",123.45,"BANK",1
The field "KEY" at the end of the record is evaluated from one transaction to the next as well. If the value of the KEY field changes, then a new transaction is started even if the first four fields are the same as the prior record. The KEY field can have any alphanumeric values you want, only a change in the value from one record to the next is significant.
In the above examples, the transactions are imported into a journal called "Import_Records". You can specify the journal using the field identifier "journal". However the journal you specify must be of type "general" (i.e.) you cannot import into the Bank, Payroll, Purchase or Sales journals.
@ACCTLEDG(ASCII):ACCT,DATE(-1),REF,DESC,AMT,XACCT,KEY,JOURNAL
"SOME_ACCOUNT",31121992,"123-XYZ","Daily Sales",-123.45,"SALES-1",0,"budget"
"SOME_ACCOUNT",31121992,"123-XYZ","Daily Sales",123.45,"BANK",1,"budget"
In the example below, the transaction is imported into a general journal called "SALES". The Accounts Receivable is called "SMITH". The Invoice date is Sep 22, 2009. The Invoice number is 1234-1 The Total Amount of the Invoice is 251.25
@ACCTLEDG(ASCII):JOURNAL,ACCT,DATE(-1),REF,DESC,AMT,XACCT,XDESC,KEY
"SALES","SMITH",22092009,"1234-1","Invoice",6.25,"HANDLING","Handling Charges","0"
"SALES","SMITH",22092009,"1234-1","Invoice",245.00,"REV_OTHER","Tax Exempt Revenues","0"
"SALES","SMITH",22092009,"1234-1","Invoice",39.50,"INVENTORY","Cost Of Goods Sold","0"
"SALES","SMITH",22092009,"1234-1","Invoice",-39.50,"COGS","Cost Of Goods Sold","0"