>What did you replace SBT with?????
We went to Visual AccountMate; the code provided was cleaner, but we're not happy with VAM, either - they do not provide the source to their class libraries when you buy source code from their dealer. We also were less than pleased with our dealer's VFP experience and understanding, but given the audience, that wasn't surprising.
>And was the problem your code or SBT?
The problems that lead us away from SBT were integrating the mods made in previous versions of SBT into the newer versions - the SBT code didn't get significantly better between versions, and was downright painful to maintain, showing its dBASE origins early and often. The VAM stuff was easier to integrate with the mods we wanted, and was developed from a VFP/OOP perspective - I just wish that things that
should have been trivial like changing some basic behavior of numeric textboxes via subclassing were easier - I ended up writing some code to hack SCXs to change a textbox subclass.
SBT's lack of native import/export facilities made it harder to integrate external apps than VAM, which had decent imports available for GL Journal Entries and AP Invoices - if we weren't creating and maintaining our customers in our own tables, the AR Import could have been managed with the AR import facility; since we create our customer records outside of VAM and maintain our inventory entirely outside of the basic accounting app, we needed an ability to add customers to VAM before adding their invoices and not have the burden of a specialized inventory that didn't fit VAM's model well.
The customer and inventory item imports were not capabilities built into VAM's basic system, so it took writing a relatively small amount of code to add customer and shipping address detail into VAM's tables, and to create new sales items on a non-onventory basis to match up with specific GL reporting requirements. We didn't deal with VAM's inventory or work in process control, since our in-house stuff does all the inventory and production management and we use Pitney-Bowes' Ascent shipping system, which we've already integrated with our apps to do rate shopping, package tracking and the like (it's an excellent product, written largely in VFP, capable of handling up to moderate package and transaction volumes, with several different mechanisms available for integration including ODBC, custom code and COM model integration), so that the invoices in VAM only need relatively crude summary details - we handle customer processing, invoicing, returns and the logistics in our own app because it fits our customer service basis better than what's available off the shelf.
The other problem was keeping the modified source code up to date with the patch levels for VAM, again, a problem that could have been fixed in many cases if we could have altered some class behaviors. IAC, we've got code to hack updated VCXs now as needed, and inserted subclass layers for some of the basic controls.
Now that the mods are in place and I understand what's going on with VAM, I'm more comfortable with maintaining the code long-term even with patches coming in fairly frequently, because the code we have access to is cleaner and less rooted in dBASE III. AccountMate would have a very satisfied customer if they'd tell you up front that source for the classes wasn't included in the price of source code, or if they provided it on request.
