>Another thing to mention is while some of SBT's code seems archaic to high level programmers (read: most of the people on UT), it has to conform to accounting standards and is therefore very conservative.
>
>Remember, if you or I screw up a mod for a client, he gripes and we do some free work. If SBT screws something up, they screw up a lot of people's accounting systems and possibly have thousands of lawsuits on their hands. It's therefore understandable that they move forward very slowly.
>
>-- John Kiernan

SBT Corp moves as fast as a slug. They base themselves around a sales core of hundreds of CPA's and a few big players in the systems sales arena. Then they allow a lot of little fish to go after the scraps that are floating around.

Talk to their marketing about sponsering a mailout? They do all the work yet you never get mentioned in the mailout. they receive all the calls and then send the big ones to the big resellers. You spend the money yet SBT makes the sales decissions after you spend the marketing $.

Now get over to code and data practices. Why they have not adopped use of a DBC? Hold view data there as a way to use SQL joins in a manner that all other systems (executive series) would and should.

Eliminate the dreaded xxYaaaNN history file! I'm real tired of writing joins just to get open invoice or sales order specifics.

Data normalization somes to mind as one of the biggest areas of improvement they could make. Retaining the SO # in AR as a key, instead of using PO#.


__Stphen