ssm taxonomy architecture document issued by: … xbrl...ssm taxonomy architecture document issued...

SSM Taxonomy Architecture Document

Issued by:

The Companies Commission of Malaysia

May 2014

This SSM Taxonomy Architecture Document will support software developers in

the implementation of the SSMT within their applications as well as to generate

supported XBRL reports.

2

Index

1. Introduction ...................................................................................................................................... 3

1.1 The SSM Taxonomy 2013 ............................................................................................ 3

1.2 Nature and Scope .......................................................................................................... 3

2. SSM Taxonomy Architecture ........................................................................................................ 4

2.1. Scope of SSM Taxonomy Elements ........................................................................... 4

2.2. Taxonomy Architecture Principles.............................................................................. 5

2.3. Data modelling techniques in the SSM Taxonomy ................................................ 7

2.3.1. Hierarchical modelling ................................................................................................... 7

2.3.2 Axes modelling ................................................................................................................ 9

2.4. The structure of SSM Taxonomy .............................................................................. 12

2.5. Absolute and relative paths....................................................................................... 14

2.6. Namespaces and prefixes .......................................................................................... 15

2.7. Core, role and entry-point schemas ........................................................................ 16

2.8. Customised Data Types.............................................................................................. 19

2.9. Linkbases ...................................................................................................................... 20

2.9.1 Presentation linkbase ................................................................................................. 20

2.9.2 Definition linkbase........................................................................................................ 21

2.9.3 Calculation linkbase ..................................................................................................... 22

2.9.4 Label linkbase ............................................................................................................... 22

2.9.4.1 Reuse of IFRS labels .................................................................................................... 24

2.9.4.2 Total and net labels ..................................................................................................... 24

2.9.4.3 Negated labels .............................................................................................................. 25

2.9.5 Reference linkbases ..................................................................................................... 27

3. Style Guide .....................................................................................................................................28

3.1 General Guidance ........................................................................................................28

3.2 Style guide for Extended Link Roles (ELR) ............................................................28

3.3 Style Guide for element name and ID .................................................................... 29

3.4 Style Guide for Label Linkbase ................................................................................. 34

4. References ...................................................................................................................................... 42

3

1. Introduction

1.1 The SSM Taxonomy 2013

The purpose of this document is to define the architecture of the Suruhanjaya

Syarikat Malaysia Taxonomy (SSMT). SSMT is the XBRL representation of

financial reporting submission to SSM, based on Malaysian Financial Reporting

Standard (MFRS), Private Entity Reporting Standard (PERS) and the relevant

requirements under Companies Act1965 and the New Companies Bill.

This SSMT document will support software developers in the implementation of

the SSMT within their applications, as well as preparers in its use to generate

supported XBRL reports.

A certain degree of familiarity with the XBRL 2.1 Specification and related

Specifications such as XBRL Dimensions 1.0 as well as with XBRL terminology and

concepts is a pre-requisite to read and understand this document.

1.2 Nature and Scope

The first version of the SSMT is based on the 2012 version of the IFRS Taxonomy

(IFRS Taxonomy 2012) as issued by the IFRS Foundation. The IFRS Taxonomy

2012 can be found in the IFRS Foundation website at the following link:

http://www.ifrs.org/XBRL/IFRS-Taxonomy/IFRS-Taxonomy-2012/Pages/IFRS-

Taxonomy-2012-files.aspx.

Relevant reference documentation of the IFRS Taxonomy 2012 should be referred

to in conjunction with this document. In particular, the principles and rules from

the IFRS Taxonomy Guide should be considered adopted “as is” in the SSMT,

unless otherwise noted.

The IFRS Taxonomy 2012 is compliant with the provisions of the Global Filing

Manual (GFM), published by the Interoperable Taxonomy Architecture (ITA)

project, a joint initiative between the US Securities and Exchange Commission

(SEC), the Japan Financial Supervision Agency (FSA) and the International

Financial Reporting Standards (IFRS) Foundation XBRL team, with the

participation of the European Commission as an observer. The GFM should also be

referred to in conjunction with this document to the extent to which its provisions

are relevant. The current copy of the GFM at the time of publication of this

document can be found here:

http://www.ifrs.org/XBRL/Resources/Documents/GlobalFilingManual20110419.pdf

http://www.ifrs.org/XBRL/IFRS-Taxonomy/IFRS-Taxonomy-2012/Pages/IFRS-Taxonomy-2012-files.aspx

http://www.ifrs.org/XBRL/IFRS-Taxonomy/IFRS-Taxonomy-2012/Pages/IFRS-Taxonomy-2012-files.aspx

http://www.ifrs.org/XBRL/Resources/Documents/GlobalFilingManual20110419.pdf

4

In addition to the reporting concepts defined in the IFRS Taxonomy 2012, which

are largely applicable in Malaysia following the adoption of the International

Financial Reporting Standards, the SSMT also includes local reporting concepts,

necessary to support Malaysian local requirements as well as additional

information not covered by the IFRS Taxonomy 2012 and necessary for SSM

consumption. In addition, SSMT architecture is ready to support additional future

reporting requirements, which will also generate the need to accommodate local

reporting concepts in the taxonomy.

One of the main objectives of this document is to define the SSMT architecture so

that it is compliant with the base IFRS Taxonomy architecture and in particular

with the best practices on its extension, and at the same time flexible enough to

accommodate the reporting concepts necessary to support the Malaysian

jurisdictional extension to the base IFRS taxonomy as well as future additional

reporting requirements. To achieve this goal the SSMT architecture is also

inspired by the experience and lessons learned from the Standard Business

Reporting (SBR) XBRL programs, in particular from the Australian SBR Taxonomy

Architecture, which includes a fully compliant IFRS jurisdictional extension and

also successfully supports heterogeneous reporting requirements from different

Government agencies – requirements that are very similar to those that the SSMT

will support.

More information about the SBR program in Australia and The Netherlands can be

found in the respective websites:

http://www.sbr.gov.au

http://www.sbr-nl.nl/english/

2. SSM Taxonomy Architecture

2.1. Scope of SSM Taxonomy Elements

Financial

Reporting Malaysian Financial Reporting Standards (MFRS)

Private Entity Reporting Standards (PERS)

Balance Sheet / Statement of Financial Position;

Income Statement / Statement of Comprehensive Income;

Statement of Changes in Equity;

Statement of Cash Flows; and

Notes to the financial statements.

http://www.sbr.gov.au/

http://www.sbr-nl.nl/english/

5

Non-Financial

Reporting - as

required under

the Companies

Act 1965 / New

Companies Bill:

Directors‟ Report;

Statement by Directors;

Directors‟ Business Review (New Companies Bill);

Auditors Report to Members / Auditor‟s Statement;

and

The return of solvent Exempt Private Company.

Type of

companies and

industries will be

included/

excluded in the

first phase of

SSM’s XBRL

submission

Inclusion

Public Companies – Listed and Non-Listed

Private Companies

Exclusion

Banking, financial and insurance industry (Bank Negara taxonomy)

