A “Journal Printing Interrupted” error while posting sub ledger (AP, AP, Inventory, et cetera) transaction batches in Microsoft Dynamics GP can be among the most frustrating and cryptic error messages an ERP system can generate. This error only occurs during the posting process and generally is not manifested when a batch edit report is generated, which is usually where we find batch errors prior to posting. See Figure 1.
When this error is raised, the associated batch is dropped into the Batch Recovery window, and the only option at that point is to mark the batch and to continue. However, it has been our experience that this typically forces a loop whereby the posting process resumes, a “Journal Printing Interrupted” error ensues, and the batch is dropped back into the Batch Recovery window. Meanwhile, it is likely that all or part of the batch has already posted to the sub ledger and to (or through, depending on the posting setup) the General Ledger, leaving your GP system in a corrupted state. Additionally, the sub ledger transactions could now be in both the work and open tables, further complicating matters.
So, what causes this?
How GP posts transactions varies among the various modules, but the process can be broken down and simplified as follows:
Subledger Work Transactions > General Ledger Batches > ISV Processes > Table Cleanup > Posting Journals.
Please note that the ISV Processes data flow refers not only to third-party posting routines, but to ancillary GP functions like EFT for Payables, EFT for Receivables, or Manufacturing processes, to name a few.
The “Journal Printing Interrupted” error, when it occurs, is raised after the subledger work transactions become general ledger transactions but before the table cleanup and posting reports are generated. Oftentimes, this is due to batch transactional data that does not conform to the GUI business rules, either from corrupted data entered through GP/eConnect, or via external data movement processes that bypass the standard GP business rules and associated logic.
Examples of this could be:
- Invalid inventory item types for items present in Inventory subledger batches
- Invalid customer addresses for receivables batches
- Inactive vendors in payables batches
- Or, some other data element required for third-party posting processes to complete.
One particular example that we recently resolved at Crestwood was a receivables cash receipt batch that was moved into GP via the eConnect integration processes through SQL scripting. The batch edit lists were always clean, but posting repeatedly dropped the batch in the recovery loop. After hours of researching, we found that the receivables cash entry batches were marking the cash receipts as EFT, which was fine and acceptable if the customer was set up for EFT. In fact, the journal printing interruption was intermittent and was not always occurring, which ruled out module setup, fiscal period setup, et cetera, and those scenarios would be caught during the batch edit printing process anyway. What we found was that the solution requirement dictated that all cash receipt be moved into GP via eConnect and custom scripting to “force” the EFT checkbox in the cash receipts entry window to be checked. See Figure 2.
Normally, if you try to check this box through the GP GUI, validation is performed to ensure the selected checkbook is set up for EFT, an EFT bank is present, an EFT file format is defined, and the customer is set up for EFT using the primary bill-to address. In this case, however, there were many customers in the client’s GP system that were not set up for EFT processing. When these cash receipt batches were posted, GP would proceed through the subledger work tables and create the GL batches, but then drop out of the process when it tried to create the EFT batch during the “ISV Processes” portion of the posting workflow, likely due to null values while trying to retrieve the associated customer EFT information. This left the system in a corrupted state and no attempt at batch recovery would be successful since some cash receipts were marked as EFT payment types even though the associated customers were not set up for EFT.
The solution
The solution was to clean up the corruption and then remove the EFT setting from those cash receipts with non-EFT customers. Recovering the batch at this point successfully posted the cash receipts without the dreaded journal printing interruption. To prevent this altogether, the cash receipt injection routines were hardened so that the EFT checkbook would only be marked if the cash receipt customer was set up for EFT processing and the cash receipt checkbook could handle EFT transactions. Processing has been smooth since those changes were made and the data cleanup was completed.
The moral of this story
If you come across the dreaded “journal printing interrupted” error during posting and the batches appear to be error-free in the batch edit lists, verify that the ancillary data elements for the transactions are valid. To do this, once the batch is recovered and is available for editing, open each transaction to ensure it can be accessed in GP without errors. If each transaction does open, it is a matter of time-consuming trial-and-error to find the bad data, and this can be accomplished by zooming into all drill-down (underlined) fields, checking/unchecking checkboxes, and opening all additional windows to see where/how/if GP presents any business logic errors.
As an alternative, enable SQL profiling during the posting process and note the last table accessed before GP drops out of posting and raises the error. Generally speaking, the last accessed table will be a clue into the routine that operated on bad data, and from there you can trace back to the transaction to get a root cause. In the example given, we found that the SY06000 table was accessed, which is the customer EFT setup table, and that allowed us to reach the conclusion that GP was attempting to access non-existent customer EFT information.
Finding the root cause is tricky and frustrating, so if you come across this error, immediately suspect and inspect any external data injection routines that create transactions in GP, or visit our support page and our team of experts can help solve the problem.
