Topic: Best Practice: How to choose between traditional, API and Integrator

I've built a test server.php file based on docs/example_server.php and got this to sync customer records to and from our application. Now before I launch fully into the integration project can I get some guidance on the best approach? i.e. should I extend the example_server.php further, do something based on example_api_*.php or do something based on the Integrator approach (example_foxycart_server.php)?

We need to be able to integrate with all current versions of QuickBooks especially international versions as well as the on line editions. The exception would be QBPos.

The information we need to syncronise (both ways) is:

Customer
Jobs
SalesOrder
Invoice
Estimate
ItemPayment
SalesReceipt
ReceivePayment
ItemInventory
ItemService
ItemNonInventory
Employee
TimeTracking
and any required supporting lists

The priority to get these all working is:

1. Lists from QuickBooks to our application
2. Lists from our application to QuickBooks
3. Transactions from our application to QuickBooks
4. Transactions from QuickBooks to our application.

This topic was originally posted on the IDN forum 7th April 2010

Last edited by jtn (2010-04-07 16:30:36)

Re: Best Practice: How to choose between traditional, API and Integrator

Question: Is your application a SaaS app? What's your timeline?

Re: Best Practice: How to choose between traditional, API and Integrator

100% SaaS. Timeline is now. Happy to contribute back generic code if it helps. Just looking for some guidance on the best approach.

Also, in a recent post by Adam140 your answer mentioned IPP in relation to SaaS. Hadn't noticed that before so I've had a bit of a look. Not real keen on changing platforms right now but can consider it after gaining a better understanding of the benefits Azure brings.

Last edited by jtn (2010-04-07 22:28:01)

Re: Best Practice: How to choose between traditional, API and Integrator

IPP doesn't require you to change platforms (Federated apps can be built in your language of choice and run on your own server), and doesn't require that you use Azure (yuck!). You should consider it. However, you'll have to look at the IPP timeline and make sure the operations you need are supported, as not all QuickBooks data is supported quite yet. IPP would probably be your best bet, as it makes communication with QuickBooks very easy and is the "official" Intuit-supported way of doing two-way sync with QuickBooks data. The entire point of the IPP is: SaaS apps that need two-way sync of data.

Note that right now, IPP does not support Online Edition or any international editions of QuickBooks (Online Edition is on Intuit's roadmap to be supported very soon, there isn't a date on the roadmap for international editions yet). It also only works for QuickBooks 2009 and newer.


Outside of IPP: If you need a 2-way sync, then the Integrator and API stuff is not an option for you, they don't support it. You should instead look at either extending example_server.php or the SQL Mirror functionality.

Extending example_server.php gives you the most control over what requests your sending and how you handle the responses. There would be a pretty hefty amount of code for you to write to get that working for all of that data. Due to the non-real-time nature of the Web Connector, two-way sync with QuickBooks can be a bit of a pain due to conflicts and time skew and a slew of other issues. It can be somewhat easily mapped over to support Online Edition as well.

The SQL Mirror stuff essentially maps QuickBooks fields to SQL fields and attempts to keep everything in sync for you. There are some components of it that are incomplete or untested, and it's still under development. So, you'd have to make sure you test it very carefully to make sure it works for you. The SQL mirror stuff does not and will not work with Online Edition.

In either of those cases: The international versions of QuickBooks are the red-headed stepchild of the Intuit world. You will likely not have good success supporting them beyond the UK and Canadian editions.



Honestly, your requirements of "timeline-is-now, all versions of QuickBooks, international editions, and Online Edition" is more than likely unrealistic. Some international editions don't support integration at all, older versions of QuickBooks are more work than they're worth developing for, and Online Edition is a significantly different beast than the desktop editions of QuickBooks (though with IPP integration should be a considerably closer process). You should analyze your actual requirements carefully. How large of a shop are you? What you're talking about is a substantially large project.

Re: Best Practice: How to choose between traditional, API and Integrator

Thanks.

I wasn't very clear.
Time line now - meaning we are working on this now. We would like to get some basic transfers happening reliably inside a month.
Support all current versions - actually by current I meant latest only.
Our immediate requirement is to support the version provided for Australian desktop users. Everything else can come in time. My understanding is that the Australian version is the same as the US version even though it is distributed by another company (Reckon) and named differently in Australia. So that would mean it would be ok - yes?

Definitely need flexibility so the example_server.php approach sounds best but the "slew of other issues" concerns me.

Also regarding 2 way sync. The main need for syncing from QuickBooks is the initial set up of data.  After that it would be ok to impose an operational rule that data is only sent to QuickBooks. Developing an ongoing, anytime 2way sync is a nice-to-have, but not essential.

Does any of this clarification change your response?

With respect to IPP are there any good getting started guides using the approach you indicated was possible? i.e. no Azure, hosting federated apps etc...  Im looking at https://ipp.developer.intuit.com/ at the moment

Last edited by jtn (2010-04-08 07:02:53)

Re: Best Practice: How to choose between traditional, API and Integrator

Our immediate requirement is to support the version provided for Australian desktop users. Everything else can come in time. My understanding is that the Australian version is the same as the US version even though it is distributed by another company (Reckon) and named differently in Australia. So that would mean it would be ok - yes?

Last I saw, the Australian edition *did* have some differences, and was usually a version or two behind the US versions. My understanding (from speaking with the Intuit developers) is that generally what the AU/UK/CA developers do is take the last version of QuickBooks, and then spend a year customizing it for their particular country, and then release it, which puts their copy of the code a year behind the US version. My understanding is that this has been changing lately to eleviate some of the development burden on the AU/UK/CA developers at Intuit/Reckon. I do not know what the current status of AU edition of QuickBooks is (did you ask Reckon?) but the last time I tried to get it to work with the Web Connector, it did not work.

Definitely need flexibility so the example_server.php approach sounds best but the "slew of other issues" concerns me.

Also regarding 2 way sync. The main need for syncing from QuickBooks is the initial set up of data.  After that it would be ok to impose an operational rule that data is only sent to QuickBooks. Developing an ongoing, anytime 2way sync is a nice-to-have, but not essential.

Most of the slew of other issues deal with conflict resolution and making sure you build your requests carefully and handling errors. You will save yourself gobs of time if you don't always need a full 2-way sync for all of that data.

With respect to IPP are there any good getting started guides using the approach you indicated was possible? i.e. no Azure, hosting federated apps etc...  Im looking at https://ipp.developer.intuit.com/ at the moment

The best "guide" would be to go an IPP CloudJam event with Intuit (there was one outside of Boston today, yesterday, and the day before). Outside of that, there's lots of documentation but it's all a bit convoluted right now and under development. You should definitely check out the open-source code on code.intuit.com, as that's a really good starting point. Look through the unit tests and examples for your language of choice.

My PHP code on code.intuit.com: https://code.intuit.com/sf/sfmain/do/vi … php_devkit
Other languages: https://code.intuit.com/sf/sfmain/do/vi … p_dev_kits