I have recently come across one very annoying bug concerning
continuous sequence numbers in Axapta 3. I thought I would share the results of
my own investigation with the community as there is almost zero help on the net
concerning this issue.
The issue
Our accounting users are usually using ledger journals in 2
steps:
- step one, they create several journals in a row and
validate them
- step two, after review and validation by their
manager they post all the journals (generally 2-3 days later)
This was running fine until one user in particular started
to regularly encounter the following type of error when wanting to post journals:
Voucher 'ADVS000172' is already used as of date 30/11/2011.
Namely, another journal had been created with the same voucher (and usually by
the same person) and posted before. Several journal names were concerned and
all were using continuous sequence numbers.
Investigation
At first, I invoked bad luck and improbable coincidences and
suggested that they just delete the faulty journals and create them again,
forcing the number sequence to increment. But when the number of journals with
duplicate vouchers per day started to raise to a 2 digit number, it became
clear that something was wrong somewhere. Because 90% of the time, the journals
were created by one particular user, I suspected that the problem came from the
user. I checked everything, from its Axapta client version to the user permissions.
I asked her to move desks with her colleagues, use another login… but I still
ended up with several dozen journals a week to correct manually in our
database. I even spent several hours in her back watching her create journals. She
was quick but I did not detect any wrongdoing. I noticed however that duplicate
vouchers seemed to happen much more often when I was not next to her!
After a while, I discovered that every so often the next
available voucher number was drawn when the user created the first line in the
journal (which is normal) but its status in the sequence number list was immediately
set to Free (whereas it should be Active before the line is validated or
deleted). As a consequence, the voucher was not reserved and would be used
again in the next journal, which ultimately caused the duplicate error when
posting the journals. However I could not seem to reproduce the problem myself on
my computer. After several weeks, I finally found the source of error – you can
try to reproduce it yourself on your system:
- Create new journal (whose voucher is associated
to a continuous sequence number)
- Input journal description but DO NOT save it yet
- This is where you have to be quick: click Lines
and immediately after press ctrl+N (if you wait more than 250 milliseconds, it
might be too late depending on the speed of your computer)
- Continue to input the journal, close and create
a new journal. The same voucher will be used again.
It is easily understandable that quick users will get the
error more often, which explained the user specificity on this issue (and also
why it seemed to happen less when I was disrupting her normal flow by watching
carefully her every steps in her back). But what exactly causes the sequence number
to be set to status FREE in this particular case?
Analysis
First of all, when pressing ctrl+N it will trigger a call to
the task method of the form, ordering it to create a new record, but the code
will only be executed once the system is idle. In our case, the system seems to
pause just a few milliseconds after the journal table record has been saved and
before the journal Lines form is completely initialized. So if you press ctrl+N
before this pause interval, the create call will be executed during the pause,
but if you’re too late, it will have to wait until the Lines form is finished
being displayed first.
Secondly, when the Lines form is being displayed, the method
linkActive is called on its datasource to create the link between the journal
table form and the journal lines form. However somewhere in this method is a
call to numberSeqFormHandler.formMethodDataSourceLinkActive(). The original
purpose of this method is to “abort” the sequence number drawn in the current journal
line record if it has not yet been saved but the focus changes on another
journal in the journal table form. This is understandable, as the line is
supposed to be dropped in this case. When the form is initialized normally, the
sequence number has not been drawn yet so nothing actually happens when
linkActive is called. However if you pressed ctrl+N before that, a new record with
the next sequence number has indeed been created but not yet saved. As you can
guess, the sequence number is then immediately “aborted” and its status becomes
Free… even though it is going to be used when the line will be saved later on.
Solution
I do not know if this issue has been fixed in later releases
of Axapta, but it was found in our case on Axapta 3 SP2. I tried the Microsoft
fix in HF30SP3_008, which is to add forcewrite in the create method of the
datasource (it makes sense to force write the record to avoid the sequence
number to be aborted later in the linkActive call) but it didn’t seem to change
anything. It seems, judging by the posts on specialized forums, that sequence
numbers are a nightmare in Axapta 3 and that Microsoft attempts at solving such
problems have been mostly unsuccessful. To partially solve the problem, I have
implemented a timer in the task method of the Journal Lines form to block any ctrl+N
attempts in the first second of its initialization. It seems to work quite well
for journals at the moment, but I suspect that the issue is widespread across the
system and is inherent to the framework chosen by Microsoft. Fixing it only for
the ledger journals will not protect you from encountering the same error later
on.
Sorry for the length of this post... I hope it will help someone.
