Researcher's Blog

Proposed XBRL Processing with COYOTE API

Patterns Identified in Xbrl Processing

We have processed the instance documents according to 2 patterns till now which are given below:

1) Label Values

2) Schedules

Fact Values according to Domain Members(Payment Experience Summary)
Combinations of Fact values and Domain Members’ labels

We have found one other pattern of output in the Financial Statements and that is “Pivot Table” Like Structure.

Above all thing were done before the understanding of XBRLS and fortunately we were not wrong in identifying patterns.

Now after the basic understanding of the XBRLS, we have some clear way to move further.

According to XBRLS

According to XBRLS there are Meta-patterns,

A meta-pattern is a design pattern. The structure of each part of a business report is not unique, but rather follows a design pattern, which offers a standard solution. Once the pattern is recognized for a problem category, we know the approach to come up with a design solution.

Let’s emphasize on the statement

The structure of each part of a business report is not unique, but rather follows a design pattern, which offers a standard solution.

According to my understanding it suggests that in a report (In our case let’s consider it as TAB-Trade Payments) each part (in our case widget-Payment Information or Payment Experience Summary or Account Placed for Collection) is not unique but it will have a standard solution and that is perfectly alright according to our understanding as well.

It means that there can be multiple use cases (Output patterns) and for each unique pattern there will be a different processing and that is perfectly fine.

If we can identify the existing patterns used in current output then we can have different processing for each of them and it will be more maintainable solution. If in future any new pattern is added then we can have different processing for that and our old processing will not be affected by that.

If we can create one general data structure which will be used for the different kind of pattern processing then at least we will be having generic data structure and that won’t be affected in future. Now after creating the generic data structure we can separate the pattern processing and let’s assume we have a separate data structure ready for all patterns individually and that will freeze processing until now and thus we will be having 2 things ready

Generic data structure which will hold the data after processing the instance documents.
Widget blocks for output according to pattern will be ready from pattern processing.

XBRL Processing Flow

XBRL Pattern Processing

Generic Output Data Structure

Till now we have used 3 patterns in our processing and those are:

1) Label Values

2) Schedule Pattern

3) Record Pattern

4) And in financial statements, it seems as it has Hierarchical pattern.

Generic Output Data Structure can be a combination of the following structures according to patterns.

Label Value Pattern Key

XBRLDto object has 2 properties1)Label

2)ValueObject(Contains the value of the label, Context information and any information required)Schedule Pattern KeySchedule Object has 3 properties1)Row headers

2)Column Headers

3)Data Object has property

3.1) DataRowObjects have

3.1.1) ValueObject(Contains the value of the label, Context information

And any information required)Record Pattern KeyRecord Object has 3 properties1)Row headers

2)Column Headers

3)Data Object has property

3.1) DataRowObjects have

3.1.1) ValueObject(Contains the value of the label, Context information

And any information required)Hierarchical Pattern KeyHierarchical Object has 3 properties1)Row headers

2)Column Headers

3)Data Object has 1 property

3.1) DataRowObject have

3.1.1) ValueObject(Contains the value of the label, Context information

And any information required)

Issues and Solution

How to identify patterns that is a different issue and can be discussed in detail for efficient outcome but if we can identify specific patterns and have different processing for that then it will be more maintainable and easy for us to handle different kind of scenario.

As of now we have identified 3 patterns and if we have the information regarding patterns used then we will have more efficient handling of those patterns and that way we will not have to change processing much.

1) How to Identify Patterns?

Let’s relate a thing we all know and that is the structure of DataCube and the custom processing we have done.

In the DataCube cliff has identified the schedules (Hypercubes) available in the given documentSet and then processed things accordingly.

He has identified schedules with the use of regular expression on labels with

public String m_scheduleSuffixRegularExpression = “^.* \\[Schedule\\]$”;

and created DataCube.

In our custom processing we are doing following things:

