Ledger Edition Management (ChatGPT)
This manual is in pilot operation.
|
Ledger data is managed by dividing it into "Editions". In addition to the "Public Edition" and "Shared Workspace Edition" that exist in every application, administrators can create any number of editions. Users (administrators) can further create any number of editions derived from existing ones.
"Public Edition" and "Shared Workspace Edition"
The "Public Edition" and "Shared Workspace Edition" are present in every application.
When you want to modify ledger data, you can work on the Shared Workspace Edition without affecting the Public Edition. The Public Edition is read-only. Once work on the Shared Workspace Edition is completed, its contents can be "published" to reflect in the Public Edition.
By using the Public Edition and Shared Workspace Edition, it is possible to separate data modification tasks from usage tasks and proceed with them in parallel while minimizing interference.
The Public Edition and Shared Workspace Edition are automatically assigned "PUBLIC" and "WORKSPACE" as their Ledger edition keys respectively (Ledger edition keys are codes prepared for users to identify editions).
Publishing Shared Workspace Edition Data
Once the modification work is completed, the data of the Shared Workspace Edition can be published. By "publishing", the content of the Public Edition is replaced with the content of the Shared Workspace Edition at that moment. The publishing process can be executed based on scenarios (it is also possible to publish multiple scenarios together).
Clearing Shared Workspace Edition Data
If you wish to redo the modification work, you can also clear the data of the Shared Workspace Edition. "Clearing" completely replaces the content of the Shared Workspace Edition with the content of the Public Edition at that moment, which is 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 an edition. It can be up to 200 characters long, using characters that can be used in labels.
A Ledger edition key consists of multiple part-keys connected by periods. For example, here are some examples of Ledger edition keys:
A
FY2018.BUDGETING.20180220
To include a period in a part-key itself, enclose that part-key in single quotes as follows:
FY2018.'BUDGETING.02'.20180220
Part-keys without periods are considered the same value, whether they are enclosed in single quotes or not. For example, the following two are different in string representation but are the same Ledger edition key:
FY2018.BUDGETING.20180220
FY2018.'BUDGETING'.20180220
When a Ledger edition key is saved, unnecessary single quotes are removed. In the examples above, either Ledger edition key would be saved as "FY2018.BUDGETING.20180220".
Reserved Ledger Edition Keys
Similar to labels, Ledger edition keys starting with a sharp sign are reserved and cannot be assigned by administrators. Note that the Public Edition and Shared Workspace Edition are pre-assigned Ledger edition keys "PUBLIC" and "WORKSPACE". Though these do not start with a sharp sign, they are still reserved and cannot be freely assigned by administrators.
Ledger edition keys are used to specify the target Ledger edition when accessing ledger data via [Browser] or [Excel-Link].
Unreserved Ledger edition keys can be deleted or changed. If a Ledger edition key is deleted, that Ledger edition becomes inaccessible from [Browser] or [Excel-Link] (it becomes accessible again if a key is reassigned).
If a Ledger edition key is deleted from one Ledger edition and assigned to another, from then on, specifying that Ledger edition key in [Browser] or [Excel-Link] will access the newly assigned Ledger edition.
Access Control for Ledger Editions
Access permissions can be used to control access to Ledger editions. For example, it is possible to limit which Participants can view or update a Shared Workspace Edition. For more details, see the description of "Ledger Edition Groups" and "Ledger Editions" in text expressions.
Moreover, when using the business process management feature, Ledger editions are generated for each Participant involved in a business process as described below. It is also possible to control access so that only the Participant "owning" such editions can access them. See Ledger Editions used in business processes and access control for more information.
Ledger Editions for Business Processes
When using the business process management feature, specific Ledger editions for business processes are created. There are two types of Ledger editions for business processes, each assigned a predetermined format of Ledger edition key:
Type of Business Process Ledger Edition | Description | Format of Ledger Edition Key |
---|---|---|
Root Edition for Business Process |
One is created for each business process. It is the content of the Shared Workspace Edition at the time of business process creation (or when "Importing Data into Shared Workspace Edition" is executed). |
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 Participant involved in a business process. The initial data content is the same as the Root Edition for the Business Process, but it is updated with data entered by each Participant thereafter. Even within a single Participant (e.g., Department A), different Workspace Editions exist for each business process (e.g., FY2014 First Half Budgeting and May 2014 Actual Processing). *Note: The Finalizer Participant responsible for publishing data in a business process can use the "Shared Workspace/WORKSPACE" as their own workspace, regardless of the above. More details are provided in the business process definition section. |
The Ledger Edition Key of the aforementioned Root Edition for the Business Process, with the Participant label appended at the end, separated by a period. Example: #P.BUDGETING.FY2014.H1.A |
Ledger Editions for business processes cannot be registered or deleted directly by users. They are automatically registered and deleted along with the creation and deletion of business processes.
General Ledger Editions
In addition to the above, administrators can create any Ledger editions they wish. Editions can be created by deriving from existing editions. The source edition for derivation is not limited to the Public Edition and Shared Workspace Edition but can be any existing edition.
Including the "Public Edition" and "Shared Workspace Edition", all Ledger editions form a tree structure through derivation relationships.
The content of each edition is exactly the same as its source edition immediately after creation. Since only the differences from the source edition are stored in the database and memory for each edition, the process of creating an edition is very fast. This is because the data from the source edition is not copied, even if it contains a large amount of data.
Uses of "General Ledger Editions"
The uses of "Other Editions" can vary, but here are two examples:
(1) Holding Multiple Budget Value Patterns
During budget preparation, you might want to create several versions of the budget with slight modifications to the basic budget values. In such cases, you can hold the basic case data in the Shared Workspace Edition or Public Edition and derive multiple editions from there, making modifications on those editions.
(2) Retroactive Corrections When Changing Calculation Bases
When changing the standards for management calculations, such as the allocation basis for shared costs, it might be necessary to retroactively process according to the new standards. However, you might want to keep the numbers calculated under the previous standards.
In such cases, you derive a new edition (let’s call it Edition A) from the edition holding the data before the standard change (either the Public Edition or Shared Workspace Edition). Edition A retains the data processed under the old standards.
Meanwhile, on the Shared Workspace Edition, you retroactively process according to the new standards and publish that data.
The retroactive processing will not be reflected in the previously derived Edition A, ensuring that data processed under the previous standards remains accessible at any time.
Restrictions on Updating Data of Source Editions
Data of Ledger editions that serve as the source for other editions becomes read-only (data writing is not allowed). This restriction is in place because updating the data of such editions could unintentionally affect all editions derived from it (since derived editions only hold differences from the source, updating the source’s data would appear to users as if the derived editions' data were also updated). If you wish to update the data of a Ledger edition that serves as a source for others, create a new edition derived from that edition and update its data.
Publishing "Other Editions"
Just like the Shared Workspace Edition, the contents of "Other Editions" can be published (reflected in the Public Edition). The ability to specify target scenarios for publication is the same. When publishing an edition other than the Shared Workspace Edition, the content of the Shared Workspace Edition is cleared, and after publication, the content of the Public Edition (i.e., the published edition’s content) becomes the same, so please be cautious.
Compressing a Series of Editions
Repeatedly deriving editions can gradually increase the size of the edition tree and also increase the number of unnecessary editions. In such cases, by deleting the Ledger edition keys of unnecessary editions and compressing the series of editions, it is possible to compress the edition series (tree). Editions meeting the following two conditions can be deleted through series compression:
-
Not being assigned a Ledger edition key (including cases where a previously assigned Ledger edition key has been deleted), and,
-
Not being a branching point on the tree of Ledger editions (i.e., not having multiple direct derivative editions)
The data of editions deleted through compression is integrated into the data of editions directly derived from them if such derivative editions existed at the time of compression (if no derivative editions exist, they are deleted).
Ledger Edition for Submission Packages
"Ledger Edition for Submission Packages" is only available in applications of the Workflow Type. |
"Submission Packages" generated by the business process management feature are treated as pseudo Ledger editions, and a Ledger edition key is assigned. By specifying the cell holding this Ledger edition key during the link area setting of [Excel-Link], it is possible to inquire the content of the Submission Package.
Ledger Edition Key for Submission Packages
The Ledger edition key for Submission Packages is in the format of prefix “#P” followed by the business process definition label, fiscal year label, relative period label, Participant label, Submission Package definition label, and submission sequence number, connected by periods.
Example: #P.BUDGETING.FY2018.H1.A.SALES.2
"BUDGETING" |
Business process definition label |
"FY2018" |
Fiscal year label |
"H1" |
Relative period label |
"A" |
Participant label |
"SALES" |
Submission Package definition label |
"2" |
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 inquired through [Excel-Link]. It cannot be inquired through fusion_place [Browser] (it does not appear in the selection options for Ledger Editions).
Access Control Specific to Ledger Edition for Submission Packages
The Ledger Edition for Submission Packages is read-only. Furthermore, only the Participant that submitted the package and the Participant that accepted or can accept the package can refer to the data of the Submission Package’s Ledger Edition. Others follow the normal ledger access control.
Considerations Regarding Data Included in the Ledger Edition for Submission Packages
The Ledger Edition for Submission Packages includes only the submitted data (※).
Even if data can be derived through dimension aggregation calculations based on the submitted data, if it itself is not included in the submitted data, it will not be included in the Ledger Edition for Submission Packages. For example, if the account dimension member tree registers various expense accounts as children of the total expenses, the total expenses can be derived from the amounts of each expense account. However, if the Submission Package form includes only the individual expense accounts 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 in the form settings are considered visible for the purposes of this determination. Therefore, that data is included in the Submission Package.
※ The submitted data refers to the data for each key displayed on the Submission Package form, excluding the relative period and display format keys, combined with all relative periods and all display formats. For example, if the submitted data includes "Sales for June", it also includes "Cumulative Sales up to May" of the same fiscal year.
"Hidden Ledger Editions" for Scenarios Not Subject to Version Control (fusion_place >= 12.1)
When the scenario attribute "Exclude from Ledger Edition Management" is set, the data of that scenario included in Ledger Editions other than the Shared Workspace Edition[1] is deleted, and the same scenario data from the Shared Workspace Edition is newly created as a Hidden Ledger Edition shared across all Ledger Editions.
Hidden Ledger Edition Key for Scenarios Not Subject to Version Control
The Ledger Edition Key for the Hidden Ledger Edition is in the format of prefix "#S" followed by the scenario label, connected by a period.
Example: If the actual scenario (label "ACTUAL") is excluded from Ledger Edition management
#S.ACTUAL
Screens/Functions That Can Specify Hidden Ledger Editions
Hidden Ledger Editions can be used (selected or specified) in the following screens/functions that operate on the Ledger Edition itself regardless of its data content.
-
[Manager] 's "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 That Cannot Specify Hidden Ledger Editions
Since there is no need to perform operations such as changing Ledger Edition Keys, creating derivative editions, or publishing for Hidden Ledger Editions, they are not displayed in the following screens.
-
[Manager] 's "Execute Processing > General Ledger Edition Management" screen
Also, in the following screens/functions that access the data content of Ledger Editions, they 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 calculation processes using forms (CALCULATE_BY_FORM)
-
Exporting data using forms (EXPORT_VALUES)
-
Publishing workspace data (PUBLISH_EDITION)
-