Purchase Search API

Extensibility
1

Hi,

I am creating standard summary reports for our finance committee, using the QuickFile API, a Windows application and Word templates.

Basically I am trying to add 2 things to a report, from the main Quickfile homepage, “Money Owed to You”, and “Money You Owe”.

The first is done, because the Invoice_Search API returns PaidToDate for invoices.

However the Purchase_Search only returns the Amount, NetAmount and VatAmount for purchases.

So if we have made a partial payment on a purchase, I can’t see how much we still owe on the purchase, I can only get the original purchase amount.

Is there a way of getting the total amounts paid to date on our purchases, or the amount outstanding after partial payments?

I am just creating a summary, so I want to avoid having loads of api calls and then summarising the results.

Also, regarding the status for the call, the parameters are (excuse the c# code)

                public const string Unpaid = "UNPAID";
                public const string PaidPart = "PAIDPART";
                public const string PaidFull = "PAIDFULL";
                public const string Credit = "CREDIT";

                public const string Draft = "DRAFT";
                public const string Sent = "SENT";
                public const string Disputed = "DISPUTED";
                public const string Active = "ACTIVE";
                public const string Deleted = "DELETED";
                public const string Credited = "CREDITED";

Originally I thought that using the ACTIVE status would return all unpaid / part paid purchases, but it doesn’t.

So am I correct in having to make 2 calls for data, one for UNPAID, the second for PAIDPART.

Thanks,

Tony

2

Update. Actually, now I have implemented and tested, I can see that Purchase_Search called with a status of UNPAID, does return both UNPAID and PAIDPART records.

So my issue can be simplified to:
For PAIDPART purchases, how can I get the outstanding amount owed? with Invoice_Search it returns PaidToDate for PAIDPART invoices, but Purchase_Search does not

3

Hi @TonyE

There isn’t currently a way to see the balance on a purchase invoice I’m afraid. However, this is something we’re aware of and is on our radar.

While I can’t confirm a timescale at the moment, we can certainly update you when this is available.

I don’t have any specific details at this time (e.g. I’m unsure if it would be added to Purchase_Search, or whether it would be done through a different endpoint).

4

Thanks Mathew.

For now I will just use a purchase_get call for every part paid purchase, but if the api changes to include the balance please let me know.

It would be nice if the api’s were being changed to perhaps also allow for more details to be returned.
Specifically I would like to be able to return the full descriptions e.g. for invoices and purchases.

At the moment they only return the first part of the description, followed by “…”

A lot of our descriptions are only a few characters longer than the bit returned, but they are chopped off.

Eventually I would like to be able to use the full description to be able to produce adhoc summary reports using keywords in the description like Amazon, Printer, Tractor etc. so we can have visibility of where we are spending money, to try and make better decisions

e.g. graphs showing spending over time on

Staff wages
Estate equipment
Water usage bills
Road repairs
Lift repairs
etc. etc.

I would like to get AI involved in my application for that, but I need to have the full descriptions to be able to pull out the key words.

At the moment e.g. this lift repair purchase description is truncated to “Supply, fit and setup for corr..” which gives no useful information.

So to get the full descriptions, at the moment, I will need to do Purchase_Get on thousands of purchases. I could download csv and keep in a separate database, but that means I would have to keep that up to date, when actually all I need is the full description.

Also, the plan is to standardise the descriptions staff enter to allow better reporting. So the current descriptions may change frequently, so I would need to update a separate database frequently.

Thanks,

Tony