Implement support for the reference field in the new Overpayment and Prepayment Endpoints
The addition of Overpayment and Prepayment endpoints, for us is still not functional with the addition of the reference field in these. Without this there is no robust way to save a prepayment at one point in time, then be able to look this prepayment up later to be used for allocation purposes.
Same problem for Overpayments.
Hope this can be added very soon as we are looking forward to the XERO api having proper Prepayment support.
David
shared this idea
-
Mark Kariuki
commented
I have been struggling with this challenge and it's impossible to reconcile any data.
Do you want to tie us to using only the Web Interface for this action its been 6 years. -
Craig St George
commented
This is most weris you also cant get if from the Bank transactions endpoint even though its showing in the UI
-
Andrew Gilmour
commented
Having access to Prepayment's Reference allows devs to use reference as controllable and known identifier.
-
Ian Young
commented
Very strange, and rather infuriating, that while we're able to populate the Reference field using the API, we're then not able to query it or return it. Why is it there?
Please add Reference to the returned properties - it's surely a couple of hour job for your developers at most?
-
Stephen
commented
I need to be able to retrieve the reference to be certain that I am picking up the correct overpayment to allocate against. Please implement this ASAP.
-
Anonymous
commented
2 years, still no resolution!!!
-
Chris
commented
I think I'm most interested in seeing the reference field in the BankTransaction endpoint, but getting it here would also be helpful. As an ERP integrator, this seems like this is the best way to handle split check payments, and not being able to recall the previously set reference number is a major bummer.
-
Andrew Pratt
commented
It is really Important that this fault is fixed ASAP. The reference is returned in the validation response and I don't see how it could take longer than 1 hours work to fix in the successful response. It is also important to fix the bug that stores successful payments into the system without reporting this if a validation error occurs on just a handful of a batch i.e. if you send 40 payments and 3 have validation errors, 37 will add to the database but you'll never receive any XML with the ID's telling you they got created.