Companies which are limited by guarantee and

Foreign Companies.

2.2. Taxonomy Architecture Principles

The objectives of consistency with the overall IFRS 2012 Taxonomy architecture

and best practices for its extension to meet local requirements as well as of

flexibility and openness to future developments and expanded reporting

requirements are achieved in the SSMT Architecture through two (2) foundational

principles:

From a taxonomy structure perspective – in other words, in terms of physical

allocation and structure of the taxonomy folders and files: the base IFRS 2012

Taxonomy files and the Malaysian extension files are allocated consistently with

the characteristic SBR two-layer taxonomy architecture:

1. Definitional layer, where all the reporting concepts and other resources –

such as data types, common labels, common references - that may be re-

used by any report supported by the taxonomy are defined;

2. Reports layer, where the subset of resources defined in the definitional

layer that are used in each report supported by the taxonomy is identified

and the structure of each report is defined.

In practical terms this translates into distributing the various core files defined in

the IFRS base taxonomy and in the Malaysian extension in the appropriate folders

6

located in the definitional layer, and the various entry points that support specific

reports in the appropriate folders in the reports layer. This physical allocation of

the taxonomy files has minimal impact on the taxonomy from a technical

perspective, and it does not affect the compliance of the SSMT with the IFRS

Taxonomy Architecture principles and with best practices in extending the base

IFRS taxonomy; on the other end, it helps support processes related to the

taxonomy creation and maintenance that enhance its consistency with the overall

requirements of the SSMT.

From a taxonomy creation and maintenance processes perspective: any new

element created in the taxonomy – by SSM now, and potentially by other entities

that will join the taxonomy development in the future – must comply with the

principles set in this document and to notify SSMXBRL Unit for the purposes of

streamlining the taxonomy. These principles basically reflect the IFRS Taxonomy

Architecture rules as stated in Section 4, Extender‟s Guide in The IFRS Taxonomy

2012 Guide, which are adopted in their entirety, unless otherwise explicitly noted,

with two important additions:

1. Every new reporting concept and related resources - such as data types,

common labels and references - must be created in the definitional layer of

the taxonomy. No reporting concept can be created in the reports layer;

2. Before adding a new reporting concept, appropriate processes must be

followed to make sure that no existing reporting concept has the same or

similar meaning. If a match is found, no new reporting concept is created and

instead the existing concept is used for the purpose for which the creation of a

new concept was initially considered.

These two key principles ensure that the growth of the taxonomy both in scope

and over time is consistent both with the IFRS architecture – by re-using the

concepts and related resources from the base IFRS taxonomy, and following the

guidelines of the IFRS Taxonomy Guide for its extensions - and the SBR

environment, where harmonization must happen across different domains rather

than limited to the financial statements domain, and therefore requires a strong

governance in place to manage duplications in reporting concepts that are

semantically identical but are called in different ways by different participating

regulators. It also helps the process of harmonization of the information within

each regulator – for example, as SSM starts analyzing the Malaysian jurisdictional

requirements and the various reports in scope and adding new reporting concepts

to the base IFRS ones, this principle will help ensuring consistency and avoid

duplications.

7

2.3. Data modelling techniques in the SSM Taxonomy

The SSMT is designed to reflect the disclosure requirements for companies in

Malaysia which are required to submit their financial statements to SSM. Given

that MFRS is largely based on IFRS, SSMT has adopted the 3,771 IFRS Taxonomy

2012 elements as the basis of its core elements.

In addition to the reporting concepts defined in the IFRS Taxonomy 2012, which

are largely applicable in Malaysia following the adoption of the International

Financial Reporting Standards, the SSMT also includes local reporting concepts,

necessary to support Malaysian jurisdictional requirements as well as additional

information not covered by the IFRS Taxonomy 2012.

SSM data requirements for regulatory, compliance, data collection and statistical

purposes were identified and selected. Upon evaluation, the elements which are

not listed in IFRS were identified and duly incorporated as extensions for SSMT.

While deciding data modelling structures, the key factors under consideration are:

a) Disclosures which are deemed useful for SSM consumption are collected

using detailed information elements (detailed tagging). Companies may

use the element „Others‟ defined in faces of financial statements to group

the additional disclosures that they wish to disclose.

b) Notes to the financial statements that are deemed to be useful for SSM

consumption are collected using detailed tagging method. Notes „Others‟ is

created for companies to utilize if they wish to disclose additional

information that is not related to specific notes to the financial statement.

c) Despite the fact that IFRS XBRL taxonomy architecture allows for

extensibility, companies or filers MUST NOT create extensions in the

form of new elements or dimensional properties (except for the

dimension mentioned in paragraph 2.3.2; page 9 and paragraph

2.9.2; page 21) , to ensure better data comparability.

Reporting scope for the SSMT is covering at the moment all MFRS, PERS and

Companies Act requirements. The modelling approach is adopted from IFRS

Taxonomy architecture and is represented in two ways – via hierarchies and/or

via axes (dimensions).

2.3.1. Hierarchical modelling

The most common modelling technique used in the SSMT is hierarchical/list

modelling in the presentation, definition and calculation linkbases (or if there are

8

no calculation relationships between the concepts, then only the presentation and

definition linkbases are modelled).

An example of hierarchical modelling is shown in Table 1 (below) in the ELR

[110000] Statement of comprehensive income, by function of expense.

Hierarchical modelling is used for most statements and notes in the SSMT.

Extended link [110000] Statement of comprehensive income, by function of expense

Statement of comprehensive income [abstract]

Revenue

Cost of sales

Gross profit

Other income

Distribution costs

Administrative expenses

Other expense

Other gains (losses)

Profit (loss) from operating activities

Finance income

Finance costs

Share of profit (loss) of associates and joint ventures accounted for using

equity method

Gain (losses) on fair value of financial assets

Profit (loss) before tax

Tax expense (income), continuing operations

Contribution of zakat

Profit (loss) from continuing operations

Profit (loss) from discontinued operations

Profit (loss)

Other comprehensive income [abstract]

Gains (losses) on revaluation

Income tax on gains (losses) on revaluation

Actual gains (losses) on defined benefit plans

Income tax on gains (losses) on defined benefit plans

Gain (losses) on share of other comprehensive income of associates and joint ventures

Income tax on share of other comprehensive income of associates and joint ventures

Exchange differences on translation [abstract]

Gains (losses) on exchange differences on translation, before tax

Reclassification adjustments on exchange differences on translation, before

tax

Income tax on exchange differences on translation

Available-for-sale financial assets [abstract]

Gains (losses) on remeasuring available-for-sale financial assets, before tax

9

Extended link [110000] Statement of comprehensive income, by function

of expense

Reclassification adjustments on available-for-sale financial assets, before tax

Income tax on available-for-sale financial assets

Cash flow hedges [abstract]

Gains (losses) on cash flow hedges, before tax

Reclassification adjustments on cash flow hedges, before tax

Adjustments for amounts transferred to initial carrying amount of hedged items

Income tax on cash flow hedges

Other comprehensive income, others

