FAPInJax

I was under the impression that the accrued benefit could not be reduced IF the reason for the reduction was SOLELY due to an increase in covered compensation. (I can not find the cite offhand)

I would ignore the zero salaries and use the most recent 5 year average.

The field that she wants is already in the RPTEEACCT table (I think). The field is INVPRODID (Investment product ID) which indicates the model. It can be linked backward to determine the English name of the model. The report just has to group data using this field I think. Does this help?

You can definitely use the new limits for funding a participant over 10 years away. The problem that may arise is that in 10 years the law says that everything reverts back to its prelaw status. For 415, that would mean that there is a 415 benefit that has been increased for 10 years establishing the new limit IF the law is not made permanent.

OK. It has also been experienced here. The symptom usually is that the user has too many applications open (using up the resources of the machine). That is why upon a reboot that the report runs OK.

Well, the general formula for a lump sum is as follows: (Nx / Dx) * Annual benefit The accepted approximation (used by most systems) for monthly lump sums is as follows: ((Nx / Dx) - 11/24) * Monthly benefit Is this what you are looking for????

The Duplicate field should work very well. Just go into the first participant and enter an allocation percentage and choose to update ALL participants with the same allocation percentage.

The answer is that at 6.0 with the most recent service pack the ADP/ACP test can be performed by divisions.

FASB 87 requires the computation of the 'average future lifetime' for a plan. A question has arisen, which I will try to use an example to clarify. 2 employees with future service of 30 and 0 (last one is at or beyond retirement age BUT still working so active). What is the average future lifetime??? (30 + 0)/2 = 15 30 / 1 = 30 Something else????

It sounds as though you already know the total number of shares that were purchased by totaling the individual pieces in the subsequent year. When settling the trade for the receivable just override the number of units and Quantech will take care of the balancing. This way the dollars will remain constant and the number of units will be correct. Alternatively, transfer the receivable money in pieces to the participant in pieces (this was permitted at release 5.0 I believe) with confirmation required and settle each one of the trades.

Version 7.0 will be part of the next release (scheduled for June) ------------------

There appears to be a LARGE misunderstanding. Corbel has NOT paid Crystal to do anything to it's software. Any modifications that appear in the functionality of Crystal are theirs alone. We are aware that other software also uses Crystal and users should be aware that there may be differences in version numbers.

Some comments regarding the Crystal conversion. It is strongly advised that all reports be set to the ODBC-CROR7 server type BEFORE going to QT 5.0. This is because QT 5.0 is strictly an Oracle application. It also makes the updating of the custom reports easier and could save time (depending on how adverse you are in Crystal). Documentation has been modified. It is no longer in paragraph format but steps. This should be much easier to read and follow. Conversion of reports will depend on the how adverse the user is with Crystal. Once the conversion is accomplished you WILL have to adjust your ODBC.ini and ODBCINST.ini files to reflect Oracle. Please feel free to call Report Writer support to assist you with this. (When you are in Crystal and try to set your reports to Oracle - you should get a prompt as to what source to use - IF you do NOT get this then your fields need to be changed!) Having a backup of your custom reports is ALWAYS advisable before conversion (for example, you may have too many report tables in your custom report and some may get lost, you may need to adjust the number of tables and possibly get rid of tables that are not actually being used - an example of the latter that we see all the time is the PLANDYN table) IF your tables showed SYSADMIN in front of the table name - it would have been there before converting! This happens based on Crystal settings. (Crystal can NOT change the type of table without being told what to do) Following all the steps should save you time in the long run BECAUSE you can do a few at at time and NOT have downtime at 4.1. Some tables and fields have been deleted. The documentation includes a list of these tables and fields. Therefore, you should be able to verify IF any reports have these tables or fields and adjust them when updating to the new version. The report conversion documentation will be available on the Quantech FTP site.