Page 1 of 1
TM1 & XBRL Reporting
Posted: Wed Jan 07, 2015 7:21 pm
by 71skyrave
Does anyone has ever developed P&L Reporting in XBRL format using TM1 10.X.X version ???? or Someone knows if TM1 can be use to generate P&L Reporting in XBRL code ???
Regards friends..!!!
Re: TM1 & XBRL Reporting
Posted: Wed Jan 07, 2015 7:25 pm
by lotsaram
Drumroll for Mr MacKenzie.
Re: TM1 & XBRL Reporting
Posted: Wed Jan 07, 2015 10:02 pm
by David Usherwood
Re: TM1 & XBRL Reporting
Posted: Thu Jan 08, 2015 12:24 am
by ellissj3
I agree w/ Mr. Usherwood. CDM is a good choice for TM1 / XBRL reporting
Re: TM1 & XBRL Reporting
Posted: Mon Jan 12, 2015 12:00 pm
by rmackenzie
The exercise roughly splits into two parts - mapping cube data to the expected output of the report per the XBRL definitions, and actually producing the output in some way. As we needed just XML output and DBRW reports the reporting part was , surprisingly for some, the simpler part of the project as our XBRL 'accounts' easily transformed into a dimension. I don't know if it is still on the shelf, but Business Viewpoint can transform XML data as an ODBC source and it's also possible to mangle it into a dimension via TI. Nowadays, I'd tend to expect that there's a general purpose Java library for XML that could be easily leveraged for this purpose rather than going for the roll-your-own-TI option.
The data mapping part for us was seriously non-trivial and there are significant issues using TM1 as a productionised solution for this mapping piece. It was however, a great tool to get a prototype up and running mainly because TM1 guys regularly 'get' finance system problems more readily than our relational cousins. If your 'account' dimension doesn't neatly match the XBRL 'account' dimension i.e. as an alternate roll-up or other straightforward mapping then things can get complex as you need to map specific intersections from part of the non-XBRL-mapped-cube to XBRL-mapped intersections in another area. The clients original architecture envisaged this being done in a data warehouse at the staging -> conceptual level and ultimately built a bespoke mart in the DW to do this with TM1 just sucking in the data. If you are wedded to TM1 or don't have a DW/ custom RDB available (with relevant expertise) then you can have all this fun too. The advice to people looking to engage in this sort of exercise is to sort the mapping out first without paying for systems guys to build something out of nothing - most finance analysts will nail this task quite easily as it's not really any different from having to do a GL1-to-GL2 type mapping as part of a corporate take-over or something like that.
Well, we didn't have CDM back in those days or at least it was early doors for it's presence in the IBM stack. Leastways the pre-sales chaps didn't try and push it. Hopefully it's a good tool for the job - anyone have any direct experience to share? There are all sorts of other tools and APIs out there to solve the reporting aspect - in Australia the government are/ were involved in trying to maintain an API - and someone mentioned to me that Dynamix has been doing this for years and years.... But, the mapping aspect is probably always going to be a customised solution unless you've got some sort of OBI-style pre-set templates, or TM1-ish equivalent, to stage cube data in a format that a XBRL dimension can easily map to an alternate hierarchy of a source dimension. Curious to hear from the other old team members that knock around on this forum if they've got a view on it (Mr FH, I'm looking at you as you had a much better view of the DW->Mart->TM1 than I did for the Sales ledger piece...

)
NB the solution was built in 9.5.1 but it was all Architect based so would stand up in 10.X.X with minimum hassle, I'd expect. You'd also want to pay close attention to the XBRL version you want to target as it has undergone significant maturation cycles. Also there are different XBRL schemas for different corporate finance functions, so depending on what area you are in, this will make a difference to how you go about things as well.