Normally when a user complains about something like this, a GP Administrator or Consultant’s immediate step is to check what the *Batch Status* field holds in SY00500 (Batch Header) table. The legend for this field says:
0 – Available – BATCH_AVAILABLE
1 – Marked to Post – BATCH_POSTING
2 – Marked to Delete – BATCH_DELETING
3 – Marked to Receive – BATCH_RECEIVING
4 – BATCH_DONE_POSTING
5 – BATCH_PRINTING
6 – BATCH_UPDATING
7 – BATCH_POSTING_INCOMPLETE
8 – BATCH_PRINTING_INCOMPLETE
9 – BATCH_UPDATING_INCOMPLETE
10- BATCH_RECURRING_INCOMPLETE
11 – BATCH_POSTED_WITH_ERROR
And quite apparently, in my case, it was 3. i.e. BATCH_RECEIVING. It’s very easy to update this field back to ZERO that denotes BATCH_AVAILABLE, so user can post it.
I could have also done the same thing. But I did not. I just wanted to make sure that this batch indeed did not receive any transactions. How do we identify whether a batch is receiving transactions or not? That I will address in another post.
This one is intended to caution a Consultant or Administrator NOT to update *Batch Status* thru’ SQL for any batch which is marked as BATCH_RECEIVING when users are logged on.
It would break a valid transaction being saved in this particular batch. When a batch receive transactions, GP locks this batch from getting posted only by updating the *Batch Status* field with BATCH_RECEIVING. By changing that from back end, we are risking batch getting corrupted.
Tell the user that he/she has to wait. And wait till users log off from GP. And then check whether the *Batch Status* becomes BATCH_AVAILABLE. In case it is not, then you update it thru’ SQL.
It is worth waiting for sometime than trying to clear a mess. I take this opportunity to insist again: SQL is not ALWAYS an appropriate approach for issues that we face in GP.
UPDATE: David has sent me a link, which quite obviously I missed mentioning here. How did I miss this? We do have a way to release stuck batches without logging off users.
VAIDY
Dynamics GP - Learn & Discuss 