If refunds are not working properly, perform the following steps:
Verify that the refund tables are set up by using the View Refunds window. The fee code for the refund should be the same as the charge fee code.
If you see the refund details on the window, the refund definition exists. The definition displays in the top part of the window and is the same for each Refund table row. Check the refund definition and make sure it is correct. The setup will vary depending on how you want to do refunds.
Check the Refund table rows. You should have Refund Details set up for the same year and charge term that your Charge Detail uses. If you do not have refund detail rows for the year and charge term you are using, you will need to set them up. You can copy them from a previous term's table, copy them from the charge detail, or set them up yourself.
Once the Refund table is set up, refunds will work for future adjustments. For students who were to receive refunds during the period the Refund table was not set up, their accounts will need to be adjusted manually. The only exception is if this was the first time refunds should have occurred, you ran charges in batch, and have not posted the charges. In this situation, you should delete the CG group of transactions, restore the Fees table from the AR charges backup and re-run charges.
Once you have set up the refunds, they will work for future charge runs.
In this case the Refund definition was not present at the time charges were generated. The program cannot recalculate refunds for any that were missed in previous runs.
If most or all of the students have already been charged for this fee code(s), refunds will have to be handled manually for the remainder of the semester. If there still are a number of students who have not yet been charged, you should set up your Refund definition(s) and table(s). Of course, those refunds for students who have already been charged will have to be done manually.
Whether the Refund Detail exists or not, if you experience problems use Recovery Method D or Recovery Method E.
Use the View Refunds window. If you do not use the override percentages at the time of processing, the refunds amounts will be determined by the percentages found in the Refund details. If your refund percentage is blank, the system reads it as a zero percentage refund.
Note that if you have copied your refunds from the charge detail, the system will set them up without a percentage and without a usage code.
Use Recovery Method D or Recovery Method E to recover from this error.
Refund definitions, just like charge definitions, must have a usage code when you are looking for a range in a data column. Make sure that if you are looking for a range of values on your refund table, that you have an R , G , or E in the usage. You can check this using the View Refunds window. If you have copied your refund definition and tables from your charges definitions and tables, you must still put in the usage values for your refund tables.
Use Recovery Method D or Recovery Method E to resolve this error.
Whether you run charges in batch, by individual, or online from the Registration module, you have the ability to override the refund table percentages.
On the Student Charges window, if you select the Override refunds checkbox, and leave the Override Refund Percentage at 0.00, refunds are not generated. If you have just run charges in batch, you can delete the generated transactions (CG group), restore the Fees table from the backup and run charges again.
If you ran charges individually, or through Registration, any students who should have had a refund when the override was set to zero, will have to have their accounts adjusted manually.
Use Recovery Method D or Recovery Method E to resolve this error.
For refunds to work properly, the refund definition must be present and correct when you generate actual charges the first time for the term. You can determine if the refund definitions were set up at the time of the initial charges by using the View Fees window. If there is no data in any of the refund columns, then the refunds were not present at the time of the first charge run.
You can also research this by running an InfoMaker report on the Fees table. Your report should drive on the Fees table and your selection should be a sample student or set of students ID numbers. Select the year and charge term you are processing for charges and refunds. Your report should include the five refund element columns. If you find no data in the refund element columns, the refund definitions were not set up at the time charges were initially generated.
You can prepare for refund calculation on the next charges run by correctly filling in the charge definitions and details and immediately running batch charges. This will have the effect of filling in the refund columns on the Fees table so that subsequent charge runs can produce refunds. You will have to manually adjust students' accounts for the refunds already missed.
Use Recovery Method D or Recovery Method E to resolve this error.
If your refunds are going to the wrong account numbers, check the data in the refund details.
Make sure the Refund Detail rows have the correct income/expense account numbers. Remember, if you are using "*ALL " for your refund definition, you can only refund back to one income account number.
Use Recovery Method D or Recovery Method E to resolve this error.
Check to see that the refund element data on the refund table matches the refund elements in the fees table
Use the View Fees window or run an InfoMaker report on the Fees table and compare it to Refund table. The query should select the ID Numbers for some students who have not received a refund, and select the year and charge term you are currently running. Your report should include Refund Element 1 through Refund Element 10 from the Fees table.
Compare the Refund Element values on the Fees table against the Refund Element values in the Refund Details. If the data does not match, the values in your Refund Details need to be changed.
Use Recovery Method D or Recovery Method E to resolve this error.
The Transaction Status column on the Student Course History table stores the status code information.
A value of C indicates a current course enrollment, P indicates a preregistration, W indicates a wait-listed enrollment, H indicates a graded course, and D indicates a dropped course. You must determine which status codes are important to your billing requirements, and then include those codes in your hours definition and tables as well as charge definitions and tables for course type charges.
Use Recovery Method D or Recovery Method E to resolve this error.