Invoice Numbering Issues

[Mark_C11]

Hi,

Seems the latest version of AccountRight (AR) has made changes to the way AR allocates invoice numbers.

We have another platform which sends invoices into AR and uses a 2 character Alpha prefix in the invoice number.  This allows easy identification of the invoices coming from that platform.  We also need to be able to continue raising invioices in AR with the the normal AR invoice numbering sequence.

Using an alpha prefix previously meant that when raising an invoice directly from AR, it would just continue to use the auto numbering in AR.  Ignoring the alternate sequence of invoice numbers with the Alpha prefix.  To the best of my knowledge (as a long term MYOB user - 20 plus years) this has alway been the behaviour to expect.

Since the most recent update, AR now seems to be wanting to continue on with the Alpha prefix.  This presents issues for us, in that if we continue to raise invoices in AR we would be requireRed to adjust the invoice numbering manually, (sounds easy...but it just isn't..and users are unreliable)

We are now in a position where it is likely we would have duplicate invoice numbers being created (not a great idea) and or our alternate invoicing platform would not be able to create invoices due to being unable to determine the currrent Alpha prefix number before pushing invoices to AR.

Given that there were changes to invoice numbering stated in the latest update (per below) is this an intended or unintended consequence of these changes?

Version 2021.7 is here

New features

• (When using AccountRight in a web browser) Invoices now support longer alphanumeric invoice prefixes in invoice numbers

[Mark_C11]

Hi,

Seems the latest version of AccountRight (AR) has made changes to the way AR allocates invoice numbers.

We have another platform which sends invoices into AR and uses a 2 character Alpha prefix in the invoice number.  This allows easy identification of the invoices coming from that platform.  We also need to be able to continue raising invioices in AR with the the normal AR invoice numbering sequence.

Using an alpha prefix previously meant that when raising an invoice directly from AR, it would just continue to use the auto numbering in AR.  Ignoring the alternate sequence of invoice numbers with the Alpha prefix.  To the best of my knowledge (as a long term MYOB user - 20 plus years) this has alway been the behaviour to expect.

Since the most recent update, AR now seems to be wanting to continue on with the Alpha prefix.  This presents issues for us, in that if we continue to raise invoices in AR we would be requireRed to adjust the invoice numbering manually, (sounds easy...but it just isn't..and users are unreliable)

We are now in a position where it is likely we would have duplicate invoice numbers being created (not a great idea) and or our alternate invoicing platform would not be able to create invoices due to being unable to determine the currrent Alpha prefix number before pushing invoices to AR.

Given that there were changes to invoice numbering stated in the latest update (per below) is this an intended or unintended consequence of these changes?

Version 2021.7 is here

New features

• (When using AccountRight in a web browser) Invoices now support longer alphanumeric invoice prefixes in invoice numbers

[Mike_James]

Hi @Mark , @Tracey_H , the quote from the What's new page appears to be incorrect: "(When using AccountRight in a web browser)...". The desktop program numbering behaviour has changed as well. Numbers of up to 13 characters are now permitted. Perhaps the "what's new" page could be corrected?

[Mark_C11]

Yes @Mike_James this would appear to be the case.

I must say I am finding it extremely frustrating that several times now updates have been release which change the behaviours of the system which have been in place for a long time.

This is extremely disruptive to customers who have designed processes around the behaviours that were in play and these all of a sudden change without notice.

The testing regime at MYOB seems to be inadequate

[Tracey_H]

Hi @Mark_C11

Thanks for your post. Third-party products will typically connect to AccountRight through the use of the AccountRight API. Generally speaking, if the Invoice Number of the transaction is passed through to AccountRight via the API, the invoice number sequence will be updated by that API. If the Invoice number of the transaction is not passed through to AccountRight via the API the invoice number of that transaction will be based on AccountRight's autonumber sequence.

So in your case, if the invoice number is being specified by the third-party in that API you are telling AccountRight to use that number and the sequence will typically be used by AccountRight going forward.

@Mike_James 

Hi Mike, the character limit in the desktop version was increased to 13 in the 2020.2 release so the information in the 2021.7 release is correct, ie, the limit has been increased in browser version in 2021.7.

Please let me know if you need further help.

[Frothy]

Hello @Tracey_H,

This does not answer the question - Is this new to this update?

Why all of a sudden is the third party API updating the invoice sequence when @Mark_C11 stated that it was not altering the "auto" fill invoice number previously.?

Cheers

[Mark_C11]

Thanks @Tracey_H 

But @Frothy is right, you havent answered my query.

To be clear, the third party product, until the latest update pushed in the invoice numbers as eg.AA00001, AA0002 etc.  

This does not (did not) alter the usual numbering sequence of invoice numbers in account right.

And even leaving out third party apps, if previously ( and  for the last 20 odd years) if you opened an invoice and used an ALPHA type characters as the invoice number eg TEST.  This also did not change the "normal" numbering sequence.  If the invoice number before you created TEST was say 0101 then the next one created after TEST would be 0102 as expected.

This long standing behaviour of the system has now changed, causing a rather large problem as we have processes designed around this.

[SANDYMW]

Thanks @Mark_C11 you are absolutely correct.  We also have been using a third party system for over 10 years (Datapel's WMS), importing invoices with S00* sequence numbers which have not impacted the default AR numbering sequence.

As of today, after updating, we are also being forced to manually reset our invoice numbering for those invoices raised in AR. 

Extremely frustrating, having to check the last number used and then manually enter it.  We also have processes designed around it.

@Tracey_H I invoices imported via API systems did not impact auto-numbering until this release.

[Mike_James]

Hi @Tracey_H , thanks, that's something I didn't know! The 8 character limit has been in my DNA for ever...

There has definitely been a change in behaviour though around the numbering sequence, as reported here.

[Tracey_H]

Hi Everyone

Just wanted to provide an update on this. AccountRight 2021 versions have been designed to use the next number in the invoice sequence. We identified a situation that third-party applications and alpha-number sequences didn't follow this pattern. This is something that we updated with the release of AccountRight 2021.7 so that those invoice numbers would follow that same principle.

We do understand that some users would like to see a different sequence for invoices generated by third-parties application and other instances. This is something that we have fed back to the required teams for the future, however, following on from the 2021.7 version the invoice number field would use the same invoice number sequence.