Income tax on other comprehensive income, others

Total other comprehensive income

Income tax on total other comprehensive income

Total comprehensive income

Profit (loss), attributable to [abstract]

Profit (loss), attributable to owners of parent

Profit (loss), attributable to non-controlling interests

Comprehensive income attributable to [abstract]

Owners of parent

Non-controlling interests

Basic earnings per share [abstract]

Basic earnings (loss) per share from continuing operations

Basic earnings (loss) per share from discontinued operations

Total basic earnings (loss) per share

Diluted earnings per share [abstract]

Diluted earnings (loss) per share from continuing operations

Diluted earnings (loss) per share from discontinued operations

Total diluted earnings (loss) per share

Table 1: A hierarchical model of a statement

2.3.2 Axes modelling

The second modelling technique used in the SSMT is modelling via tables

(hypercubes) and axes (explicit dimensions). Each such axis can be connected to

any set of line items (reportable concepts) via a table, thereby creating a

dimensional structure.

The SSMT contains two types of axes – applied axes, and for application axes.

Most axes in the SSMT are applied axes because they have relationships to line

items (reportable concepts). Only one axis in the SSMT is for application because

it does not have any explicit relationships.

Table 2 provides an example model of the Statement of changes in equity

[abstract] by the means of axes. Line items (reportable concepts) are denoted

10

with an X. Line items can be reported for various members (domain members) of

the axis Components of equity [axis], which are linked by the table Statement of

changes in equity [table]. For example, preparers can report the line item

Issuance of shares, for the member Share capital [member], on the axis

Components of equity [axis].

Extended link [310000] Statement of changes in equity

Statement of changes in equity [abstract]

Statement of changes in equity [table] table MFRS101.106

Components of equity [axis] axis MFRS101.106

Equity [member] member [default] MFRS101.106

Equity attributable to owners of

parent [member] member MFRS101.106

Issued capital [member] member MFRS101.106

Treasury shares [member] member MFRS101.106

Retained earnings [member] member MFRS101.106

Other reserves [member] member MFRS101.106

Non-controlling interests [member] member MFRS101.106

Statement of changes in equity [line items] line items MFRS101.106

Equity at beginning of period X MFRS101.106

Changes in equity [abstract]

Profit (loss) X MFRS101.106

Other comprehensive income X MFRS101.106

Total comprehensive income X MFRS101.106

Dividends paid X MFRS101.106

Acquisition (dilution) of equity interest in subsidiaries

X MFRS101.106

Issuance of shares X MFRS101.106

Other transactions with owners X MFRS101.106

Other changes in equity X MFRS101.106

Total increase (decrease) in equity X MFRS101.106

Equity at end of period X MFRS101.106

Table 2: A dimensional model of a Statement of changes in equity (presentation linkbase view)

11

Components of equity

Equity

Equity attributable to owners

of parent

Non-c

ontr

ollin

g

inte

rests

Issued

capital

Tre

asury

share

Reta

ined

earn

ings

Oth

er

reserv

es

inte

rest

Statement of changes in equity

Equity

Changes in equity

Comprehensive income

Profit (loss)

Other comprehensive income

Comprehensive income

Dividends paid

Acquisition (dilution) of equity interest in

subsidiaries

Issuance of shares

Increase (decrease) through transactions

with owners, equity

Increase (decrease) through other

changes, equity

Increase (decrease) in equity

Equity

Table 3: A dimensional model of a Statement of changes in equity (Cartesian product view)

12

2.4. The structure of SSM Taxonomy

Figure 1 illustrates the folder structure and files content of SSMT:

Figure 1: Folder structure in SSMT

There are two layers defined in SSMT folder structure:

1. Definitional layer:

Definitional layer is where the Core schema and other imported schema are

located. There are 3 folders defined in this layer:

i. In the “ic” folder, the file ssmt-cor_2012-12-31.xsd is the schema

where the Malaysian jurisdictional extension elements are defined, and

lab_ssmt-en_2012-12-31.xml is the related English label linkbase.

Multiple languages will be supported with multiple label linkbases in the

same location.

ii. In the “ext” folder, two of the “base” IFRS taxonomy resource ifrs-

cor_2012-03-29.xsd and lab_ifrs-en_2012-03-29.xml are imported as

external resources. In SSMT all IFRS concepts are imported and will

serve as the base taxonomy where only some of the concepts will be re-

used in the report layer.

13

iii. In the “fdn” folder, the file ssmt-fdn_2012-12-31.xsd is the schema

where the new data types for non-financial report or Companies Act are

defined.

2. In the Reports layer:

Reports layer is where the related concepts are grouped to represents a

submission report. This layer consists of the following folders:

i. The “ssm” folder is the only folder that will be present in the first SSMT

release – other folders will be added in the future as more Government

agencies and regulators join the SSMT. Within each agency folder there is

one folder for each report of that agency supported by the SSMT. Initially,

the “ssm” folder will contain the MFRS, PERS and CA (requirements under

new Companies Bill) reports, as shown in Figure 1.

a. In the “mfrs” folder, the file mfrs_2012-12-31_full_entry_point.xsd

is the full entry point for the MFRS report. This entry point is then

break down into four different entry point files to accommodate

preparer‟s disclosure type which are:

mfrs_2012-12-31_func-direct

mfrs_2012-12-31_func-indirect

mfrs_2012-12-31_nature_direct

mfrs_2012-12-31_nature_indirect

These entry point files imports both the ssmt-cor_2012-12-31.xsd

and the ifrs-cor_2012-03-29.xsd schemas from the Definitional

layer and related labels. The folder also contains the folder

“mfrs_2012”, which contains “per standard” resources such as

presentation, definition calculation and reference linkbases,

modified as appropriate to include resources related to the

Malaysian jurisdictional extension elements.

b. In the “pers” folder, the pers_2012-12-31_full_entry_point.xsd is

the entry point for the PERS report. This entry point is then break

down into four different entry point files to accommodate preparer‟s

disclosure type which are:

pers_2012-12-31_func-direct

pers_2012-12-31_func-indirect

pers_2012-12-31_nature_direct

pers_2012-12-31_nature_indirect

This entry point imports both the ssmt-cor_2012-12-31.xsd and the

ifrs-cor_2012-03-29.xsd schemas from the Definitional layer and

14

related labels. The folder also contains the folder “pers_2012”,

which contains all resource such as presentation, definition

calculation and reference linkbases related to non-financial report.

c. In the “ca” folder, the file ca_2012-12-31_full_entry_point.xsd is

the entry point for a non- financial report. This report contains the

disclosure requirements under the new Companies Bill. This entry

point imports both the ssmt-cor_2012-12-31.xsd and the ifrs-

cor_2012-03-29.xsd schemas from the Definitional layer and related

labels. The folder also contains the folder “ca_2012”, which contains

all resource such as presentation, definition calculation and reference

linkbases related to non-financial report.

2.5. Absolute and relative paths

The unique root resource location (URL) of the SSMT is

http://www.ssm.com.my/taxonomy/YYYY-MM-DD/ followed by the file path as per

