New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is there any plans to add Tax API supports? #257

Closed
raecoo opened this Issue Jul 22, 2015 · 20 comments

Comments

Projects
None yet
4 participants
@raecoo
Contributor

raecoo commented Jul 22, 2015

Currently, only the Tax Code query api available. Actually, we also need other Tax APIs. e.g. create and update.

@minimul

This comment has been minimized.

Show comment
Hide comment
@minimul

minimul Jul 22, 2015

Collaborator

Everything is done on a volunteer and "as needed" (usually) basis. Since you need these abilities it would be great if you could add them back into the gem. By looking at the specs in combination with https://developer.intuit.com/docs/api/accounting it is easy to get started implementing these features.

Collaborator

minimul commented Jul 22, 2015

Everything is done on a volunteer and "as needed" (usually) basis. Since you need these abilities it would be great if you could add them back into the gem. By looking at the specs in combination with https://developer.intuit.com/docs/api/accounting it is easy to get started implementing these features.

@minimul minimul closed this Jul 24, 2015

@raecoo

This comment has been minimized.

Show comment
Hide comment
@raecoo

raecoo Jul 27, 2015

Contributor

@minimul I tried to implement the TaxService API, but encountered the exception "System Failure Error: Cannot consume content type", Can you help to take a look?

this is my fork version https://github.com/raecoo/quickbooks-ruby
here is exception info https://gist.github.com/raecoo/b237c267127837867686
the request params and format is correct as official API docs mentioned.

thanks.

Contributor

raecoo commented Jul 27, 2015

@minimul I tried to implement the TaxService API, but encountered the exception "System Failure Error: Cannot consume content type", Can you help to take a look?

this is my fork version https://github.com/raecoo/quickbooks-ruby
here is exception info https://gist.github.com/raecoo/b237c267127837867686
the request params and format is correct as official API docs mentioned.

thanks.

@minimul

This comment has been minimized.

Show comment
Hide comment
@minimul

minimul Jul 27, 2015

Collaborator

Where is service/tax_service.rb?

Collaborator

minimul commented Jul 27, 2015

Where is service/tax_service.rb?

@raecoo

This comment has been minimized.

Show comment
Hide comment
@raecoo

raecoo Jul 28, 2015

Contributor

@minimul Sorry, forgot committed. please pull it again.

Contributor

raecoo commented Jul 28, 2015

@minimul Sorry, forgot committed. please pull it again.

@tchang1

This comment has been minimized.

Show comment
Hide comment
@raecoo

This comment has been minimized.

Show comment
Hide comment
@raecoo

raecoo Jul 29, 2015

Contributor

@tchang1 Yes, I have already implemented the feature in my fork version, will push it later.

Contributor

raecoo commented Jul 29, 2015

@tchang1 Yes, I have already implemented the feature in my fork version, will push it later.

@minimul minimul reopened this Jul 29, 2015

@raecoo

This comment has been minimized.

Show comment
Hide comment
@raecoo

raecoo Jul 29, 2015

Contributor

@minimul I've pushed a beta version to my fork that implemented the TaxService API via JSON way.

Contributor

raecoo commented Jul 29, 2015

@minimul I've pushed a beta version to my fork that implemented the TaxService API via JSON way.

@minimul

This comment has been minimized.

Show comment
Hide comment
@minimul

minimul Jul 29, 2015

Collaborator

I know I was just looking at it. Good find and work but at the same time Intuit should be consistent and provide the same support for both data formats.

For better or worse this gem is wedded to XML requests and responses so I would like to see them flip the switch on XML for this entity.

I just put in a question https://intuitdeveloper.lc.intuit.com/questions/1195446-taxservice-is-json-only . We need to evaluate their response before we can consider a merge.

Collaborator

minimul commented Jul 29, 2015

I know I was just looking at it. Good find and work but at the same time Intuit should be consistent and provide the same support for both data formats.

