Mostly I spend my time taking businesses off Sage and onto VT... Not because its cheaper, in my view its better.
I just enter the trial balance associated with the last set of accounts and then enter everything that has happened since in the new package.
I did start putting together a package to simplify the process by automating the strip and load but hit an issue with Sage not liking VT being on the same machine (even when Sage isn't running).
I'm guessing that from the rave reviews and evangelical following VT has over on Aweb that there's really no love lost between those two!
In answer to your question though to the best of my knowledge there is no industry standard for making it easy to move off a software providers product onto someone elses. But, trial balances are global and will contain all the information that you need to set up your opening balances with your chosen software.
kind regards,
Shaun.
__________________
Shaun
Responses are not meant as a substitute for professional advice. Answers are intended as outline only the advice of a qualified professional with access to all relevant information should be sought before acting on any response given.
1] Is there a standard file format and structure that all software unloads to?
No. This is because each software handles the data differently, and has different associations within the data.
2] If not is there a format that most of the industry conform to?
3] If there is an industry standard which (if any) software providers are compatible/incompatible with this standard?
Internally, the heart of an accounting package is a database - each transaction, each supplier, each customer (etc) is just a record in that database (or set of databases). A common import/export format for databases is CSV, whereby (at its simplest) each line in the file is a database record, and each field within each record is delimited with a comma.
Most accounts packages, therefore, should be able to import (and export) CSV files.
The difficulty is ensuring what you export from one can be imported into another in a meaningful way - which ultimately means the difficulty is making sure you understand the nature of the data exported from one, and the requirements of the package into which you are going to import.
For example, since you mention Sage, when importing transactions into that you need to understand the different transaction types, and be aware that certain transaction types can't be directly imported - this is a minor hurdle even when exporting data from Sage to be imported directly back into it.
The bottom line is that it can be done, but can require some manipulation of the CSV files to cope with the requirements and foibles of the different packages.
The usual approach is not to transfer the data at all, but to leave historical data in the original package* and to start afresh in the new package from a fixed point, with the only historical data to be entered being the opening balances at that point.
* Is this where I start to rant about Sage's new policy?
__________________
Vince M Hudd - Soft Rock Software
(I only came here looking for fellow apiarists...)
thats pretty much what I was trying to look at automating with Sage and VT when the compatibility issue shot that idea in the foot.
VT has a very handy little batch load function so my idea was to extract a CSV file, write a quick macro to format the load datasets and then process a batch load which would include all of the historic data rather than just the period end trial balance.
As I say though, that one got shot down in flames and although with two PCs I could get around it I just don't have the time now to do that :(
__________________
Shaun
Responses are not meant as a substitute for professional advice. Answers are intended as outline only the advice of a qualified professional with access to all relevant information should be sought before acting on any response given.
thats pretty much what I was trying to look at automating with Sage and VT when the compatibility issue shot that idea in the foot.
Similarly - although not specifically for this purpose, I've written things in the past for clients for turning other data into suitable CSV files for importing, and they may have been adaptable either for specific cases or, with a little effort, may have been adaptable into something reasonably generic.
I should consider adding just such a generic program to my ever growing list of programs I really should write!
It'd work by having a simple script that is applied to each row as its processed. The script might have simple instructions, perhaps to insert a new field at any given point on the row, or ensure a particular field is a specific format, and conditional ones, which might change the value of one field based on the contents of another, delete the entire record under certain circumstances, convert it to two records in others - and so on.
As a simple example, I mentioned above that Sage can't import certain transactions that exports of its data will produce. These are PP and SR (IIRC) - so the instructions fed to my should-write program would say "if Field 1 = 'PP' then Field 1 = 'PA'" and "if Field 1 = 'SR' then Field 1 = 'SA'" - or something along those lines.
But anyway, yes... I know where you're coming from when it comes to writing something to help automate such a process. :)
As I say though, that one got shot down in flames and although with two PCs I could get around it I just don't have the time now to do that :(
I have (as you might have realised from the thread about considering VT) both Sage and VT CashBook/VT Transaction+ happily coexisting on the same machine. Given that I know you use the bigger VT Accounts, and VT Accounts has Excel as a requirement, I'd guess the issue is probably with ODBC. (I assume VT Accounts talks to Excel via ODBC - which I know Sage does - so I expect there's a driver or library clash.
__________________
Vince M Hudd - Soft Rock Software
(I only came here looking for fellow apiarists...)