the folder structure in Figure 1. The following table provides examples of absolute

paths to SSMT files:

Table 4: Sample absolute paths

SSMT files can be referenced using both absolute and relative paths. Software

vendors should note that SSMT files should not be amended and should therefore

be referenced via absolute paths in order to avoid file changes being made by

preparers and extenders. This is particularly important when working directly on

the entry point schemas without importing them to another extension schema. In

such cases, all linkbase amendments should be treated as an extension and

saved in new, separate linkbase files.

File Absolute path

core schema http://xbrl.ssm.com.my/taxonomy/YYYY-MM-DD/ssmt/

def/ic/ssmt-cor_YYYY-MM-DD.xsd

English label linkbase http://xbrl.ssm.com.my/taxonomy/YYYY-MM-DD/ssmt/

def/ic/lab_ssmt-en_YYYY-MM-DD.xml

reference linkbase for

MFRS (IAS 1)

http://xbrl.ssm.com.my/taxonomy/YYYY-MM-DD/ssmt/

rep/ssm/mfrs/mfrs_2012/ias_1_2012-12-

31/ref_mfrs_101_2012-12-31.xml

15

2.6. Namespaces and prefixes

Namespaces are required to uniquely identify the schemas that are defined in the

taxonomy. In addition, it also provides information relating to release date of

taxonomy and owners of the taxonomy.

For every namespace a unique prefix is to be defined. The prefix provides some

indication of what the namespace refers to. The table below summaries the

namespaces and prefixes used in the SSMT:

Prefix Namespace URI Use

rol_{ias | ifrs | ifric | sic|

ps_mc}_{“number”}_YY

YY-MM-DD

http://xbrl.ssm.com.my/r

ole/mfrs/ rol_{ias | ifrs

|ifric | sic

}_{“number”}_YYYY-MM-

DD

Namespace for the standards‟

roles schemas (where YYYY-MM-

DD is the standard or

interpretation issue date related to

the latest taxonomy release date).

This namespace is not used for

concepts. Example of

such role is rol_ias_12_2012-12-

31 with URI

http://xbrl.ssm.com.my/role/mfrs/

rol_ias_12_2012-12-31

rol_{mfrs |

pers | ca}-dim_YYYY-

MM-DD

http://xbrl.ssm.com.my/r

ole/{mfrs | pers |

ca}/{mfrs | pers | ca}-

dim

Namespace for the dimensional

roles schema. This namespace is

not used for concepts.

ssmt http://xbrl.ssm.com.my/t

axonomy/YYYY-MM-

DD/ssmt

Main namespace for all SSM

taxonomy concepts shared by

MFRS, PERS and CA (where YYYY-

MM-DD is the taxonomy release

date).

Table 5: Namespaces and prefixes

16

2.7. Core, role and entry-point schemas

The SSMT uses IFRS taxonomy as its base taxonomy, hence there are two

schemas which define the reporting concepts

i. ssmt-cor_YYYY-MM-DD.xsd

Consists of additional reporting concepts which are not define by IFRS,

mostly local reporting concepts which necessary to support Malaysian

jurisdictional requirements

ii. ifrs-cor_YYYY-MM-DD.xsd

Consists of reporting concepts as released in IFRS taxonomy

Just like IFRS Taxonomy, SSMT also does not use tuples or typed axes. Items

and explicit axes are used instead. There are a total of 4053reporting concepts in

the SSMT which includes the concepts define in IFRS Taxonomy.

In the SSMT, only the core schema (ssmt-cor_YYYY-MM-DD.xsd andifrs-

cor_2012-03-29.xsd) contains reportable concepts (located in definitional layer).

An additional role schema is placed in each standard (and axes) folder (located in

reporting layer). These role schemas contain definitions of the presentation,

calculation and definition ELRs. Role schemas do not contain concepts, tables,

axes or members.

Entry points are defined to group related reporting concepts in one schema file.

The following table lists all entry points schemas define in SSMT:

Entry point Schema Location Purpose

mfrs_2012-12-

31_full_entry_point

.xsd

http://xbrl.ssm.com.my/taxon

omy/2012-12-

31/ssmt/rep/ssm/mfrs/mfrs_2

012-12-

31_full_entry_point.xsd

Full entry point schema

consists all reporting

concepts for MFRS

mfrs_2012-12-

31_func-direct.xsd


omy/2012-12-


012-12-31_func-direct.xsd

Entry point for MFRS

preparer who submit the

following:

i. Statement of

comprehensive income,

by function of expense

ii. Statement of cash flows –

Direct

17


mfrs_2012-12-

31_func-

indirect.xsd


omy/2012-12-


012-12-31_func-indirect.xsd



following:

i. Statement of




Indirect

mfrs_2012-12-

31_nature_direct.x

sd


omy/2012-12-


012-12-31_nature_direct.xsd



following:

i. Statement of


by nature of expense


Direct

mfrs_2012-12-

31_nature_indirect.

xsd


omy/2012-12-


012-12-31_nature_indirect.xsd



following:

i. Statement of



ii. Statement of cash flows – Indirect

pers_2012-12-

31_full_entry_point

.xsd


omy/2012-12-

31/ssmt/rep/ssm/pers/pers_2

012-12-


Full entry point schema

consists all reporting

concepts for PERS

pers_2012-12-

31_func-direct.xsd


omy/2012-12-


012-12-31_func-direct.xsd

Entry point for PERS


following:

i. Statement of




Direct

18


pers_2012-12-

31_func-

indirect.xsd


omy/2012-12-


012-12-31_func-indirect.xsd



following:

i. Statement of




Indirect

pers_2012-12-

31_nature_direct.x

sd


omy/2012-12-


012-12-31_nature_direct.xsd



following:

i. Statement of




Direct

pers_2012-12-

31_nature_indirect.

xsd


omy/2012-12-


012-12-31_nature_indirect.xsd



following:

i. Statement of comprehensive income, by nature of expense

ii. Statement of cash flows – Indirect

ca_2012-12-

31_full_entry_point

.xsd


omy/2012-12-

31/ssmt/rep/ssm/ca/

ca_2012-12-


Entry point for non-financial

reporting - as required under

the Companies Act 1965 /

New Companies Bill:

i. Directors‟ Report;

ii. Statement by Directors; iii. Directors‟ Business

Review (New Companies Bill);

iv. Auditors Report to the Members / Auditor‟s Statement; and

v. The return of Exempt Private Company

Table 6: Entry point schemas

19

2.8. Customised Data Types

The SSMT uses item types as defined in XBRL 2.1 specification and the additional

data types as defined in customized data types schema, ssmt-fdn_2012-12-

31.xsd which is located in “fdn” folder in definitional layer. SSM imposed some

restrictions on the allowed values for some reporting concepts. These restrictions

are incorporated in the taxonomy by creating customized data types (XML

schema enumerations) for the concepts. For example, a ssmt-

fdn:companyStatusItemType has enumerations of Sdn. Bhd., Bhd., and Sdn.

