This feature allows the design objects of one application to be distributed and reflected in a different application. Only design objects are distributed, and administrative objects are not distributed. Therefore, in the destination application, it is possible to register/set up its own administrative objects. One typical use of this feature is the construction of a standard management accounting system to be deployed across group companies.

The headquarters creates a common template application (source application), which is then distributed to each group company. Each group company registers its own unique accounts and departments in the distributed application (destination application) for use.

Using this feature, when design objects are added, changed, or deleted in the source application, those changes can be distributed to each destination application.

For example, in the department dimension of the source application, register the "Total" member as a template member (design object). In the destination application, each company can register its own departments under this member. The departments registered by each company are "user-defined members" (administrative objects).

When there are changes to design objects in the source application, such as adding dimensions or ledgers, or modifying/adding forms, the template (the entirety of design objects) of the source application can be exported and imported into the destination application to distribute the changes. In this case, user-defined members and data already registered in the destination application are generally retained as is.

To export the entirety of design objects, i.e., the template from the source application, use [Web-API] (or Requester). The request type for exporting is as follows:

The template data is in hexadecimal format, and its format is not public. To import template data into the destination application, use [Web-API] (or Requester) as well. The request type for importing is as follows:

Note that import operations may fail due to conflicts with other processes, such as dimension updates. In such cases, the destination application remains unchanged. Determine the presence of an error through the "operation result code" in the response body or the exit code of the Requester, and retry if necessary.

Below are cases where data registered on the side of the destination application may be deleted/changed due to the incorporation of template data.