|
|
|
|
|
|
|
|
| Cashwise Impact Assessment |
|
|
|
| 3.7 Service Pack 3 (Build 3.7.7437.*) |
|
|
|
| Note: Because this report is grouped by feature, projects associated with multiple features may appear more than once. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixed a problem that resulted in ACH payments initiated from ACH collateral deposits or ACH
installment loan payments that subsequently returned incorrectly attempting to return a
collection payment when encountered in an ACH return file. |
|
|
|
|
|
|
|
|
|
Modified the ACH Return processing code so that ACH Installment Loan Payments and ACH
Deposits now get an 'LT' discretionary data code and are converted into debts when processed
by the ACH Return subsystem. ACH Installment Loan Payments that are returned are
converted to a debt and the balance of the loan is also transferred to the newly created debt. |
|
|
|
|
Issue a Cash Advance that has ACH setup for collateral.Issue an Installment Loan that is setup
for ACH Auto Pay.Roll forward to and then from the Due Date of the Cash Advance so that the
collateral will deposit.Also roll forward to a date that will cause the first payment for the
Installment Loan to be made.Now create the ACH file (see documentation if necessary) and add
the transactions that corresponds to the deposit and the Installment Loan payment to the ACH
file batch.Get an ACH Return file that includes those transactions.Import that return file and
verify that the transactions both have an 'LT' Discretionary Data code.Process the records and
verify that the debts are created for the correct amounts and that the corresponding cash
advances both have AmountDue = $0.00 |
|
|
|
|
|
|
|
|
|
|
|
|
Fixed error message "Access violation at address 0043DCB9 in module 'vcl90.bpl'. Read of
address 00000028." when using a TWAIN capture device. |
|
|
|
|
|
|
|
|
|
Fixed TWAIN capture. The ConvertDIBToBitmap was not functioning properly. Added
bitmap palette support as well. |
|
|
|
|
| Capture an image using a device type of "TWA" for TWAIN capture. |
|
|
|
|
|
| Cash Advance DPT Integration |
|
|
|
|
|
|
|
Added the DPT Deferred Presentment Tracking (Veritech) report event. This event is fired
whenever an action is performed for a Loan Type that is configured to use DPT Tracking. |
|
|
|
|
|
|
|
|
|
The logic that creates Deferred Presentment Actions that are sent to Veritech to validate Cash
Advance Transactions has been updated to call the DPT report event. |
|
|
|
|
Configure a loan type to use DPT Tracking. Associate a 'REP' - Report, report event step with
the DPT report event. Issue a new loan of the type mentioned above and verify that the report
event is firing. |
|
|
|
|
|
|
Added a step to the Veritec DPT integration that will display a message when a Check
Eligibility action is successful and the Response Other field is not empty. |
|
|
|
|
|
|
|
|
|
The Veritec DPT integration for Cash Advance loan approval was updated to provide this
behavior. |
|
|
|
|
| Verify that the message only displays if there is a value in the Response Other field. |
|
|
|
|
|
|
|
|
|
|
|
|
| Removed the AccuredateFollowAgreementDate setting. |
|
|
|
|
|
|
|
|
|
Removed the AccruedDateFollowsAgreementDate setting. In place of this setting we now
prevent fees from being prorated or charged when doing an extension before or after the due
date while having EarlyExtendFromTermDate or LateExtendFromTermDate checked. |
|
|
|
|
Check Prorate and Charge Late under fee setup.Check EarlyExtendFromTermDate and
LateExtendFromTermDate under the extension setup.Perform an extension on a loan of this
type before the due date and after the due date. The fees should remain the same regardless of
the day the transaction takes place on. |
|
|
|
|
|
|
Introduced the ability to calculate single-payment cash advance rate-based fees based on the
total amount due of the cash advance, rather than the principal advanced. This feature is
available as a new calculation method in the Single Payment Cash Advance Fee Type setup. |
|
|
|
|
|
|
|
|
|
Added the Fixed On Amount Due calculation method in the cash advance single-payment
engine. |
|
|
|
|
Configure a Single-Payment Cash Advance Type to use the Fixed On Amount Due calculation
method and verify that the fees are calculated based on the amount due of the loan, rather than
the principal. |
|
|
|
|
|
|
The collateral entry behavior for an extension of a single-payment cash advance is now
consistent with the collateral entry behavior for a new cash advance. |
|
|
|
|
|
|
|
|
|
Modified the behavior of the collateral list so that when doing an extension on a Cash Advance,
if the collateral entered does not satisfy the Collateral Value Protocol the list will not
automatically close so that the user has the opportunity to manage the collateral for the loan and
add more if necessary. |
|
|
|
|
For a Cash Advance loan that is configured to replace collateral perform an extension. When
promted to enter a piece of collateral enter an amount for that collateral that will not satisfy the
collateral value protocol (most common would be to enter an amount less than the loan
amount), when you save that piece of collateral the Collateral List should still be open giving
the opportunity to add more collateral. |
|
|
|
|
|
|
Payment amount can now be overridden when doing an extension on a single-payment cash
advance that is configured to settle fees and the loan had previously had a fee override of $0
applied. |
|
|
|
|
|
|
|
|
|
| Update logic for the single-payment extension transaction was updated to address this issue. |
|
|
|
|
Configure a single payment loan type to Allow Paydown on extensions and to Settle Fees. Issue
a loan of that type and override the fees setting them to $0. On the due date, extend that loan
and verify that the payment amount can be increased in an attempt to pay extra. |
|
|
|
|
|
|
| Collateral can now be deleted when processing a cash advance. |
|
|
|
|
|
|
|
|
|
| You can now delete collateral during the creation of a loan. |
|
|
|
|
Verify that collateral can be deleted after it has been added within the same transaction.Verify
that collateral cannot be deleted if it was not added as part of the current transaction. |
|
|
|
|
|
|
| Refund transactions can now be performed historically through the Cash Advance Manager. |
|
|
|
|
|
|
|
|
|
Added the Refund transaction to the list of historical transactions available in the Cash Advance
Manager. |
|
|
|
|
| Attempt to do a historical refund transaction through the Cash Advance Manager. |
|
|
|
|
|
|
|
|
|
|
|
|
Fixed the error Invalid object name 'Customer' when using Force Customer in the Cashiers
Check module. |
|
|
|
|
|
|
|
|
|
When the Cashiers Check module is configured to 'Force Customer' the system was attempting
to retrieve the Name for the customer from the Customer table. This table no longer exists and
so an 'Invalid Object Name 'Customer' error would be thrown. The Customer table no longer
exists in v37+ and so the Name is now retrieved from the Contact table. |
|
|
|
|
Configure Cashiers Check to 'Force Customer' by going to Setup > Sales > Modules Edit the
Cashiers Check record and check the 'Force Customer' option.Then process a Cashiers check
for a customer and verify that processing can be completed successfully. |
|
|
|
|
|
|
|
|
|
|
|
|
Fixed error "Access Violation at Address 04D1F757 in module 'Contact.bpl'. Read of address
00000000" when attempting to clear Contact Addresses. |
|
|
|
|
|
|
|
|
|
| Correct the Access Violation error when clearing the primary address of a Customer |
|
|
|
|
| Edit a customer with a primary address. Open the Address Lookup box and press 'Clear.' |
|
|
|
|
|
|
|
|
|
|
|
|
Made several performance improvements to Cashwise, including OFAC point-of-sale checking
and Hardware Service Provider polling performance. |
|
|
|
|
|
|
|
|
|
Optimized the OFACCheckLastName procedure so that there is now less overhead associated
with calling the procedure.Also added an index on the MoneyOrderRequestMoneyOrder table
on (Request_ID, MoneyOrder_ID) to help optimize the query used by the Hardware Service
Provider (HSP) that checks for Money Order requests |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fees are now applied to debts for a debtor when making a debtor payment via point of sale so
that the recommended payment includes all fees up through the current day. Prior to this the
current day fees were still showing as outstanding after the payment was made due to the fact
that they had not been applied prior to the payoff. |
|
|
|
|
|
|
|
|
|
Fees are now applied to debts for a debtor when making a debtor payment via point of sale so
that the recommended payment includes all fees up thru the current day. This change was made
to resolve an issue with fees being applied after the payment was made and the debts remaining
open with an amount equal to the amout of fees that weren't applied prior to the payment. |
|
|
|
|
Create a Debt that has recurring fees. Roll forward to a point where the fees should be applied.
Do a payment for the debt via point of sale and verify that the recommended payment amount
includes all fees up thru the current day and that making that payment results in the debt being
closed. |
|
|
|
|
|
|
| Improved the performance of several of the processing steps that occur as part of rollforward. |
|
|
|
|
|
|
|
|
|
| Changed several rollforward processing procedures to improve performance. |
|
|
|
|
| Verify that rollforward can be still be performed effectively. |
|
|
|
|
|
|
| The RowGUID column has been removed from the Working Debtor Browse. |
|
|
|
|
|
|
|
|
|
| Removed the RowGUID field from the Working Debtors screen. |
|
|
|
|
Cashwise Main Form > Collections menu > Working Debtors... > verify that the RowGUID
field is not longer displayed as part of the Debtor records. |
|
|
|
|
|
|
Modified the system to disallow the modification of Filing Costs for existing suits in the
Collector. |
|
|
|
|
|
|
|
|
|
| Changed the suit edit user-interfaces in the Debt Collector. |
|
|
|
|
In the Collector, work a debtor. On the legal tab, file a suit and enter in the Filing Cost. Save
and close that suit. Now, edit that suit and attempt to change the filing cost. You should get an
error saying the Filing Costs cannot be modified. |
|
|
|
|
|
|
| Fixed a defect where only the first report was created for a collection plan with multiple reports. |
|
|
|
|
|
|
|
|
|
Collection plans configured to schedule multiple reports when applied, now apply all reports
rather than just the first report. |
|
|
|
|
Configure a Collection Plan to apply multiple reports. Create a debt of a type that is configured
to apply the collection plan. Verify that all reports for the collection plan were scheduled for the
new debt. |
|
|
|
|
|
|
| Fixed defect where the user could not edit debt charges when creating a debt. |
|
|
|
|
|
|
|
|
|
Modified the system so that the Amount of charges applied to debts can now be overridden by
the user. |
|
|
|
|
Configure a debt type selection that has a charge that uses a Fee Type for calculation. Create a
new debt of that type. Verify that the amount of the charge that is applied can be overridden. |
|
|
|
|
|
|
| Fixed a defect where the user could not create a debt from a loan that had a negative balance. |
|
|
|
|
|
|
|
|
|
Modified the DeferredDebt processing logic Debts can be created and amounts transferred from
Loans with pending negative balances. |
|
|
|
|
Create a Single-Payment loan. Make a payment on the loan.Deposit the collateral for the full
amount, thus creating the negative amount. Create a new deferred debt and transfer the balance
from the loan. |
|
|
|
|
|
|
Fixed a problem that resulted in rate-based charges configured for a debt type would always
calculate a $0.00 charge. |
|
|
|
|
|
|
|
|
|
Fixed an issue with Debt Charges that were configured to use a Rate based Fee Type. Using
this configuration would result in Charges for $0.00 every time. This is corrected and updating
a new debt proposal should result in a charge being calculated based on the new principal after
the modification. |
|
|
|
|
Setup a Charge that uses a Rate-based Fee Type on a Debt Type. Create a debt of that debt type
and verify that the correct amount is calculated and applied for that charge. |
|
|
|
|
|
|
Fixed a problem that resulted in debtor letters for debtors with multiple debts printing for all
debts, instead of the selected debts for the task. |
|
|
|
|
|
|
|
|
|
DebtorLetter report query was not limiting by individual debts. When some of the debts were
left unselected, they were still included in the letter. |
|
|
|
|
Verify that scheduling a debtor letter for a debtor with multiple debts, and only selecting one of
the debts in the scheduled letter functions as expected. |
|
|
|
|
|
|
Loan Date and Loan Default Date on the Recurring Fees tab for a debt now have the correct
date rather than the "zero date" of 12/30/****. |
|
|
|
|
|
|
|
|
|
| Changed the logic for adding recurring fees to a debt. |
|
|
|
|
View any debt that has a Recurring Fee associated with it and verify that the Loan Date field
and the Loan Default Fee fields are correct. |
|
|
|
|
|
|
Fixed error "Maximum stored procedure, function, trigger, or view nesting level exceeded
(limit 32)" generated when trying to use ro remove action for debtors pools. |
|
|
|
|
|
|
|
|
|
| Fixed the debtor pool OnRemove action. |
|
|
|
|
Add an OnRemove action to a debtor pool. When a debtor is removed from the pool have the
debtor move to another pool. |
|
|
|
|
|
|
| Significantly improved the performance of debtor letter printing. |
|
|
|
|
|
|
|
|
|
| Changed the WorkReportTask to filter the view results by DebtorID |
|
|
|
|
| Schedule a Debtor Letter letter and then work the task |
|
|
|
|
|
|
Changed the Checkbox control for the 'Transfer Outstanding Balance' to a
TDBAdvancedCheckBox so that it will now properly transfer the balance. |
|
|
|
|
|
|
|
|
|
Checking the 'Transfer Outstanding Balance' checkbox will now update the debt proposal
triggering the calculation of any fees and charges and ensuring that the outstanding balance is
correct and that the proposal is based on that outstanding balance. |
|
|
|
|
Create a new Cash Advance debt. In the debt edit form, check the 'Transfer Outstanding
Balance' checkbox and verify that the outstanding balance amount is correct and that any fees
and charges associated with the debt type are calculated and applied correctly. |
|
|
|
|
|
|
"Date must have a value" error when making a debt payment from the Collector has been fixed.
System has been modified so that the update is called manually only after the date has been set. |
|
|
|
|
|
|
|
|
|
Making a debt payment from the Collector resulted in a "Date must have a value" error. This
was caused by the Update procedure being called and forcing the dataset to attempt to post
before the Date had been set. Modified the system so that the update is called manually and
only after the date has been set. |
|
|
|
|
| Make a Debt Payment from the Collector. |
|
|
|
|
|
|
The Module_ID field was not included in the dataset that is used when viewing a debt. This
was resulting in the error "mtblDebts: Field 'Module_ID' not found" The Module_ID field has
now been added, thereby fixing the problem. |
|
|
|
|
|
|
|
|
|
Fixed an error when viewing a debt from the Debtor Payment edit form. The dataset used for
looking up the debt when clicking view, did not include the Module_ID field and so you would
get an error stating that. |
|
|
|
|
Requisites:1. Create DebtSteps: 1. Click POS2. Click on Debt Payment3. Select Customer4.
Select Debt5. Click on ViewYou should be able to view the debt and not get an error saying
mtblDebt does not have a field 'Module_ID'. |
|
|
|
|
|
|
| Improved performance for processes using Bankable Item view. |
|
|
|
|
|
|
|
|
|
Changed every union in BankableItemView to union all.Changed the date restriction in
BankableDeferredDebtView to use DDBC.DepositDate instead of DDB.DepositDateChanged
the date restriction in BankableCheckDebtView to use CD.DepositDate instead of
CI.Check_DateAlso, change the BankableCheckDebtView to use CheckDebt.DepositDate i/o
CheckItem.Check_Date, and the BankableDeferredDebtView to use
DeferredDebtCollateral.DepositDate instead DeferredDepositableCollateral.DepositDate. |
|
|
|
|
| Verify that the Banking Calls interface can still be used to log calls against bankable items. |
|
|
|
|
|
|
Fixed a problem that resulted in a severe reduction in the performance of the Returned Item
Import. |
|
|
|
|
|
|
|
|
|
| Update statement has been changed to restrict by D.Debt_ID in DeferredDebtUpdate |
|
|
|
|
| Verify that debt entry still functions. |
|
|
|
|
|
|
The right for adding a debtor pool is now checked when we create a pool from the Manage
Collector browse and edit forms. |
|
|
|
|
|
|
|
|
|
| Changed the Manage Collector user-interface to check the create pool right when adding a pool. |
|
|
|
|
Uncheck the right to add debtor pools and try to create a pool through the Manage Collector
browse and edit forms. |
|
|
|
|
|
|
The enable/disable functionality of Recurring Fees on the WorkingDebtBrowse was shutting
the program down when toggled. The code that calculates the Loan Date and Debt Default Date
was causing an infinite loop. |
|
|
|
|
|
|
|
|
|
The enable/disable functionality of Recurring Fees on the WorkingDebtBrowse was causing a
stack overflow. The code that calculates the Loan Date and Debt Default Date was causing an
infinite loop. |
|
|
|
|
Working Debt Browse, use the Enable/Disable button on the Recurring Fees tab to toggle the
Enabled status of the fee associated with a debt. |
|
|
|
|
|
|
The Add, Edit and Delete buttons on the Report Task Address lookup form have been removed
for now due to a problem with adding an address from there. Project 37304 is planned to put
them back in working order. |
|
|
|
|
|
|
|
|
|
The Add, Edit and Delete buttons on the Report Task Address lookup form are no longer
available. The functionality for them was not implemented and attempting to use them resulted
in an error. This funcitonality will be implemented and the buttons made available upon
completion of proposal #37304 |
|
|
|
|
go to Collections > All Debtors > select a debtor and 'Work' that debtor > Print Letters >
Choose Address and verify that the Add, Edit and Delete buttons are not available. |
|
|
|
|
|
| General Ledger Export Module |
|
|
|
|
|
|
|
Fixed the error 'Violation of primary key constraint PK_GLHistory' when multiple stores
attempted to roll forward at the same time. |
|
|
|
|
|
|
|
|
|
| The GenerateGLHistory procedure was changed to address this issue. |
|
|
|
|
| Verify that two stores can rollforward at the same time with the same user logged in at each. |
|
|
|
|
|
|
|
|
|
|
|
|
Added support for No Interest Installment Loans. To configure an installment loan type to use
this feature, do not add any fee types on the loan type. The loan type can still be configured
with charges, if necessary. |
|
|
|
|
|
|
|
|
|
| Installment loan amortization logic was changed to provide this feature. |
|
|
|
|
Create an installment loan type without any fees and ensure that the payment schedule is
created. |
|
|
|
|
|
|
|
|
|
|
|
|
Leaving the Max Fee Overrides setting null in the loan type setup will no longer check the
override count. |
|
|
|
|
|
|
|
|
|
| Single-payment fee override calculation logic was updated to address this issue. |
|
|
|
|
| Leave the Max Fee Overrides setting null and attempt to override a fee. |
|
|
|
|
|
|
| The Cash Advance Manager now allows new transactions for cash advances to be reversed. |
|
|
|
|
|
|
|
|
|
| The Cash Advance Manager reverse logic was changed to provide this functionality. |
|
|
|
|
Create a new loan and reverse the new transaction in the Cash Advance Manager. The status
ID of the loan should be set to VOI. |
|
|
|
|
|
|
Introduced a new extensibility point in Cash Advance collateral entry to allow required
collateral value to be determined by a stored procedure. |
|
|
|
|
|
|
|
|
|
| Added the extension procedure RequiredCollateralValueProcedure to DeferredType. |
|
|
|
|
Create a custom procedure that returns an amount less than the total amount due on the loan and
see if it allows you to create collateral for that amount with the EQU value validation protocol. |
|
|
|
|
|
|
|
|
|
|
|
|
Fixed the error messag "debtorpaymentplanfindmissedpayments" when runing an Early Payoff
Inguiry on a cash advance loan. |
|
|
|
|
|
|
|
|
|
Modified the Early Payoff Inquiry functionality for Cash Advance loans. It was attempting to
verify that the payment plan was current for both Installment Loans and Single-Payment Cash
Advances which was causing an error in the latter case because a payment plan does not exist in
the Single-Payment case. |
|
|
|
|
Run and Early Payoff Inquiry' for a pending Single-Payment Cash Advance loan and verify that
you do not encounter an error. |
|
|
|
|
|
|
|
|
|
|
|
|
The Cash Recycler Integration now detects empty cassette and automatically posts a correcting
overage transaction. |
|
|
|
|
|
|
|
|
|
Changed the RecyclerSetCounts routine to check the hardware counts and post an overage if
the Cashwise counts don't match. |
|
|
|
|
|
|
|
|
|
|
| Resolved a key violation exception when inserting into CashTransactionDenom. |
|
|
|
|
|
|
|
|
|
Changed PostTransaction to use a denoms dictionary based on aggregate denoms rather than
CashUnits. |
|
|
|
|
|
|
|
|
|
|
Fixed recycler error "Request Incomplete: System.Exception: WFS_ERR_CDM_ITEMSLEFT
at Sof" when adding more money than requested. |
|
|
|
|
|
|
|
|
|
If more than 120 notes are placed in the issue unit then once the accept is complete for up to
120 notes, the remaining notes will be left in the issue unit. The software will now detect that
the excess notes remain in the issue unit and open the door and wait for the operator/teller to
remove the notes before recycler operation will continue. The consequence of this change is
that to load large quantities of notes via the issue unit notes need to be in bundles of 120 notes
or less. |
|
|
|
|
Place 121 notes in the issue unit and perform an accept operation for an amount greater than the
face value of the deposited notes. After the accept the door should open revealing the single
excess note sitll in the issue unit. This note will need to be removed before the recycler
continues operation. |
|
|
|
|
|
|
|
|
|
|
|
|
Fixed the error 'All queries in a UNION must have the same number of columns' when
attempting to run the Hourly Transaction Report. |
|
|
|
|
|
|
|
|
|
| The Hourly Transaction report was updated to address this issue. |
|
|
|
|
| Verify that the Hourly Transaction Report runs successfully. |
|
|
|
|
|
|
|
|
|
|
|
|
Improved the accuracy of the automatic matching capability in the Returned Item Import
Module. |
|
|
|
|
|
|
|
|
|
This is a two part fix as described below:Modified the KB Item browse form to correctly
display the Routing and Account numbers found in the database.Modified the item match
criteria to compare routing and account numbers as found in the data and if not found to remove
left zeroes and compare again. This enhances the match criteria and improves the match
statistics. |
|
|
|
|
Review the data input to the KB Import and visually verify that the routing and account
numbers are correctly displayed for each item.Modify the source file data to add left fill zeroes
to the account numbers which do no thave left zeroes and verify that a match is still found
(items modified this way should not be assigned a N/A action). |
|
|
|
|
|
|
|
|
|
|
|
|
| Fixed a defect in Export settings where the resulting code did not compile. |
|
|
|
|
|
|
|
|
|
Fixed two defects in the script settings feature. It was appending commas to the last column in
an insert or update statement for tables where the last column is RowGUID. Also, it was
mismatching values with column names when checking to see if a row already exists. |
|
|
|
|
Use the export settings feature in the Enterprise setup to export your Loan and Cash Advance
settings. Once exported open the script and look for the LoanTypeFeeType table and make
sure the code compiles. Also, Make sure that the "if" statement that checks for the existance of
the row have the right values aligned with the column names. |
|
|
|
|
|
|
|
|
|
|
|
|
If a Wisecard load void fails on Galileo's side it will need to be resolved for Roll Forward to
complete. |
|
|
|
|
|
|
|
|
|
Changed the Wisecard unresolved transaction logic to include transactions that failed to void at
the service but are attached to a voided sale. |
|
|
|
|
|
|
|
|
|
|
|
| Cashwise Impact Assessment |
|
|
|
|
| 3.7 Service Pack 3 (Build 3.7.7437.*) |
|
|
