Difference between revisions of "Information Systems:ACA - Auto Cash Application"
Jump to navigation
Jump to search
m |
m |
||
| 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.'' |
+ | ''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= |
=Known issues= |
||
Revision as of 16:19, 14 November 2016
Overview
From the 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.
Known issues
Accounting may report that they cannot run Auto Cash because 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). 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.
Lastly, if F14 doesn't bring up a dialog box, check your permissions (OMS Functional Authority).