Ledger Data Edition Management

Designer Administrator
This manual is in pilot operation.

Ledger data is managed by "editions". In addition to the "Published Edition" and "Working Edition" that exist in every application, administrators can create arbitrary editions. Users (administrators) can also create any edition derived from existing ones.

"Published Edition" and "Working Edition"

Both "Published Edition" and "Working Edition" are present in every application.

When you want to modify ledger data, you can work on the Working Edition without affecting the Published Edition, which is read-only. Once work on the Working Edition is completed, its contents can be "published" and reflected in the Published Edition.

Using the Published and Working Editions allows for the separation of data modification tasks from usage tasks, enabling concurrent work while minimizing interference.

The "PUBLIC" and "WORKSPACE" ledger edition keys are automatically assigned to the Published and Working Editions, respectively (A ledger edition key is a code prepared for users to identify editions).

Publishing Working Edition Data

Once modifications are completed, the data of the Working Edition can be "published". By "publishing," the contents of the Published Edition are replaced with those of the Working Edition at that point in time. The publication process can be executed by scenario (it is also possible to publish multiple scenarios together).

Clearing Working Edition Data

If you wish to redo modifications, you can also "clear" the Working Edition data. Clearing replaces the contents of the Working Edition entirely with those of the Published Edition at that point, the exact opposite of "publishing".

Ledger Edition Key

Editions can be assigned a "ledger edition key". A ledger edition key is a code for specifying editions. It can include up to 200 characters using characters that can be used in labels.

A ledger edition key consists of multiple sub-keys connected by periods. For example, here are some ledger edition key examples:



To include periods in sub-keys themselves, enclose the sub-key with single quotes:


Sub-keys without periods are regarded the same whether they are enclosed in single quotes or not. For example, the following two are different in their string representation but are the same ledger edition key:



When a ledger edition key is saved, unnecessary single quotes are removed. In the examples above, any ledger edition key would be saved as "FY2018.BUDGETING.20180220".

Reserved Ledger Edition Keys

Just as with labels, ledger edition keys starting with a hash symbol are reserved, and administrators cannot assign them. Note that the Published and Working Editions are pre-assigned the ledger edition keys "PUBLIC" and "WORKSPACE". Though they don’t start with a hash symbol, they are still reserved and cannot be freely assigned by administrators.

Ledger edition keys are used to specify target ledger editions when accessing ledger data via the [Browser] or the [Excel-Link].

Unreserved ledger edition keys can be erased or changed. Be careful when erasing a ledger edition key because that edition will no longer be accessible from the [Browser] or [Excel-Link] (it will become accessible again if the key is reassigned).

If a ledger edition key is erased from one edition and assigned to another, accessing that ledger edition key via the [Browser] or [Excel-Link] will access the newly assigned edition from then on.

Access Control for Ledger Editions

Access control for ledger editions can be implemented using Access Permission Types. For example, it’s possible to limit which participants can view or update the Working Edition. For more details, see the explanation on "ledger edition groups" and "ledger editions" in text expressions.

Furthermore, when using the Business Process Management feature, as described below, ledger editions are created for each participating participant in the business process. It’s possible to control access so that only the participant "owning" those editions can access them. See Ledger Editions and Access Control in Business Processes for more details.

Business Process Ledger Editions

When using the Business Process Management feature, specific ledger editions for the business process are created. There are two types of business process ledger editions, each assigned a predetermined format of ledger edition key:

Type of Business Process Ledger Edition Description Ledger Edition Key Format

Root Edition of the Business Process

One is created for each business process. It’s the content of the Working Edition at the time of the business process creation (or when executing "Intake Working Edition Data" thereafter).

Prefix "#P" followed by the business process definition label, fiscal year label, and relative period label, connected by periods.

Example: #P.BUDGETING.FY2014.H1

Workspace Edition for Each participant

One is created for each business process and for each participant participating in that business process. The initial data content is the same as the root edition of the business process, but it will be updated with data entered by each participant afterward.

Note that a single participant (e.g., Department A) will have different workspace editions for each business process (e.g., FY2014 H1 Budgeting and May 2014 Actual Processing).

⚠ The Finalizer participant of the business process, regardless of the above, can use the "Working Edition/WORKSPACE" as its own workspace. Details are explained in the section on Business Process Definitions.

The key of the root edition of the business process mentioned above, further connected with the label of the participant separated by periods.

Example: #P.BUDGETING.FY2014.H1.A

Business process ledger editions cannot be directly registered or deleted by users. They are automatically registered or deleted in conjunction with the creation or deletion of the business process.

General Ledger Editions

Apart from the above, administrators can create any ledger editions. Editions can be created by deriving them from existing editions. The source edition for derivation is not limited to the Published and Working Editions but can be any existing edition.

All ledger editions, including the "Published Edition" and "Working Edition", form a tree structure through derivation relationships.

The content of each edition is exactly the same as its source immediately after creation. Since only the differences from the source are stored in the database and memory for each edition, the creation process is very fast. Even if the source edition contains a large amount of data, it is not copied.

Uses of "General Ledger Editions"

Various uses for "Other Editions" can be considered, but here are two examples:

(1) Holding Multiple Budget Value Patterns

When budgeting, you may want to create several scenarios with slight modifications to the basic budget values. In such cases, you can hold the basic plan data in the Working or Published Edition, and then derive multiple editions from it to make modifications on those editions.

(2) Retroactive Corrections for Calculation Standard Changes

When changing the standards for management calculations, such as the allocation basis for overhead costs, you may need to retroactively reprocess past data according to the new standard. However, you often want to keep the numbers calculated under the previous standard.

