Copyright ©2009 XBRL International Inc., All Rights Reserved.
Circulation of this Working Group Note is unrestricted. Other documents may supersede this document. Recipients are invited to submit comments to gl-feedback@xbrl.org, and to submit notification of any relevant patent rights of which they are aware and provide supporting documentation.
1 Language independence
2
Introduction
3
Background
4
[measurable] For Attributes
4.1
Case 1: When [measurable] refines [account] or [identifierReference]
4.2
Case 2: When [measurable] describes [measurable]
4.3
Case 3: When XBRL GL is the envelope and a specific standard is the content
5
Future capabilities
A Intellectual property status (non-normative)
B Document history (non-normative)
C Errata corrections in this document
The official language of XBRL International's own work products is English and the preferred spelling convention is UK English.
The Color Purple. "A-B-C". "Five foot two and eyes of blue." What do these things have in common? They are all kinds of information people may wish to collect about employees or inventory that do not have a specific data field in XBRL Global Ledger (GL) today.
There have been requests for new representation capabilities of XBRL GL such as moving into even more detail in inventory management, payroll and fixed assets. This has encouraged us to discuss how to best use existing XBRL GL structures, in particular the [measurable] structure, for capturing new attributes and discuss philosophical issues related to expanding the taxonomy.
XBRL's Global Ledger has hundreds of data fields and dozens of reusable structures that, by using enumerated fields and freeform fields, can represent a wide variety of information found in a typical ERP system. Through the use of concepts that take on special meanings under specific circumstances, the four hundred elements in XBRL GL take on the meaning of thousands of specific fields with no ambiguity.
By design, XBRL GL was created to be modular, and to facilitate growth to represent more detailed information. That growth needs to be controlled and in conformance to the XBRL GL Philosophy. That means that adding a new element must be preceded by asking how that element can bring more power to XBRL GL as a whole, not just meet one specific purpose. At the same time, reducing as much ambiguity related to the use and understanding of that field in an automated fashion is required.
As a taxonomy whose genesis preceded the XBRL effort, some of the existing XBRL taxonomy could have been more generically designed. For example, at the [entryDetail] level, there are a series of dates associated with the order process. These include [dateAcknowledged], [confirmedDate], [shipReceivedDate] and [maturityDate]. In practice, these elements are reinvented for other uses - for example, [dateAcknowledged], primarily used to capture the data that the receipt of an order or other exchange is acknowledged by a trade partner, can be used as an "approval" date for journal entries.
A [entryDetailDateStructure] tuple could have been developed at the [entryDetail] level that would have allowed for easier expansion of dates at this level, using enumerated values for the nature of the date. Many new fields that we are looking at related to payroll and fixed assets are date related, and very specific to their discipline: "date of last raise", "date of last review", "date of last discipline". On the other hand, you can find starting and ending dates/times in both the [measurable] and [depreciationMortgage] structures which can be used for that very purpose.
The [measurable] structure is by design an incredibly flexible structure, meant to capture quantitative and qualitative data that is associated with a code or category. As such, it can be used as a generic holder for all of those strange and otherwise overly specific data fields unique to certain areas of business reporting, such as size, color or importance. [ 1 ]
A brief review of the [measurable] structure:
| Measurable | Required parent |
|---|---|
| measurableCode | An enumerated field that helps describe the use of a specific instance of the [measurable] structure. Not a required field, but best practices would call for at least the use of {OT} for "other". |
| measurableCodeDescription | A freeform field to augment [measurableCode], provide definition when using {OT} (other), or provide a broad description of the use of the [measurable] tuple in lieu of a [measurableCode]. |
| measurableCategory | The field for "product category", or some similar sub-classification of [measurableCode] and/or [measurableCodeDescription]. |
| measurableID | A primary identifier code, such as an internal code for identifying inventory. This is most likely the "internal ID", the company's code for the item. |
| measurableIDSchema | A URI that is associated with the [measurableID], especially useful where the [measurableID] is part of a formal list, such as a taxonomy. |
| measurableIDOther | A secondary identifier code, such as a UPC code, a manufacturer’s ID, a bar code, or a sub-classification. Normally an alternate identifier to [measurableID], it might be used to supplement the [measurableID] as a supplemental classification. |
| measurableIDOtherSchema | A URI that is associated with the measurableIDOther. |
| measurableDescription | A description of the measurable item. |
| measurableQuantity | The quantity for this measurable item, and this should not be a monetary amount. Note that the monetary amount associated with this measurable (or multiple measurable lines if more than one is associated with an entry detail line) is represented elsewhere - in the [amount] at the [entryDetail] level. |
| measurableQualifier | Used in conjunction with or instead of the [measurableQuantity], this provides a place for qualitative/textual information. |
| measurableUnitOfMeasure | The unit of measure associated with the [measurableQuantity]. |
| measurableCostPerUnit | The cost per unit associated with the [measurableQuantity]. The extended amount [measurableQuantity] * [measurableCostPerUnit] would be represented with the primary [amount] if provided. |
| measurableStartDateTime measurableEndDateTime | Most often associated with human labour and machine time, [measurableStartDateTime] and [measurableEndDateTime] are used to capture the period of time associated with the labour/machines expended. This is primarily when [measurableCode] is {SV-P} or {SV-M}. |
| measurableActive | A Boolean (true/false) to indicate whether the subject of this specific instance of the [measurable] structure is "active". This often is used to filter lookup lists and reports or to limit the use of the record in new transactions. |
The [measurable] structure can be repeated numerous times within an [entryDetail] line in order to communicate many quantities or qualitative information pertinent to the focus of the [entryDetail] line.
Looking specifically at the classification identifiers in the [measurable] structure, you will see a hierarchy (from least to most specific):
There are three primary cases we need to consider when we are looking for additional attributes:
In our first case, such as when collecting information about an employee, we use the fields higher in the hierarchy described above in order to collect information. The [measurableCode] can be {KPI} or {OT}, the [measurableCategory] and [measurableID] can come from company, industry or market lists, and the values places in [measurableQuantity] or [measurableQualifier]. As XBRL (and especially XBRL GL) were not designed to compete with industry standards, it would be a goal to have as much of this detailed information represented with a specific industry standard (e.g., HR-XML) and then to link and reuse.
In such a case, where we wish to communicate than an employee is "five foot two with eyes of blue" [ 2 ] , an [entryDetail] line containing an [identifierReference] structure for an employee might have measurable structures where:
Structure 1:
[measurableID] = height
[measurableQuantity] = 62
[measurableUnitOfMeasure] = iso31-1AxA:inch
Structure 2:
[measurableID] = eye_color
[measurableQualifier] = iso31-6:blue
[
3
]
or
[measurableID] = eye_color
[measurableQuantity] = 475
[measurableUnitOfMeasure] = iso31-6:nm
Of course, other fields might also be used - [measurableCategory] could be used for personal, as opposed to job-related, statistics, as one example.
The flexibility and choice of using the [measurable] structure to add representational capabilities is, under my current thought pattern, more limited. There is no "primary focus" flag for a [measurable] tuple, so the reuse of anything more specific than [measurableID] in a secondary [measurable] tuple could bring confusion. That would leave the [measurableQualifier] as the primary tool for adding new data fields without extension.
Looking at two examples cited above, XBRL GL does not currently capture "color", such as "purple" (possibly relevant for inventory and supplies; probably not relevant to person or machine services). Likewise, it has no set field for an ABC analysis [ 4 ] .
One approach would be to emulate the approach used above - use a [measurableCode] of {KPI} or {OT} for the structure (rather than, for example, the primary {IN}, and then take advantage of the hierarchy. (I have an intuitive problem with this approach, as this is just supposed to be an extension of the primary {IN} item, but I am not fully sure why. It seems like the higher hierarchy items should be explicitly the same as - or inherit - the values from the primary [measurable] structure.)
The other would be to use the [measurableQualifier] in an agreed-upon fashion. For quantitative information, the [measurableQualifier] would hold the description of the data, while the content would be entered into [measurableQuantity]. For qualitative information, both description and content would need to be contained within the [measurableQualifier] textual field, perhaps in the forms:
"color | purple"
"color=purple"
and multiple values could potentially be placed in one or multiple [measurable] structures:
"color=purple; abc_code=a"
XBRL GL is not in competition with industry or domain specific standards, but rather aims at integrating their representational power in the business reporting supply chain (BRSC). When the data being represented requires the use of very specific attributes for which a standard representation already exists (for example, HR-XML [ 5 ] , MISMO [ 6 ] or ACORD [ 7 ] ) the use of XBRL GL as a container for the representation of those attributes in the appropriate standard allows to fully leverage the benefits of both:
The current capabilities of XBRL GL allow to store the physical location of the document that contains the non-XBRL GL data in [documentLocation]. This is enough only when there is no ambiguity around the meaning of the non-XBRL GL data and how they fit within the XBRL GL envelope. For example, if the XBRL GL instance represents an employee timesheet and the [documentLocation] points to an HR-XML file that represents attributes of one employee no additional information is required to relate the two sets of data.
This unambiguous situation obviously occurs only on a limited basis. Normally the XBRL GL instance represents more structured data, and additional tools are necessary to precisely relate the XBRL GL and non-XBRL GL content. For example, if the XBRL GL instance represents a listing of employees, a way to relate each of them with the corresponding data within the HR-XML instance will be required.
This could be achieved through the ability to store an XPath expression in an additional element [documentReference] at [entryDetail] level. The XPath expression would provide the capability to create an explicit link between a subset of the non-XBRL GL data and a specific element/structure in the XBRL GL instance.
Other additional elements that would be very useful in this context, and that have been proposed in the past [ 8 ] as support to the capabilities of XBRL GL to facilitate a complete and reliable electronic audit trail, are:
"[documentHash] and [documentHashMethod]: This would allow the storage of a cryptographic hash (a relatively unique fingerprint of an electronic file) and the method used to create the hash (such as SHA-1) so the auditor knows that an electronic file provided is the same one as the file used to trigger the original transaction
[documentStore]: This would specifically allow a text, xHTML or base 64 encoded binary representation of the original document."
Together, these new elements would provide a powerful toolset to reference source/external documents and help accomplish the main goals of XBRL GL: bridging from transaction to end reporting, facilitating a seamless audit trail and supporting data integration.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to XBRL International or XBRL organizations, except as required to translate it into languages other than English. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy ( www.xbrl.org/legal ).
This document and the information contained herein is provided on an "AS IS" basis and XBRL INTERNATIONAL DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The attention of users of this document is directed to the possibility that compliance with or adoption of XBRL International specifications may require use of an invention covered by patent rights. XBRL International shall not be responsible for identifying patents for which a license may be required by any XBRL International specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. XBRL International specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. XBRL International takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy ( www.xbrl.org/legal ).
| Date | Author | Details |
|---|---|---|
| 24 June 2008 | Eric E. Cohen |
Initial document. |
| 28 July 2008 | Gianluca Garbellotto |
Case 3 added. |
| 02 June 2009 | Gianluca Garbellotto |
Editorial review. |
This appendix contains a list of the errata that have been incorporated into this document. This represents all those errata corrections that have been approved by the XBRL International XBRL GL Working Group up to and including 03 June 2009 . Hyperlinks to relevant e-mail threads may be followed only by those who have access to the relevant mailing lists. Access to internal XBRL mailing lists is restricted to members of XBRL International Inc.
No errata have been incorporated into this document.