which describes the company status in Malaysia. By defining a new data type,

preparers submitting values for this concept will be restricted to this set of

enumerations. The definitions of all the data types will be placed in a special

module (called ssmt-fdn) which will be imported by schemas containing the

concepts. The examples of new data type defined within SSMT are defined in the

following table:

DataType Assigned to element Restriction

companyStatusItemType CompanyStatus Sdn. Bhd.;

Bhd.;

Sdn.

businessReviewIsRelated

ToItemType

DisclosureOfBusinessRevie

wAdressOfEnvironmentSoci

alCommunityAndOtherMatt

ers

Environmental matters;

Social and Community

issues;

Others

recordsNotKeptProperlyB

yCompanyItemType

ExplanationOfRecordsWere

NotKeptProperlyByCompan

y

Accounting and its

supporting documents;

Register books

sevenDigitAndOneAlphab

etItemType

CompanyRegistrationNumb

er;


erOfLocalHoldingCompany;


erOfLocalUltimateHoldingC

ompany;


erOfLocalSubsidiary

[0-9][0-9][0-9][0-9][0-

9][0-9][0-9][a-z|A-Z]

Table 7: Examples of custom data types

20

2.9. Linkbases

Linkbases in SSMT are organised and viewed as a set of financial statements as

prepared by different types of entities. The SSMT uses sort codes (an artificial 6-

digit number) at the beginning of each ELR definition, which provides viewing and

sorting functionality.

2.9.1 Presentation linkbase

The presentation linkbase is designed to display the hierarchy of elements as it

would appear in a typical set of financial statements. Example of the

presentation view of Statement of financial position is as shown in the figure

below:

Figure 2: Presentation linkbase

21

2.9.2 Definition linkbase

The SSMT uses definition linkbases to express dimensional relationships. The

SSMT defines axes and members for listed relationships, and therefore only uses

explicit axes. Typed axes are not used in the SSMT at the moment. The SSMT

defines tables where an axis has clearly been applied to a set of line items.

Example of the definition view of Statement of changes in equity is as shown in

the figure below:

Figure 3: Definition linkbase

Consequently, axes in the SSMT are either applied (to line items) or for

application (not linked in a table). The latter can be connected to any set of line

items, depending on the needs of the preparer.

There are two types of definition linkbases in the SSMT.

The first is the definition linkbase file placed in the standards folder, which mirrors

the structure of the presentation linkbase if the presentation linkbase contains a

table. These file names have the prefix def_, they represent hierarchies of line

items, and they link axes to a given set of reportable items (line items) within the

SSMT. These hierarchies re-use the presentation linkbase ELRs and therefore also

their ordering numbers (ELR definitions that are numbered between [100000] and

[899999] represent line items).

The second type of definition linkbase represents axes, and these are placed in

the dimensions folder or in the standards folder (if they represent axes that are

applied to a set of line items). Dimensional definition linkbases also have an

equivalent in the structure of the presentation linkbase. These filenames have the

prefix dim_ or pre_. ELR definitions that are numbered between [900000] and

[989999] should be linked via tables with ELR definitions numbered between

22

[100000] and [899999]1 or they should already be linked to the respective sets of

line items. It is possible to combine one set of line items with more than one axis

on a table.

All defaults for axes (dimensions) are placed in a single ELR number [990000] to

avoid redundancies. This ELR does not have an equivalent in the presentation

linkbase.

2.9.3 Calculation linkbase

In the SSMT, calculation linkbases are used to define arithmetical relationships as

per XBRL specifications. Example of the calculation view under ELR [821000] Note

– Provisions.

Figure 4: Calculation linkbase view

Weight of +1 denotes the element will be added to arrive at the sub-total, while -

1 indicates value to be reduced.

Due to certain limitations of calculation linkbase, not all additive and subtractive

relations can be defined. For example, additive and subtractive relationship

cannot be handled in Calculation linkbase due to the different periodtypes (instant

and duration) being assigned to elements.

2.9.4 Label linkbase

The SSMT2012 uses the label roles as specified in XBRL 2.1 as well as label roles

which are introduced in XBRL standards in recent years. All the labels are defined

in English and are created as per the rules specified in Style Guide. The different

types of labels are defined to make the taxonomy to facilitate easy viewing of

taxonomy. The label roles used in the SSMT are listed in the table below:

1In other words, ELRs that have the prefix def_ should be linked via table (hypercube) with ELRs

from the file that have the prefix dim_.

23

Label role Use

http://www.xbrl.org/2009/

role/negatedLabel

Label for a concept, when the value being

presented should be negated (sign of the value

should be inverted). For example, the standard

and standard positive labels might be profit (loss)

after tax and the negated labels loss (profit) after

tax.


role/negatedTotalLabel


role/negatedTerseLabel


role/netLabel

The label for a concept when it is to be used to

present values associated with the concept when

it is being reported as the net of a set of other

values. Net labels allow the expression of labels,

other than the one to be used as total label, if the

presentation tree represents a gross/net

calculation instead of a traditional calculation roll-

up. For example, the standard label for Property,

plant and equipment can have the total label

Total property, plant and equipment and the net

label Net property, plant and equipment.


role/label

Standard label role for a concept. The IFRS

Taxonomy uses standard labels to guarantee

uniqueness of the labels.


role/totalLabel

The label role for a concept when it is to be used

to present values associated with the concept

when it is reported as the total of a set of other

values. This role should not be used to infer

semantics of facts reported in instance

documents.


role/periodStartLabel

The label role for a concept with the

periodType="instant" when it is to be used to

present values associated with the concept when

it is reported as a start (end) period value. These

roles should not be used to infer semantics of

facts reported in instance documents.


role/periodEndLabel


role/terseLabel

Short label role for a concept, often omitting text

that should be inferable when the concept is

reported in the context of other related concepts.


role/documentationLabel

Additional explanation for the user on particular

concept

Table 8: Label roles

24

2.9.4.1 Reuse of IFRS labels

Current version of SSMT is not reusing some of the original labels as

defined within IFRS 2012 Taxonomy. The reason for that is SSMT includes

local reporting labels as well as to provide additional information not

covered by the IFRS Taxonomy 2012.

Result of such approach may generate a number of Financial Reporting

Taxonomy Architecture (FRTA) validation errors according to section

2.1.102. The section states that each concept must have a label with the

standard label role. However some of the IFRS elements were not provided

with a label, in order to indicate that particular concept is not reportable to

SSM for this taxonomy version. The above mentioned inconsistencies will

not have a negative impact on the taxonomy or its users.

2.9.4.2 Total and net labels

Total and net labels are used as preferred labels in presentation linkbase

for those elements which have calculations are defined in calculation

linkbase. For example, if an element (which is numeric in nature) is a

summation of other elements, then total label role is used. Figure 5

displays the calculation hierarchy of the example where total label is used

in presentation linkbase.

Figure 5: Total label in presentation linkbase

2http://www.xbrl.org/technical/guidance/FRTA-RECOMMENDATION-2005-04-25.htm#_2.1.10

