Resource Section:
The resource section includes examples of data manipulation, i.e. how to handle date formats, dealing with whitespace, setting up a new coding structure, a detailed example of migrating data to a new finance system etc.
Resources
Converting Data
The format of data exported from your legacy system might not be in the required format to import into your new system. Although there are many conversion tools we will look at a few examples of data which we're going to manipulate in excel. Even if you use another tool to clean data an understanding of the types of problems you may encounter will help you debug should a file fail to import correctly.
| A | B | C | D | E | F | |
|---|---|---|---|---|---|---|
| 1 | 1012007 | 01012007 | 01 | 01 | 2007 | 01/01/2007 |
| 2 | ||||||
| 3 |
Migrating Your Financial Data
In this article we do a step by step financial migration, working through the double entry, to ensure our trial balance is converted correctly and our control accounts function from day one. Our particular objective is to have.
- A clean cut off
- A clear audit trail from one system to the next
- No loss of control over balance sheet control accounts
- No impediments to collecting debt, i.e. transactions on statements are still understood by customers
In particular we look at the bank account, and how to post it into the new system so you can continue with a clean bank reconciliation rather than a fudge.
Country Codes
Many import routines rely on the two or three character country code rather than the country name. The table below gives the two and three character country codes, as well as the EU member two character VAT prefix. You can download the file to excel by clicking the link below. Once downloaded, it's a simple exercise to associate a VAT code with a country (GB = VAT, EU = 0%, Rest of World = out of scope).
Familiarity With Your Chart of Accounts or Product
Your new chart of accounts or your product tree may differ from your old one. Your new COA code might use, for example, a segmental approach such as the code below. In any case, it takes time for users to become familiar with things new, so what can you do to improve familiarity, and hence accuracy, during the early days of post go live?
| Business area | Location | Expense Code | Dept |
| X | XX | 0000 | XX |
You might not wish to clutter up your new database with old code references and search routines which will have an early shelf life. There are other ways to develop familiarity. Your intranet, for example, can provide you with an invaluable backup to your training plan. Tools, written in simple javascript, can be used to provide old code new code lookups; or, as in the example below, modified from a live site, a logical lookup to quickly find a new code.
....read more (page opens in a new window and contains javascript)
Testing
When you turn on your new system you won't want to see bugs helter skelter into the corners. You need to test your system in a structured and cogent fashion. There are four ways in which your system might not act as you'd expect.
- Genuine software bug
- Incorrect settings
- Incompatible hardware
- The bug is a feature
You need careful management over the synchronisation of your test and live environments, as well as strong visibility on your testing so bugs, like these, don't undermine your investment.
Inspired Notes
Resources