– Bob Hornick, President CIM-Data Ltd.
Switching EDI Servers opens up what is usually a reliable transport mechanism for EDI upload and download files, to the possibility of file loss or duplication, or even worse, incorrect sequencing.
Let�s explore some of the issues around EDI file sequencing, and how the CSIO standards themselves have provided for both manual and automatic detection of incorrect file delivery.
Download File Structure
Each download file contains zero or more transactions wrapped in a message envelope. There can be one or more message envelopes per file, but in practice, there is normally only one.
The message envelope consists of a message header record, followed by transactions, followed by a message trailer record.
Transactions always start with a transaction header record and end when another transaction header record is encountered, or when a message trailer record is found.
The CSIO Standards define what records, what elements, what codes, and in fact, every aspect of what a download file can contain.
A receiving system designed to process a standard CSIO transaction generally processes incoming files in the order they are received, and transactions in the order they are encountered within each file.
When a system generates EDI files, transactions marked for transmission are gathered and formatted using CSIO standards into download files. These files are then sent to the appropriate EDI mailbox for each company contract number.
So what can go wrong?
There are so many ways downloads to brokers have messed up in the past but in general, download file management errors all reduce to three main types of errors:
1) An item is missing.
2) An item is duplicated.
3) An item is sent or received out of sequence.
Each one of these errors is fraught with potentially enormous consequences.
E & O Issues
When a paperless office trusts its downloads for passing along policy information, its staff should always remember that download errors are possible and couch information within that context. For example, when a download transaction is missing, an added coverage will not be displayed, or a deleted coverage will still show up as in force.
When a transaction is sent out of sequence though, more subtle and more insidious problems could occur.
Consider two endorsements:
Endorsement #1
- Carries Address of Principal Residence
- Deletes Coverage #1
Endorsement #2
- Changes Principal Address of Home
- Adds Coverage #1 Back
To the CSR, this would appear as of if a coverage was deleted on a home, then the client moved, and added the deleted coverage back on.
Now let�s consider how your system may display policy data if these two transactions were received in the wrong order:
Endorsement #2
- Changes Principal Address of Home
- Adds Coverage #1 Back
Endorsement #1
- Carries Address of Principal Residence
- Deletes Coverage #1
Now, to the CSR, with only Endorsement #2 being applied, it would appear that the client moved to a new address. The added coverage wouldn�t actually show as added at all since it still existed on the brokerage database.
But after Endorsement #1 arrives, things really get weird. It looks like the client moved back to the original address, then deleted Coverage #1. If the CSR only looked at the last downloaded data, it might not be obvious (depending upon the BMS) that the client moved, and, it would look like a coverage was removed from the policy.
You can probably imagine more quirky situations, particularly when more than two files are involved.
Accounting Issues
When downloads are used to generate billings automatically, significant time and accuracy savings can be realized. But what happens when files are transmitted incorrectly?
Duplicated files will generate duplicated billings and clients may be invoiced twice. Most clients will gladly report that error to you. But what if you are generating billings for direct bill in order to post producer commissions? Oh of course, your producers will tell you � right?
On the other hand, if a file is missing, invoicing will not be done, and you may not hear from your client, but you might hear from your producer.
Depending upon your BMS, out of sequence errors shouldn�t really have an impact on automatic billing, but if your BMS has a module like in CIM-Data�s VCIM, that tracks policy status, it can be thrown off.
How can we check if Download files are received correctly?
Fortunately, the CSIO Standards define two very useful fields for detecting proper file delivery. Unfortunately, not all systems generate proper coding for these fields, and even fewer are able to automatically detect errors. If your BMS prints these fields for you, you can check them manually very easily.
Message Sequence Numbers
The easy way to verify that all files are received once and only once, and in the correct sequence, is to check your log files. Each Message Header contains a field called the �Message Sequence Number� or MSQNO. When generated correctly, MSQNO�s start at one, and wrap around again to one after 999,999 files. The MSQNO of a message should always be one higher than the previous file.
Each contract number with each company should have its own MSQNO series.
Automatic detection of correct MSQNOs requires software that can recover from counting errors when a transmission error or file processing restart occurs. If receiving software detects a MSQNO that is not exactly one higher than the last received MSQNO, then it should alert your system manager and prevent that file from being processed until the problem can be analyzed.
Transaction Sequence Numbers
Similar to MSQNO�s each Transaction has its own �Transaction Sequence Number� or TRSEQ. TRSEQ�s are only four digits long, start numbering at one, and wrap around to one again after 9,999 transactions are processed. It is incorrect for a sender to start numbering at one within each Message and any system that does so generates numbers that are useless for detecting download problems.
The thing is, if the last TRSEQ in the last downloaded file is 7309, then the first TRSEQ in the first download file the next day, should be 7310. Again, each TRSEQ series is unique for each contract number.
Checking TRSEQ�s can be done in the same way as checking for MSQNO�s, either automatically or manually.
Why two sets of Sequence Numbers?
A sending system might calculate and apply both types of sequence numbers at two different stages of EDI file generation. Thus a TRSEQ error could detect a problem in one subsystem, and a MSQNO error could indicate an error in an entirely different subsystem. This could help identify where a problem exists in a system.
If MSQNO and TRSEQ numbers are both generated correctly when files are produced, then a receiving system or manager can easily detect missing, duplicated, or out-of-order downloads due to the delivery systems (CSIONet), or its own receiving software.
What about Upload?
Both MSQNO and TRSEQ are supposed to be generated by all CSIO EDI Systems, but sadly, they are not. If they were, companies could also put into place automatic detection of file errors on upload.
How often do File Errors Occur?
The good thing about file errors is that they happen rarely. Incidents increase when there are communications problems, software upgrades, or when the industry changes from one server to another.
Sometimes, a company or brokerage system, can just glitch out randomly. Manual or automatic checking of sequence numbers is the best, most reliable way of verifying reliable, end-to-end transmission of data.
Now that you know a little more about sequence number checking, you may be able to spot sequence numbers in your logs. Even with fully automatic checking enabled, it won�t hurt for you to take a peek at these numbers every so often, just to be sure, particularly before and after the CSIO-Telus Migration.
About CIM-Data
CIM-Data provides Canadian Insurance Brokers with a fast, reliable and easy to use Broker Management System. For more information, visit www.CIM-Data.com.
