how to maintain the numberFormat ?


I have already tried to change the script like the table below, need help.

Also, how to handle the format of the crossover column or row as pic1?

the TM1 format to show 87.2% would be “c: #,###.0%;(#,###.0%);”-";
and for 2.3 would be “c: #,###.0;(#,###.0);”-";

That is assuming you want negative numbers in parentheses and zero to display as -

The format for number formats in TM1 respects the conventions of Excel. That is
positiveFormat ; negativeFormat ; zeroFormat ; stringFormat

If entering formats via Rest UI I believe there is a bug which will chop off the “c:” or “b:” from the front of the string (for “custom” and “built-in” formats). Not sure if the formatting is still correctly applied without this in native TM1 UI but in UX we ignore this part of the string anyway and only worry about the format itself. Note in UX we only render formats for row and column dimensions, with column having priority. Format attribute on filter and fixed dimensions is ignored.

In TM1 and Excel number formats a “0” indicates a mandatory display regardless of available significant figures of non-formatted value whereas “#” indicates only when unformatted value has (at least) this level of precision. For example a raw value of 9.45 will display as
09.450 with format “#,#00.000;-#,#00.000;0”
9.45 with format “#,##0.##;-#,##0.##;0”
9.5 with format “#,##0.#;-#,##0.#;0”

@cw-ch Thanks for your reply.

You mention in UX only render formats for row and column dimensions, how about the customize row or column by user insert? (version 2.5.1: insert a row/a column like Excel)

While the user inserts a new row or column in UX, in [Setting] page the script will be generated as below, but it can not work as well?

I think formatting for inserted rows and columns might be something we are still working on. I need to check. @tganz

@cw-ch Got it and looking forward :grinning:

In this instance I think you would be much better off defining CONSOLIDATIONS for “Q2-Q1” and “Q2-Q1%” (the latter with feederless rule). I think this type of calculation would make much more sense to be doing in the TM1 db side and not as a patch in the front end.

Understand, this is the example of formatting setting and the extract information the end-user might ask