We recently posted a new, five-minute XBRL Overview video on YouTube! Please check it out and let us know what you think!
Tags: diff merge tool, DiffDog, directory comparison, file comparison, Java
A recent message on Twitter asked whether DiffDog can create a differences report. The short answer is yes! In addition to its renowned directory compare and merge, file compare and merge, database compare and merge, and XML diff merge functionality, Altova DiffDog can create differences reports for directory comparisons and for file comparisons. After you select the directories or files and the compare options you want to apply, you can create a report file by choosing Export differences from the DiffDog File menu. This opens a Save File dialog that lets you choose to create the diff report in text format or as an XML file. Text format reports follow the well-accepted Unix diff style. In the directory comparison example report below, the < character indicates a file that exists only on the left side, > indicates a file exists only on the right, and ! signifies file names that occur in both directories with unequal content. Report files in XML format are human-readable with descriptive element names and record the the comparison mode and the paths of the directories compared: You can also use the DiffDog directory report functionality to create diff report files for comparisons of Zip archives or OOXML documents. Developers and other project stakeholders often want to keep a record of changes to source code files in a software project. DiffDog can create diff reports for all comparisons of text-based files, including source code files. DiffDog can even create detailed XML-aware reports for XML file comparisons. The illustration below shows two versions of a Java source code file: If you read our earlier series on Reverse Engineering an Existing App with Altova UModel, you may recognize this code. Lines 8 and 9 on the left introduce a new class property called fee that is set to an initial value of 2. Here is the file compare report for the differences shown above in text format: And the XML version of the report for the same portion of the files: You can even execute DiffDog from a command line to create differences reports automatically. Here is an example of a short batch file that compares the same two directories from our GUI example and writes the output in XML in a file named diff_1.xml: The DiffDog Help system includes extensive documentation on all the command line options, including specific instructions on how to integrate DiffDog with 19 popular source control systems. If DiffDog report files get your tail wagging, don’t just Twitter about it! Click here to download a free 30-day trial of Altova DiffDog.
Tags: Altova, data mapping, HL7, MapForce
When mapping HL7 EDI components, it is often necessary to add locally-defined information, or z-segments, to accommodate additional fields not included in the standard. Following is a simple walkthrough that will demonstrate how to add z-segments to the HL7 configuration files that are available as a free download with MapForce. In the example below we will be adding a ZLR segment to an HL7 2.3 Observation Results Unsolicited (ORU) message. The ZLR segment is commonly used for adding additional information for legacy laboratory-based reporting. ZLR attributes are provided below:
|SEQ||LENGTH||OPT||DATA TYPE||ELEMENT NAME|
|1||106||true||XAD||Ordering Provider’s Address|
|2||90||true||XON||Ordering Facility Name|
|3||106||true||XAD||Ordering Facility Address|
|4||40||true||XTN||Ordering Facility Phone|
|6||40||true||XPN||Next of Kin/Associated Party Name|
|7||40||true||CE||Next of Kin/Associated Party Relationship|
|8||106||true||XAD||Next of Kin/Associated Party Address|
|9||40||true||XTN||Next of Kin/Associated Party Phone|
The ZLR segment must follow each OBR (Observation Request) segment, and there can only be one ZLR per OBR. 1. Go to C:Program FilesAltovaMapForce2009MapForceEDIHL7.v230 to access the MapForce configuration files for HL7 version 2.3. 2. First, locate the message configuration file in question, ORU_R01, and open it in XMLSpy – or any text editor.[i] Add a ZLR just below OBR. 3. Save this file as ORU_R01_ZLR (or any unique name you choose). 4. Now open the EDI collection file and add the new message to the list.[i] 5. Next, simply open the HL7 SEGMENT file to add the segment details to the GENERATE DATA section as provided above.[i] 6. Finally, scroll down to the GENERATE SEGMENTS section and add the following: 7. Now, let’s access our newly customized HL7 EDI mapping component in MapForce. Open MapForce and choose Insert > EDI. In the Browse EDI collections dialog, select HL7.v230 and scroll down to select ORU_R01_ZLR. Press OK to insert. 8. Your new mapping component will appear in the MapForce design pane with the new ZLR segment included. Now you can complete your data integration design by inserting another source or target data structure(s) and dragging lines to connect nodes. MapForce supports mapping to/from XML, databases, flat files, EDI, XBRL, and Web services. [i] If you are working in XP, you will have to unclick “read-only” in the Properties dialog. Vista users will need to copy the file to another location before editing – you can then copy the file back to the appropriate HL7 collection directory. For more information about mapping HL7 and other EDI formats, please see the MapForce feature pages – or download a 30-day free trial of MapForce today!
Tags: Altova Online Training, XBRL
We have recently updated Altova’s MissionKit XBRL online training course, which debuted in May, to make the XBRL filing process as accessible to accountants and financial professionals as it is to more technical users. The new course includes easily identifiable “Accountant’s Notes” to make key XBRL concepts more transferable for those with an accounting background. An updated glossary also includes more accounting-friendly definitions of XBRL concepts to help you ease into the XBRL filing process. Access Altova’s MissionKit XBRL course now. (Yes, it’s free!)
Tags: Altova, data mapping, MapForce, XBRL
Having recently returned from a short visit to the 19th XBRL International Conference in Paris, I can’t help but think that many organizations are simply missing the point – and that perhaps the SEC mandate is partly to blame for this. One would think (well, I thought, anyway) that in the year following the issuance of XBRL reporting requirements by the world’s largest economy, that this conference would be overflowing with company representatives eager to learn more about how, and best of all, why they should mark up their financial data in XBRL. But alas, this was not the case. I can only guess that the meager attendee numbers – especially from the United States – have to do with the fact that organizations are still viewing XBRL as singularly a compliance issue and are continuing to outsource the “tagging” of their financial statements to financial printers or other EDGAR filing entities. So, is XBRL a compliance issue? Well, of course it is, but it is much more than that. I can tell you this for certain because I work for Altova and we simply do not focus on compliance software. We build tools that help businesses to maximize the efficiency of their internal processes with an eye toward reducing the overall time and cost of the data management workflow. And this is well within the realm of possibility for any company using XBRL – but it means taking a proactive look at the way you manage your data. “Tagging” implies that financial statements are drawn up in the traditional manner in a spreadsheet or accounting program and then retroactively and meticulously marked up with XBRL tags to make them compliant. Ugh… no wonder compliance has such an ugly ring to it! Haven’t we all got enough work to do? And wait, isn’t this just adding one manual task on top of another – doubling the chances of human error? I’m not sure exactly when this word “tagging” became so popular for describing XBRL implementation, but all it has done is succeeded in oversimplifying something that was not very complicated in the first place (admittedly, it was probably coined by someone in the marketing tribe – of which I’m a member). Anyway, let’s put this idea of tagging aside and see if we can come up with something a little more dangerous. Let’s say that all of your company financial data resides in some sort of backend repository, a database, accounting/ERP system, XML, or even some combination of these. What if you could simply map your data to XBRL in-house instead of having external consultants comb through reports and tag each line item? What if you could even reuse this mapping the next time you had to produce a similar financial report? And what if you could even have your IT department automate your XBRL filing processes?
XBRL Mapping Altova MapForce is an enterprise-level data integration tool that lets you do just this. It is used at a high level by developers and application architects, but its easy-to-use graphical interface makes MapForce accessible to anyone with an understanding of the data that needs to be mapped. Let’s look at a partial example to illustrate how easy this can be: The first step is to load insert the source data component – in this case a database – into the MapForce design pane. Note that the mapping component is a representation of the tables and columns in the database, the underlying data can, therefore, change at any time and the mapping itself will not be affected. The same is true for any mapping structure that you use in MapForce – XML, databases, flat files, EDI, Excel, XBRL, or Web services. Next, we’ll add our target mapping component, in this case a basic XBRL extension taxonomy built on top of US GAAP – Commercial and Industrial. Now, we can simply begin the mapping by connecting lines to associate line items. There will be some cases when we need to apply data processing rules to slightly modify the format, filter data, or even add constants for XBRL reporting requirements that do not exist in the database. All of this is very easily done by dragging and dropping intermediary functions from the MapForce library in the sidebar. Let’s say, for example, that your database automatically requires a datetime format to record any accounting period. Since XBRL reporting only requires a date, we need to strip the time out in our mapping. So, simply drag a date-from-datetime function from the library and connect the lines between your database and XBRL component. Of course, you’ll probably also need to add a variety of other math, logical, or other types of functions to your data, and you will find a long list of these already available in the function library.
You can also easily add custom functions, if needed, using a graphical function builder. In the end, your mapping will look something like this: Now just hit the Output tab to see what the XBRL looks like. And there you go… a reusable, extensible data mapping that you can run any time you need to submit XBRL data. You can even integrate the mapping interface into another application, or ask IT to generate code that will automate the XBRL file generation each time a report is due. For a more detailed overview of how XBRL mapping works in MapForce, check our Altova’s XBRL tutorial.
So, here we have a very quick example of generating XBRL directly from an accounting system – no need for re-keying information, no need to create a set of traditional financial statements, and certainly no need for “tagging”. And best of all, all of this can easily be done in-house and at a fraction of the cost. Now don’t get me wrong, outsourcing could very well have a place in your company’s XBRL implementation. Building an XBRL extension taxonomy, for example, could very well be something that you feel more comfortable leaving to those who have years of experience working with XBRL syntax and other complexities. But putting your organization’s financial data into XBRL… shouldn’t that be left to those who know the data best? For more information on the Altova MissionKit tools for XBRL – which includes support for XBRL mapping and automation, XBRL validation and taxonomy creation, and XBRL rendering – please visit https://www.altova.com/solutions/xbrl-tools.html …or download the Altova MissionKit today!
Tags: Altova, Altova XMLSpy, Case Study, DatabaseSpy, DiffDog, MapForce, MissionKit
XMLSpy and the other tools in the Altova MissionKit are well-known in the development community as the go-to toolset for XML, data integration, UML, and database development projects. But Altova tools are also used by IT professionals to efficiently complete a variety of enterprise support tasks: XMLSpy is an advanced tool that makes XML documents easy to navigate and edit. Do you use XMLSpy to edit or validate any of the wide variety of XML configuration and data files increasingly essential to today’s IT environments? MapForce integrates and maps data between any combination of XML, databases, flat files, EDI, Excel 2007, XBRL, and/or Web Services. Have you ever used MapForce to merge an end-user’s Excel data into a database? DatabaseSpy is the unique multi-database query, design, content editor, and comparison tool selected as Roundup Champion by Redmond Magazine. Have you used DatabaseSpy to browse an unfamiliar database or build a SQL query to get a quick answer? And who could forget DiffDog? At every trade show visitors come to the Altova booth to rave about Altova’s file, folder, and database diff/merge tool. Do you depend on DiffDog to quickly identify changes between the live instance of a mission-critical file or folder and a backup copy? If you’re an IT professional who uses Altova tools to support the technical infrastructure of your enterprise, we’d like to hear your story. Click here to visit the Altova Case Studies page and check out the right margin to contact us. Of course you can comment right here too!