>>>Has anyone used AccountMate (VFP5.0b) and or written addon components, heard any news about the softare ???
>>
>>I've finished switching our in-house accounting from SBT to VMP; while I like much of what they've done, I was sorely disappointed to find that even when you buy the source code, you are not provided the source to their class libraries. This can make integrating other applications tough, although there are good data import facilities in the existing code for many standard sorts of things (import invoices, vendor invoices, journal entries, etc.) although other things I would've liked to see with built-in imports were not present.
>>
>
>**********
>
>I'm switching a client over from a custom App I wrote to either SBT or VAM, my decision is how "easy" it will be to add a POS module to their system data. (I also understand that VAM Lan will not be ported to VFP 6.0, 5.0b is their last VFP version updgrade! Their SQL version is in 6.0 now.) From what youv'e seen of their code, is it possible to link my POS directly to A/R invoice files or will I have to use their ascii data import module. I was hoping to breakdown their Order Entry code to move the data seamlessly. But .... if all the code is not there, this could pose a problem. I want to keep the export steps from the POS down to a minimum. My POS will be a standalone front-counter package written in VFP6.0, so I will have no reason to intergrate it directly into their software.
>

I've not considered it from that standpoint; there are a number of companies selling POS systems that integrate with both VAM and SBT. As i asaid, adding thisngs to their menu system is fairly straightforward, and if you're going to call your own code from there, there shouldn't be a problem. the public interface to their class library is documented, and it is possible to write your own document import - I had to be able to add invoices and credit memos directly from our OE system, for example, because there is no direct import of a customer record supported by the native import facility; the logic to update the invoice table, add detail lines, etc. is supported by published interfaces to their business objects, so as long as you are happy with the business rules implemented by VAM, there's a published interface to get at them. i'd estimate that the import facility that I did for our OE processing ran a few hundred lines of code, and took 3-4 days to write and debug, not counting the time spent finding what i needed in their technical manuals, which were considerably sparser than the technical guides that I'd used with SBT.

It is cleaner, more modern code than SBT - much of SBT has bubbled up from dBASE III days, and examining SBT's code in detail shows its parentage.

As far as VAM moving to another platform, rumors about SBT switching to a different platform in a future release (VB, Powerbuilder and Oracle Business Objects have all been mentioned at one time or another) have been around for years. If VAM moves to a COM component based product, I'm not married to VFP as their implementation platform, as long as I can access their mid-tier logic cleanly from the VFP (or other language platform) that I want to use. The fact that VAM is clearly moving towards an n-tier model makes a change of platform workable as long as they use a COM model. They already have support for moving the data engine to one of several backends, so it's not a big issue.

The business model for VAM probably fits a small business with a straightforward pricing structure better than it does a publishing company where we have a very complex, rule-based discounting and pricing system. While the SO/Invoicing would not do what we need to do, it would integrate well with most small businesses with a primarily cash basis and straightforward pricing.

You'll probably encounter some of the same integration issues we did - unless you do tight integration, you probably won't be able to exploit their credit card processing directly, for example. For us, it was easier to integrate our OE to our bank's credit card processing application completely outside of VAM, and the cost of credit card processing through our bank was lower than the clearhouses supported by VAM in our case.

We're pretty happy with their basic AP model, and we import vendor invoices and debit memos from several of our systems into VAM using their native import. We also integrate using the text file import to post Journal Entries generated during our eond of month processing, and have been able to rework some of our budgeting done in Excel to pull a simplified Excel spreadsheet into the VAM budgeting facility.

>I'll say this for sure, VAM, from an OOP standpoint is head over heals versus SBT. SBT still has that FPW2.6 look and feel, using browses instead of grids etc.
>
>PS: I am considering being a 'vendor/reseller' for VAM or SBT. My decision is still up in the air. I will question the fact that there is no source in their class lib's.

I have a very low opinion of VAM resellers at the moment, or at least of the one we dealt with, so I wouldn't be the person to ask about this. I'm not satisfied with either the accounting background, and especially not the programming and design skills, associated with being a VAM dealer. In the former case, I relied on our accountants from Cohen and Berger and our financial people for the evaluation; there were areas where I felt I had a better grasp of some basic accounting rules than the vendor, who had a CPA on staff. My formalaccount background was one course as an undergrad 18 years ago, but I've been working with accounting systems for the better part of ten years now.

As far as programming skills, our situation at Weatherhill is not typical of what a vendor can expect at most end-user sites. I'm pretty knowledgable about VFP as a development environment, and the level of expertise that the vendor's staff exhibited didn't impress me at all; being somewhat less skillful than what I'd expect of a VFP programmer with a year or two of VFP under his belt. They did have some top-notch talent available to them on a contract basis, but they didn't make adequate use of their hired guns.

It quickly became apparent when we had data problems that I was probably going to be able to do things myself faster and better than the vendor's staffers, even though they'd been working with the VAM prodcut a lot longer than I had. My guess is that I made their lives fairly miserable at times.

From that perspective, I've been far more impressed with the SBT shops I've worked with in the past - you can't customize SBT without resorting to some ancient techniques, and I'd judge that the SBT shops I dealt with were better trained on both their product and the programming environment than this one VAM dealer.