search

ruckus / quickbooks-ruby

Quickbooks Online REST API V3 - Ruby
MIT License
374 stars 302 forks source link

invoice.id appears to return Transaction ID, when it historically returned invoice doc number #605

Closed vastolf closed 6 months ago

vastolf commented 6 months ago

I have a system that stored invoice IDs from Quickbooks in my database.

Previously, when I accessed invoice.id it gave me a number beginning in "1". e.g. 10234, which actually seems to correspond to what is referred to as the doc_number (in some contexts apparently referred to as the referenceNumber). It is the number that displays in the Quickbooks invoice interface:

Screenshot 2024-02-22 at 12 43 49

Around December 14th this changed, and I had not modified my implementation of using invoice.id whatsoever.

Now, it appears to save a number beginning in a "2". This appears to be a transaction ID (txnId) which is linked to the invoice (e.g. 29291)

See below where the invoice # is listed in the header of the page, but the txnId url param is this 29291 number:

Screenshot 2024-02-22 at 12 45 38

I'm not sure if this is related to a change in quickbooks API or this library, though it appears I've been on 2.0.2 for some time.

Essentially, the number that actually stores in my database when calling invoice.id is the number beginning in "2", not the number beginning in "1", since around mid December.

Wondering if anyone else is experiencing this and whether there has potentially been some change to the Quickbooks API that would cause this gem's implementation to be outdated or behave unexpectedly.

ruckus commented 6 months ago

I don't know if Intuit made any changes. However, I don't think there is any correlation between the numeric Invoice.Id which is the QBO unique identifier and the Invoice.DocNumber aka the invoice # which is user-provided / changeable.

Here is the XML result from QBO of a random invoice:

Zight 2024-02-23 at 8 45 05 AM

And in this case yes the Id happens to begin with "1" and the invoice # (which is generated by the client) is alphanumeric, but they really have no relation to each other

vastolf commented 6 months ago

Strange, it appears my docNumbers are always set to be the invoice #/ID, whereas the ID is actually a txnId instead of an "Invoice ID".

I will close this, but maybe someone can re-open if they're experiencing similar issues.

I just find it strange that my implementation hasn't changed yet what is getting stored has.

Thanks for your response, if I am able to figure out what happened and what caused it, and I think it'll be useful for others, I will report back here.