Difference between revisions of "Information Systems:Cannot Close Period"
| Line 1: | Line 1: | ||
| − | + | An accounting period cannot be closed if there are outstanding transactions that have not yet been posted. |
|
Use [[QUERY|Query]] to look at files SROBTR (Accounting transactions created in ASW-DIS) and SROOVF (G/L Input transactions). Look for any transaction for the accounting period that will not close. The field is INPERI in file SROBTR, and OVPERI in SROOVF. |
Use [[QUERY|Query]] to look at files SROBTR (Accounting transactions created in ASW-DIS) and SROOVF (G/L Input transactions). Look for any transaction for the accounting period that will not close. The field is INPERI in file SROBTR, and OVPERI in SROOVF. |
||
| − | These transactions can be because someone in Finance back dated a transaction |
+ | These transactions can be because someone in Finance back dated a transaction, or that an update did not complete properly and left behind orphaned transactions. |
| + | Records in SROBTR will post over night. Some records in SROOVF will post when the user closes the batch. Any transaction with old dates (the orphaned ones) will have to be manually deleted. Use [[QUERT|Query]] to print them first, so Nancy can reenter them if necessary. |
||
| + | Use [[DFU]] on file SR1OVF in library UP1480BFVA to delete records for the old accounting period. |
||
| ⚫ | |||
| ⚫ | |||
| − | |||
| − | |||
| ⚫ | |||
| − | |||
| − | * I can see only one place where this could be happening, but I haven’t figured out why. BERUP075 (BED -- Post A/R payment G/L corrections to ASW) calls GCFC851 (Interface accounting transfer), which calls GCFR851 (Interface accounting transaction transfer). If field &GRIW is returned as blank, FMC050 (G/L update transactions and balances) is not run. |
||
| − | |||
| ⚫ | |||
Revision as of 17:36, 17 November 2015
An accounting period cannot be closed if there are outstanding transactions that have not yet been posted.
Use Query to look at files SROBTR (Accounting transactions created in ASW-DIS) and SROOVF (G/L Input transactions). Look for any transaction for the accounting period that will not close. The field is INPERI in file SROBTR, and OVPERI in SROOVF.
These transactions can be because someone in Finance back dated a transaction, or that an update did not complete properly and left behind orphaned transactions.
Records in SROBTR will post over night. Some records in SROOVF will post when the user closes the batch. Any transaction with old dates (the orphaned ones) will have to be manually deleted. Use Query to print them first, so Nancy can reenter them if necessary.
Use DFU on file SR1OVF in library UP1480BFVA to delete records for the old accounting period.
One of the reasons for these orphans is our custom system to receive transactions from the bank and post them to the store’s accounts receivable (see Bank EDI). Sometimes this leaves transactions in SROOVF. We can’t do anything but manually delete them, and do a journal entry.
- Nancy seems to have found the problem and a solution. In 2005, we changed the job queue QBATCH to run two jobs at a time instead of one. If Nancy waits until one card type (Visa, Master Card, etc) completes before starting the next, the problem doesn’t seem to happen.