eiConsole for ACORD – ACORD Replacements (Demo)
Welcome to the eiConsole ACORD Replacements Demo. Electronic processing of Replacements has recently become a hot-button topic for many annuity carriers. Working with DTCC and the ACORD standards, these organizations have defined a set of TXLife Transactions for Replacements processing. With the eiConsole, implementation of these transactions can be made painless. Over the next several minutes you’ll see just how easy it is to build an ACORD compliant Replacements transaction.
Now, we’ll double click the newly created Route to bring up the Main Route grid.
Here is one Source of the Replacements information and one Target.
We’ll begin the interface configuration with the Listener, where we’ll choose to use a Directory / File Listener.
To poll a Directory every 10 seconds for an inbound tab-delimited file.
Configure the Post-Process Operation.
Once the tab-delimited file arrives, we’ll want to convert that to XML.
We’ll do this in the Source Transformation using the Delimited and Fixed-Width File Transformation Module.
To specify the structure of this file we’ll use the File Specification Editor. In this case, we’ll import field names from our tab-delimited file.
When promoted we’ll load the sample.
Click Yes.
The structure of the file will be depicted on the left and the sample file will appear in the To XML preview panel.
We can execute the transformation to XML and review the results.
Once finished, we’ll return to the Console and click “OK” to save.
Now the tab-delimited file can have more than one Replacement within it. We’ll want to fork each of these into an individual transaction using our XPath forking module.
For each Record element, we’ll create a unique transaction.
To test this we’ll now switch to Testing Mode, start our test with the transformation and end the test after the forking.
We’ll provide the sample data that will be originally converted into a single XML stream.
Forked, and then converted into two individual transactions. We’ll save one aside.
Back in Editing Mode, in our Routing Module, we’ll keep the default, All Targets.
And then we’ll move on to the Target Transformation. Here we’ll add a conversion into ACORD XML.
In this case, we’ll use the Data Mapper.
The Data Mapper will allow us to convert data from our Source Format.
Which we’ll load using the sample XML file that we just saved aside…
And we’ll be mapping onto ACORD.
Which we’ll load using the ACORD Life Schema Release Format Reader.
We’ll also load a sample transaction that will give us the skeletal structure of our Replacements.
Using this sample we can pre-fill the center panel of our mapping. This gives us all of the data elements that we’ll want to generate in our output. However, if we were to run the transformation now it would be populated just with static entries. What we’ll want to do is replace this with dynamic mappings from our Source data.
We’ll generate a TransRefGUID from the current date and time. The pallet above the Mapper can be used to do these types of generic data manipulations.
We’ll change the TRANSSUB type from 12702 to 12701.
And we’ll continue to move through the mapping now replacing static fields with dynamically mapped fields from the tree on the left.
Some fields like the ArrType will require us to do a mapping between one set of code values and the ACORD code values. To do this we can use the Tabular Mapping tool. Here we’ll see that the Target values are prefilled with allowable ACORD values. We’ll map FLK to Free Look and FLL to Full Surrender.
We’ll scroll down and begin to map information into the Source Policy. We’ll map Policy-Number to PolNumber, leave LineOfBusiness “As Is”, map Source-Carrier-ID to CarrierCode, and leave the rest the same.
Now, down in the Party section, we’ll input information about the applicant. We can use XPath Functions, like string concatenation, to combine fields into one. These functions can even be nested. Here we’ll use First-Name, Middle-Name, and Last-Name from our Source to populate the FullName element in our result.
For GovtID we’ll map the SSN, but will want to remove all non-numeric characters. We can use the Filter Non-Numeric tool to accomplish that.
Then we’ll provide straight forward one-to-one mappings for First-Name, Middle-Name, and Last-Name.
The next party is our first carrier, our Source-Carrier. We’ll map Source-Carrier to FullName, Source-Carrier-DTCC-ID to DTCCMemberCode, and Source-Carrier-ID to CarrierCode.
As we scroll down we’ll see that we have a separate Party instance to represent the destination carrier. We’ll repeat the process here, this time using destination carrier information.
And that’s it. We can now save our mapping. Moving on to the Transport stage, typically this information will be fed to DTCC using our HTTP Post for DTCC transport. However, for the purposes of demonstration, we’ll just use a simple directory drop. We’ll drop the file in an output directory giving the file the name ACORD 12701 and the extension of XML.
We can finish our interface by providing the Source System Name.
And Target System Name.
We can save the Route, again return to Testing Mode, and now we can try to test this from end to end. We can provide the input manually, or start at the very beginning and poll the directory. When the data is picked up it will be deleted from the directory, passed through the transformation, and then converted into two different files.
There you have it, that’s all there is to it. We’ve completed the interface.
You have just watched us develop and test a functional Replacements interface in 10 minutes. Now, it’s your turn. If you haven’t done so already, download your free evaluation copy of the eiConsole today.