Information Systems:ACA - Auto Cash Application - Revision history

Norwinu at 17:21, 3 October 2017

2017-10-03T17:21:59Z

Norwinu at 23:34, 14 November 2016

2016-11-14T23:34:58Z

Norwinu: /* Known issues */

2016-11-14T23:34:19Z

Known issues

Norwinu at 23:32, 14 November 2016

2016-11-14T23:32:20Z

Norwinu: /* Known issues */

2016-11-14T23:28:23Z

Known issues

Norwinu at 23:21, 14 November 2016

2016-11-14T23:21:24Z

Norwinu at 23:19, 14 November 2016

2016-11-14T23:19:17Z

Norwinu at 23:16, 14 November 2016

2016-11-14T23:16:05Z

Norwinu at 22:41, 14 November 2016

2016-11-14T22:41:23Z

Norwinu at 22:41, 14 November 2016

2016-11-14T22:41:04Z

@@ Line 1: / Line 1: @@
 =Overview=
 From the {{unc | \\superserver.unipharm.local\unity\S000- UNITY Project\P0300 - Phase III Implementation\P0399 - Technical Reference Materials\ | technical reference manuals}}:
@@ Line 6: / Line 7: @@
 =Known issues=
 Accounting may report that they cannot run Auto Cash and that the System Status field reads "AUTO CASH IS ACTIVE." This is because the application has a mechanism to lock itself if there's already an existing run. The way it does this is by checking a data area (i.e. basically, checks if a particular program field is blank or not). System glitches or prior, interrupted runs can cause the field to not be blanked, leading to this locked state.
@@ Line 11: / Line 13: @@
 Lastly, if F14 doesn't bring up a dialog box, check your permissions ([[Information_Systems:Extension_User_Security#Granting_functional_authorities|OMS Functional Authority]]).
 [[Category: Extensions]]

← Older revision		Revision as of 23:34, 14 November 2016
Line 13:		Line 13:

	[[Category: Extensions]]		[[Category: Extensions]]
		+	[[Category: Finance Problems (I.T.)]]

@@ Line 10: / Line 10: @@
 Fix this by using F14 (shift+F2) to reset the data area, but '''make sure with Accounting that there are no pending issues on their end'''. Basically, check that they're sure they didn't do anything strange prior to auto cash not working, because resetting a data area when in fact there is an open batch may lead to unprocessed transactions or orphaned entries.
-Lastly, if F14 doesn't bring up a dialog box, check your permissions (OMS Functional Authority).
+Lastly, if F14 doesn't bring up a dialog box, check your permissions ([[Information_Systems:Extension_User_Security#Granting_functional_authorities|OMS Functional Authority]]).
 [[Category: Extensions]]

@@ Line 6: / Line 6: @@
 =Known issues=
-Accounting may report that they cannot run Auto Cash and that the System Status field reads "AUTO CASH IS ACTIVE." This is because the application has a mechanism to lock itself if there's already an existing run. The way it does this is by checking for a data area (i.e. basically, checks if a particular program field is blank or not). System glitches can cause the field to not be blanked, leading to this locked state.
+Accounting may report that they cannot run Auto Cash and that the System Status field reads "AUTO CASH IS ACTIVE." This is because the application has a mechanism to lock itself if there's already an existing run. The way it does this is by checking a data area (i.e. basically, checks if a particular program field is blank or not). System glitches or prior, interrupted runs can cause the field to not be blanked, leading to this locked state.
 Fix this by using F14 (shift+F2) to reset the data area, but '''make sure with Accounting that there are no pending issues on their end'''. Basically, check that they're sure they didn't do anything strange prior to auto cash not working, because resetting a data area when in fact there is an open batch may lead to unprocessed transactions or orphaned entries.

@@ Line 8: / Line 8: @@
 Accounting may report that they cannot run Auto Cash and that the System Status field reads "AUTO CASH IS ACTIVE." This is because the application has a mechanism to lock itself if there's already an existing run. The way it does this is by checking for a data area (i.e. basically, checks if a particular program field is blank or not). System glitches can cause the field to not be blanked, leading to this locked state.
