<trial DeepL> Ledger edition management of ledger data

designer administrator
This manual is in pilot operation.

Ledgers data is managed in "editions. In addition to the "published editions" and "shared working editions" that always exist in any application, the administrator can create arbitrary editions. The user (administrator) may further create arbitrary editions derived from the existing editions.

"Public" and "Shared Work Editions

Public" and "Shared Working Editions" are always present in any application.

When you want to modify data in Ledgers, you can work on the shared working edition without affecting the public edition. The public edition is for reference only. Once you have completed your work in the shared working version, you can "publish" the content to the public version.

By using the published and shared editions, you can work in parallel while keeping data modification and usage tasks well separated to minimize interference.

The published and shared editions are automatically assigned the ledger edition keys "PUBLIC" and "WORKSPACE", respectively (the ledger edition key is a code that allows the user to identify the edition).

Publishing Shared Working Edition Data

Once the modification is complete, the shared working edition data will be available at https://docs.fusionplace.net/manual/ja/op_guides/manager/execution/manage_shared_workspace_edition/publishing _working_edition_data.html[Publish]. Publishing" replaces the content of the published edition with the content of the current shared working edition. The publishing process can be performed on a scenario basis (multiple scenarios can be published at once).

Clearing Shared Working Edition Data

When you want to redo a revision, you can clear the shared working edition data at https://docs.fusionplace.net/manual/ja/op_guides/manager/execution/manage_shared_workspace_edition/ clearing_working_edition_data.html[clear]. Clearing" completely replaces the content of the shared working edition with the content of the current published edition, exactly the opposite of "publishing".

Ledger edition key

You can assign a "ledger edition key" to an edition. The ledger edition key is a code used to designate an edition; it can be up to 200 characters long and can be any of the characters used in Label.

A ledger edition key is composed of multiple partial keys joined by a period. For example, the following is an example of a ledger edition key

A

FY2018.BUDGETING.20180220

Note that to include a period in a period-delimited partial key itself, enclose the partial key in single quotes as follows:

FY2018.'BUDGEING.02'.20180220.

None of the partial keys that do not contain a period are considered the same value whether they are enclosed in single quotes or not. For example, the following two are the same ledger edition key, although they have different string representations:

FY2018.BUDGETING.20180220

FY2018.'BUDGETING'.20180220

When ledger edition keys are saved, unnecessary single quotes are deleted. In the example above, any ledger edition key would be saved as "FY2015.BUDGETING.20150220".

reserved ledger edition keys

As with Labels, ledger edition keys beginning with a Sharpie are reserved and cannot be assigned by the administrator. The ledger edition keys "PUBLIC" and "WORKSPACE" are pre-assigned to the public and shared working editions. These keys do not start with a Sharpie, but are also reserved and cannot be assigned freely by the administrator.

Ledger edition keys can be found at [ browser] and https://docs.fusionplace. net/manual/en/op_guides/excel_link/excel_link_overview.html[[Excel-Link\]] to specify the target Ledger edition when accessing Ledger data.

None of the ledger edition keys are reserved and can be deleted or changed. If a ledger edition key is deleted, then that ledger edition will be stored in [ browser] or https:// Note that the ledger version will no longer be accessible from docs.fusionplace.net/manual/en/op_guides/excel_link/excel_link_overview.html[[Excel-Link\]] (it will be accessible again once the key is (Assigning the key again will make it accessible).

