Information Systems:Cannot Close Period - Revision history

Norwinu at 23:10, 3 October 2016

2016-10-03T23:10:13Z

Darrenf at 16:34, 19 July 2016

2016-07-19T16:34:54Z

New page

During the overnight month end process, the current (open) accounting period is rolled to the next one. The previous period stays open so that the finance department can continue to do entries to it. When they are finished, the previous period is closed to prevents any changes to accounting periods that have been finalized. If it it necessary to an entry to a closed period, it can be opened then closed again.

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.

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|Query]] to print them first, so Nancy can reenter them if necessary.

Use [[Information Systems: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.

Darren uses the saved SQL query called "Nancy-cannot-close-period.sql". Change the orange number at the end of the statement to whatever the period it is that needs editing. It should show a series of records, hopefully not too many. Look for the column that has AMX, VIS, MC which are credit cards. Check with Nancy that these records can be deleted. If yes then change the SQL statement to delete from up1480bfva.sroovf where ovperi = 'periodnumber' and then run that. The number of records deleted should be the same as the number originally shown in the select statement.

==Todo==
* Blurb on calendar year
* Add SROTRAC
* Explanation of files

Norwinu: Text replacement - "DFU" to "Information Systems:DFU"

2016-06-17T22:23:00Z

Text replacement - "DFU" to "Information Systems:DFU"

172.30.19.122 at 17:39, 18 November 2015

2015-11-18T17:39:52Z

Sheilav at 17:17, 18 November 2015

2015-11-18T17:17:48Z

Sheilav at 17:17, 18 November 2015

2015-11-18T17:17:20Z

Sheilav at 00:36, 18 November 2015

2015-11-18T00:36:38Z

Sheilav at 00:18, 18 November 2015

2015-11-18T00:18:29Z

Sheilav at 00:11, 18 November 2015

2015-11-18T00:11:10Z

Sheilav at 00:09, 18 November 2015

2015-11-18T00:09:54Z

← Older revision		Revision as of 23:10, 3 October 2016
Line 21:		Line 21:
	* Add SROTRAC		* Add SROTRAC
	* Explanation of files		* Explanation of files
		+
		+	[[Category: Finance Problems (I.T.)]]

@@ Line 7: / Line 7: @@
 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.
+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|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.

← Older revision		Revision as of 17:17, 18 November 2015
Line 1:		Line 1:
		+	During the overnight month end process, the current (open) accounting period is rolled to the next one. The previous period stays open so that the finance department can continue to do entries to it. When they are finished, the previous period is closed to prevents any changes to accounting periods that have been finalized. If it it necessary to an entry to a closed period, it can be opened then closed again.
		+
	An accounting period cannot be closed if there are outstanding transactions that have not yet been posted.		An accounting period cannot be closed if there are outstanding transactions that have not yet been posted.

← Older revision		Revision as of 00:18, 18 November 2015
Line 1:		Line 1:
−	A period cannot be closed if there are outstanding transactions that have not yet been posted~~. If an update does not complete properly, sometimes orphaned transactions are left behind~~.	+	A 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.
		+
		+	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.
		+
		+
		+
		+

⚫	Use [[QUERY]] to look at files SROBTR (Accounting transactions created in ASW-DIS) and SROOVF (G/L Input transactions).

	For example, we have a 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.		For example, we have a 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.

@@ Line 1: / Line 1: @@
-A period cannot be closed if there are outstanding transactions that have not yet been posted.
+A period cannot be closed if there are outstanding transactions that have not yet been posted.  If an update does not complete properly, sometimes orphaned transactions are left behind.
-Use [[Query]] to look at files SROBTR (Accounting transactions created in ASW-DIS) and SROOVF (G/L Input transactions).  If an update does not complete properly, sometimes orphaned transactions are left behind.
+Use [[QUERY]] to look at files SROBTR (Accounting transactions created in ASW-DIS) and SROOVF (G/L Input transactions).
 For example, we have a 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.

@@ Line 9: / Line 9: @@
 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|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.
+Use [[Information Systems: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.

← Older revision		Revision as of 17:39, 18 November 2015
Line 14:		Line 14:

	* 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.		* 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.
		+
		+	==Todo==
		+	* Blurb on calendar year
		+	* Add SROTRAC
		+	* Explanation of files