Information Systems:Balance Month End Reports - Revision history

Norwinu at 17:20, 15 July 2016

2016-07-15T17:20:49Z

Norwinu at 16:13, 29 June 2016

2016-06-29T16:13:38Z

Norwinu at 16:10, 29 June 2016

2016-06-29T16:10:49Z

New page

=Overview=
The month end process (job schedule entry ENDOFMONTH) generates eleven reports; three of which should be checked to make sure things are in balance.

==Balance A/R Reconciliation List==
The first FSR297P in the month end reports checks to make sure the Analyser entries for A/R transactions balance to the Analyser entries for the G/L account.

*VA/480B* A/R RECONCILIATION LIST
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
A/R AMOUNT A/R AMOUNT G/L AMOUNT G/L AMOUNT G/L AMOUNT DIFFERENCE
Main Grou Subg Temp intrupt(a) Balance amt (b) Temp intrupt(c) Balance amt (d) Journal Maint(e) Diff (a+b)-(c+d+e))
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
120000 6,553,021.93 6,553,021.93
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Grand total 6,553,021.93 6,553,021.93

If these totals do not agree, the Analyser totals for A/R will have to be rebuilt. The first thing is to find the earliest accounting period that is out of balance. You will have to run this report for each period until you find the last one that balances. (You must rerun the lists; you cannot just look at ones generated at each month end; the finance department can post entries to previous periods.) To to this, key in GO RECON and press enter. Select the option 'Print A/R reconciliation list'. Key in the accounting period, and press enter.

