A few weeks ago, I did a blog post introducing the “EDAC” functions in Legato with a very brief example of how to create an NPORT filing and fill in a few fields. Well, I thought we would take that a few steps further, and show how you can use that to create an import function for a complex table like the Part C section of NPORT. This table is fairly involved because it has three possible layers of sublists (lists contained in other lists), and we’ll need to keep track of this. Therefore, this blog is going to discuss a lot of “level 1”, “level 2”, and “level 3” tables, all of which occur within a single data table. To help visualize what exactly is meant by these different levels, take a look at this screenshot from GoFiler:

In our recent blog series discussing Bulk Filings, we used a couple of functions to open and save files, EDACOpenFile and EDACSaveFile. EDAC, or the EDGAR Data Access Class, is a method to interact with EDGAR submission files (as defined by the SEC’s EDGAR Form XML specifications) using Legato. We used EDAC functions to open the submission files and to save them, but EDAC is much more powerful than that. In fact, using the EDAC functions to open and save files is like using a chainsaw to trim a finger nail.

Last week, Dave added to our Bulk Filing script, giving it the ability to add folders and to detect if it’s going over the maximum allowable size from the SEC. This week, we’re going to do our final update on this script and develop its ability to actually file to the SEC. As part of this, we’re going to read back the SEC’s response, determine if it’s an error or a success, and if it’s a success we’ll parse the accession notices out and create an output file that maps the accession number to the original file. This will be very handy in case one of the filings comes back suspended, so you can just look up the accession number of the file to see which one failed.

Last week, Dave went over how to build a basic UI for our Bulk Filing function. This week, we’re expanding that a little bit by adding a “clear all” function to drop all items from the list, a “LIVE” checkbox to mark our submission as a live filing, and a setting to store the previously chosen files to reload if we need to rebuild the filing.

EDGAR 18.3 was released on October 1st, 2018, and while most of its features are clearly documented, one change that was made seems to have flown under the radar of most people. Starting with this version, all facts created with elements of data type StringItemType are no longer rendered as HTML. Instead they are rendered as plain old strings. While this makes sense (and does close some potential security risks on the SEC’s side), it does effect how people are doing XBRL. For example, most people doing Risk Return taxonomy filings use <B> tags to make their heading items bold. This is no longer possible, because it would come out rendered like:

Writing new scripts can make tasks faster and easier than ever. Back in July, we talked about a script that can map endnotes in an HTML file to the correct page from which they came and move them there. This makes moving the endnotes to their proper positions faster and significantly easier than copy/pasting text around by hand. As we automate functions, we begin to rely on those functions working a specific, predictable way. If our scripts cannot be counted on to work correctly, then we didn’t really make anything faster or easier, did we?

Last week, we added a modify dialog for our page break style manager, to let us rename and delete page break styles. This got us to a point where we have what I’d consider “minimal functionality” required to have a useful script, but let’s take it a step further, and add in a re-order function. It’s very useful to be able to shuffle the order around so you can have all styles, for a single client, grouped together. You don’t have to constantly search through a list anymore. While we’re at it, we can add in functionality to disable buttons if they are not applicable to our selection. For example, if we don’t have a selection, everything should be disabled. if we have the top list item selected, the move up button should be disabled, because we obviously can’t move the top item up even higher. The opposite applies to the bottom selection.

Last week, we discussed how to add page breaks into the page break template with a Legato script. As useful as that is, without a way to delete them or rename them, the function isn’t really complete. To do that, we’re making a page break manager this week. This will give us a new menu option, “Modify Page Break Templates”, which lets us manage our stored page breaks.

This is a script I’ve wanted to write for a while, because it makes it significantly easier to use custom page breaks in GoFiler. For a long time, GoFiler has supported page break style templates, which let you save and customize a list of page headers and footers. Using this script, you’ll be able to add, remove, and edit entries in that template file without having to edit the HTML.

This week, we’re going to take a closer look at a script that’s been in GoFiler for a while as a base script, but has been through several revisions. This script, the Endnotes to Footnotes converter, takes endnotes in an HTML file and moves them to the appropriate page in the HTML file. These endnotes are common if you have a Word file that has been converted to HTML, that had footnotes in it. They are often converted as endnotes, and putting them back where they belong can be annoying if you have to do it manually.

A pretty common task in any document editing environment is running find and replace operations. If you have a character that’s repeated, and you want to replace every instance of that character with a different character, then running a find and replace is the fastest way to do it. What happens if you need to execute these operations many times on different documents? You could run Find and Replace and type the information in each time but it’s often a much easier solution to just write a small Legato function. You can execute the Legato function from the Tools menu to run a common find and replace operation. I know in previous blog posts I’ve done similar scripts to replace wingdings characters with character entities, or to replace certain inline tags with other inline tags. For this week’s blog script, I took those previous scripts and made a more generic version, that can be easily modified by anyone to do different find and replace operations.

Legato is an interpreted language, but even so, it performs quite quickly. Most scripts will execute within a second or so, even if it’s the script contains relatively complex HTML parsing or something similar. However, occasionally there are scripts that iterate over extremely large data sets, or work with file IO, or really do anything that can take a long time. If the script is just running, unless you put up some sort of a progress bar, it might look like the application has frozen to the user. Therefore, it’s really important to put up a progress bar to let the user know what’s going on with the script. I’ve put together a simple example script of a progress bar below, but let’s talk about how to use one first.

Back in February, I wrote a blog post about how we can use the XBRL Object in Legato to do some extra validation on XBRL. In that blog we added a check for the number of custom elements. That was a relatively basic application of XBRL in Legato though, not very complicated. What if we want to do something a lot more in depth? For example, check to ensure we’re not defining any cyclic presentation relationships. By that, I mean that you have a dimension - member pair in a context, but in the presentation properties for a presentation where that context appears the domain for that dimension is set to the same member. That’s a cyclic relationship; saying something is it’s own parent element. This isn’t Futurama, you can’t be your own grandfather in XBRL.

This week, we’ll be introducing a script that adds a very handy feature to GoFiler: the ability to save, load, and edit preference templates. These preference templates will include settings like your EDGAR credentials, HTML conversion settings, and default options for edit windows.

One common task when working on an HTML document in GoFiler is to save different versions of the file. Every time a copy is sent out for review, users can do a save as operation, and save a new copy of the file with a different version number. GoFiler by default allows you to create backup copies of the file (.bak files) whenever you press the save button, but that’s often too many backups, and they don’t represent true versions. The example script in this blog post then attempts to automate the process of creating different versions of files. This script will trigger when the user presses the “To Browser” button on an HTML file, and ask if the user wants to create a previous version folder of this file. If the user presses “Yes”, the script makes a new folder called “Revisions”, puts a folder stamped with the version number, date, and time into it, and copies all the HTML and images out of your folder into this previous version folder.