End of Day Processing Options and Running EOD

The End of Day Process is the program that rolls the system date from one day to the next. Therefore, a check mark should default in the Roll System Date field. This ensures that the system's date automatically changes from one (1) day to the next before users begin accessing the system and begin entering transactions for the next business day. When End of Day completes on a Monday, the date is then rolled forward to Tuesday's date.

Note: If your company will not process Hurricane Blackout information, this item can be removed by an Insuresoft Database Administrator.

 

Process Blackout End Date is used to process policies associated with hurricane blackout periods. When this process is selected, the system does the following:

 

1. First, it determines if any future effective hurricane blackouts are now effective. If so, then all policies that are eligible for the newly effective blackout period are identified. If a policy matches the county / state / line of business criteria and it does not already have a prior blackout id associated with it, then the hurricane blackout id field in the Policy table is set to the ID of the blackout being saved.

2. If a hurricane blackout expiration date is less than the current system date, then all policies with that id are processed.

 

1. A policy is checked to determine if it is eligible for the new blackout period. If it is, then it is moved to the new blackout period.

2. A policy is checked to determine if it is in Legal Notice of Cancellation.

1. If the system setting, "Send New Legal On Blackout End," is set to "True" (Enable), a new Legal Notice of cancellation is created with a roll date equal to the system date. The Final Notice of Cancellation Date is changed with a roll date that is equal to the System Date + Legal Notice Days for the policy's pay plan.

2. If the system setting, ""Send New Legal On Blackout End," is set to "False" (Disable) the Final Notice of Cancellation Date is changed with a roll date that is equal to the System Date +  Legal Notice Days for the policy's pay plan.

3. A policy is checked to see if any Future Legal Notices of Cancellation should have occurred during the blackout period.

1. A new Legal Notice of Cancellation is created with a roll date equal to the system date.

2. The Final Notice of Cancellation Date is changed with a roll date that is equal to the System Date + Legal Notice Days for the policy's pay plan.

4. A policy is checked to determine if a Reminder Notice has rolled, and the renewal expiration should have occurred during the blackout period.

1. A new Legal Notice of Cancellation is created with a roll date equal to the system date.

2. A Final Notice of Cancellation Date is changed with a roll date that is equal to the System Date + Legal Notice Days for the policy's pay plan.

5. A policy workflow item is created for the policy if a catastrophe claim has occurred during the blackout period.

6. The hurricane blackout id is updated for the policy.

1. If a new blackout period is available, the ID is set to the new blackout.

2. If there is no new blackout period available, the ID is set to "0."  

If your company is using the Claim System, ensure a check mark is placed in Process Claims. When selected, this function updates all claim activity entered each day.

When selected, this process checks for "Future" transactions that are on or prior to the current date and updates the policy and billing information with the information from these future transactions. This is done by first looking at all future transactions on or before the current date, on which End Of Day is being run. Once this completes, the system processes each policy having any future transactions. For each policy, the system verifies whether or not the future transaction is a cancellation (e.g., Cancel, Cancel Rewrite or ABT Cancel Rewrite).

The cancellation of a policy is performed as a policy transaction in Diamond. When selected, the system first checks for policies with a billing notice type of Final

Cancellation Notice or Renewal Expiration Notice. If the notice type is "Final" the system, using the pay plan setting, verifies that the system date is not less than the Cancel Date plus the Cancel Delay days. Next, it also verifies that the minimum cancel balance is not greater than the current outstanding amount. If either of these items exist, then the system will not cancel the policy. If both of these items are false, or if the notice type is Renewal Expiration, the

system continues with canceling the policy. The system deletes any pending or quote status images and adds an automatic cancellation. If a pending image existed, the

system generates a workflow item informing the user that a pending item has been removed due to the issuance of an automatic cancellation. This process is completed

for each policy that is available for cancellation on the system date.

 

Special Notes: If the Process Cancellations errors out during End of Day Processing, errors are written to the Error Log. Here are the steps you may see in the Error Log:

 

Step 1: Diamond looks for policies that have reached their Final Cancel Date. They have a Billing Notice of Billing Notice Type Final. The policies having this are cancelled for non-payment. (Non-Pay Cancellations)

 