For better or worse this gem is wedded to XML requests and responses so I would like to see them flip the switch on XML for this entity.

I just put in a question https://intuitdeveloper.lc.intuit.com/questions/1195446-taxservice-is-json-only . We need to evaluate their response before we can consider a merge.

@raecoo

This comment has been minimized.

Show comment
Hide comment
@raecoo

raecoo Jul 29, 2015

Contributor

Yup, I agree with you about the gem is wedded to XML requests and responses. so let's waiting their feedback then consider next thing.

Contributor

raecoo commented Jul 29, 2015

Yup, I agree with you about the gem is wedded to XML requests and responses. so let's waiting their feedback then consider next thing.

@minimul

This comment has been minimized.

Show comment
Hide comment
@minimul

minimul Jul 31, 2015

Collaborator

Update: There was some more comments on this thread: https://intuitdeveloper.lc.intuit.com/questions/1195446-taxservice-is-json-only

Collaborator

minimul commented Jul 31, 2015

Update: There was some more comments on this thread: https://intuitdeveloper.lc.intuit.com/questions/1195446-taxservice-is-json-only

@tchang1

This comment has been minimized.

Show comment
Hide comment
@tchang1

tchang1 Jul 31, 2015

By the way, I'm from Intuit (you may have seen me answer q's on the intuit live community) but I lurk here to see if theres any issues I can help with. The short answer is we would prefer clients to use JSON and will not be enhancing existing services for xml support.

Here's the reasoning. Supporting xml and maintaining our (legacy) xsd schema has slowed us down and created problems when we do enhancements, fixes and improvements. In general, we are encouraging JSON for development moving forward which will help us deliver higher quality and more capabilities into our API. The next major version of the QBO API will for sure be JSON only. I agree though that this Tax Service should have been built with XML support to be compatible with existing V3 clients but starting to use JSON here will help us immensely.

tchang1 commented Jul 31, 2015

By the way, I'm from Intuit (you may have seen me answer q's on the intuit live community) but I lurk here to see if theres any issues I can help with. The short answer is we would prefer clients to use JSON and will not be enhancing existing services for xml support.

Here's the reasoning. Supporting xml and maintaining our (legacy) xsd schema has slowed us down and created problems when we do enhancements, fixes and improvements. In general, we are encouraging JSON for development moving forward which will help us deliver higher quality and more capabilities into our API. The next major version of the QBO API will for sure be JSON only. I agree though that this Tax Service should have been built with XML support to be compatible with existing V3 clients but starting to use JSON here will help us immensely.

@ruckus

This comment has been minimized.

Show comment
Hide comment
@ruckus

ruckus Aug 1, 2015

Owner

In general, we are encouraging JSON for development moving forward which will help us deliver higher quality and more capabilities into our API. The next major version of the QBO API will for sure be JSON only

This might be the final nail in the coffin to do a top-down re-write and migrate to JSON

Owner

ruckus commented Aug 1, 2015

In general, we are encouraging JSON for development moving forward which will help us deliver higher quality and more capabilities into our API. The next major version of the QBO API will for sure be JSON only

This might be the final nail in the coffin to do a top-down re-write and migrate to JSON

@tchang1

This comment has been minimized.

Show comment
Hide comment
@tchang1

tchang1 Aug 1, 2015

@ruckus I don't know if it would be needed to rewrite the current ruby library for JSON, right now, but eventually - yes I would recommend it. For the most part, existing V3 accounting endpoints/services aren't going to change. New things that would be JSON only would be for example, a set of payroll use case APIs, or eventually V4 accounting APIs - our own UI & clients would be consuming these in JSON.

tchang1 commented Aug 1, 2015

@ruckus I don't know if it would be needed to rewrite the current ruby library for JSON, right now, but eventually - yes I would recommend it. For the most part, existing V3 accounting endpoints/services aren't going to change. New things that would be JSON only would be for example, a set of payroll use case APIs, or eventually V4 accounting APIs - our own UI & clients would be consuming these in JSON.

