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. 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. 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. 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. The batch edit lists were always clean, but posting repeatedly dropped the batch in the recovery loop. 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. Or, some other data element required for third-party posting processes to complete.Invalid customer addresses for receivables batches.Invalid inventory item types for items present in Inventory subledger batches. 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. 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. 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. Subledger Work Transactions > General Ledger Batches > ISV Processes > Table Cleanup > Posting Journals. How GP posts transactions varies among the various modules, but the process can be broken down and simplified as follows: Additionally, the sub ledger transactions could now be in both the work and open tables, further complicating matters. 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. 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. 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. 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. 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |