Bank Deposits being incorrectly marked as Canceled

My client is using AX2009 SP1 (I think they’re on Rollup 6). They are having a problem where a newly created deposit slip for a customer payment journal transaction will mark some of the BankDeposit records as cancelled.

Here’s what appears to be happening:

Several months ago, they created a customer payment journal, posted it, and created a deposit slip for it. One of the payment transactions in that journal had a payment reference of “Cash”.

As part of normal processing, the bank deposit was reconciled, so the BankAccountTransaction record for that cash payment was marked as reconciled.

Now, a totally new payment journal is created. Another payment transaction record is created, also with the payment reference of “Cash”. Journal is posted, and they create a deposit slip for it. However, the BankDeposit record for this cash payment is being marked as Canceled

Here’s the code path that AX executes:

Starting from the BankDepositSlip class, bankDepsoitSlip method:

bankDeposit.createTransFromJournal(ledgerJournalTrans, depositNum, _accountId);

That method executes the following code:

this.Canceled = BankAccountTrans::find(ledgerJournalTrans.PaymReference).Reconciled;

The find method executes the following code:

select firstonly
bankAccountTrans.PaymReference == _paymReference;

This find method is looking for the first BankAccountTrans record with a payment reference of “Cash”. It finds the old record that was posted months ago and was reconciled. Because that reconciled field is true, the code in the createTransFromJournal method is therefore marking our new BankDeposit record as Canceled, even though that new bank deposit is completely unrelated to the one that was reconciled.

This is all base AX code; we have not customized the bank deposit creation process at all.

A payment reference of “Cash” is one of the most common ways our customer payments are recorded, and so far it is on these cash payments where we are seeing the Canceled flag being incorrectly marked on deposits, but I suspect that this problem may exist on others. If two completely unrelated payments come in, and they happen to have the same check number, it is possible that this code could be causing the deposit on the new check to be incorrectly marked as well.

Has anyone else encountered this issue? If so, how were you able to get around it? I did a search of PartnerSource and of the web in general, and I did not find anything that addressed this issue. Do you know if Microsoft is aware of this and if a fix may be forthcoming for AX2009?


Bill Yater

Blue Horseshoe Solutions, Inc