@minimul

This comment has been minimized.

Show comment
Hide comment
@minimul

minimul Aug 3, 2015

Collaborator

Let's try to work in JSON only entity support without considering a large
rewrite. Like @tchang1 said the V3 API is going to be with us a long, long
time and it almost completely supports XML. In fact, I believe in the case of
a few entities it was the opposite, devs were complaining about JSON support
not being up to par with XML.

Anyway, let's cross the v4 bridge when we come to it in which time it may be
best to just to roll a new gem (like was done in the case of v2 & v3)

Looking at @raecoo's fork I think we can at least abstract out the TaxService
service code into say a ServiceCrudJSON. Same with some of the his model code
like to_json and from_json.

In this way we can more easily add new entities or existing ones that are
JSON only.

Collaborator

minimul commented Aug 3, 2015

Let's try to work in JSON only entity support without considering a large
rewrite. Like @tchang1 said the V3 API is going to be with us a long, long
time and it almost completely supports XML. In fact, I believe in the case of
a few entities it was the opposite, devs were complaining about JSON support
not being up to par with XML.

Anyway, let's cross the v4 bridge when we come to it in which time it may be
best to just to roll a new gem (like was done in the case of v2 & v3)

Looking at @raecoo's fork I think we can at least abstract out the TaxService
service code into say a ServiceCrudJSON. Same with some of the his model code
like to_json and from_json.

In this way we can more easily add new entities or existing ones that are
JSON only.

@minimul

This comment has been minimized.

Show comment
Hide comment
@minimul

minimul Aug 4, 2015

Collaborator

@raecoo If you could form a PR like described in my previous post that would be so appreciated. If not I plan on contributing to this solution largely based on your fork.

Collaborator

minimul commented Aug 4, 2015

@raecoo If you could form a PR like described in my previous post that would be so appreciated. If not I plan on contributing to this solution largely based on your fork.

@minimul minimul referenced this issue Aug 6, 2015

Closed

Reports #259

@raecoo

This comment has been minimized.

Show comment
Hide comment
@raecoo

raecoo Aug 6, 2015

Contributor

@minimul I agree with the ServiceCrudJSON solution. I've sent the PR.

Contributor

raecoo commented Aug 6, 2015

@minimul I agree with the ServiceCrudJSON solution. I've sent the PR.

@minimul

This comment has been minimized.

Show comment
Hide comment
@minimul

minimul Aug 6, 2015

Collaborator

I am thinking more along the lines of this:

minimul@b7a5f74

I'll have more comments and code tomorrow.

Collaborator

minimul commented Aug 6, 2015

I am thinking more along the lines of this:

minimul@b7a5f74

I'll have more comments and code tomorrow.

@raecoo

This comment has been minimized.

Show comment
Hide comment
@raecoo

raecoo Aug 7, 2015

Contributor

the refactoring is awesome.

Contributor

raecoo commented Aug 7, 2015

the refactoring is awesome.

@minimul

This comment has been minimized.

Show comment
Hide comment
@minimul

minimul Aug 7, 2015

Collaborator

I have more updates on that branch that are based off sandbox testing.
Trying to get this merged into master while I have time and it is fresh in my mind.
Probably Monday or Tuesday night, US Eastern time.
This should be a good first step as well (1.0.0 release?) to supporting either data format.

Collaborator

minimul commented Aug 7, 2015

I have more updates on that branch that are based off sandbox testing.
Trying to get this merged into master while I have time and it is fresh in my mind.
Probably Monday or Tuesday night, US Eastern time.
This should be a good first step as well (1.0.0 release?) to supporting either data format.

@minimul

This comment has been minimized.

Show comment
Hide comment
@minimul

minimul Aug 10, 2015

Collaborator

Merged into master.

Collaborator

minimul commented Aug 10, 2015

Merged into master.

@minimul minimul closed this Aug 10, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment