consolibyte
IPP Customer query returned Ids that do not match add response
I am working with the IPP example included with the distribution. I can add and query customers without a problem, but I've noticed that when I query customers the ID is different and is in braces.
e.g. I run example_customer_add.php and it says "Our new customer ID is: [4]". However, when I query customers, the same customer returns "{-4}" from the getID method.
I've traced this down to _push method of QuickBooks/IPP/Parser.php#L469 and the buildIDType method in QuickBooks/IPP/IDS.php#L217
Hopefully, I'm missing something and this is working as intended, but shouldn't these two values match?
Can you let me know specifically which example you're using?
Also, are you using V2, or V3 of data services?
Sorry...forgot to include that. It's IPP v3 against QBO. If I run docs/example_app_ipp_v3/example_customer_add.php, I get "Our new customer ID is: [4]" along with the additional request and response output.
However, if I then run docs/example_app_ipp_v3/example_customer_query.php, I get "Customer Id={-4} is named: Keith R Palmer Jr 493".
This is probably a bug. v3 support is very new, and v2 used a different format of identifiers. I will look into it.
From what I can tell, the { [domain]-[id] } format is used for QBD. Is that right? If so, I'll do a fix to return only the content of the tag if either:
- flavor is QBO
- the idDomain attribute is not present.
@consolibyte I have commit to resolve the problem, but unfortunately, it is downstream from another pull request I've already submitted. So, if my other pull request is ok and gets merged, I'll submit the fix along with some other IPP v3 additions.
If you'd rather see it in a separate pull request, I'll try to rebase my branch and extract that one fix.
arjoe/quickbooks-php@0a7acd3042ab81924f1b3dd714ce618142a9012f
This should be fixed with the latest commit. Can you check and confirm?
Just from looking at the source, they should be the same; but I'm not sure it's the intended result. According to https://developer.intuit.com/docs/0025_quickbooksapi/0050_data_services/v3/020_key_concepts/0700_other_topics#IdType, for QBO (where the domain is empty) the Id should be numeric.
I have a fix in one of my branches, but I can't submit a pull request for them yet since I'm a github noob and had previously been committing to my master branch (which is apparently not a good idea when I want to request a pull).
https://github.com/arjoe/quickbooks-php/commit/0a7acd3042ab81924f1b3dd714ce618142a9012f
My personal preference would be that QBO and QBD implementations should return similar output, hence why I didn't make it just return an integer. It seems strange to me to write code that returns an integer for what platform, but a string for another, when one of the big purposes of V3 is that it should unify communication methods across QBO and QBD.
Is there any practical reason to return an int, vs. something that can be returned consistently across both flavors of QB?
being numeric doesn't mean it can't be a string. The doc doesn't say anything about a integer so from my perspective ID's from either could be strings.
@consolibyte I agree with you on consistency and think that Intuit should have consistent IDType values across platforms. However, I think that the SDK should match the API specification. That being said, I will defer to your preference since you are the primary maintainer of the project and take care of the difference in my code external to the SDK.
@rps-repo That is true, but I think that Keith is saying that he would prefer the format to be consistent not just the data type.
With V3 example_customer_add.php, I'm getting {-12} as the $resp variable.
If the $resp == {-12}, the ID = 12, personnaly I just do :
$resp = {-12} $pattern = '/\d+/'; preg_match( $pattern, $resp, $match);
$match[0] contains 12