Step 2: The system looks for Renewals that have not been paid and will cancel them on this date. (Renewal Option 1 Cancels)

 

Step 3: The system looks for Renewals that have not been paid, but they are set to cancel flat on the Renewal Effective Date. (Renewal Options 2 and 3 flat cancels.

 

Item Count: This is the number of policies that fit the criteria for processing.

When the Process Legal Cancellations field is checked, Diamond loads policies with future Legal Cancellation Notices in an "In Force" or "Future" status and creates a billing notice for those policies.

 

The system creates a print event if the Current Outstanding Amount is greater than or equal to the Minimum Invoice Amount based on the pay plan settings.

This process updates invoices and accounts receivable with payment information. Additionally, it looks at active policies that are not in Notice of Legal Cancellation and that contain installments set to roll on or before the system date.

 

When the system determines which policies meet the requirements for processing, it then offsets any unapplied cash on each of those policies and updates the information.

The installments that meet the date criteria are then rolled. Billing charge credit information is updated, and the cancel information is reset. The offset cash is reapplied on the policy, and the automated pay plans (e.g., EFT,  credit card, agency bill, etc.) are also processed.

 

For the automated pay plans, the system applies the appropriate payments according to the "Due Now" amount and invoices and accounts receivable information are both

updated as well. Finally, invoice print events are issued for policies that have an amount due.

When selected, the system loads all the future events having a roll date less than or equal to the system date and an "Active" status. The system then processes each of the records, first determining if they are a non-renewal, non-renewal notice or automatic manual cancellation event.

 

1. For Non-Renewals: The system retrieves the policy images for the policy id number and submits and issues a non-renewal.

2. For a Non-Renewal Notice: The system generates a print event and creates a billing Non-Renewal Notice.

3. For an Automatic Manual Cancellation: The system verifies that the policy has an "Active" image. If it does, an automatic cancellation is processed on the "Active" image.

 

After each event is processed, the future event is deleted.

The Process Daily Premium field, when checked, updates premium information on policies. Within a given month, if a policy's image has not already been created, a new record

is inserted if it meets the following criteria. The accounting date in policy's image must be greater than or equal to the first day of the month of processing and less than the system date plus one. Additionally, the policy image status code must be one of the following:

  

• In Force

• Future

• History

• Written Off

• Reapplied

• Void Due to OOS Cancel

• Offset Due to OOS Cancel

  

Finally, the policy image transaction type must be one of the following:

 

• Cancellation

• New Business

• Endorsement

• Renewal

• Reinstatement

• Rewrite Full

• Cancel-Rewrite

• Renewal Underwriting

• Binder

• Non-Renewal

 

After all of the criteria is checked, all records are updated with the correct earned premium. This is only for policies where the expiration date is greater than the system date. For each policy, policy image, and coverage combination, the earned and unearned premium for each combination as well as the month-to-date (MTD) and year-to-date (YTD) figures are tracked as well.

For Rebalancing Credit Balances on EFT Billed Policies in Account Bill

 

The process determines if a credit balance on the account exists, then determines the policies in the account that will have the EFT Installments roll during the current EOD.

This function is used to process those Installment Pay Plans having the Invoice Notice Reminder set to "1" (Send Reminder Notice) and a defined number of days set in the corresponding Invoice Reminder Notice Days field.

 

The Invoice Reminder Notice will generate on the due date of an unpaid invoice if Legal Notice of Cancellation for non-payment and the resulting Final Cancellation Notice are delayed due to advanced equity on the policy. An Invoice Reminder Notice is then triggered and printed during this process if payment has not been received by the billing invoice due date.

 

Once generated, the Invoice Reminder Notice is displayed on the Statement Display screen. Additionally, a triggered Invoice Reminder Notice, when printed, displays in Print History. (Note: The Invoice Reminder Notice will generate before the Legal Notice of Cancellation.)

This process checks for policies with a billing notice type of Renewal Reminder Notice. The system verifies that there is no future cash on the policy. Then, it verifies that the notice is not within the Invoice No Print Days setting in the pay plan setup.

 

Finally, it verifies that Minimum Cancel Balance is not greater than the Current Outstanding Amount. If all of the above items are false, the system creates a billing reminder notice for those policies. The system also creates a reminder notice print event.

When the Process Expired Renewal Offers field is selected, the system retrieves all of the Renewal Offers that have an effective date less than or equal to the system date minus the renewal offer grace period days. Diamond then deletes the renewal offer image and creates an automatic cancellation for the policy.

Implementation specific. Please contact your Insuresoft business analyst for more information.

There are two (2) ways users may purge either quotes or policies in Diamond:

 

1. Purge Process (Manually): Using the Purge Process in Diamond Administration allows users to manually purge either quotes or policies through a specific date that are no longer needed.

2. End of Day Processing (Automatically): If Purge Quotes and Purge Policies are functions selected when End of Day Processing runs, the system uses system settings in Diamond System Editor to determine how far back to purge from the current date. It then purges any quotes or policies that are older than that during the End Of Day process.

 

When Process Purge Quote is selected, this process looks at the number of days in the "Purge Quote Days" system setting (Policy Purging folder), and removes or deletes those quotes that have a trans_date (transaction date) that fall within a period ranging from the current date and back the number of days that are specified in the system setting, "Purge Quote Days."

 

When billing activity has occurred on the policy, the system does not purge the quote associated with it.

 

These purged quotes are not archived, they are completely removed from Diamond.

Similar to the Process Purge Quote function, when Process Purge Policy is selected this process removes policies automatically from Diamond. The number of months defined in the "Purge Policy Months" (Policy Purging folder) controls the number of months that will be subtracted from the current system date. The resulting date is compared against the Expiration and Accounting Dates to identify which policies should be purged from the system.

 

Policies having claims will not be purged.

 

The policies that are purged are not archived. They are completely removed from Diamond, and there is not a way to retrieve them.

If your company is using the Premium Collection functionality, this process sends out a Collection Notice for each policy that has cancelled with a balance due.

 

This is dependent on the following option / setting in the Collection Notice Option section of the pay plan:

 

• Collection Notice Option: This field is set to "1" - Send Collection Notices.

• Collection Notice Days: This is the user defined number of days between when the policy cancels and the Collection Notice generates during End of Day Processing.

 

So for example, a policy cancels with an outstanding balance on 05/04/2011. When End of Day is processed the evening of 05/19/2011 (or 15 days later if Collection Notice Days = 15), a Collection Notice is generated. Additionally, a line is added to the policy on the Billing Statement Display screen that reads: "Collection Notice."

This process is also used with the Premium Collections functionality. It is designed to waive the premium due on a policy that has been cancelled with an outstanding balance.

 

This is dependent on the following setting in the Collection Notice Option section of the pay plan:

 

• Collection Waive Days: This is a user defined number of days when a Collection Notice generates and when an outstanding balance on a cancelled policy is waived.

 

For an example, a policy cancelled on 05/04/2011 that had an outstanding balance. On 05/29/2011 (15 days later), a Collection Notice is generated. If "Collection Waive Days" is set to 10, then when End of Day is run on 05/29/2009, the premium is automatically waived. A line is added to the Statement Display screen of the policy that reads: "Automatic Waived Premium." The amount owed is subtracted and the balance owed is zero (0).

When the Process Automatic Waives is selected, the system automatically waives off outstanding credit or debit amounts that are less than or equal to an amount that is specified in a system setting, "Automatic Waive Amount " (Diamond System Editor: Billing Folder).

This function posts any "post dated" checks entered. When a check is entered and "post dated," it is displayed on the Billing Future screen.

 

When the Process Future Cash In executes, it processes the post dated checks and posts them to the Billing Statement screen.

Special Note! Prior to using this process, some work may have to be done at your company's implementation level. Please discuss this with your Insuresoft Business Analyst.

 

This process is used to delay forms until End of Day Processing which allows your company to determine if all forms are sent or not. These forms (e.g., invoices, etc.) are specified and programmed in the Billing Forms Attachment code.

 

An example of this would be the following. A policy generated activity that normally would have generated two (2) invoices. Instead of generating two (2) separate invoices, your company could suppress this into one (1) invoice combining, or showing, the two (2) separate activities on one (1) invoice which would not generate until this process is run during End of Day.

This process is used to generate the XML files used in the Batch Print Process. Prior to enabling this function, you must do the following in Diamond System Editor:

 

• Print Interface Type: Set this to "1" (Directory).

• Export Path: Specify the name of the path for exporting batch print XMLs.

Implementation Specific.
 

This executes the Texas Quarterly Report for commercial auto. If your implementation will be using this, tables, system settings and End of Period Processes need to be set up prior to use.

Implementation Specific.

 

This executes the weekly report for each personal auto's book of business for the state of Texas. If your implementation will be using this, tables, system settings and End of Period Processes require set up prior to use.

Implementation Specific.

 

This executes the Texas Quarterly Report for personal auto. If your implementation will be using this, tables, system settings and End of Period Processes require set up prior to use.

Implementation Specific.

 

This executes the Annual Aggregate Report for personal auto. If your implementation will be using this, tables, system settings and End of Period Processes require set up prior to use.

Implementation Specific.

 

This executes the Annual Reconciliation Report for personal auto. If your implementation will be using this, tables, system settings and End of Period Processes require set up prior to use.

This is used to process ELIOS (Electronic Lien holder Notification Service) information. When a policy is rated, the system populates required information to the ELIOS table.

 

When Generate ELIOS File is selected, it checks the ELIOS table for any records not processed and sets the records to "True" (Process). A file is then generated to a user defined path / directory.

 

Two (2) System Settings have been added for this functionality in the Printing / Base Print Solution folder in DiamUI System Editor:

 

• Process ELIOS Records: Values are "False" (Disable) and "True" (Enable). When this is set to "True" (Enable), this means a company is using the ELIOS (Electronic Lien holder Notification Service) functionality. When a policy is rated, information is written to the ELIOS table. The default value is "True" (Enable). 

• ELIOS File Path: User-defined. This is the path / directory that holds the file generated in End of Day Processing when the process Generate ELIOS File contains a check mark. The default value is "C:\Temp."

The Create GL function is used to create a text file in the Freedom ® format to be sent for processing. In order to do this, you will need to have your implementation team set up its location in the General Ledger table, If you want to export to this file as opposed to an XML, you will have to set the generate_freedom_file column in the General Ledger table to a "1."

The Download function is used to generate an XML file containing all transactions that can be sent to IVANS. Once processing is complete, IVANS then returns the information to agents. This can be run either here, during End of Day, or as a "stand alone" function in Diamond Processes.

 

Prior to using this function in End of Day, you need to establish the following system settings in the Download folder in the Diamond System Editor:

 

• Days Before System Date for Start Date: This is the user defined number of days to default the start date for the Down Load range. The number entered here looks at the system date to determine when the Download range should begin.

• Days Before System Date for End Date: This is the  user defined number of days to default the ending date for the Download range. The number entered here looks at the system date to determine when the Download range should end.

 

Also, you will need to identify the "Download Path" system setting held in the Policy folder or the process will not complete successfully.

 

When Download runs, it takes in the following criteria:

 

1. All agencies set up for Download will be included.

2. All policies that have not already been downloaded will be included.

3. The date range will be calculated as follows: Start Date will be the current system date minus (-) the value in the (Download folder) "Days Before System Date for Start Date" system setting.

4. End Date will be the current system date minus (-) the value in the (Download folder) "Days Before System Date for End Date" system setting.

5. The Download file (s) will be sent to the path named in the (Policy folder) "Download Path" system setting.

Note: This is controlled by the system setting, "Allow Payments With EOD," in the End of Day folder in Diamond System Editor. When this is set to "True" (Enable) users are able to submit payments when End of Day, End of Month and End of Year are running.

 

When a check mark is placed in this process, payments that were accepted via the Web Service while End of Day Processing was running are automatically posted.
 

Because these payments are posted AFTER End of Day Processing finishes, a check mark should be placed in the Process After Sysdate Rolled field. Payments are posted using the current system date (i.e., the next business day's date) as the Transaction Date.

This process is used with the Electronic Notification of Print Events functionality. Basically, this allows users to determine (by policy) print events that can electronically be sent to notify a policyholder that a form has been issued. Some of these forms (print events) include, but are not limited to: Dec pages, Endorsements, Invoices and Payment Receipts.

 

On the Policy Information screen, a user can select the Manage Print Delivery and Notification Options link and indicate if a form should be sent by email. Forms that have a Print Distribution Type = Email or Mail and Email are then placed in a queue with records written out to the Emailqueue table.

 

When Process Email Export runs, the system sends a link to each email address provided. The form is not attached.

 

Note: Some implementation work is required prior to using this function.

This allows the automated processing of SR 22 / 26 filing data sent to and received from the state. Any user running End of Day must have the authority, "Import SR 22 / 26 Data."

When selected, this process is used to store “X” amount of days of Billing Account Receivable information in the table BillingAcctReceivableDaily.

 

A system setting controls the number of days to store the Accounts Receivable information. This is found in Diamond System Editor: Billing folder / "Days to Keep Acct Receivable." The number entered here represents the number of days to store Accounts Receivable information. In the Diamond Base System, this is set to zero (0). Using this as an example, each day this process runs new Daily AR Totals are written out.

This process is used with the Explore EARS ® product for ordering MVR Reports and receiving accident / violation information. If your company is using this third party interface, this End of Day process should default with a check mark to run each day. When run each day, it applies any imported violations from EARS to the associated policies. The system then attempts to apply any violations whose current status is imported. (Note: The system currently supports both the Standard EARS Output Format and the Comma-Delimited (CSV) EARS Output Format.) The Standard EARS Output Format is the recommended format.

 

There are four (4) methods available for applying violations to policies:

 

1. Process Violations Immediately: All violations (major and minor) are applied to the associated policies by means of a Renewal Underwriting transaction.

2. Process Violations at Renewal: All violations (major and minor) are applied to the associated policies when the Renewal transaction is created.

3. Delay Minor Violations Until Renewal:  All major violations are applied to the associated policies by means of a Renewal Underwriting transaction. All minor violations are applied to the associated policies when the Renewal transaction is created.

4. Delay Minor Violations: All major violations are applied to the associated policies by means of a Renewal Underwriting transaction. All minor violations are applied to their associated policies at the specified number of days prior to the expiration date of the policy (e.g., the effective date of the next Renewal) by means of a Renewal Underwriting transaction.

 

The following options can be configured for the violation application process:

 

• Delay Lead Days: This option holds the number of days prior to the expiration date of the policy (e.g., effective date of the next Renewal) that triggers the application of any minor violations returned from Explore (Note: This value can vary by company / state / line of business.)

• Apply Violation Method Type: One of the four (4) methods mentioned above of applying violations to the associated policies. (Note: This value can vary by company / state / line of business.)

• Transaction Remark: The Transaction Remark used for submitting the Renewal Underwriting transaction. (Note: This value can vary by company / state / line of business.)

• Transaction Reason ID: The Transaction Reason used for submitting the Renewal Underwriting transaction. (Note: This value can vary by company / state / line of business.)

• User or Queue ID: This identifies the user or workflow queue that receives Diary items for each violation that cannot be applied to an associated policy.

 

In order to apply violations to the policies correctly, the system must be configured to map the violation information imported from EARS to the corresponding values in Diamond. The following options can be configured by company / state / line of business for each violation code imported from EARS:

 

• Accidents / Surcharge Type ID: This corresponds to the Accident Surcharge Type table in Diamond.

• Accidents / Violations Type ID: Corresponds to the Accidents Violations table in Diamond.

• Apply Points: This is a flag that indicates if the points from the imported EARS violation should be applied to the violation record in Diamond.

• Is Major Violation: This is a flag that indicates if the imported EARS violation is considered to be "Major;" used to apply violations differently based on "Major" versus "Minor."

• Major Surcharge Type ID: Corresponds to the Major Surcharge Type table in Diamond.

• Minor Surcharge Type ID:  Corresponds to the Minor Surcharge Type table in Diamond.

• Surcharge: This is a flag that indicates if an imported EARS violation record should be surchargable in Diamond.

• Violation Conviction Type ID:  Corresponds to the Violation Conviction Type table in Diamond.

• Violation Source ID:  Corresponds to the Violation Source table in Diamond.

This process is used with the Explore EARS ® product for ordering MVR Reports and receiving accident / violation information. If your company is using this third party interface, this End of Day process should default with a check mark to run each day. Diamond imports the records contained in the file into the database. The records are then held in a queue for processing. The system allows the selection of risks to be controlled by means of a database configuration. The following options can be configured for the file import process:

 

• Create an Archive Copy: When this option is enabled, the system keeps a copy of the import file in the Blob table. (Note: After the file has successfully been imported, the physical file is deleted. The entire file must be successfully imported before it can be deleted. An "atomic" transaction is used.)

• General User or Queue ID: This option identifies the user or workflow queue that receives messages from the export process. If a problem is found, the system creates a Diary item containing the details and assigns the item to the entity defined in this option.

• Import Directory: This option identifies the directory where the import file is located. (Special Note: This directory must be accessible by your Business Server.)

• Import File Name: This option contains the static file name provided by Explore for the import file.

• Rejected File Name: This option holds the static file name provided by Explore for the rejected driver file. (Note: The assumption is made that the rejected driver file will reside in the Import directory.)

• Rejected File User or Queue ID: This option is used to identify the user or workflow queue that receives notification for each driver returned in the rejected driver file. The system creates a diary item for each driver returned in the file that contains a reason for rejection. The Diary item is assigned to the entity identified by this option.

 

An historical record is created each time the import file and / or rejected driver file is imported.
 

In the Claims System, Scheduled Payment Cycles can be set up for fixed payment amounts, such as loss wages in Workers Compensation. This function is used to process those Scheduled Payments and their corresponding amounts.

 

Payments that have not been suspended are picked up and applied. These are written to the Scheduled Pay record for the Claimant. As each payment is processed, the number of payments and their corresponding amounts are tracked. Payments that have been suspended will not be picked up until they are reinstated.

 

Because these Scheduled Payments are posted AFTER End of Day Processing finishes, a check mark should be placed in the Process After Sysdate Rolled field. Payments are posted using the current system date (i.e., the next business day's date) as the Transaction Date.

This reads results from the ISO Claim Search Interface and processes the error file. When errors are found, tasks are sent notifying the adjusters of errors that need to be fixed and resets the claims for new or updated submission.

 

Prior to use, the system setting, "Error File Path," (ISO Claim Search folder) must have the name of the path where the match file error file is stored identified.

 

If an inside adjuster has not been assigned at the Claim level and the system setting, "Workflow Queue for ISO Errors," (Claims / ISO Claim Search folder) has been set with a name, then a Task will be generated to that queue. This assures all ISO Claim Search rejections are handled accordingly.

This process is also used with the ISO Claim Search Interface. It reads the .PDF match text file and adds attachments to the claims and notifies the adjusters of a match file found.

 

Prior to using this function, the following system settings in the ISO Claim Search folder need to be set:

 

1. "Match PDF Path:" This determines the name of the path where the match file error file is stored. This is an implementation specific / user defined setting.
2. "Skip Submitted Report Only:" This determines if match files for a reported claim only should be skipped or not. Values are "True" (Enable) and "False" (Disable).

When Credit Card Pay Plans that have the option, "Send Credit Card Decline Notices," set to "1," a Notice is created on the Billing Future tab. This function is used to pick those Notices up and process them.

This is used to export Bills and Legal Notices to a third party for processing. When selected, this function generates a file that holds all of the Invoices and Legal Cancellation Notices. Once the file has been created, it is sent to an implementation specific / user defined directory.

 

Before use, you must define the export path's directory in the  "Billing Invoices and Legals Output File Path" in the Billing / End of Period folder in Diamond System Editor.

This is used to generate the Batch Inquiry File for Metropolitan Police Reporting data. This process writes a record to the Metro Transmission table for the Batch Status Order Inquiry with a transmission status of "Sent" and sends the XML to Metro requesting all "Changed" orders. The record will include the XML sent to Metro and a unique request ID generated by Diamond.

This creates a file for each company and CLUE report type (Auto, Property and Commercial).

This function contains the following components.

 - Credit Card Expiration - This component will find and report all recurring credit card policy records where the credit card expiration date will expire within the [Number of Months] specified by the corresponding system setting value.
 - EFT Account Numbers - This component will validate all policy EFT account routing numbers.  Note that the Billing / EFT / Validate Routing Number system setting must also be enabled.
 - Pending Automatic Transactions - This component will report all pending transactions that match the transaction type (s) in the Transaction Types system setting value.
 - Print Output - This component will report all Print XML records with a batch or real-time status of error or processing. Print XML Package records that are out of sync with the Print XML records will also be reported.

This process also supports the ability to notify additional email recipients per component. Please note that End of Period email notification must be configured and enabled in order for this to work. In order to use this new process, you must add the new process to an EOD configuration and set the desired system settings appropriately.

Numerous system settings have been added for the Diagnostic Process. These are located in the End of Day / Diagnostic Process folder with the following sub-folders: Create Credit Card Expiration, EFT Account Numbers, Pending Automatic Transactions and Print Output.

This process is used with the Claims Medical Module (CorVel Interface). When the field "Report to CorVel" on a claim contains a check mark, the claim is picked up by the CorVel Export File process and placed in a directory (designated by a system setting) to be sent to CorVel for processing.

 

Once the process has been run, the flag is cleared on the claim. If changes are made on the claim, the flag is reset and those changes are reflected in the next file when this process is run again.

 

In Diamond System Editor, you must establish the path / directory for the export files using the system setting: "Export File Path" (Integration / Corvel folder).

This is used with the function "Automatic Transaction Based on Respond Date," which allows customers to create a trigger to cancel a policy in the future based on a respond by date. This must be set up in End of Day to run in order for the cancellation transaction to be created.

This is used with the Claims Salvage Data Capture (Copart) process. This function scans a folder specified in Diamond System Editor in the "Attachments Path" (Claims / Salvage / Attachments folder) for all PDF files and attaches them to the file specified in the file name of the .PDF.

This function is used with the Salvage Module (Copart Interface) in the Claims System. Basically, it is used to pull Salvage Invoice PDF documents from an FTP location and attaches those documents to the claims.

 

It is not dependent on any other process in EOD and can be run at any time.

This function provides users with the ability to automatically import claim transactions from an Excel ® spreadsheet. Each row in the spreadsheet that is used for the import is added into Claims as a claim transaction. Once Check Processing is run, the transaction is converted into a check. If it is a bulk payee, there is one (1) transaction for each row in the spreadsheet. (Note: This can also be done manually via the Diamond Administration / Claims / "Import Transactions.")

 

Prior to use the system setting, "Import Path," in the Claims / Transaction folder must be set up. It is an implementation specific / user defined value.

This process creates an electronic file that can be transferred to NCCI (3rd Party Vendor) to report new business Workers Compensation policies.

This process allows the Reserve Amount to be increased on a claim feature based on the type of feature and number of days it has been open.

 

When executed, it identifies open claim features meeting the criteria defined in the Claims Reserves table and updates the Reserve Amount when applicable. The new amount is based on the Feature Type, Number of Days Open and Current Loss Reserve amount.

This process will determine the forms to attach to an agency. The data is based on the agency activity database. This process will check to see if there are any NSF checks, commissions, payments or refunds for an agency and attach any applicable forms.

This process will run the XMLs through Publisher or any printing service that the client chooses.

If your company is using the Email Integration function, this is the process that calls the Scheduler Runner Job.

This is used to trigger Batch Agency Forms. It does not output print, it simply adds them as needed.

This process performs the Output of the Batch Forms. It generates the Print XML, outputs to Publisher, then Publisher receives and generates the print as needed.