<?xml version="1.0" encoding="utf-8"?>
<ManualTopic ID="/baanerp/tg/onlinemanual/em000250" xml:lang="de">
   <Header>
      <Title>Version structure</Title>
      <Keyword type="header" order="d1e2437503">
         <Level1>Version</Level1>
         <Level2>structure</Level2>
      </Keyword>
      <Keyword type="header" order="d1e2437508">
         <Level1>Structure</Level1>
         <Level2>version</Level2>
      </Keyword>
   </Header>
   <GeneralSection>
      <SectionTitle>Version structure</SectionTitle>
      <Paragraph>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.</Paragraph>
      <Paragraph>To create reference models and project models, use links to
		model items, such as business functions and business processes, which have been
		defined in the repository in a certain version. Therefore, to change the
		description of a business function referred to as <Emphasis>One</Emphasis>,
		which is used in one reference model, you can only do this in the
		repository.</Paragraph>
      <Paragraph>This means that if this business function is also used in a
		number of other reference models or project models, and the description is
		changed in the repository, this change will be automatically implemented in all
		the reference and project models of the same version.</Paragraph>
      <ExampleSection>
         <SectionTitle>Beispiel</SectionTitle>
         <Paragraph>If you change <Emphasis>One</Emphasis> into <Emphasis>Ten</Emphasis>, this change is implemented in both reference
		  models.</Paragraph>
         <Paragraph>This is a problem 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.</Paragraph>
         <Figure space-and-orientation="indented-estimated">
            <HTML:IMG xmlns:HTML="http://www.w3.org/TR/REC-html40" width="969" height="629"
                      SRC="../images/tr_graph_dem_versions_1.png"
                      alt="[...]"/>
            <FigCaption>Changing the repository without version
			 management</FigCaption>
         </Figure>
         <Paragraph>This problem is solved through version management. In the
		  example shown in, you must define a new version derived from the version that
		  was being used.</Paragraph>
         <Paragraph>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.</Paragraph>
         <Paragraph>In the example shown, the descriptions and places of the
		  business functions in the repository of Version 2 are retrieved from the
		  repository of Version 1.</Paragraph>
         <Paragraph>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.</Paragraph>
         <Paragraph>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.</Paragraph>
         <Paragraph>This situation is displayed below. The white circles in the
		  repository of Version 2 indicate they cannot be modified, because they are only
		  physically available in Version 1.</Paragraph>
         <Figure space-and-orientation="indented-estimated">
            <HTML:IMG xmlns:HTML="http://www.w3.org/TR/REC-html40" width="684" height="625"
                      SRC="../images/tr_graph_dem_versions_2.png"
                      alt="[...]"/>
            <FigCaption>Creating a derived-from version.</FigCaption>
         </Figure>
         <Paragraph>After a new version has been created, you can change the
		  description of the business function. In this example, the description <Emphasis>One</Emphasis> in Reference Model 1 of Version 2 must be changed into <Emphasis>Ten</Emphasis>.</Paragraph>
         <Paragraph>You can only change model items if they belong to your current
		  modeling version. Because the description of a business function used in
		  Version 2 must be changed, your current modeling version must be set to Version
		  2.</Paragraph>
         <List>
            <ListIntro>To do this, use the <GUIRef href="/baanerp/tg/brg/tgbrg1510m000" role="session">Current Modeling Version of Users (tgbrg1510m000)</GUIRef> session, as described in the
			 Repository chapter.</ListIntro>
            <ListItem>Before description <Emphasis>One</Emphasis> can be changed
			 to <Emphasis>Ten</Emphasis>, you must copy the business function to the current
			 modeling version, which is Version 2, because the business function cannot be
			 changed in Version 1.</ListItem>
            <ListItem>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.</ListItem>
            <ListItem>When you have changed the description in the business
			 function repository of Version 2 to <Emphasis>Ten</Emphasis>, the business
			 function in both reference models of Version 2 will be automatically changed.</ListItem>
         </List>
         <Paragraph>This is because both models use the model items as defined in
		  the repository of Version 2.</Paragraph>
         <Paragraph>The advantage is clarified in Figure 2.11, which indicates
		  that Reference Model 2 must not be used in Version 2, but in Version
		  1.</Paragraph>
         <Paragraph>Figure 2.11 shows the situation after you have copied the
		  description to the current version, and after you have changed the description
		  in the repository.</Paragraph>
         <Paragraph>Business function <Emphasis>Ten</Emphasis>, or <Emphasis>One</Emphasis> before the description was changed, is now physically
		  available in Version 2.</Paragraph>
         <Figure space-and-orientation="indented-estimated">
            <HTML:IMG xmlns:HTML="http://www.w3.org/TR/REC-html40" width="687" height="628"
                      SRC="../images/tr_graph_dem_versions_3.png"
                      alt="[...]"/>
         </Figure>
      </ExampleSection>
      <Paragraph>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 need to implement and store the
		changes.</Paragraph>
   </GeneralSection>
   <GeneralSection>
      <SectionTitle>Version authorizations</SectionTitle>
      <Paragraph>You must indicate whether the authorization mechanism must be
		applied after you have created a new version.</Paragraph>
      <Paragraph>If you choose for the authorization mechanism to be applied, you
		are automatically authorized for that version.</Paragraph>
      <Paragraph>You can also set version authorizations by using one or more of
		the three sessions discussed below.</Paragraph>
      <Paragraph>If no LN user has been authorized for a specific version, all LN users can use that
		version.</Paragraph>
   </GeneralSection>
   <GeneralSection>
      <SectionTitle>User Authorization for all Versions (tgbrg1140m000)</SectionTitle>
      <Paragraph>To quickly authorize one or more LN users for all versions by only specifying their LN user logons, use the <GUIRef href="/baanerp/tg/brg/tgbrg1140m000" role="session">User Authorization for all Versions (tgbrg1140m000)</GUIRef> session. When an LN user is included in
		this session, they can access all versions, including those created after the LN user was inserted in
		the session.</Paragraph>
      <Paragraph>If you do not authorize a single LN user for a version,
		all LN users can use
		that version.</Paragraph>
      <Paragraph>However, 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.</Paragraph>
   </GeneralSection>
   <GeneralSection>
      <SectionTitle>Version Authorization by User (tgbrg1150m000)</SectionTitle>
      <Paragraph>To authorize a specific LN user for one or more
		versions, use the <GUIRef href="/baanerp/tg/brg/tgbrg1150m000" role="session">Version Authorization by User (tgbrg1150m000)</GUIRef> session.
		If you only specify one LN user, all other LN users cannot use the specified versions.</Paragraph>
   </GeneralSection>
   <GeneralSection>
      <SectionTitle>Revalidate Licensed Version (tgbrg1247m000)</SectionTitle>
      <Paragraph>To revalidate the authorization to use a particular version
		initially purchased from Infor, use the <GUIRef href="/baanerp/tg/brg/tgbrg1247m000" role="session">Revalidate Licensed Version (tgbrg1247m000)</GUIRef> session.</Paragraph>
      <Paragraph>After the expiration date of a license code, a new license code
		must be acquired from the manufacturer.</Paragraph>
   </GeneralSection>
</ManualTopic>