I’m working on a web app for craft breweries. The app will help them file information about their production to the US TTB (Alcohol and Tobacco Tax and Trade Bureau) Midway through I realized it’s a perfect opportunity for iXBRL.
(It should look and behave fine in Chrome, Firefox, and IE8 or above)
I should look like the PDF published by the TTB. (If it doesn’t, let me know your browser information)
Now use your browser to check under the covers; there’s iXBRL in there!
(As of the time of writing, the iXBRL is not complete. It needs improvements:
precision /decimal attributes of valuesNow decimals=”2″ unit attributes of valuesNow units are in ttb:bbl (Barrels). Can I use the UTR’s bbl? Is that the same unit used to measure gas? formatting informationI now use format=”ixt:numdotdecimal“; I think MassiveDynamic is out-of-date; it still uses “ixt:numcommadot” proper XHTML contents (they have input children in my example, I don’t think that’s allowed)I put <ix:nonFraction> inside of <p>
- correct calendars — currently uses only duration context which is 43 years long. These filings are quarterly, monthly, or even more frequent.)
- instant contexts for start and end dates
and of course, actual values!)
This form eliminates so much complexity of the SEC XBRL domain I’m used to:
- It’s fixed in data needs; no extended elements. Except maybe for the “Other” line-item.
- It’s a fixed in presentation; presentation is fixed. Marginal or no value added by a Presentation Linkbase.
- Both of the above points make iXBRL a great choice
- All values must be positive. It’s a no-brainer.
- There is only one reporting period. Like a single column of a Cash Flow Statement.
- Patterns are not complex. It is a basic roll-forward pattern. (Again, the Cash Flow)
Maybe you’ll say eliminating complexity makes this a contrived application of XBRL. Au contraire. I think it’s a wonderful application. But I’m not sure why, just yet. I want your opinion. Do you like the way I’ve “tagged” this data? In other words, do you like the way I’ve modeled it?
You don’t need any experience with brewing to understand how this form works. The top tracks increases, the bottom tracks decreases.
This picture gives a visual of how I’ve “tagged” the data, in case you’re wondering.
I explain the tagging in the context of rows (left), then columns (top).
Then you see how these overlap to affect a single cell (bottom-right).
- Before iXBRL, this cell would probably be called “Row 1, Column C”.
- Now, with iXBRL, it can be given meaningful business coordinates : “Beer_Balance, Racking, Bulk”.
- I chose to use members for the columns.
- I used two dimensions.
- One dimension — ttb:Operations — represents the first row of labels, (Cellar, Racking).
- The second dimension –ttb:Storage — represents the second row of labels (Bulk, Keg).
- Then I used a unique element for every row. Except beer_balance; it’s used twice to express the starting and ending balance (like a Cash Flow statement! These patterns are everywhere!)
I’m especially interested in your take on the use of members.
- Would you have avoided Axes altogether? Without Axes we’d lose the ability to understand the data is tabular, would you agree? I think we’d need a unique element for every cell — so the taxonomy would bloat. On the other hand, this form is unique because certain cells are “greyed-out“, or (notice the class attribute I used) “nullified“. So we would only need unique elements only for those “non-nullified” cells. See more, below*
- Would you have used only a single Axis? There would have been fewer members that way. My two Axes are only kind-of “orthogonal”. For a geeky discussion about what this means, see below.**
Eureka! I think we’ll make XBRL work for the Business of Beer. And all with a lovely IPA in-hand. Cheers to X-Beer-L. Plans for the future include:
- Integrating with iQ (for example, you can identify the row and column intersections [like my screenshot] using nothing but your browser)
- Validating business rules (like the TTB explains in this screenshot)
- Publishing a taxonomy (for the elements, axes, and members I’ve created), and lobbying the TTB to allow iXBRL filing.
Please make a comment below if you support these efforts.
*This is form/business logic at work; it would be nonsense to provide a value for Fermentation Production (Row 2) in Racking, Bulk (Column C). All Fermentation happens at the Cellar stage (Column B).
What’s the best way for XBRL to express that?
- Omit the values altogether?
- Or maybe, include the values as all “nil”?
(I remember many SEC-filers choosing this to encourage the rendering engine to form a table with the values; with iXBRL that is unnecessary.)
I say, omit the values. Then we wouldn’t need as many unique elements for every cell. However, this comes at a cost– since I use members, instead, we need some way to communicate that the user should never use the element ttb:produced_ferment (row 2) with the ttb:operation->ttb:racking, and ttb:storage->ttb:bulk (column c).
**”Orthogonal” means ninety-degree (or, right angles). When I say “orthogonal”, I mean it makes sense to put (two axes) at right angles because there would be meaningful intersections at every point in the “table” which would result. Here is a picture of the “table” which results:
You can see the Axis-Member ttb:Storage->ttb:Bulk is used twice.
- See (c) [ttb:Operations->ttb:Racking]
- and (e) [ttb:Operations->ttb:Bottling].
This suggests Bulk Storage could apply at two different members of the second axis ttb:Operation.
In other words, orthogonal suggests that every intersection of “Bulk” and another Operation is a meaningful intersection.
But this isn’t completely true. Notice that no other storage types intersect more-than-once.
- See (d) ttb:Storage->ttb:Keg might only be appropriate for ttb:Operation->ttb:Racking.
- and (d) ttb:Storage->ttb:Case might only be appropriate for ttb:Operations->ttb:Bottling
This is captured in the my diagram. Only the green cells are represented as columns in the form; Only the green cells are meaningful. Maybe it takes a Brewer to tell me the nature of the table!