Recently we have seen some cases where during a long running process in AX (for example data import/export, company duplication or create absence journals) the process appears to switch companies, so the process begins running in company A but after a point it continues running in company B, this could then create some records in the first company and some records in the second company.

Since the exact steps are difficult to replicate, as it relies on several specific factors it is unlikely to occur on a day-to-day basis for a typical user. However, given the potential that records could be created in an incorrect company we recommend applying the fix in a proactive manner to safeguard against any possibility of a problem in the future.

Example scenario:

I have my AX client open in, for example, company "CEU". I also have a form open which is in a different company, "CEC". Now from this form I start a long running process (for example HR->Create absence journals) which is using company "CEC" as this is the company of the form, then using the windows task bar I click onto the main client window.

At this point the system processor is running at 100% so the windows will not switch immediately however after some time a thread will become available and the main client window will become active and the long running process will then switch to company "CEU" and continue running in that company.

The error that the user would see, in this scenario with "Create absence journals" would be:
Cannot create a record in Absence registrations (HRMAbsenceTable). Insert operations are not allowed across companies. …

There is a kernel hotfix available now to address this issue, for both AX2009 SP1 and AX2009 RTM, it's available under KB974507 and can be obtained by contacting Microsoft Support.

Note:
Use normal database recovery options when doing imports or company duplication.  A full SQL backup should be performed and the process should be done with limited users in the system.