Show TrackingOptionID in LineItem in Invoices API (and other endpoints)
The Invoices endpoint in particular (and many others in general), do not include the TrackingOptionID in the data set. Instead, they generally provide only the Name, Option and TrackingCategoryID.
It is really important for being able to use "joins" on the data to incl;ude the TrackingOptionID .
-
IT Admin
commented
For what it's worth, I checked the below (one more endpoint than I listed earlier) -
bank transaction
credit note line item
invoice line item
journal line
manual journal line
overpayment line item
purchase order line itemAll return tracking for at least some line items. JournalLine does not (though ManualJournalLine does).
I note for all those that do return tracking options, they are contained in a structure in the JSON labelled "Tracking", while for JournalLine, which fails to populate the structure - it's there but empty - the structure is named "TrackingCategories".
This looks like it will solve 6/7ths of the issue.
The API docs do not mention TrackingOptionID as being part of the results (yet?)
Fingers crossed Xero checks why the JournalLine endpoint (Get Journal operation) is not populating the TrackingCategories structure.
-
IT Admin
commented
@Chintan - whoa!
I just tried the API Explorer for invoices, using Get Invoice to pull a single invoice, and can confirm, one tracking option ID is there!
I then checked our raw warehouse table - which is created via the Fivetran connector ... and checked the Xero API documentation for that endpoint ... and no tracking option ID in either place.
Perhaps Xero has literally only just rolled this out? Can I ask when did you first notice the option ID was in the endpoint?
For my use case, I need the option ID in many other endpoints. I have not checked these in Explorer yet, but they are:
credit note line item
invoice line item
journal line
manual journal line
overpayment line item
purchase order line item -
Chintan Prajapati commented
I can confirm that the original issue is SOLVED - TrackingOptionID is now being returned correctly in the API response when fetching a single invoice.
However, I've discovered a new bug: the API only returns 1 tracking category per line item when 2 are assigned. I tested this in API explorer for Demo Organization.
Test Case (Invoice INV-0028):Xero UI shows 2 tracking categories: Region + Project
API response returns only Region
Project tracking category completely missingSince Xero allows up to 2 tracking categories per line item, the API should return both. Currently it's dropping the second one.
-
IT Admin
commented
I posted a comment previously, but it's not showing. Xero support staff say they can see in the back-end that I posted, but don't know why it's not showing.
In any case, I've added my vote. It's pretty frustrating that this issue was raised 29 months ago and Xero hasn't fixed it. I think this should be considered a bug, not a feature request. The API's tracking info does not provide any reliable key to link tracking back to financial transactions. The only field given is name, which can be changed in the UI. This means old transactions will be lost, and, if in future a prior tracking category option name gets re-used, transactions will be linked to the wrong category option. In short - the data coming through the API are unreliable (and the reports we are building are unreliable as a result).
Having been a developer for 15+ years, this is surely a 15 minute fix for Xero developers. The field already exists. Just add a comma and the field name to each API that already includes tracking category info. Seriously, that's all. It shouldn't break anyone's existing usage of those APIs.
-
Rafael Echeverria commented
We would also like to get this done
-
Neill Skelly
commented
I would like for the GET Invoices endpoint to return tracking option Ids on line items, for example: GET https://api.xero.com/api.xro/2.0/Invoices?page=1
Tracking options are returned when getting a single invoice, for example: GET https://api.xero.com/api.xro/2.0/Invoices/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
-
Richard Armstrong
commented
The users can edit the options which means the text/ option can change over time even if the optionID is unchanged. If externally we can only use option then any relationships with external data using the categories become corrupted.