http://www.xbrl.org/technical/guidance/FRTA-RECOMMENDATION-2005-04-25.htm#_2.1.10

25

2.9.4.3 Negated labels

Negated labels in the SSMT use a set of label roles from the XBRL

International Link Role Registry (LRR). Negated labels are generally used

for elements which are to be reduced in order to arrive at a sub-total. The

label merely indicates, the negative weight and the use of negated labels

do not affect the sign of a reported value in XBRL. Negating a label only

affects the visualization of the reported data; it does not affect the data

itself (there is no influence on the sign of reported concepts).

The following negated labels are used in the SSMT:

i. Standard negated label role

ii. Negated total label role

iii. Terse negated label role

Figure 6 below shows the use of negated label and negated terse label as

preferred label in presentation linkbase.

Figure 6: Negated label in presentation linkbase

26

Calculation view of the same example of statement of cash flow is shown in

Figure 7 below:

Figure 7: Calculation view of negated label

In the taxonomy, the debit and credit attributes impact the way calculation

linkbase is created. As per XBRL specifications, a debit can be added to

debit, or credit can be added to credit and a credit can be reduced from

debit or a debit can be reduced from credit. Addition or reduction of

elements is determined by weight attribute. So if weight is +1, it indicates

elements are added and if weight is -1, it indicates element is to be

reduced in order to arrive at the sub-total.

With reference to Figure 7 above, „Payments to suppliers for goods and

services‟, „Payments to and on behalf of employees‟ and „Other cash

payments from operating activities‟ are to be deducted from other cash

flow receipts from operations . Therefore, those elements are defined with

“-1” weight in the taxonomy. As the weight is negative, the value to be

27

stored in instance document will have no sign (or will be positive). By doing

this, the calculation relationships defined in the taxonomy will tally.

However while displaying the information; software products may use

inverted sign, wherever negated labels are used in the taxonomy. Inverted

values may be presented in brackets, in a separate column or with a minus

before the value.

2.9.5 Reference linkbases

The SSMT uses reference roles as listed in the following table:

Reference role Use

http://www.xbrl.org/2003/role/

disclosureRef

Reference to documentation that details an

explanation of the disclosure requirements

relating to the concept.


exampleRef

Reference to documentation that illustrates by

example the application of the concept that

assists in determining appropriate usage.


commonPracticeRef

Reference for common practice disclosure

relating to the concept. Enables common

practice reference to a given point in

Table 9: Reference roles

A reference resource is made of several parts and these are parts defined in XBRL

specification. Table 9 below summarizes the reference parts that are referred to

in SSMT:

Part Use

Name {MFRS|PERS|CA}

Number Number of the standard or interpretation

Section Title of sections of standard or interpretation

Subsection Title of the subsection of the section

Paragraph Paragraph (number) in the standard

Sub-paragraph Subparagraph (number) of a paragraph

Clause Subcomponent of a subparagraph

URI Link to text of the standard in MFRS/PERS/CA

Table 10: Reference resource parts

28

3. Style Guide

The purpose of this Style Guide is to facilitate the creation of a consistent, high-

quality and easy-to-use taxonomy in many languages.

The objectives of defining the Style Guide are to:

1. Provide users of the taxonomy with labels that are recognizable to the

user.

2. Provide users of the taxonomy with consistency, which makes it easier

to locate a concept.

3.1 General Guidance

Wording prescribed in Malaysian Financial Reporting Standards (MFRS), Private

Entity Reporting Standards (PERS) and Companies Act (CA) takes precedence

over the rules in this guide. This guide is to be used in conjunction with the above

mentioned standards and act. It should only be applied when the said standards

and act do not provide enough guidance to construct labels for SSMT.

3.2 Style guide for Extended Link Roles (ELR)

3.2.1 Roles definitions SHALL start with the ordering number.

For better sorting of the extended link roles (ELR), the definitions of the ELRs

SHALL starts with a six-digit number.

The numbers allow sorting of the ELRs according to the structure of financial

reports.

ELR for faces of financial statements will follow the sequence of number

starting from 1.

For example:

Statement of comprehensive income starts with number „1‟

Statement of financial position starts with number „2‟

Statement of changes in equity starts with number „3‟

Statement of cash flows starts with number „4‟

The second digit of ELR sequence number represents further categorization of

an ELR.

29

For example, Statement of comprehensive income have two types; by

function and by nature. Hence, the sorting numbers for these ELR are:

[11000] Statement of comprehensive income, by function

[12000] Statement of comprehensive income, by nature

ELR for notes to the financial statements will start with number „8‟ followed by

sequence running number.

For example

„[801000] Notes – Corporate information‟ followed by „[802000] Notes –

Summary of significant accounting policies

3.2.2 Roles definitions SHOULD use the agreed wording.

Roles definitions for disclosures should start with the number followed by the

word „Notes – „.

For example:

[833000] Notes –Other assets.

Exceptions for dimensions ELR:

[901000] Axis - Retrospective application and retrospective restatement‟.

3.3 Style Guide for element name and ID

3.3.1 The element id MUST be created in the format namespace prefix of

the taxonomy, followed by an underscore, followed by the element name (“prefix_ElementName”)

For example:

ssmt_DisclosureOfProfitBeforeTaxAbstract‟

ssmt_DateOfAuditorsStatement‟

3.3.2 Element name SHOULD be concise, follow terminology as per the

regulations, and avoid being excessively descriptive

30

For example:

Reporting concept Element name

PropertyPlantAndEquipmentBeforeAccu

mulatedDepreciationAndExcludingIntan

gibleAssets

PropertyPlantAndEquipmentGross

Table 11: Example of concise element name

3.3.3 Concept names SHOULD adhere to the LC3 convention

LC3 means Label Camel Case Concatenation (LC3). Some of the important or

relevant LC3 rules require that:

Element names MUST be based on an appropriate presentation label for the

element. The element name SHOULD be a natural language expression

that is meaningful to experts in the domain covered by a taxonomy

The first character of the element name must not be underscore ( _ )

The first character of the element name must be capitalized

Connective words in the label may be retained in the element name.

Examples of English connective words include (but are not limited to) the

following: and, for, which, with

As a consequence of XML element name restrictions, all special characters

must be omitted from the element name. Special characters include the

following:

( ) * + [ ] ? \ / ^ { } | @ # % ^ = ~ ` “ ” ; : , <>& $ ₤ €

Element names must be limited to 256 characters or fewer

3.3.4 The following articles MUST NOT be used in element names:

Disallowed articles:

An

A

The

31

3.3.5 The adjectives in all labels SHOULD be used with a noun (except terse

labels).

For example, “TemporarilyIdle” alone means nothing.

“ExplorationAndEvaluationAssetsTemporarilyIdle” is meaningful

3.3.6 Numbers SHOULD be expressed as text when less than 10.

The expression of number is a matter of judgment. The following rules for

numbers should be considered:

Exact numbers one through nine should be spelt out, except for

percentages and numbers referring to parts of a book (for example, „5

per cent‟, „page 2‟) and accounting standard number or paragraph, if to