If you delete a ledger edition key from one ledger edition and assign it to another ledger edition, you will not be able to access [Browser] or [Excel_link_overview.html[[Excel-Link] from now on. or [Excel-Link]* with that ledger edition key. the ledger edition edition of the newly assigned key will be accessed.

Access control for Ledger editions

Access Permission Types can be used to control access to ledger editions. For example, it is possible to limit the participants who can view or update a shared working edition. For more information, see . Ledger Editions" and "Ledger Editions" in the text formula.

When using the business process management function, ledger editions are generated for each business unit participating in a business process, as described below, and it is possible to control access to such editions by only allowing access to those participants who "own" the ledger edition. See Ledger editions used in business processes and access control. Please refer to the following page.

Ledger editions of business processes

When using Business Process Management, a process-specific ledger edition is created. There are two types of ledger editions for business processes, each of which is assigned a ledger edition key in a specific format:

Type of Ledger Edition of Business Process Description Format of ledger edition key

Root edition of business process

===

One is created for each business process. This is the content of the shared working edition when the business process is created (or when "Import data from shared working edition" is executed afterwards).

The prefix "#P" and the Process Definitions Label, Fiscal Years Label, and Relative Periods Label are connected by a period.

Example: #P.BUDGETING.FY2014.H1

Workspace edition for each participants

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

Note that even one BUDGET participants (e.g., Department A) will have different workspace editions for each business process (e.g., BUDGET for the first half of 2014 and ACTUAL for May 2014).

The business process participants in charge of finalizing public data will use the "Shared Work Edition/WORKSPACE" as its own workspace, regardless of the above. The workspace version of the business process [work unit responsible for finalizing published data] can use "shared work version/WORKSPACE" as its own workspace regardless of the above. For more information, please refer to Process Definitions section.

Ledger editions of business processes cannot be directly registered or deleted by users. The ledger version of a business process is automatically registered and deleted when the business process is created or deleted.

General Ledger edition

In addition to the above, the administrator can create any ledger edition. An edition can be created by deriving it from an existing edition. The derived editions are not limited to the Public and Shared Work editions, but can be derived from any existing edition.

All Ledger editions, including "public" and "shared working" editions, have a tree structure formed by derivation relationships.

The content of each edition is exactly the same as the edition from which it was derived immediately after creation. The creation process is very fast because each edition contains only the difference data from the source edition, both in the database and in memory. None is copied, even if the original edition contains a large amount of data.

Uses of "General Ledger Editions"

There are many possible uses for "other editions," but here are two examples:

(1) Holding multiple patterns of BUDGET values

When preparing a BUDGET, you may want to create multiple versions of the basic BUDGET with slight modifications. In such cases, the data of the basic proposal can be maintained in a shared working or public version, from which multiple editions can be derived, and modifications can be made on those editions.

(2) Retroactive modifications in the event of changes in calculation standards

If the standard for administrative calculations, for example, the standard for calculating the allocation of common expenses, is changed, it may be necessary to go back in time and redo the process using the changed standard. However, even if the calculations are to be redone, it is often the case that the figures calculated under the previous standard should be retained.

In such cases, a new edition is created (let’s call it Edition A) derived from the edition (either the public edition or the shared work edition) that holds the data prior to the change in the standard. This edition A contains the data processed under the old standard.

On the other hand, in the shared working edition, we go back and redo the processing with the new criteria and publish the data.

The previously derived edition A does not reflect the retroactive processing, and the data processed with the old standard remains available for reference at any time.

Restrictions on updating data in the derived edition

Data in ledger editions that are derived from other editions are for reference only (data cannot be written). The reason for this restriction is that updating the data in that edition will have an unintended effect on the data in all editions from which it is derived (since the destination edition holds only the difference data from the source edition, updating the data in the source edition will, to the user’s eyes, also update the data in the destination edition). (Since the target holds only the difference data from the source, updating the source data will also update the target data in the eyes of the user). If you wish to update data in a ledger edition from which another edition is derived, create a new edition from that edition and update the data in that edition.

Publishing "Other Editions"

You can publish "other editions" in exactly the same way as shared working editions. You can specify which Scenarios are to be published. Please note that if you publish an edition other than the shared working edition, the content of the shared working edition will be cleared and the content of the published edition will be the same as the content of the published edition (i.e., the content of the edition you published).

Compressing the edition series

As editions are repeatedly derived, the tree of editions gradually grows larger, and more and more editions are no longer needed. In such cases, the ledger edition keys of the unneeded editions can be deleted and the edition tree can be compressed by compressing series of editions. Delete an edition by compressing the edition series if the following two conditions are met

  • None has been assigned a ledger edition key (including cases where the once-assigned ledger edition key has already been deleted), and

  • None is a branch point in the tree of ledger editions (i.e., it does not have more than one directly derived edition).

Data from an edition deleted due to compression will be merged with data from any directly derived editions that existed from that edition at the time prior to compression (or deleted if None existed).

Ledger edition of the submission package.

The "Ledger Edition of the Submission Package" is only available for applications of the Workflow Type.

The "Submission Package" generated by the Business Process Management function is treated as a pseudo ledger edition and assigned a ledger edition key. The contents of a submission package can be queried by specifying a cell that holds this ledger edition key when setting the link region of [Excel-Link].

Ledger edition key for a submission package

The Ledgers key of a submission package is a prefix “#P” followed by a Process Definitions Label, Fiscal Years Label, Relative Periods Label, Period Unit Label, Submission Package Definitions Label, Submission Order Sequential Number, and a period.

Example: #P.BUDGETING.FY2018.H1.A.SALES.2 [horizontal]. BUDGETING":: Process-related Definitions Label FY2018":: Fiscal Years Label H1":: Relative Periods Label A":: Participants Label SALES":: Submission Package Definition Label 2":: Sequential number in submission order (this example indicates that this is the second submission package)

Clients with available Ledger editions of the Submission Package

Ledger editions of submitted packages can only be queried on [Excel-Link], not on fusion_place [Browser] (they will not appear in the Ledgers edition selection).

Access Controls Specific to Ledger Editions of Submission Packages

Ledger editions of the submission package are for reference only. In addition, only the Ledgers edition of a submission package can refer to the data of the Ledgers edition of the submission package, as well as the participants who have accepted or can accept the package. Otherwise, Normal Ledgers Access Control will be followed.

Notes on data contained in the ledger edition of the submission package

The ledger edition of the submission package contains only the submitted data*.

Please note that data that can be derived by performing aggregate calculations with Dimensions based on the submitted data will not be included in the ledger edition of the submission package unless the data itself is included in the submitted data. For example, if each expense account is registered as a Child member of the expense total in the Member Trees of the Accounts dimension, then the expense total can be derived from the amount of each expense account. However, if the submission package form includes only expense line items but not expense totals, then the expense totals will not be included in the ledger edition of the submission package. Note that rows and columns that are hidden in the form settings are assumed to be visible for the purposes of this decision. Therefore, the data will be included in the submitted package.

Submitted data is data for keys other than Relative Periods and Views for each of the keys of the data displayed on the form in the submission package. For example, if the submitted data includes "Sales for the Single Month of June," then it also includes "Year-to-date sales for May" for the same year.

"Hidden ledger edition" for Scenarios where None ledger edition control is applied ( fusion_place >= 12.1 )

If the attribute "Is edition-insensitive" is set for Scenarios, the ledger edition [1]. The data of the scenarios included in the scenarios in the "Scenarios" section will be deleted, and the same scenario data of the shared work edition will be newly created as a hidden ledger edition as the common scenario data for all ledger editions.

Hidden ledger edition keys for Scenarios for which Ledger Edition Management is not applied

The ledger edition key for hidden ledger editions is a prefix "#S" followed by a period between the scenarios labels. +S Example: Is edition-insensitive for the ACTUAL scenarios (Label "ACTUAL")
  #S.ACTUAL

Screens/Functions where hidden ledger editions can be specified

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

  • [Manager]'s "Ledgers Update History" screen

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

    • Compression of Ledgers row data by generation (COMPRESS_LEDGER_LINES)

    • Delete Ledgers update history (DELETE_LEDGER_HISTORY)

Screens/Functions where None of the hidden ledger editions can be specified

Hidden ledger editions are hidden in the following screens because none of the operations such as reassigning ledger edition keys, creating derived editions, or publishing ledger editions need to be performed.

  • "Process Execution > General Ledger Edition Management" screen of [ manager ].

In addition, the following screens/functions that access the data contents of ledger editions cannot be used (selected or specified).

  • Ledger edition selection fields in [Browser ], etc.

  • [Excel-Link] to specify ledger edition key

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

    • Importing data using forms (IMPORT_VALUES)

    • Performing calculations using forms (CALCULATE_BY_FORM)

    • Exporting data using forms (EXPORT_VALUES)

    • Publish working edition data (PUBLISH_EDITION)