The article explains the unique problems involved with importing transaction records into the Transaction Database of a instance of BACKTRACK and the side affect of accidentally altering other data in the database. In the Solution section, the article goes on to suggest approaches to the doing an import that should help the user get the desired outcome.
When trying to import transactions to replace or overwrite past transactions, the user will likely find:
- Item quantities have randomly changed
- Status (In Out) may change
- Location (including Parent/Child relationships) may be altered
- Reports based on transactions may start to show erroneous data
The import process in BACKTRACK for Transaction records is different from other imports.
For other imports, BACKTRACK simply adds the new records (or updates existing ones with the same key field value) and makes any necessary linkages (e.g. importing a new item will trigger BACKTRACK to update the Relation table with the correct location and quantity).
However, when importing Transactions, BACKTRACK will execute the transaction and, even if it is duplicate, add it again to the Transaction Table. This is VERY IMPORTANT to understand when doing imports. Reports based on Transactions will see the re-imported transactions twice and related fields (e.g. Relation table) will get updated with more inventory (in the case of an imported Restock) or less inventory (in the case of a Take Out). Re-importing an “Add” for example, can trigger an error message when BACKTRACK tried to ‘add’ the item for a second time (and find the same item # key field already exists in the database).
If lost Transaction records need to be imported/replaced in the database, DO NOT USE THE BACKTRACK Import feature. It is better to use a database editor (such as SQL Management Studio) to change/update the field directly.