Purchase Reference and Credit Note

Extensibility
1

I love the new API which seems much simpler and better documented, but I noticed two points:

Purchase: the supplier_reference is in the post purchase suppplier_reference (3p)

Invoice: negative amounts throw an error of missing “credit note meta data” but there is no documentation on the required meta data.

If you make changes to the suppplier_reference integrations will break, so please make sure this will be communicated.

2

Hello @goetz

Thanks for bringing this to our attention.

I have passed this on to the development team.

3

Hi,

I have noticed a typo in the new REST API schema for POST /purchases.

There is a key/value pair in the json as follows: “suppplier_reference”: “suppplier_reference”,

Note, that the word supplier incorrectly has 3 p’s in it… I am sure this is something you will want to correct, but please let me know when done, as I will have to have one less p in my code!

Thanks, Rob.

4

Hi @rocketman

Thanks for letting us know! I’ve merged your post with an existing thread which mentioned this, so we can keep you updated.

We will, naturally, update the spelling error.

There won’t be a wide communication on this, just an update here (which should send you an email). However, please note that API v2 is still in beta, please do keep an eye on the documentation as changes may happen during the beta period.

1 Like
7

@goetz @rocketman

Just a quick update to let you know we’ve corrected the ppp typo.

The Credit note update will follow, hopefully one day next week. The details are updated in the docs, but a bug was identified while testing in the code itself which needs fixing before it’s live.

New REST Api Credit Note documentation
8

thank you; I did update my integration.

9

Tested, and confirmed working OK thanks!

1 Like
10

Following up on this — we’ve hit what looks like the same credit-note numbering issue, but via the REST v2 API rather than the old one.

Setup: We create invoices via POST /invoices, and credit notes the same way, using the documented credit_note: { type: "void", invoice_id: <parent invoice id> } object.

What’s happening: Every credit note create attempt against this account fails with:

HTTP 400: Invoice #CN00016 already exists.

We’ve confirmed:

  • CN00016 is a real credit note in the account, but its QuickFile status is Deleted, and the UI says it cannot be restored.
  • It is not linked to the invoice we’re trying to credit — so this isn’t a per-invoice number clash, it looks like a single account-wide counter.
  • We tried explicitly setting invoice_number in the request body to a different value (e.g. "000070"), hoping to bypass whatever auto-numbering picked CN00016. QuickFile ignored it completely and still returned the exact same CN00016 already exists error — so the field has no effect for credit notes, and there’s no way for us to specify a different number ourselves.

So as far as we can tell, the account’s credit-note auto-numbering sequence is stuck pointing at a deleted, unreusable document number, with no way to advance it or override it from the API side. This means no credit note can currently be created on this account via the REST API — happy to share the exact request/response JSON if that helps you reproduce it.

Is there a way to either free up that number, or force the counter to advance past it?

11

Hello @edsgroup

I have sent you a private message to get more information.

12

Is this just the API or do you get the same problem if you try to create a credit note through the UI? Would manually creating and then fully crediting a dummy invoice in the web UI be sufficient to un-stick things?