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).

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".

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.

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

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.

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.

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:

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).

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

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).

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.

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.

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
#S.ACTUAL

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.

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.

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