Finance | Project Operations, Human Resources, ...

Invoice number sequence after update 71 (ITA – “Continuous” sequences, Issue 1120115)

(3) Share

Report

Posted on by Diego Mancassola

829

Hi all,

We are experiencing some unexpected behavior after applying Update 71 (7.0.7858.76) and wanted to check if anyone else has seen the same in the Italian localization (Number sequences with “Continuous” flag).

This seems related to standard Issue 1120115 under investigation

AS-IS situation:

After the PU, all “Continuous” number sequences show anomalies.

Observed issues:

The number sequence cleanup date is always before the PU application
→ suggests cleanup might not be working correctly.
The system writes to NumberSequenceList much more frequently than before.
If a document posting (e.g., invoice) fails:
- The number is stored in NumberSequenceList with “Undecided action” (e.g., 96759)
- The next posting skips this number and assigns the following one
- The number is only released later (e.g., when the user session ends)
During posting, the system prompts for cleanup more often than in the past.
Cleanup only applies to number sequences not linked to active sessions.

Why this is critical (Italy-specific):
Open number sequences can create compliance issues.
Example: if an invoice is posted today with voucher 123, it becomes problematic to post a backdated invoice (yesterday) with a higher number than 123.
Therefore, leaving sequences “open” from previous dates is not acceptable.

Has anyone encountered the same behavior in PU71 (Issue 1120115)?
If yes, how are you managing or mitigating this?

Thanks in advance for any insights.

Note, the post is AI written supported based on a internal our document.

Categories:

Dynamics 365 Finance

I have the same question (0)

All responses (3)

Answers (0)

Sort by

Suggested answer

Giorgio Bonacorsi 2,461 on at

Like (1)

Report
Copy link

Link copied!

Hello,

Yes, I confirm the business requirement.

In Italy we need to keep the "Continue" flag selected because the new voucher number must be higher than the previous one (this is a tax requirement from the Italian authorities).

The cleanup can help reduce the number of errors, but it does not completely eliminate them.

Thank you,
Giorgio

Was this reply helpful? Yes No
Diego Mancassola 829 on at

Like (0)

Report
Copy link

Link copied!

Hi Giorgio, of course there is that requirement.

In addition to my post i'll would put attention on this issue.

We need to know if anyone, in Italian location of course, has this problem and how workarounded that.

Was this reply helpful? Yes No
CU08070205-3 8 on at

Like (0)

Report
Copy link

Link copied!
I can confirm I’m experiencing the same behavior after PU71 in an Italian setup with continuous number sequences.

From what I see, the issue is not just about the legal requirement (which is clear), but more about how the system is now handling failed transactions and session-bound sequences. The fact that numbers remain in “Undecided action” and are only released at session end is what makes things quite risky from a compliance perspective.

I also tried relying on cleanup, but as Giorgio mentioned, it only helps partially. In my case it doesn’t prevent temporary gaps during the day, especially if users encounter posting errors.

One thing I noticed is that the problem becomes more visible in environments with higher transaction volume or where users tend to keep sessions open longer. That seems to delay number release even more.

At the moment I’m handling it by:

trying to reduce posting failures as much as possible

asking users to close sessions more frequently

monitoring NumberSequenceList to catch stuck numbers

But honestly, this is more of a mitigation than a solution.

It would be really useful to understand if anyone has received feedback from Microsoft beyond “under investigation,” or if a hotfix is already planned. Given the Italian compliance constraints, this behavior feels quite critical.

Curious to hear if others are seeing the same pattern or found a better workaround.

Thanks. heardle

Was this reply helpful? Yes No