Intuit Master Builder

Being a construction company, we use Intuit Master Builder pretty extensively at work. It’s basically an all-in-one accounting/construction management package and while it does the job reasonably well—for the average user—I thought I’d relay some of the problems with it from an IT/computer programming standpoint. (Kind of an anti-review.) Which is sure to be amusing (or frightening) for other people in my position.

First of all, it’s a database-driven application, which is fine, but the underlying database format is Visual FoxPro—and not a new version of FoxPro. I’m not even positive it is FoxPro for that matter: the tables are all in DBF format, and the indexes are CDX files. That’s one problem—I mean, it’s 2005, and we’re still having to deal with DBF files? Even worse: each table name and field name inside the tables is constrained to exactly six characters long. No exceptions. So you either have ridiculously-abbreviated field names (like “invttl” for “Invoice total” or “lstupd” for “Last updated”) or short names that are padded out with underscores (“state_”). Uhm, hello? DOS called, and it wants its lame database back.

Second, the relational qualities of such a database are a joke. Sure, there are key fields that build relationships to other tables (foreign keys), but there’s no consistency between them—primary key field names are duplicated, fields in different tables linking to the same foreign key field are named differently, etc. But—and here’s the dealbreaker—you can only have one “company” per database; in other words, if you have multiple companies (or projects), then each one requires its own database in a separate directory. And there’s no inherent way to combine these separate databases to share data among them (like a master list of vendors or cost codes) or to build consolidated reports of any kind. This is probably the single biggest flaw in Master Builder.

So one of my tasks is to build/maintain consolidated reports and software to manage the data among the databases. This, of course, is a huge pain, but I have a variety of tools that I use to do this (which illustrate how hackish this all really is):

• Crystal Reports. Great application, it’ll hook into just about any data source and build just about any report you can think up, so I’ve built a number of consolidated reports in Crystal. Here’s the problem: I’m stuck using CR version 8 because that was the last version which allowed you to compile the reports into standalone executable files that people can run without needing Crystal Reports installed on their computers. I have to do this because at least half the PCs here are still running Windows 98 and we don’t have a server capable of publishing Crystal’s distributed reports.
• Microsoft Access. This is like, the hacked method of managing the databases. I connect to a Master Builder database via ODBC, and I can directly access (no pun intended) the data. The drawback is because of ODBC, I can’t connect to more than one database at a time—if I want to copy-and-paste data from the Master Company (the source) to any of the others, I have to close Access completely after each database to sever and then renew the ODBC connection.
• PHP. Yep, PHP. I’ve built some web form interfaces to the databases (running on the server intranet in-house), one of which is a utility to copy vendors out of the Master Company and paste the new or updated data into each subsequent database. I’ve also done a bunch of consolidated reports via PHP, accessible through a browser—I find it’s much quicker and easier to write the reports in PHP than in Crystal Reports. The drawback? You have to have a web server and PHP running on the intranet. And, have ODBC connections set up for each database on the server as well. And, you have to know PHP.

What really sucks is when a new company/project is added, and I need to go through the existing consolidated reports and update them to include the new database. In the PHP reports, this is pretty much a cinch. In the Crystal reports, though, the pain level ranges from moderate to severe, depending on which report I’m modifying. All of them make extensive use of formulas, so I always have to weed through and update all of those. The worst report is one that uses subreports to break down data from each company, and global variables and formulas to consolidate all this data into the master report; each subreport has to be formatted exactly the same (which is anal retentive beyond words) and I’ve got this daisy chained house of cards of formulas in various sections of the master report relying on an EvaluateAfter cascade to properly calculate certain values… the anxiety levels creep higher and higher just thinking about that damn thing…

The end result is I’ve got a lot of scripts, reports and techniques for handling Master Builder that are only known to me, and would be very hard to explain to someone else. Some might say this is “job security,” but I was talking with someone about this today and we decided it’s much more of a “lock-in” (and not in a good way).

Now, compared to much of the competition out there, Master Builder is a good program. It does accounting voodoo that is a total mystery to me, and seems to do it well. It’s got a low barrier-to-entry user interface that makes it easy to learn and use for non techie types. It’s an open system to the extent that the database schema is available and there’s an API that allows the development of independent software that ties into it (a lot of third party developers have developed PDA modules for it, for instance).

But good god, I pity the poor fool who has to administer the system…