Welcome to this demonstration of ACORD Based Automated Vendor Invoicing with the eiConsole. Over the next few minutes you’ll see how the PilotFish eiConsole can be used to produce and consume ACORD AVI transactions, the TXLife 118 and 1119. Let’s look at the submit invoice interface, the ACORD 118.
In this route we’ll be accepting a typical Microsoft Excel spreadsheet which might contain thousands of rows of invoice level detail. Rather than sending invoices out in this human readable format, the service provider and their carrier client have elected to automate the process.
In order to minimize the impact on existing systems, the spreadsheet will be produced as it always has been. The eiConsole Directory / FIle Listener was selected to pick up this Excel spreadsheet from a pre-determined network location.
Every so often the Listener will poll for this file and when it finds a spreadsheet will move it along to the Source Transformation stage.
In the Source transformation stage the spreadsheet is effortlessly converted to XML using the Microsoft Excel Transformation Module.
With the generic XML representation now available, XSLT is now used to logically map the columns from the spreadsheet onto the desired ACORD 118 transaction.
The Data Mapper is used to map the values from the spreadsheet (you can see the column headers displayed here) onto the structure of the ACORD transaction (you can see the ACORD model on the right).
The values are dragged and dropped together to create the mapping pane that you see in the middle. Green nodes indicate XML elements that are going to be in the resulting ACORD transactions, and the blue nodes represent the values that are being pulled in from a given row on the spreadsheet.
You’ll also see yellow nodes indicating conditional logic.
Conditional logic, special formatting, concatenation, etc. is handled by pulling down values from the pallet of functions above the mapping.
So we’ve gone through and dragged-and-dropped to create this mapping. Under the covers W3C standard XSLT has been generated. Now, once the Excel spreadsheet comes in, as it is translated into an XML format, it will be translated via XSLT into an ACORD transaction.
The data then moves along to the Routing stage, where in this case we route the data to two target systems. The first Target does no further transformation of the data…
And stores a copy of the ACORD 118 XML transaction in the specified Directory using our Directory / File Transport.
The second transform also leaves the information untouched and then submits the XML via WebService using our HTTP Post Transport. The carrier will then receive the invoice and process it.
Now let’s take a look at this in action. Switching to Testing Mode of the eiConsole, we can begin our test with the Source Transform.
We’ll also stop our test right before we call out to the Carrier client (we don’t want to inadvertently send any information into a production environment).
When we click Execute Test we can select a sample spreadsheet. When we click Open it will flow through each stage in the process.
Each successful stage is denoted by a green checkmark. Had there been a failure there would be a red X.
Now we can look at the data as it appeared at each stage. First, here’s the Excel spreadsheet.
The spreadsheet was then processed and converted into an XML representation. Each row that you see is represented by an XCSExcelRow tag with the column headers used for the tag names underneath.
Then, we used XSLT to map this into an ACORD 118 transaction. The 118 was then dropped in a directory and we stopped just short of calling the Web Service.
Of course, once this interface has been tested, it was deployed into an eiPlatform server environment using the Server view of the eiConsole.
Automated Vendor Invoicing for the eiConsole also includes an ACORD 1119 transaction template that allows you to handle the invoice status message that will come back from the carrier client.
This concludes our demonstration of Automated Vendor Invoicing with the eiConsole.