Version structure

The version of the business models and their model items are not related to the different versions, releases, and customisation of the different LN software packages.

To create reference models and project models, use links to model items. Items such as business functions and business processes, which are defined in the repository in a certain version. Therefore, changing the business function description that is referred to as One, and used in one reference model, can only be done in the repository.

If this business function is used in several other reference models or project models, and the description is changed in the repository. That change is automatically implemented in all the reference and project models of the same version.

Example

If you change One into Ten, this change is implemented in both reference models.

This is an issue if you only want the change to be implemented in reference model 1. The dotted lines indicate that the descriptions of business functions in reference and project models are retrieved from the repository.

This diagram shows changing the repository without version management:

This problem is solved through version management. In the example, you must define a new version that is derived from the version that was being used.

When you define this version, the model items of the previous version, including the repositories, reference models, and project models, can be used. Although they are not physical copies and only available through a link.

In the example, the descriptions and places of the business functions in the repository of Version 2 are retrieved from the repository of Version 1.

The descriptions of the business functions in both reference models of Version 2 are retrieved from the repository of Version 2. Therefore, they are indirectly retrieved from Version 1 because of the derived-from structure.

The place of the business functions in the reference models of Version 2 are derived from the reference models of Version 1. Therefore, nothing is stored in Version 2, except for the link to Version 1.

This situation is displayed in the diagram. The white circles in the repository of Version 2 indicate they cannot be modified, because they are only physically available in Version 1.

This diagram shows creating a derived-from version:

After a new version is created, you can change the description of the business function. In this example, the description One in Reference Model 1 of Version 2 must be changed into Ten.

You can only change model items if they belong to your current modeling version. Because the business function description that is used in Version 2 must be changed, your current modeling version must be set to Version 2. Use the

Current Modeling Version of Users (tgbrg1510m000) session, as described in Current modeling version sessions.

Before description One can be changed to Ten, you must copy the business function to the current modeling version, which is Version 2. The business function cannot be changed in Version 1.
Copying a model item to your current modeling version means you place a physical copy of the business function in the repository of Version 2. You also break the link with the business function in Version 1.
When you changed the description in the business function repository of Version 2 to Ten. The business function in both reference models of Version 2 are automatically changed.

This is because both models use the model items as defined in the repository of Version 2.

The advantage is clarified in the diagram, which indicates that Reference Model 2 must not be used in Version 2, but in Version 1.

The diagram shows also the situation after you copied the description to the current version, and after you changed the description in the repository.

Business function Ten, or One before the description was changed, is now physically available in Version 2.

This procedure also applies to components such as business processes, or reference models and project models. This places the creation of a new version in a broader perspective, because the model items do not have to be created from scratch. Instead, you only must implement and store the changes.

Version authorizations

Indicate whether the authorization mechanism must be applied after you have created a new version.

If you choose for the authorization mechanism to be applied, you are automatically authorized for that version.

To set version authorizations use one or more of these sessions:

User Authorization for all Versions (tgbrg1140m000)
Version Authorization by User (tgbrg1150m000)
Revalidate Licensed Version (tgbrg1247m000)

If no LN user is authorized for a specific version, all LN users can use that version.

User Authorization for all Versions (tgbrg1140m000)

You can authorize one or more LN users for all versions by only specifying their LN user logons. Use the User Authorization for all Versions (tgbrg1140m000) session. When you include users this session, they can access all versions. they can access all versions, including those created after they were inserted in the session.

If you do not authorize a single LN user for a version, all LN users can use that version.

Setting authorizations using this session does not mean you have authorized a user for a version. If only this session is used to implicitly authorize some LN users for a certain version, all other LN users can still use that version.

Version Authorization by User (tgbrg1150m000)

To authorize a specific LN user for one or more versions, use the Version Authorization by User (tgbrg1150m000) session. If you only specify one LN user, all other LN users cannot use the specified versions.

Revalidate Licensed Version (tgbrg1247m000)

To revalidate the authorization to use a particular version initially purchased from Infor, use the Revalidate Licensed Version (tgbrg1247m000) session.

After the expiration date of a license code, a new license code must be acquired from the manufacturer.