In such cases, derive a new edition (let’s call it Edition A) from the edition holding data before the standard change (either the Published or Working Edition). Edition A will contain data processed under the old standard.

Meanwhile, reprocess past data under the new standard on the Working Edition and publish it.

Retroactive processing will not be reflected in the previously derived Edition A, leaving the data processed under the old standard always accessible.

Restrictions on Updating Data of Source Editions

Data in a ledger edition that serves as the source for other editions becomes read-only (data cannot be written). This restriction exists because updating data in such an edition could unintentionally affect all editions derived from it (since only the differences from the source are stored in the derived editions, updating the source data would seem to also update the data in the derived editions). If you wish to update the data of a ledger edition that serves as the source for others, you should create a new edition from that source edition and update the data there.

Publishing "Other Editions"

Just like the Working Edition, the content of "Other Editions" can be published (reflected in the Published Edition). The ability to specify target scenarios for publication is the same. Please note that when publishing an edition other than the Working Edition, the content of the Working Edition is cleared for the target scenarios, and the content of the Published Edition after publication (i.e., the content of the published edition) becomes the same.

Compressing Series of Editions

Repeated derivation of editions leads to an increasingly large edition tree and an accumulation of unnecessary editions. In such cases, deleting the ledger keys of the unnecessary editions and then compressing the series of editions can compress the series (tree) of editions. Editions that meet the following two conditions will be deleted through series compression:

  • Not having an assigned ledger edition key (including cases where an initially assigned ledger edition key has been deleted), and,

  • Not being a branching point in the tree of ledger editions (i.e., not having multiple direct derived editions).

Data in editions deleted through compression will be integrated into the data of their directly derived editions if they existed before the compression (if there are no derived editions, they will be deleted).

Ledger Edition for Submission Packages

"Ledger Edition for Submission Packages" is available only in applications of the Workflow Type.

Submission packages generated by the Business Process Management feature are treated as pseudo ledger editions and are assigned ledger edition keys. By specifying a cell holding this ledger edition key during the link area setting in [Excel-Link], you can query the content of the submission package.

Ledger Edition Key for Submission Packages

The ledger key for submission packages is formed by prefixing ‘#P’ and then connecting the business process definition label, fiscal year label, relative period label, participant label, submission package definition label, and submission sequence number with periods.

Example: #P.BUDGETING.FY2018.H1.A.SALES.2


Business process definition label


Fiscal year label


Relative period label


participant label


Submission package definition label


Submission sequence number (this example indicates the second submission package)

Clients That Can Use Ledger Edition for Submission Packages

The ledger edition for submission packages can only be queried in [Excel-Link]. It cannot be queried in the fusion_place [Browser] (the ledger edition will not be displayed as an option).

Unique Access Control for Ledger Edition of Submission Packages

The ledger edition for submission packages is read-only. Furthermore, only the participant that submitted the package and the participant that has received or can receive the package can refer to the data of the ledger edition for submission packages. Others follow the standard ledger access control.

Notes on Data Contained in the Ledger Edition for Submission Packages

The ledger edition for submission packages contains only the submitted data. [1]

Even if data could be derived from submitted data through aggregation calculations in dimensions, it will not be included in the ledger edition for submission packages unless it itself was part of the submitted data. For example, if the expense accounts are registered as child members of the total expenses in the account dimension tree, the total expenses can be derived from the amounts of each expense account. However, if the form of the submission package includes only each expense account and not the total expenses, then the total expenses will not be included in the ledger edition for submission packages. Note that rows and columns set to be hidden by the form settings are considered visible for this determination, so their data is included in the submission package.

"Hidden Ledger Edition" for Scenarios Not Subjected to Ledger Edition Management (fusion_place >= 12.1)

When the scenario attribute "Exclude from Ledger Edition Management" is set, data for such scenarios contained in ledger editions other than the Working Edition [2] are deleted, and new hidden ledger edition data common to all ledger editions for the same scenario is created in the Working Edition.

Hidden Ledger Edition Key for Scenarios Not Subjected to Ledger Edition Management

The ledger key for the hidden ledger edition is formed by prefixing '#S' and connecting it with the scenario label with periods.
Example: Excluding the actual scenario (label "ACTUAL") from ledger edition management

Screens/Functions Where Hidden Ledger Edition Can Be Specified

Hidden ledger editions can be used (selected or specified) in the following screens/functions that operate on the ledger edition itself regardless of the data content of the ledger edition.

  • [Manager] "Ledger Update History" screen

  • [Web-API] / [Requester] for the following processes:

    • Compressing generational ledger line data (COMPRESS_LEDGER_LINES)

    • Deleting ledger update history (DELETE_LEDGER_HISTORY)

Screens/Functions Where Hidden Ledger Edition Cannot Be Specified

Since there is no need to perform operations such as reassigning ledger edition keys, creating derived editions, or publishing for hidden ledger editions, they are not displayed in the following screen.

  • [Manager] "Processing Execution > General Ledger Edition Management" screen

Moreover, in screens/functions that access the data content of the ledger edition, hidden ledger editions cannot be used (selected or specified).

  • [Browser] and other ledger edition selection fields

  • [Excel-Link] for specifying ledger edition keys

  • [Web-API] / [Requester] for the following processes:

    • Importing data using forms (IMPORT_VALUES)

    • Executing calculations using forms (CALCULATE_BY_FORM)

    • Exporting data using forms (EXPORT_VALUES)

    • Publishing Working Edition data (PUBLISH_EDITION)