We identify the Abstracts available and then find the Schedules (I would love to mention here that we are not using any specific searching criteria to find schedules but we have found it according to the structure available in all presentation linkbase)
After we find the schedule we have identified whether it is a case of Payment Experience Summary(Where single Dimension is available) or it is a case of Account Placed For Collection(Where multi Dimension is available) or it is a case of Financial Statement(Balance Sheet)(Where Balance Sheet [Hierarchy] abstract item is available). So we have 3 identifiers for patterns as of now in custom processing.
1. Single Dimension
2. Multi Dimension
3. Hierarchy Abstract Element
For Label-Value case we have observed that those are direct child of abstract and not abstract.

So from above what I understand is 2^nd case can be easily identified since we will have Schedules (Hypercubes) if we assume we are using DataCubes. Now For Label and Values we need to make some space in the DataCube Structure if we can and that will solve all issues as far as the current instance files available.

2) Code should not be using any XBRL related stuff outside the XPU [XBRL processing Utilities], if we get any Coyote of XPU code to the Pattern processing then that would be leakage of concerns

For pattern processing we need the Coyote and so we need to use it there. I don’t know whether I am correct in interpreting the issue. We can discuss on this issue.

3)

The “Schedule” meta pattern is a container which is used by all other meta-patterns. The table holds all other portions of the pattern. A Schedule may contain a Hierarchy pattern, a Calculation pattern or a Movement pattern.

So, Schedule can be represented in different ways as we have in Trade payments Tab for the widget “Payment Experience Summary (Single Dimension)” and “Account placed for collection (Record Pattern –Multiple Dimension)” so we can identify the difference between these two by identifying number of dimension.

And Hierarchy pattern in the case of financial statement is contained in the Schedule Pattern and till now whatever use cases we are having, we have been able to separate the processing for them but we can’t be sure for this thing. And multiple use cases can be there.

4) Rules Processing

Pattern Processor should take care of the rules suggested by the Eugene

Benefits

After processing instance file we will get output data structure that will serve as input for pattern processing will be fixed once and for all and so we will be out from the issue of processing instance file. (this structure can be a issue to discuss and once fixed, must not be touched again)
For different patterns there will be separate processing so we can maintain the pattern processing easily and we can also add new patterns easily without much effort and it will not affect the current processing as well.
We will have an output data structure which will be a combination of data structures coming out from specific patterns (As shown in Figure) and that will be the data which we need and need to display.

Please provide your input and concerns for this specific approach. I have found this much easier but we can discuss it to make more efficient and help ourselves in a big way.

Please discuss this approach and if all concerned persons are agreed then we can move forward in the same direction.

1) How to Identify Patterns?

Let’s relate a thing we all know and that is the structure of DataCube and the custom processing we have done.

In the DataCube cliff has identified the schedules (Hypercubes) available in the given documentSet and then processed things accordingly.

He has identified schedules with the use of regular expression on labels with

public String m_scheduleSuffixRegularExpression = “^.* \\[Schedule\\]$”;

and created DataCube.

In our custom processing we are doing following things:

We identify the Abstracts available and then find the Schedules (I would love to mention here that we are not using any specific searching criteria to find schedules but we have found it according to the structure available in all presentation linkbase)
After we find the schedule we have identified whether it is a case of Payment Experience Summary(Where single Dimension is available) or it is a case of Account Placed For Collection(Where multi Dimension is available) or it is a case of Financial Statement(Balance Sheet)(Where Balance Sheet [Hierarchy] abstract item is available). So we have 3 identifiers for patterns as of now in custom processing.
1. Single Dimension
2. Multi Dimension
3. Hierarchy Abstract Element
For Label-Value case we have observed that those are direct child of abstract and not abstract.

2) Code should not be using any XBRL related stuff outside the XPU [XBRL processing Utilities], if we get any Coyote of XPU code to the Pattern processing then that would be leakage of concerns

For pattern processing we need the Coyote and so we need to use it there. I don’t know whether I am correct in interpreting the issue. We can discuss on this issue.