When you identify the first period that is out of balance, [[Information Systems:Analyser Problems#Rebuild|rebuild the Analyser balances]].

==Balance A/P Reconciliation List==
The second FSR297P in the month end reports checks to make sure the Analyser entries for A/P transactions balance to the Analyser entries for the G/L accounts. In this case, we are out by 4 cents; interestingly enough, it is a US exchange issue with an old IBS invoice.

*VA/480B* A/P RECONCILIATION LIST
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
A/R AMOUNT A/R AMOUNT G/L AMOUNT G/L AMOUNT G/L AMOUNT DIFFERENCE
Main Grou Subg Temp intrupt(a) Balance amt (b) Temp intrupt(c) Balance amt (d) Journal Maint(e) Diff (a+b)-(c+d+e))
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
210000 6,601,215.09- 6,601,215.09-
210025 1,354,314,64- 1,354,314.60- 0.04-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Grand total 7,955,529.73- 7,955,529.69- 0.04-

If these totals do not agree, the Analyser totals for A/P will have to be rebuilt. The first thing is to find the earliest accounting period that is out of balance. You will have to run this report for each period until you find the last one that balances. (You must rerun the lists; you cannot just look at ones generated at each month end; the finance department can post entries to previous periods.) To to this, key in GO RECON and press enter. Select the option 'Print A/P reconciliation list'. Key in the accounting period, and press enter.

When you identify the first period that is out of balance, [[Information Systems:Analyser Problems#Rebuild|rebuild the Analyser balances]].

* [[Balance Unmatched PO's]]

Sheilav: Replaced content with "The month end process (job schedule entry ENDOFMONTH) generates eleven reports; three of which should be checked to make sure things are in balance. * Balance A/R Recon..."

2015-11-30T18:18:41Z

Replaced content with "The month end process (job schedule entry ENDOFMONTH) generates eleven reports; three of which should be checked to make sure things are in balance. * Balance A/R Recon..."

Sheilav at 17:10, 30 November 2015

2015-11-30T17:10:27Z

Sheilav at 23:33, 2 November 2015

2015-11-02T23:33:19Z

Sheilav at 23:32, 2 November 2015

2015-11-02T23:32:21Z

Sheilav at 23:30, 2 November 2015

2015-11-02T23:30:34Z

Sheilav at 23:30, 2 November 2015

2015-11-02T23:30:00Z

Sheilav at 20:29, 2 November 2015

2015-11-02T20:29:37Z

@@ Line 60: / Line 60: @@
 ===In InfoNet===
-[[File:unmatPO-3.jpg]]
+[[File:UnmatPO-3.jpg]]
 This shows
@@ Line 76: / Line 76: @@
 Some difference here are okay.  The [[Generated Journal Entries|journal entries]] for manual orders (MO) are set up to both debit and credit 210050 when they are received, and again when they are invoiced.  Therefore the G/L balance will always be zero; no matter what is in uninvoiced receipts (SROGRT).
-[[File:unmatPO-1.jpg]]
+[[File:UnmatPO-1.jpg]]
 Click on 'Summary to Excel' to see the total by purchase order numbers.
@@ Line 82: / Line 82: @@
 ===Export to Excel===
-[[File:unmatPO-2.jpg]]
+[[File:UnmatPO-2.jpg]]
 Line 5 shows that PO 8195055 has been received, but not invoiced.  The other lines show rounding errors.  As these net out to zero, you don't really have to do anything with them - but they will stay on this inquiry for two fiscal years.  They can be removed by doing an adjustment, with the PO number in the text field.  Next month the PO will net out to zero, so will be ignored.

← Older revision		Revision as of 16:13, 29 June 2016
Line 36:		Line 36:
	When you identify the first period that is out of balance, [[Information Systems:Analyser Problems#Rebuild\|rebuild the Analyser balances]].		When you identify the first period that is out of balance, [[Information Systems:Analyser Problems#Rebuild\|rebuild the Analyser balances]].

−	* [[Balance Unmatched PO's]]	+	==Balance Unmatched PO's==
		+	The first (and largest) query month-end report (file name QPQUPRFIL) gives the detail of unmatched receiving (remaining amounts on file SROGRT). The totals of the order types should match the G/L balances. You should look up the G/L balances as soon as possible, as the accounting department can back date entries to the previous period.
		+
		+	'''Order Type amount G/L balance difference'''
		+	MO manual order 1,140.00 210050 0.00 1,140.00
		+	RT return to vendor 170.00 210300 170.00-
		+	CS car stock 0.00 210500 0.00
		+	BE price variance-charge to H/O 0.00
		+	PV price variance-charge to rep 0.00
		+	QV quantity variance 3,616.79-
		+	total 3,616.79- 210623 2,521.14 1,095.65-
		+	PE EDI purchase order 693,407.41
		+	PO regular purchase order 1,005,743.82
		+	RO rush order 0.00
		+	XF reference purchase order 8,949.45
		+	total 1,708,100.68 220000 1,708,100.91- 0.23-
		+	RE receiving error .00 220050 .00
		+
		+	===Month-end===
		+
		+	A part of the month-end process is to reconcile G/L transactions to the uninvoiced receipts. (See program BAL001CL.) Every G/L transaction is scrutinized, and the PO number(s) it refers to, and was matched with, is(are) found. All PO transactions that net out to zero, or that balance to uninvoiced receipts, are removed. The remaining transactions are shown in 'Out of Balance Unmatched POs' in InfoNet (Under uniVIEW / Finance).
		+
		+	===In InfoNet===
		+
		+	[[File:unmatPO-3.jpg]]
		+
		+	This shows
		+
		+	- Total G/L transactions from file SROLOGGL that could not be net to zero, or balanced
		+
		+	- Total uninvoice receipts from file SROGRT that could not be balanced
		+
		+	- Total unposted batches from file SROTRAA that could not be balanced
		+
		+	- Total unposted journals from file SROOVF ([[Journal in Error\|journal in error]]) that could not be balanced
		+
		+	'Balanced' means that the total of the G/L transaction in SROLOGGL, SROTRAA, and SROOVF for matched PO's either net to zero, or agree with the remaining amounts for SROGRT.
		+
		+	Some difference here are okay. The [[Generated Journal Entries\|journal entries]] for manual orders (MO) are set up to both debit and credit 210050 when they are received, and again when they are invoiced. Therefore the G/L balance will always be zero; no matter what is in uninvoiced receipts (SROGRT).
		+
		+	[[File:unmatPO-1.jpg]]
		+
		+	Click on 'Summary to Excel' to see the total by purchase order numbers.
		+
		+	===Export to Excel===
		+
		+	[[File:unmatPO-2.jpg]]
		+
		+	Line 5 shows that PO 8195055 has been received, but not invoiced. The other lines show rounding errors. As these net out to zero, you don't really have to do anything with them - but they will stay on this inquiry for two fiscal years. They can be removed by doing an adjustment, with the PO number in the text field. Next month the PO will net out to zero, so will be ignored.
		+
		+	===Technical===
		+
		+	As part of the month end, '''BAL001CL''' is run, which extracts all G/L entries for accounts -
		+
		+	210050 (AP - clearing (manual orders))
		+
		+	210300 (AP returns debit adj (2052))
		+
		+	210500 (AP car stock (2055))
		+
		+	210625 (AP costing debit note clearing)
		+
		+	220000 (AP PO matching clearing)
		+
		+	220050 (AP Non-PO matching clearing)
		+
		+	This includes all records; right from conversion - which as of November 2015 was three and a half million.
		+
		+	For some transactions, the document number is the PO number; but not all - so the program '''BAL001R''' tries to figure it out.
		+
		+	- The text on some generated transactions is vendor number, seven spaces, then the PO number.
		+
		+	- Some transactions have text that is the vendor invoice number then vendor name. The invoice number can be used to get the PO number from the A/P transaction files.
		+
		+	- If none of the above, the program searches the text for a seven digit number starting with '8'.
		+
		+	Hint - this process will work much more efficiently if finance ensures that every transaction entered conforms to one of these.
		+
		+	If all the transactions for a PO for the same G/L number add up to zero, '''BAL002R''' will delete them.
		+
		+	'''BAL005R''' will delete offsetting amounts for the same G/L number and PO - but only if there are not uneven multiples. For example, if there is a single 5.00, and a single -5.00 they will be deleted. If there are three 5.00 and three -5.00 they will be deleted. If there is one 5.00 and two -5.00 they will not be deleted.
		+
		+	If all transactions for PO's that were matched together add up to zero, they are deleted in '''BAL008R'''.
		+
		+	Transactions for PO's that agree with uninvoiced receipts are deleted in '''BAL009R'''.
		+
		+	PO's that were in process as of conversion will never balance; therefore '''BAL010R''' will delete them from the transactions.
		+
		+	When an adjustment is made to balance the account, it can not be applied against each PO or vendor that is out of balance, so they will all still be in the transaction file. If, after two fiscal years, the account balances to zero, all transactions will be deleted. '''BAL017R''' is run for each G/L account number. It will -
		+
		+	- Delete all transactions for period 201412 and earlier, as we know the account is in balance.
		+
		+	- If all transactions two fiscal years old or older add up to zero, delete them. If they don't add up to zero, work backwards to find a period end at which they did, then delete them. This shouldn't be a problem, as the account should be balanced at every year end.
		+
		+	===Reasons for Being Out of Balance===
		+
		+	Manual Orders are configured to debit and credit account 210050 both when they are received, and when they are invoiced. This means that the total of the transactions, posted and unposted, should always add up to zero. Between receiving time and invoicing time, there will be a value in 'received not invoiced'; but that is not a problem.
		+
		+	Account 210625 can be out of balance if finance matches a debit note with a PO before the adjustment PO has been closed.

@@ Line 1: / Line 1: @@
 The month end process (job schedule entry ENDOFMONTH) generates eleven reports; three of which should be checked to make sure things are in balance.
 * [[Balance A/R Reconciliation List]]
 * [[Balance A/P Reconciliation List]]
 * [[Balance Unmatched PO's]]

← Older revision		Revision as of 17:10, 30 November 2015
Line 2:		Line 2:

	The first FSR297P checks to make sure the Analyser entries for A/R transactions balance to the Analyser entries for the G/L account.		The first FSR297P checks to make sure the Analyser entries for A/R transactions balance to the Analyser entries for the G/L account.
		+
		+	* [[Balance A/R Reconciliation List]]
		+	* [[Balance A/P Reconciliation List]]
		+	* [[Balance Unmatched PO's]]
		+

	VA/480B A/R RECONCILIATION LIST		VA/480B A/R RECONCILIATION LIST

@@ Line 44: / Line 44: @@
 Some difference here are okay.  The [[Generated Journal Entries|journal entries]] for manual orders (MO) are set up to both debit and credit 210050 when they are received, and again when they are invoiced.  Therefore the G/L balance will always be zero.
-Use [[Query]] on file SROTRAC (Entry pgm work file, G/L transactions) to look for transactions that have updated SROGRT (Goods reception transactions) but not the G/L file.
+Use [[QUERY|Query]] on file SROTRAC (Entry pgm work file, G/L transactions) to look for transactions that have updated SROGRT (Goods reception transactions) but not the G/L file.
 There could be a [[Journal in Error|journal in error]], which again would have updated SROGRT but not the G/L file.

← Older revision		Revision as of 23:30, 2 November 2015
Line 46:		Line 46:
	There can be transactions in file SROTRAC (Entry pgm work file, G/L transactions) that have updated SROGRT (Goods reception transactions) but not the G/L file.		There can be transactions in file SROTRAC (Entry pgm work file, G/L transactions) that have updated SROGRT (Goods reception transactions) but not the G/L file.

−	There could be a [[journal in error]], which again would have updated SROGRT but not the G/L file.	+	There could be a [[Journal in Error\|journal in error]], which again would have updated SROGRT but not the G/L file.

← Older revision		Revision as of 23:30, 2 November 2015
Line 42:		Line 42:
	RE receiving error 764.44- 220050 764.44		RE receiving error 764.44- 220050 764.44

−	Some difference here are okay. The [[Generated Journal Entries\|journal entries]] for manual orders (MO) are set up to both debit and credit 210050 when they are received, and when they are invoiced.	+	Some difference here are okay. The [[Generated Journal Entries\|journal entries]] for manual orders (MO) are set up to both debit and credit 210050 when they are received, and again when they are invoiced. Therefore the G/L balance will always be zero.
		+
		+	There can be transactions in file SROTRAC (Entry pgm work file, G/L transactions) that have updated SROGRT (Goods reception transactions) but not the G/L file.
		+
		+	There could be a [[journal in error]], which again would have updated SROGRT but not the G/L file.

@@ Line 25: / Line 25: @@
  Grand total                      7,955,529.73-                   7,955,529.69-                                0.04-
-The first (and largest) query report (file name QPQUPRFIL) gives the detail of unmatched receiving (remaining amounts on file SROGRT).  The totals of the order types should match the G/L balances.
+The first (and largest) query report (file name QPQUPRFIL) gives the detail of unmatched receiving (remaining amounts on file SROGRT).  The totals of the order types should match the G/L balances.  You should look up the G/L balances as soon as possible, as the accounting department can back date entries to the previous period.
  '''Order Type'''                           '''amount'''        '''G/L'''          '''balance'''    '''difference'''