Dynamics AX 2012发票日记账异常排查：AX问题还是AR软件捕获时机错误？

Let’s break this down step by step, starting with how AX 2012 handles invoice numbering and then connecting it to your AR XML capture problem.

First: Why You See Gaps in Database Continuous Record IDs #

This is actually expected behavior in Dynamics AX 2012, not a bug. Here’s why:

• When you create an invoice journal (backed by the CustInvoiceJour table), if you’re using an auto-number sequence for invoice numbers (INV#), AX immediately allocates the next available number from the sequence.
• Critically, this number allocation is not rolled back if the subsequent posting fails (even due to a system crash). AX does this to prevent duplicate numbers—if it rolled back the number, another user or process could grab it before you retry, leading to conflicts later.
• So when you created a new journal after the crash, AX just grabbed the next unallocated number in the sequence, creating the gap you see in the database record IDs. This is intentional design, not an AX flaw.

Now: Why AR Captured the Old Invoice Number XML #

This is almost certainly a timing issue with your AR software’s XML capture logic, rather than an AX problem. Here’s the breakdown:

• If your AR system is set to capture XML when an invoice journal is first created (i.e., it listens for the insert event on the CustInvoiceJour table), it would have grabbed the old invoice number’s XML as soon as you made the first journal—even before posting failed.
• When you created the second journal and posted it successfully, the AR system either:
  1. Didn’t listen for the update event that marks the journal as posted (so it never picked up the valid, new invoice number), or
  2. Still had the old journal record in its queue (since AX doesn’t automatically delete failed journals by default) and prioritized that over the new, posted one.

How to Verify This #

To confirm the root cause, you can check two things:

1. AX Number Sequence Settings: Navigate to Organization administration > Number sequences > Number sequences and find your invoice number sequence. Verify it’s set to allocate numbers on creation (the default) rather than on posting—this will confirm the gap is expected.
2. AR Capture Trigger: Work with your AR team to check if their XML capture is tied to the CustInvoiceJour.insert() event vs. the CustInvoiceJour.update() event (specifically when the journal’s status changes to "Posted"). If it’s tied to insert, that’s the timing mistake.

Edge Case to Rule Out #

In rare cases, if AX failed to mark the first journal as "Failed" or "Cancelled" after the crash, the AR system might still treat it as a valid record. You can check this by looking at the CustInvoiceJour table for the old invoice number—if its Status field isn’t set to a failed/cancelled state, that’s an AX cleanup issue, but this is far less common than the timing problem.

内容的提问来源于stack exchange，提问作者Steven Schotter