Organizing your Sage Fixed Asset database(s)
By Sam Cimmarusti, Certified Trainer
After initially setting up the SFA—Depreciation software, a common question from students is how to setup the database(s) for efficiency and the separation of data. My general suggestion for setup is as follows: create separate databases as individual work areas to store the various companies that hold asset information based on the use of those companies. I like to setup a minimum of 3 separate databases based on what part of the process I am working on. If you would like to learn how to setup these databases, join us at a SFA— Basic Depreciation class – either online, in the classroom or an onsite.
The first database to create is the Production database – this is the area where you will create one or more ”LIVE” companies to hold the actual real company asset information. The companies that are created in this database are holding the actual asset data you would use to do things like “post” to your General Ledger and file your Federal 4562 Depreciation and Amortization schedule (attend our SFA Intermediate Depreciation class to find out more about this). I like to use a very specific naming convention such as names like PROD, PRODUCTION or LIVE. If you need multiple databases, use names like PROD1, PROD2, PROD3 or even PRODA, PRODB or PRODC. The asset data in these companies inside these aptly named databases is to be protected as much as possible. I would only manipulate this asset data after practicing on “test” data several times and have a very good understanding of what will happen when the actual asset data is worked on. Keeping this asset data as secure as possible will probably save you numerous calls to our customer support (1-800-331-8514), but they are always available to help you with any issues.
The second database I would create is the TEST database - your practice database. After making a copy of your LIVE company here, you can practice the features you want to use on a “copy” of your live asset data. You can practice the feature to familiarize yourself with it and you can also see what will happen to a copy of the production asset data without actually changing real data. This allows you to see the changes without putting your production asset data in jeopardy ( also saving you calls to customer support if a negative change occurs). Once you are comfortable with the feature - after practicing it several times and checking that the results are acceptable, you can then go to the production company and repeat that procedure there.
The last database I would create would be a RESTORE database. Hopefully, you have been creating backup copies of your data over time (learn how to do this in our SFA Intermediate Depreciation class). Backups should be done on a regular basis such as at the end of each period and before and after a significant change to your asset data and software updates. These backup copies can be RESTORED into this particular database and the asset data can then be viewed and reports run on this asset information as well. I don’ t recommend restoring backup copies of companies into the production database. The possibility exists that you could overwrite current asset data with asset data from a past time frame – not something you would want to cause or have happen even accidentally.
By setting up the databases in this way, you keep everything separated and avoid making accidental changes to your “live” companies and their asset data. A copy of the “live” company with the asset data is used to practice in TEST, but the feature being tried is not actually repeated in PROD unless a good result occurs. Restoring a company in the RESTORE database eliminates any accidental changing of the production asset data for that company. This allows you to spend less time on the phone with customer support and more time doing the myriad tasks that you need to accomplish besides working on your fixed assets.