Rolling over Quickbooks to New Year

I started using Quickbooks in 2001. Prior to that I had been using my own system, written in Perl with an HTML front end. I don't remember now what convinced me to switch away from that, but honestly I wish now that I had just stayed with it.

I originally used the Windows version of Quickbooks, but switched to Mac a few years ago. That was a mistake in some respects: the Mac version lacks many, many features that are found in the Windows product. However, I was tired of maintaining a Windows environment simply for one program, so I switched and have simply suffered the missing features. It's not all that horrible - if you didn't know the Windows version had the features, you wouldn't even notice most of them. It's mostly that I was accustomed to certain shortcuts and so on that disappeared when I switched.

The BIG problem I have had with Quickbooks has been data corruption. This existed before switching and after switching, so I can't blame the Mac version for that. Nor am I alone in this problem: there are several companies that offer Quickbboks data repair services.

I suspect most of this comes from Quickbooks never having a "close out year" or "rollover year" function. There is no year end procedure in Quickbooks, no rollover, no closing of a year. You just keep on trucking, and your data file grows and grows..

Well, somewhere between 2001 and when I first realized I had problems, they did add two somewhat related functions. One is "Verify Data" and the other is "Condense Data". Unfortunately, by the time I noticed these, my data file was alread out of whack and those just crashed and burned.

The corruption manifests in little details: a customer who shows up in A/R reports with a balance, but there are no unpaid invoices and no balance to apply an adjustment credit to. I have similar oddities in sales tax calculations. It's all just a mess.

I could contract with one of those Quickbooks data repair firms, but I decided instead just to start over: start a new company file for 2011 and go forward from there, verifying and condensing appropriately in years to come.

On the face of it, this seemed like a reasonable thing to do. Quickbooks has an export function that will kick out some data to files that can even be loaded into a spreadsheet. I exported customer lists, vendor lists, my chart of accounts and my sales item lists that way and imported them into a new company. We then went in and added in all outstanding invoices and accounts payable, plus a starting bank balance. That part was easy enough, especially so because December has been slow and there were less than a dozen outstanding invoices to re-enter.

Quickbooks for Windows could have transferred my custom invoice formats, but for the Mac version, we had to design them all from scratch. That was probably the most annoying and time consuming part of the work.

If I had just a little bit more energy and time to spare, I would take this "starting fresh" opportunity and go back to my own custom written bookkeeping. I may do that yet: I'm really not happy with Quickbooks and could get exactly what I want by writing it myself.



Got something to add? Send me email.





(OLDER) <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> Starting over with Quickbooks for Mac


6 comments



Increase ad revenue 50-250% with Ezoic


More Articles by

Find me on Google+

© Anthony Lawrence







Wed Jan 5 16:19:48 2011: 9204   BigDumbDinosaur

gravatar


I never got lured in by the promise of easy bookkeeping with Quickbooks. Indeed, the one thing that stopped me from even considering QB for my business was (still is) the monolithic data file. Instead, I wrote my own accounting using the Thoroughbred Dictionary-IV environment, which in this case is run on UNIX.

Unlike QB, my concoction uses separate files for customer data, invoice headers, invoice details, etc. Although some may cringe at the thought of file proliferation, the reality is it is much easier to fix something if needed. However, in some 13 years of using this package (with some updates), I have never experienced data corruption of any kind.

Part of the reason for this reliability is that I'm not running it on Windows. However, the avoidance of a monolithic data structure is the big part. Lamentably, the use of monolithic data file structures is common in Windows, QB being but one example of what is generally considered to be a fundamentally flawed programming model.

Anyone who has ever done transactional database software development knows that confining each data type to its own file structure is much easier to manage than trying to stuff unrelated data types into a single file. Different data types (e.g., customer masters or A/P details) will have different record sizes, different key structures, etc. Trying to fit all that in a single file (e.g., ISAM in the UNIX/Linux environment) becomes an exercise in putting square, triangular and trapezoidal pegs in round holes (along with a few round pegs). The file's record structure has to be tailored to the longest record type. Ditto for the key structure. That means shorter records have to be padded, short keys have to padded and appended with record type flags so the software can tell a customer master key from an invoice line item key, etc. It gets to be a major mess, and accomplishes nothing other than reduce the number of files in the database.

However, I'd rather have a few more files than risk losing the whole nine yards because a booger in a monolithic file has broken my key structure and rendered records inaccessible or corrupted.



Wed Jan 5 16:37:40 2011: 9206   TonyLawrence

gravatar


Yes, I maintained separate text data files also. It's the only way to go.



Thu Jan 6 00:30:00 2011: 9207   NickBarron

gravatar


Ah flat text files. Joyous they are!



Thu Jan 6 02:32:31 2011: 9208   zdw

gravatar


You might want to check out Ledger:


It's a full double-entry accounting system that uses text files for input, and has a decent sized community surround it.

I switched to using it from a bunch of spreadsheets, and it's been great.



Thu Jan 6 07:49:28 2011: 9210   anonymous

gravatar


Knock on composite lumber, but I haven't had the data problems you mentioned. I have a project I've been dragging my feet on to move QB'99 to Windows on a VM, but before I do that, I've been reviewing options like GNUCash



Thu Jan 6 11:29:56 2011: 9211   TonyLawrence

gravatar


I've looked at Ledger and GnuCash before. If I do decide to move, I would much rather write my own. I want the power of getting exactly what I need; otherwise there is no point - it would just be another "ok" system.

------------------------
Kerio Samepage


Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us





If we define Futurism as an exploration beyond accepted limits, then the nature of limiting systems becomes the first object of exploration. (Frank Herbert)

If you understand something, it is probably already obsolete (James Burke)







This post tagged: