Release of the STIC Taxonomy for SuperStream Release of the STIC Taxonomy for SuperStream

ATO has replaced the taxonomy previously used for tax file number lookups for SuperStream (VFMI) with a new taxonomy called Super Tax File Number Integrity Check (STIC). Full details of the STIC taxonomy (including the MIG) can be found at:

http://www.sbr.gov.au/software-developers/developer-tools/ato/ato-superannuation-data-and-payment-standards/stic

The taxonomy is in the sbr_au_reports\ato\stic directory of the 2013.02.28 SBR taxonomy release which can be downloaded from:

https://www.taxonomy-collaboration.sbr.gov.au/yeti/resources/yeti-gwt/Yeti.jsp

The STIC taxonomy has a number of differences from the original VFMI taxonomy, including:

  • Elimination of tuples
  • Removal of one of the contexts
  • Removal of some elements
  • Addition of new elements
  • Changes in namespaces
  • Changes in the scheme names within the contexts
  • The Super Fund Member details are now spread across two contexts as details include both instant and duration periodTypes

To use the new STIC taxonomy with our software, you will need to re-run tdschemaextractor to create a new typed dimension class.

To assist users of our software, we have modified the previous TFN lookup sample application (CreateTFNLookupRequest) to work with the new taxonomy - CreateSTICLookupRequest.java. We have also created a heavily commented version which will show you the differences between CreateTFNLookupRequest and CreateSTICLookupRequest. Please click on the following links to download the samples.

CreateSTICLookupRequest.java

CreateSTICLookupRequestWithComments.java

Please let us know if you encounter any issues.

Pete Campbell - peterc@fast.fujitsu.com.au

 

New Release of the SBR Taxonomies - 2013.02.28 New Release of the SBR Taxonomies - 2013.02.28


Do It Yourself (DIY) XBRL - Is There a Better Approach? Do It Yourself (DIY) XBRL - Is There a Better Approach?

I've been working with  global XBRL implementations over the past eight years and sometimes get into discussions with experienced software developers in regards to the "buy or build" argument. Obviously this argument isn't unique to XBRL and, being a software developer myself, I totally understand developers questioning the need to use a specialised XBRL package to create "a simple XML document".

Typically I hear comments which can be summarised as - "All we need to do is build a simple XML handler which can generate the XBRL instance documents which SuperStream mandates. They're just XML documents which need to conform to a schema. How difficult can that be?"

While understanding such comments, I don't believe that the requirement to create XBRL instance documents consistently and reliably is quite that simple. The document below is my response to the questions which have been raised with me over the last eight years and, I am happy to admit, reflects my personal opinion. I would also like to highlight that I have more than a personal interest in the topic as the company I work for has a set of commercial XBRL offerings!

Pitfalls with DIY XBRL Processors