be used.

Numbers of 10 or more should be expressed in figures.

3.3.7 Adjectives SHOULD be used when there is ambiguity surrounding a concept.

For example, „Provisions‟ should always be current, non-current or total. The

proper element name should be „CurrentProvisions‟ or „NonCurrentProvisions‟

3.3.8 Concepts for disclosures that define textual type explanations SHOULD start with a descriptor that explains the nature of the text

For example:

“DisclosureOfCorporateInformationAbstract”

“ExplanationOfReasonWhyPreviousFinancialStatementFiguresAreRestated”

Whereas for the concept label “ImpactOfChangesInAccountingEstimates” , it is

not clear if the concept is an amount or a narrative.

The following are common starting wordings for text-type content that appear

in disclosures:

AdditionalInformationAbout

AddressOf

AddressWhere

CountryOf

DescriptionAndCarryingAmount

Of

DescriptionOf

ExplanationWhen

IndicationOf

InformationAbout

InformationRequired

InformationWhether

MethodsUsedTo

NameOf

32

DescriptionOfAccountingPolicyF

or

DescriptionOfNatureOf

DescriptionOfReasonFor

DescriptionOfReasonWhy

DisclosuresIn

DisclosureOf

DomicileOf

ExplanationOf

PrincipalPlaceOf

QualitativeInformationAbout

RangeOf

ResidenceOf

StatementOf

SummaryQuantitativeDataAbout

3.3.9 Concepts that represent a non-monetary or non-text value SHOULD start with an appropriate descriptor

These include concepts that are decimals, percentages and dates.

For example:

“DateOfExemptPrivateCertificate”

“NumberOfExecutiveEmployees”

The following are common starting labels for non-monetary and non-text

content which appear within disclosures:

“DateOf…”

“NumberOf….”

“WeightedAverageExercisePriceOf …”

“PercentageOf…”

“ProportionOf…”

3.3.10 The element name for abstract concepts that do not represent

hypercubes, dimensions, domains, or domain members MUST append the word “Abstract” or “LineItems” to the end of the element name

Abstract elements are used to organise the taxonomy. Element names for

abstract items shall append the word “Abstract” or “LineItems”. The reason for

this is to differentiate the abstract concepts from the concepts which can

actually hold values.

For example:

“DirectorsBusinessReviewAbstract”

“StatementOfFinancialPositionLineItems”

33

3.3.11 The element name for nonnum:textBlockItemType concepts MUST

append the word “Explanatory” to the end of the name

Text block elements are used to disclose narrative information.

For example:

“DisclosureOfStatementByDirectorsExplanatory”

“DisclosureOfDirectorsReportExplanatory”

3.3.12 The element name for dimensions MUST append the word “Axis” to the end of the name

Dimensions are abstract concepts used as containers for domains, and domain

members should be clearly recognizable through their names.

For example: “CategoriesOfRelatedPartiesAxis”

3.3.13 The element name for hypercubes MUST append the word “Table” to the end of the name

Hypercubes are abstract concepts used as link between dimensions and line

items.

For example: “DisclosureOfProfitBeforeTaxTable”

3.3.14 The element name for domain and domain members MUST append the word “Member” to the end of the name

Domain and domain members are abstract concepts used as members on the

axis (dimension).

For example: “KeyManagementPersonnelOfGroupMember”

3.3.15 The word “total” MUST NOT be used in any element name

The word “total” should not be used in an element name. The word “total” can

be used in the total label role. In addition, the total label role can use the word

“aggregated” and net label role the word “net”.

For example, “AssetsTotal” should not be used as element name; “Assets” is

sufficient. A total label as “Assets, Total” should be created instead.

34

3.4 Style Guide for Label Linkbase

3.4.1 Labels SHOULD be concise, follow IFRSs terminology, and avoid being excessively descriptive.

For example „Property, plant and equipment before accumulated depreciation

and excluding intangible assets‟ should be „Property, plant and equipment,

gross‟.

3.4.2 The agreed spelling SHOULD be used.

As there are various accepted ways to spell some terms, the following list of

terms should be used in the SSMT.

anti no hyphen

co no hyphen except

o “co-operate/co-operation”

o “co-ordinate/co-ordination”

non always hyphen (but note “nonsense”, “nonentity” etc.)

over no hyphen except

o “over-optimistic”

o “over-represent”

pre no hyphen except

o “pre-empt”

o “pre-exist”

post always hyphen

pro no hyphen except

o “pro-forma”

re no hyphen except

o “re-enter”

o “re-present” (to present again)

o “re-record”

semi always hyphen

35

sub no hyphen except

o „sub-lessee”

o „sub-lessor”

super no hyphen

un no hyphen

under no hyphen except

o “under-record”

o “under-report”

o “under-represent”

Specific terms to be used with hyphen

o Available-for-sale

o Held-to-maturity

o Held-for-trading

3.4.3 Labels SHALL NOT contain certain special characters.

The following characters should generally be avoided in creating concept

labels:

Disallowed Characters

? | >< : * “ + ; = . & ! @ # { } \

Allowed Characters

A-Z, a-z, 0-9, (,), comma, -, „, space, [ ], /

3.4.4 Labels MUST start with a capital letter and MUST NOT use upper case,

except for proper names and abbreviations

For example, “Explanation of reason why previous financial statement figures

are re-classified”.

List of words (among others) that are capitalized:

MFRS

PERS

36

XBRL

CA

Director‟s Report

Stock Exchange

3.4.5 The following articles MUST NOT be used in labels:

Disallowed articles:

An

A

The

3.4.6 The adjectives in all labels SHOULD be used with a noun (except terse labels).

For example, „Temporarily idle‟ alone means nothing. „Exploration and

evaluation assets, temporarily idle‟ is meaningful

3.4.7 Dashes SHALL NOT be used in labels where commas can be used

instead.

For example, DO NOT use „Disclosure - Director's Report [text block]‟, but

rather use „Disclosure of Director's Report [text block]‟.An exception is the use

of dashes in the definition of extended link roles.

3.4.8 In a series of three or more items, commas SHALL be used after each item excluding the penultimate item.

Use a comma to separate items in a series of three or more items not

including before the final „and‟. For example: „Property, plant and equipment

3.4.9 Numbers SHOULD be expressed as text when less than 10.

The expression of number is a matter of judgment. The following rules for

numbers should be considered:

Exact numbers one through nine should be spelt out, except for

percentages and numbers referring to parts of a book (for example, „5

per cent‟, „page 2‟).

37

Numbers of 10 or more should be expressed in figures.

3.4.10 The word „per cent‟ SHALL be spelt out, as two words.

A range would be written as ‟5 to 10 per cent‟.

3.4.11 Labels SHALL NOT have leading spaces, trailing spaces or double spaces.

3.4.12 Certain adjectives and prepositions used in labels SHOULD appear before or after the noun and be separated by a comma.

For example: ‟Other intangible assets, gross‟ and „Other comprehensive

income, net of tax‟.

The following sentence construct models the intention of how concept labels

