I have a client request to automate their billing process by interfacing to their QuickBooks accounting system. I seem to recall a (commercial) clarion template/library that allow Clarion application to interact with QuickBooks but I am not sure if that is for the Desktop version only.
Has anyone use NetTalk to access QuickBooks API? I am wondering if there are other solutions.
Any comments or suggestions as to how or what product(s) you use to achieve this is greatly appreciated.
Hi Edward,
You are in luck, we have created a Wrapper template for use with the Chilkat Comms library.
As well as covering all their base classes (100+ including Rest, Http, Json, Xml, OAuth2, Google, Amazon etc etc), we have also created our own “Task” classes who’s jobs are to cover all things for a related API endpoint.
We do have a Task class dedicated to Quickbooks Online and which allows you to perform all the usual everyday tasks like, downloading and updating of Customers, Vendors, Currencies, Tax Rates, G/L Accounts, Sales + Purchase Transactions and Credits, Employees and Journals etc etc. The task class includes groups + queues that match the published structures from QBO / Intuit - so basically if you can use a group / queue, then you can work with QBO 
As well as a dedicated class for Quickbooks, our wrapper also includes the following Task classes:-
MYOB (accounting)
Xero (accounting)
Quickbooks Line (accounting)
Email (including Generic email accounts, Gmail Oauth2 and Office 365 Ouath2)
WooCommerce (ecommerce)
DocuSign (esignatures)
SigniFlow (esignatures)
Google (Calendar and Tasks)
Detrack (logistics)
Paypal (payment processing - in dev)
Stripe (payment processing)
PaySimple (payment processing)
Text Messaging (including 7 endpoints like Twilio, Plivo, ComAPI, BulkSMS, BoomSMS…)
Dropbox (file sharing)
Thirdlight (digital image store)
Weather
Currency
Betfair (betting exchange - in dev)
A demo is available via our web site - https://noyantis.com/product/chilkat/ - the download link is on the Additional Information tab.
Any questions, please feel free to ask
Thanks,
Andy
Sounds like it does everything, Andy. I will check out the demo.
It may be more than I need (if that is even possible).
Thanks.
“It may be more than I need” … lol, you don’t hear that everyday
Don’t worry though, you can now tick which Task Classes are now compiled into your application so only the relevant resources are used, but with lots of scope for the future should your needs change
Thanks,
Andy
Well. I am a men with little needs (if you believe that).
That’s good to know. I am reading up on what is Chilkat Comms.
Thank you again,
Edward
I do it with nettalk. Their API it’s pretty straightforward and it uses Json.
They have a great sandbox.
They have very strict look and feel and behavior requirements. It took us a while to get it right and approved for production.
Hi Kevin,
Thanks for the suggestion. I was thinking about using NT. When I looked into QB’s testing services, I was not too sure of their service agreement.
Do you have any pointers or suggestions/examples you may be able to share?
Regards,
Edward
Here is the URL to all the things your app must conform to. Even if you app is used in-house or select customers.
Hi Kevin,
Thanks for the link. I will start again from there. Hopefully, it will work out better the second time around.
Regards,
Edward
Hi Kevin / Edward,
If Edward’s requirements are to simply interface into their billing systems, then there are no “look and feel” requirements because all the updates will simply be performed via API calls. The only UI part of it are via the OAuth2 login and you call the QBO UI pages for that, which in turn returns you the Access and Refresh tokens, after that, there is no UI, just API pushes and pulls, and as you say via Json content.
There are strict business requirement rules that must be followed (eg, correct Tax Codes used and things add up etc… ), but they can easily be imposed in the calling system to ensure quality of data.
If Edward is wanting to create a full UI of his own, which then talks to QBO then yes, there would be extra things to consider, but I didn’t read that from the initial requirements. On all the systems we work with, the customers already have their own applications and just want to push and pull updates to and from QBO - so the non UI interface is perfect for that.
Just adding my 2p worth
Cheers,
Andy
Yes, Andy,
My needs do not require any QB specific UI. It is pretty much as you said, all background work except authentication.
Regards.
Edward
Yes, we are 100% API but you have to meet their login\logoff screen requirements and also handle all their refresh requirements. and any mention of QB in your app must also follow their rules. Tedious, but not hard.