Version: 8.5 & Up

This enhancement will allow users to post AR cash receipts for a specific batch even if another user is in the middle of editing a cash transaction. 

For the longest time, we didn't allow the posting of cash receipts when other users were editing the cash receipt transaction. This restriction existed because our cash receipt posting process lacked the safety logic to prevent the posting of a cash transaction that another user was simultaneously working on. While you can mitigate this problem manually by ensuring that your users only post their own batch, there's no guarantee that your users won't make mistakes, as they might accidentally post all batches or post another user's batch. Therefore, our default logic needed to incorporate a safe method to ensure it works under all conditions. We achieved this by using a lock file, a method that has been in place for over 30 years.

The lock file logic was broken several years ago when we decided to convert all lock files from DAT to BTR. The changing from DAT to BTR lock file was made to close any potential security loopholes related to NTFS security. For AR cash receipt posting, we were supposed to lock ARLCKCSH.BTR. However, due to a bug, we were checking the .BTR file instead. Because of this bug, users were able to post AR cash receipts while other users were still in the middle of processing cash receipts. Recently, we encountered a support incident. After further investigation, we discovered that the posting routine was attempting to post the cash transaction that another user was editing. The issue was reported to R&D.

Our R&D determined that the locking mechanism for A/R cash transaction processing had been broken per the explanation above. So they fixed the bug with the 8.5d.906 and 8.63.906 releases. However, after this fix, our user now sees the following message when they try to post a cash receipt if another user is still in the middle of editing.

The above message is not a bug but a bug fix aimed at preventing potential conflicts when posting cash receipts. On the other hand, we understand that our user might prefer our "bug" from before since they maintain that all their users have the discipline to post by batch. Therefore, they are not at risk if we relax the restriction.

After careful consideration, we made the change so that if a user chooses to post a specific cash receipt batch, we will allow it even if other users are in the middle of editing cash receipt transactions.  We assume that users will not make the mistake of posting another user's batch.

On the other hand, if a user chooses to post "All" batches, and there are other users still in the middle of editing the batch, we will not allow this posting to proceed. Users will receive the following message:

In addition, if user choose to post blank batch, then we assume the batch is not in used and hence we will prevent cash receipt posting with the following message:

This logic is not only applied to the entry screen user interface program which prompts for the parameters (see above example); it is now also applied to the Cash Receipt Posting Journal which can be scheduled through deferred processing to bypass the screen user interface checking. 

Modified Programs: ARCSHJNL, ARCSHENT, EL850TSK (8.5), NWSMTASK (8.6)

CLS, EMK