should be created. Note that what is contained in curly braces {}, is one

component of the label. The different sets of curly braces are the different

components of the same label. The format below prescribes the order in which

the components should appear if present:

{Total*} {other} {current or non-current} {noun}, {net [of tax] or

gross [of tax]}, {at cost or at fair value}

For example: „Total other non-current asset, gross, at fair value‟

Example of properly-constructed labels (per model):

„Current trade receivables, gross‟

„Other comprehensive income, net of tax‟

„Accumulated depreciation of biological assets, at cost‟

Example of poorly-constructed labels (not per model):

„Current gross trade receivables‟

„Trade and other receivables, current, net‟

„Equity – share subscriptions, total‟

„Accumulated at cost depreciation of biological assets‟

Exceptions include net or gross labels for which the counterpart does not exist.

For example:

38

„Gross profit‟, „Net exchange differences, brand names‟ or „Net cash flows from

(used in) financing activities‟.

3.4.13 Adjectives SHOULD be used when there is ambiguity surrounding a concept.

For example, „Provisions‟ should always be current, non-current or total. The

proper label for the taxonomy concept should be „Current provisions‟, „Non-

current provisions‟ or „Total provisions‟ (this used as a totalLabel role for the

concept Provisions).

3.4.14 Concepts for disclosures that define textual type explanations SHOULD start with a descriptor that explains the nature of the text

For example:

“Explanation of reason why previous financial statement figures are

restated”

“DescriptionOfReasonWhyUsingDifferentReportingDateOrPeriodForForeig

nSubsidiary”.

Whereas for the concept label “Impact of changes in accounting estimates”, it

is not clear if the concept is an amount or a narrative.

The following are common starting labels for text-type content that appear in

disclosures:

Additional information

about…

Address of …

Address where …

Country of …

Description and carrying

amount of …

Description of …

Description of accounting

policy for…

Description of nature of…

Description of reason for…

Indication of …

Information about…

Information required …

Information whether …

Methods used to…

Name of …

Principal place of …

Qualitative information about …

Range of …

Residence of …

Statement of …

39

Description of reason why…

Domicile of …

Explanation of …

Explanation when …

Summary quantitative data

about …

3.4.15 Concepts that represent a non-monetary or non-text value SHOULD

start with an appropriate descriptor

These include concepts that are decimals, percentages and dates.

For example:

“Date of Exempt Private Certificate”

“Number of executive employees”

The following are common starting labels for non-monetary and non-text

content which appear within disclosures:

Date of…

Number of….

Weighted average exercise price of …

Percentage of…

Proportion of…

3.4.16 Labels SHOULD avoid defining what they do or do not include.

For example, ‟Property, plant and equipment including land and buildings‟

should be avoided. What an item includes or excludes should be provided in

the definition of the concept or the calculation linkbase. In some cases, a label

needs to define inclusions and exclusions, because particular concepts do not

have an agreed meaning.

For example: „Intangible assets without goodwill‟ is allowed.

3.4.17 For concepts that can be either negative or positive, the concept label MUST use parentheses ( ) to indicate which concept is represented as

positive or negative values in the instance document

There are occasions in an instance document when the value of a concept

could be positive or negative, for example, “Increase (decrease)”. A space

should appear between the positive item and the opening parenthesis. A slash

should not be used. The following are examples of concepts that may have

positive or negative values:

40

Disposals (acquisitions)

from (used in)

Gains (losses)

Income (expense)

Increase (decrease)

Inflow (outflow)

Loss (reversal)

Paid (refund)

Profit (loss)

Proceeds from (purchase

of)

Write-downs (reversals)

Parentheses SHOULD be used to denote positive or negative values and

SHOULD NOT be used to denote alternative terms for a label such as „Deferred

(unearned) revenue‟.

3.4.18 The label component related to XBRL and not to regulations

(accounting standards, acts etc.) MUST be placed between square brackets “[ ]” at the end or beginning of the label

The component of labels placed in square brackets provides XBRL-related

information that does not influence the accounting information (for example

for alternative breakdown). For example:

[824000] Notes – share capital

Disclosure of share capital [abstract]

3.4.19 The standard label for abstract concepts that do not represent hypercubes, dimensions or domain members SHALL append the word

„[abstract]‟ or „[line items]‟ to the end of the label.

Abstract elements are used to organize the taxonomy. Labels for abstract

items shall append the word „[abstract]‟. The reason for this is to differentiate

the concept labels and names.

For example:

„Assets [abstract]‟.

„Disclosure of trade and other payables [line items]‟

3.4.20 The standard label for textBlockItemType concepts SHALL append the word „[text block]‟ to the end of the label

Text block elements are used to disclose narrative information.

For example:

„Disclosure of Exempt Private Certificate [text block]‟.

41

3.4.21 The standard label for dimensions SHALL append the word „[axis]‟ to

the end of the label.

Dimensions are abstract concepts used as containers for domains, and domain

members should be clearly recognizable through their labels.

For example:

„Consolidated and Separate [axis]‟.

3.4.22 The standard label for hypercubes SHALL append the word „[table]‟ to the end of the label.

Hypercubes are abstract concepts used as link between dimensions and line

items.

For example:

„Disclosure of share capital [table]‟.

3.4.23 The standard label for domain members SHALL append the word

„[member]‟ to the end of the label.

Domain members are abstract concepts used as members on the axis

(dimension).

For example:

„Company [member]‟.

3.4.24 The word „total‟ SHALL NOT be used in any label (except in the total label role).

The word „total‟ should not be used in a standard label name. The word „total‟

can be used in the total label role. In addition, the total label role can use the

word „aggregated‟ and net label role the word „net‟.

For example, „Assets, total‟ should not be used as standard label; „Assets‟ is

sufficient.

Examples of disallowed use of „total‟, which should be avoided for standard

label role:

„Assets, total‟

„Changes in issued capital, total‟

„Sales, total‟

„Total assets‟

42

„Aggregated assets‟

3.4.25 Authoritative references SHOULD NOT be used in a label, unless

necessary to make the label meaningful

Labels should not include the name of authoritative literature. However in

certain cases, where it is necessary to include such details, there is can be

used.

3.4.26 Labels representing the period start label SHALL use the following

format ‟at beginning of period‟ at the end of the label. Labels representing the period end label SHOULD use „at end of period‟ at the end of the label.

Example of proper use of the period start and period end label:

„Provisions at beginning of period‟

„Provisions at end of period‟

Example of disallowed use of the period start and period end label:

„Provisions, beginning balance‟

„Provisions, at start‟

„Provisions, period end‟

4. References

The SSM Taxonomy Guide has been prepared considering the practices followed

by some of the globally known taxonomies. The following documentation has

been considered for identifying the scope of information to be provided as part of

Taxonomy Guide.

The IFRS® Taxonomy 2012 Guide

Global Filing Manual (GFM)

ACRA Taxonomy 2013 Guide

The content of this Guide is purely based on SSM Taxonomy. The above

mentioned guides were referred in order to be in line with the documentation

practices followed globally.