Added a new phone "Verification" status in the consent screen.

Beyond - Phone Verification Status

We have added a new column and field for phone numbers in the Consent screen within Beyond called “Verified”. This new field works similar to consent and allows you to grant or revoke “Verification” with a reason why. This new field is intended to track whether a phone number has been confirmed to belong to the consumer. Currently Verification must be set manually for each phone number in the consent screen.

Note: A phone number having verification verified or unverified does not change how DCS text messages are sent. No modifications or updates to any DCS workflow or communications is required by this change. This new field is purely to improve the ability to track the status of a phone number as well as improve how DCS works with the Reassigned Number Database (RND) feature on DAKCS Hub as described below in more detail.








---

Reassigned Number Database Scrub (RND) Integration

Phone verification improves how DCS works when also using the Reassigned Number Database Scrub feature on DAKCS Hub. When marked as Verified, DCS will not block outgoing text messages even if the RND scrub. This allows DCS to better handle the use case for when a consumer gets a new phone number, confirms the number belongs to them, but RND still flags the number as reassigned.

If a phone number is unverified then the RND scrub feature will work as it does currently where; For an unverified number, when the RND scrub flags it as as recently reassigned, DCS will block text messages from being sent to that number.




Note: DCS still performs all other existing checks to determine if a message should be blocked from being sent. Verification only allows bypassing if the number was flagged as recently reassigned from the RND scrub.

New

First Alert upload now allows users to skip all previous "You are out of..." errors.

Changed

Fixed an issue where updating a scheduled action would insert a new record instead of updating the existing one, causing a message indicating that the schedule had been set up multiple times.

Fixed

Fixed an issue that caused the Lock Clear screen to list a single PDC payment session multiple times, it would hang when clearing one of those locks.

Fixed

Fixed an issue where the PDC authorization prompt could prompt multiple times.

Fixed

Fixed an issue where, in very specific circumstances, the PDC screen would allow a payment to be authorized and processed twice.

Fixed

Fixed an issue where Run Another action would take a long time to process.

Fixed

Fixed an issue where Beyond would lock up when viewing accounts.

Fixed

Fixed an issue with the "Report Payment Amount" feature where the payment amount sometimes would show the full debtor due rather than the amount from the document body.

Fixed

Added the function PROPER

Added PROPER() function

We have added a new function PROPER() to help formatting text. This new function converts text into title case where the first letter of each word is uppercase an the rest of the word is lowercase. This function can be used with any text regardless of the original format. Examples of PROPER() converting text:

• JOHN SMITH → John Smith
• mArY-aNn o'CONNOR → Mary-Ann O’Connor

New

Added the functions GET_DCS_SENT and GET_COM_TRACK

Added GET_DCS_SENT() function

We have added a new function useable within queries GET_DCS_SENT() that allows you to easily get the total count of DCS messages that have been sent o a master within a specified time range. The function also allows filtering the count to only return messages sent as emails, texts, or both in a combined total. GET_DCS_SENT() requires the following parameters:

• Master Number
• Starting Date
• Ending Date
• Message Type
  • 'A' - All messages (both email and SMS)
  • 'E' - All messages as an email
  • 'T' - all messages sent as a text message.

Note: Start and End date parameters are required. If you wish to get the counts for all-time you will need to put in a very long date range (I.E. 01/01/1900 through the current date). An example of using the function is shown below:

---

Added GET_COM_TRACK() function

We have another new function GET_COM_TRACK() which counts communication tracking records for a master. This function also allows filtering filter the count by message type and also lets you specify if it should count only attempts, only contacts, or everything. GET_COM_TRACK() requires the following parameters:

• Master Number
• Starting Date
• Ending Date
• Message Type
  • 'A' - All messages (both email and SMS)
  • 'E' - All messages as an email
  • 'T' - all messages sent as a text message.
• ATTEMPTCONTACT
  • 'E' - Count every communication tracking record for the master
  • 'A' - Count only communication tracking for attempts
  • 'C' - Count only communication tracking records resulted in a contact

An example of using the function is shown below:

New

The email recipient field now suggests available email addresses

When adding or editing an email recipient on Advanced Inquiry exports and on notification setup for scheduled/automated processing the address field now displays a list of available email addresses as you type, allowing you to quickly select the correct address instead of entering it manually.

Changed

Extended Rate Tables now include an option to calculate commissions based on the payment amount at the time of posting.

Changed

Fixed an issue where custom screen data grids could cause an error when selecting another action to run.

Fixed

Fixed an issue with how some large data objects are stored.

Fixed

Fixed an issue with Flow Documents and Regulation E signature request not updating consent properly.

When a Flow Document request was being sent to an email address and the email message bounced, in some cases consent was not being updated properly. This fix ensures that when an email bounces from a Flow Document or Regulation E Signature request, consent will be properly updated to indicate that the request bounced.

Fixed

Fixed an issue where a credit card payment may attempt to be requested more than once.

When doing the online authorization of a credit card in Beyond, there was a rare chance that the online authorization would be submitted twice. This caused one request to succeed and the second to fail. This issue has been fixed so that the credit card will only be submitted once.

Fixed

Added support for to embed text from a Report Designer Document into the "state disclosure" fillpoint.

Report Designer State Disclosures

We have added a new property to Validation Notice and the Send Communication action nodes within Beyond that allows selecting a Report Designer report to populate the State Disclosure template fillpoint. This new property allow more fine-tuning and control over exactly what the state disclosure says based on the communication template or account/consumer information.

---

Both the Validation Notice and Send Communication action nodes now include a new optional property for selecting a State Disclosure. This new property allows you to select any report saved in Report Designer*. When the communication is sent DCS, will copy the text from the Report Designer report and embed it within the State Disclosure fillpoint of the outgoing message. This differs from a traditional DCS document attachment because rather than embedding the report itself as an attachment or message or providing a link to view the document, the text from the state disclosure instead is written directly within the body of the communication. If a communication or Validation notice is sent without a state disclosure report, DCS will use the existing “Communication State Disclosure” as setup on DAKCS Hub. Additionally, if a template does not contain any State Disclosure fillpoints, then the new report will not be added to the communication.

---

Note: A report designer State Disclosures report should contain only text. Images or complex formatting are not supported at this time.

New

Fixed an issue when using a zero-cost payment processor where one-time PDC payments were created with a future due date.

We have fixed an issue when using a zero-cost payment processor when processing one-time PDC payments that were created with a future due date. When the future PDC payment is saved, the technology fee could sometimes be improperly saved as $0.00 rather than the proper amount and when the payment attempted to process the processor would reject the payment due to the incorrect technology fee.

Fixed