Cashbook Bank Management & Accounts Receivables - Critical Audit Trail Code Link

I recently worked on an issue reported by one of my Finance Colleagues, whose team takes care of Cashbook Bank Management (CBM) Transactions as process owners.

They post Receipts from CBM and that in turn creates an AR Receipt. They post these AR transactions either by posting the AR Batch having that CBM originated receipt OR sometimes by directly posting that AR Receipt by deleting the Batch Number from that transaction.

A week earlier, they reported an issue:

Couple of receipts were voided in AR after posting it in AR, but it is not showing up in CBM Transaction Enquiry/Void process, for them to apply that void entry in their Bank Book. That means, voiding specific CBM originated AR Cash Receipts is not automatically creating a void link in CBM.


Quite serious and I had no clue whatsoever. I asked them for some samples of those which were voided in AR and getting reflected in CBM as well. Idea is to find THAT difference which prevents the couple of AR Voids not getting shown up.

The major and critical difference that I found is as shown below:

The first payment #2445 was voided in AR and it created a void link entry in CBM, whereas the second payment #2446 was voided in AR and it DID NOT created a void link entry in CBM. The difference, after seeing the above screenshot, is quite telling.

CBM - User [username] is busy with batch [batchname].

As promised in my previous article, here we go.

This is another frequent error message that Users get when they enter CBM Manual Payments in a CBM Batch:

CAUSE: There will be an Activity record inserted when you open a Batch for Payment Entry, in the table CB300006 (Display Name: Batch Entry Records Locked). This does not get cleared at times.

SOLUTION:

I. Follow the Resolution Steps I & II from this article: http://www.vaidy-dyngp.com/2010/04/cbm-checkbook-checkbook-id-is-already.html.

II. Run the following query once above steps are completed.

DELETE CB300006 WHERE USERID = '[username]' AND BACHNUMB = '[batch number]'


We are good to go now.

VAIDY

CBM - Checkbook [checkbook id] is already in user by user [username].

I often come across this request from GP Users:

This happens when the User try to reconcile from CBM Reconcile. And once he/she selects the Checkbook which needs to be reconciled.

After some SQL Profiling & Dex Script Log, I found the following:

Cause:

The table CB100006 contains the User Checkbook Activity records, as and when a User reconciles a Checkbook. This table for some reason is not cleared properly. Sometimes:

1. If you open the form, enter the Checkbook ID and just close it without any activity, this record is not cleared.

2. If you open the form, enter the Checkbook ID and just close GP directly without any activity, this record is stuck.

The above scenarios are faced by me and have not heard of this from any other consultants, so the above need not be recreated consistently.

Resolution:

I. Consultants must open SQL Management Studio, log on to the Data Server and connect to relevant company DB.

II. Run the following queries against DYNAMICS and the respective companies:

/*
   This below queries will delete all stranded and unwanted SQL Sessions.
*/
DELETE TEMPDB..DEX_LOCK WHERE SESSION_ID NOT IN (SELECT SQLSESID FROM DYNAMICS..ACTIVITY)

DELETE TEMPDB..DEX_SESSION WHERE SESSION_ID NOT IN (SELECT SQLSESID FROM DYNAMICS..ACTIVITY)

/*
   The below queries will ensure that the respective user, against whom the error message was thrown, would be cleared from GP Application Session(s).
*/
SELECT * FROM DYNAMICS..ACTIVITY WHERE USERID = '[username shown in the CBM error message]'

--Ask that user to log off, if this user has logged on for the day.

III. Run the below query to clear the CBM Checkbook Lock:

DELETE CB100006 WHERE USERID = '[username shown in the CBM error message]'

That's it. We are good to go with our Checkbook Reconciliation in CBM.

NOTE: I will be posing another article on CBM Payments Batch Lock Error (which is identical to this error message).

VAIDY