Write macro in 5.3A, deploy on 5.5 3

[JoeAtWork]

I need to write a macro to import invoices. I have done this a couple of times with the COM API. I only have version 5.3A (SP3) of ACCPAC Advantage Series Enterprise, my client has 5.5.

Can I write a macro, which will include at least a couple of forms, in my version and deploy on theirs?

I have noted on another recent thread (

http://www.tek-tips.com/viewthread.cfm?qid=1475380&page=1)

the following:

Yes, ARCBAL has been added to the composition of ARIBH. You'd better record an invoice macro again to get the details.

What view should I open for ARCBAL, and can I assume that I won't need to update any of it's fields, just that I have to include it in the Compose method of ARIBH?

Will the forms and controls I use in 5.3A work in 5.5? I don't think I need anything more complicated than textboxes, dropdowns, and buttons.

 

[Jay Converse]

If you have Accpac clients, how can you _not_ have a copy of 5.5?

 

[JoeAtWork]

If you have Accpac clients, how can you _not_ have a copy of 5.5?

I am not specialized in AccPac. In general, I do custom software development for businesses in VB6, Access, and .NET (C#). I get a request to do something with AccPac maybe twice a year.

When your clients are mostly small business, you have to become a Jack Of All Trades. I have clients who use QuickBooks and Simply Accounting as well. I do not get enough work for any of these systems to cover the cost of keeping up to date on every new version. And that's just accounting systems, I could also mention software for manufacturing and utility services I have had to learn in order to effectively integrate those programs with my clients' other systems.

Whether or not hiring a specialist (assuming we could find one within a 100 mile radius) would be in the interest of my client is questionable. I may not be an expert in AccPac, but I am an expert in my client's systems as a whole. In the end it is a question of what is more time and cost effective:

1. An AccPac specialist becoming familiar enough with the client's other systems to be able to effectively integrate the AccPac solution with it
2. Myself becoming familiar enough with AccPac's API's to do what should be a relatively straight forward task

And as I alluded to earlier, there are few AccPac specialists in this area, and none that I know of that can do the programming side. It would be difficult for my client to locate somebody else willing to take this on, and almost for sure much more expensive.

So far no one has complained about the work I've done on AccPac systems. In part I owe that to the excellent advice I have received on this forum.

I hope I have sufficiently justified my situation.

 

[Jay Converse]

C'mon, be a professional. You might as well say "my custom program runs fine on Windows XP, is it going to run on Vista? I don't have a copy of Vista to test it on, please help me".

 

[JoeAtWork]

I've spent thousands on the tools I use the most: Visual Studio, all MS operating systems including server OS's, SQL Server, and various programming toolkits.

So what do you do when a client asks you to integrate their system (which you are intimately familiar with) with some software XYZ that you don't use yourself? Is your answer going to be:

"Sorry, you will need to find an XYZ expert, pay him for all the time it will take to become familiar with your current system, then pay him for the custom work he will do for you on XYZ."

My answer is usually something like:

"Sure, I'll do a little research to see if XYZ has API's for third party programming, and if I think it looks feasible I will give you an estimate. I may need to spend some time on site to do the programming, since none of my other clients use XYZ I can't spend the $5000 for my own copy."

Perhaps you should consider it from my perspective. What I tend to do the most is write bridge software that connects all those goliath pieces of software together. My customer may want me to create an ASP.NET application that gathers information from their PMC, inventory and accounting systems. Now, am I going to buy those 3 systems for my testing? The answer is no, because I would have to charge my client more to cover my costs than my actual programming work - and that's not feasible for my client. Nor is hiring 3 experts, one for each system.

For me, AccPac is just one of the many programs I bump into occassionally. Perhaps you are right and I shouldn't be doing anything with AccPac at all. Nor should I have written a program that integrates the BOL system of one of my customers with QuickBooks, or that other one that makes Simply Accounting invoices from the company's POS program. After all, I don't keep up to date on those programs either. Of course, it would have cost my clients a lot more to hire specialists, whose solution may or may not have integrated as well as mine did.

In any case, I wasn't asking anyone to test my solution or hold my hand. My question was very simply whether a macro written in version 5.3A will work in 5.5 (I mean generally - I'm sure there are some specific things that will break it). I've answered similar questions in the Access forums, when somebody wants to know if a VBA code written in Access2000 will work in 2003 (the answer is Yes, except for a few minor tweaks that might have to be made).

 

[Jay Converse]

Ok, the answer is maybe. Nobody knows until you try.

 

[DjangMan]

Have your client contact their reseller and hook you up with a 30-day trial of 5.5.

 

[ettienne]

I would record a macro at the client on 5.5 and use that as the starting point for my macro. You can also grab a copy of the client's software and install a 30 day trial as suggested.

 

[JoeAtWork]

Thanks everyone. The 30 day trial seems like a good option.