Batches stuck as "in use"

We have run into an issue a few times with both AP and GL batches. The status changes and is stuck on "in use". We check that there are no users in the batch, but the status gets stuck, we can't delete it or post it. The only resolution we are able to do is have our IT department go through the back and into the database and change the status there.

Have others had this problem?

Is there a better/easier way to resolve it?

Any idea of what causes this, so we can avoid it in the future?

Parents
  • We have seen similar problem where batch status remains 'In Use' for several days then reset to Balanced itself. User manually created AP batch but status remained 'In Use' even if user(s) restart their computers. So far can't figure out the problem.

  • in reply to iubac-ASingh

    From your description, the application behavior would appear to be acting as it was designed. In general, the batch status changes and accessibility to the data changes according to how a user is interacting with the batch. The batch status descriptions are contained in the module overview documents, but a simplified version is:

    Balanced - the documents are in balance and no user is processing data in the batch so it is ready for data entry or posting.

    In Use - a user or process is entering, processing or printing data in the batch. If a user is only entering or modifying data, then additional user access to data entry is allowed if the batch is not marked as private. Posting is not allowed while data is being modified.

    The batch status will change accordingly when a user is interacting with the batch data. For example, if a user opens Process Vouchers and clicks on Enter Vouchers the batch status will change to "In Use" until they close the Enter Vouchers window for that batch. If the window is exited ungracefully (crash, etc.), then simply enter that batch again in Process Vouchers. The system will attempt to remove "orphaned" batch locks on its own but it needs user interaction with the batch screens or processes before it runs the cleanup.

    You can review how users are interacting with the application using System Manager / Tools / System Status from the Sage 500 standard menu. This should be enough although there are more technical methods used in the back-end to drill-down on which batches are locked by which users.

    Pretty much all the technical details change if you are on an old version (before maybe 7.4) though. Then it was easier to cross the SQL spids so a lock might have to be released manually.

Reply
  • in reply to iubac-ASingh

    From your description, the application behavior would appear to be acting as it was designed. In general, the batch status changes and accessibility to the data changes according to how a user is interacting with the batch. The batch status descriptions are contained in the module overview documents, but a simplified version is:

    Balanced - the documents are in balance and no user is processing data in the batch so it is ready for data entry or posting.

    In Use - a user or process is entering, processing or printing data in the batch. If a user is only entering or modifying data, then additional user access to data entry is allowed if the batch is not marked as private. Posting is not allowed while data is being modified.

    The batch status will change accordingly when a user is interacting with the batch data. For example, if a user opens Process Vouchers and clicks on Enter Vouchers the batch status will change to "In Use" until they close the Enter Vouchers window for that batch. If the window is exited ungracefully (crash, etc.), then simply enter that batch again in Process Vouchers. The system will attempt to remove "orphaned" batch locks on its own but it needs user interaction with the batch screens or processes before it runs the cleanup.

    You can review how users are interacting with the application using System Manager / Tools / System Status from the Sage 500 standard menu. This should be enough although there are more technical methods used in the back-end to drill-down on which batches are locked by which users.

    Pretty much all the technical details change if you are on an old version (before maybe 7.4) though. Then it was easier to cross the SQL spids so a lock might have to be released manually.

Children
No Data