-Fix this by using F14 (shift+F2) to reset the data area, but '''make sure with Accounting that there are no pending issues on their end'''. Basically, check that they're sure they didn't do anything strange, because resetting a data area when in fact there is an open batch may lead to unprocessed transactions or orphaned entries.
+Fix this by using F14 (shift+F2) to reset the data area, but '''make sure with Accounting that there are no pending issues on their end'''. Basically, check that they're sure they didn't do anything strange prior to auto cash not working, because resetting a data area when in fact there is an open batch may lead to unprocessed transactions or orphaned entries.
 Lastly, if F14 doesn't bring up a dialog box, check your permissions (OMS Functional Authority).

@@ Line 3: / Line 3: @@
 From the {{unc | \\superserver.unipharm.local\unity\S000- UNITY Project\P0300 - Phase III Implementation\P0399 - Technical Reference Materials\ | technical reference manuals}}:
-''Auto cash application will be primarily a background process that will be scheduled to run early in the morning Tuesday to Saturday (after back ups have been run). This job will read through all accounts (marked as eligible for auto cash posting) and will generate vouchers for payments based on unapplied cash for the account. One voucher will be created for each day noting all of the cash that is being applied automatically for that customer. Initially, vouchers will be reviewed on the following business day and will be posted manually by A/R staff, as if they had been entered manually. Once there is confidence that the process is working properly, the voucher posting will be made automatically after it is generated. Each generated voucher will look as if it had been keyed by hand, but will have a particular voucher type for auto cash. The system will automatically keep a log of all runs and what has been posted on a particular auto cash posting run, in addition to the implicit logging which arises out of the vouchers themselves.''
+ ''Auto cash application will be primarily a background process that will be scheduled to run early in the morning Tuesday to Saturday (after back ups have been run). This job will read through all accounts  (marked as eligible for auto cash posting) and will generate vouchers for payments based on unapplied cash for the account. One voucher will be created for each day noting all of the cash that is being   applied automatically for that customer. Initially, vouchers will be reviewed on the following business day and will be posted manually by A/R staff, as if they had been entered manually. Once there is  confidence that the process is working properly, the voucher posting will be made automatically after it is generated. Each generated voucher will look as if it had been keyed by hand, but will have a  particular voucher type for auto cash. The system will automatically keep a log of all runs and what has been posted on a particular auto cash posting run, in addition to the implicit logging which arises out of the vouchers themselves.''
 =Known issues=

← Older revision		Revision as of 22:41, 14 November 2016
Line 3:		Line 3:
	From the {{unc \| \\superserver.unipharm.local\unity\S000- UNITY Project\P0300 - Phase III Implementation\P0399 - Technical Reference Materials\ \| technical reference manuals}}:		From the {{unc \| \\superserver.unipharm.local\unity\S000- UNITY Project\P0300 - Phase III Implementation\P0399 - Technical Reference Materials\ \| technical reference manuals}}:

		+	''Auto cash application will be primarily a background process that will be scheduled to run early in the morning Tuesday to Saturday (after back ups have been run). This job will read through all accounts (marked as eligible for auto cash posting) and will generate vouchers for payments based on unapplied cash for the account. One voucher will be created for each day noting all of the cash that is being applied automatically for that customer. Initially, vouchers will be reviewed on the following business day and will be posted manually by A/R staff, as if they had been entered manually. Once there is confidence that the process is working properly, the voucher posting will be made automatically after it is generated. Each generated voucher will look as if it had been keyed by hand, but will have a particular voucher type for auto cash. The system will automatically keep a log of all runs and what has been posted on a particular auto cash posting run, in addition to the implicit logging which arises out of the vouchers themselves. It is this feature that is addressed in this document.''
−	''Auto cash application will be primarily a background process that will be scheduled to run early in the morning Tuesday to Saturday (after back ups have been run).
−	This job will read through all accounts (marked as eligible for auto cash posting) and will generate vouchers for payments based on unapplied cash for the account. One voucher will be created for each day noting all of the cash that is being applied automatically for that customer.
−	Initially, vouchers will be reviewed on the following business day and will be posted manually by A/R staff, as if they had been entered manually. Once there is confidence that the process is working properly, the voucher posting will be made automatically after it is generated.
−	Each generated voucher will look as if it had been keyed by hand, but will have a particular voucher type for auto cash.
−	The system will automatically keep a log of all runs and what has been posted on a particular auto cash posting run, in addition to the implicit logging which arises out of the vouchers themselves. It is this feature that is addressed in this document.''

	=Known issues=		=Known issues=