Sales Pack: Invoice number changes after changing status from 'Issued' to 'Paid'

[GLMFM2026]

After upgrading from 3.1.9 to 4.4.3, issued invoices are getting their numbers incremented when changing the status to 'Paid'!!

I suspect this could have something to do with the new isIssued/wasIssued/isDone fields introduced in 4.0? These are all set to 0 for existing records no matter the status. So an invoice issued before the update would not have it set? How does the number increment logic work in detail and is this expected behavior under these circumstances?

How can we prevent this from happening?

[yuri]

Administration > Entity Manager > Invoice > Edit.

Check status lists in the bottom.

Here's defaults:

[GLMFM2026]

Yup, defaults are the same on our installation.

I figured it out in the meantime:

This was indeed an interaction between the new (since 4.0) draft numbering behavior and the isIssued field on existing records.

So if:
- the new draft numbering feature is enabled (which it was by default on our installation)
- an invoice from before the update has status "Sent" (or "Issued", wouldn't matter, I think?)
- but its isIssued field is 0 (because that field was newly introduced in 4.0, and I didn't see any code that would automatically initialize it based on the status field)

The numbering logic would assign a new number on the change to status "Paid", which it considers "Done".

We have temporarily fixed this by disabling the draft numbering feature (it was unexpected anyway), which seemed to disable the issuance numbering behavior altogether.

As a permanent fix, i suppose we can set isIssued (and wasIssued? what's the difference?) for all invoice records with the given status values.

If this is a general bug and not accidentally specific to our setup and customizations, it might be a good idea to properly calculate this field when upgrading? Though it can't automatically handle custom status values of course...

[yuri]

The field wasIssued is set to true once the document is issued and it stays there even if the document is set back to Draft (which is not allowed if Issuance Locking is enabled).

[yuri]

It's not simple to have a reliable migration script. As statuses are customizable, and there's no way to know whether an invoice with a custom status is considered issued in pre-v4 versions. We didn't have such a concept before.

[GLMFM2026]

I understand now, this makes sense. So isIssued would become false again by setting the status to Draft (without locking), but wasIssued latches permanently. Thanks for clarifying!

Re: migration script - yeah. Before the update I realized when we introduced Espo years ago, we translated the status field to German by changing the option set to have German names, instead of using the translation feature. So we would have run into this exact problem with a hypothetical migration script if I hadn't caught it before.

[yuri]

If change statuses of existing invoices with status Issued to Draft, and then change back to Issued, this should move the invoices to the issued state.

[GLMFM2026]

Will try this next week. I'm assuming this works with a mass update?

[yuri]

It should work with mass update.

You can also just run an UPDATE SQL query to set those two fields to true. Only if status is Paid, Sent or Issued (plus any custom status if you have).