<?xml version="1.0" encoding="utf-8"?>
<Session ID="/baanerp/bc/mti/bcmti1102m000" xml:lang="en">
	<Header>
		<Title xmlns:ssa="http://www.ssaglobal.com" xmlns:HTML="http://www.w3.org/TR/REC-html40">Mapping Table for Routing Operations (bcmti1102m000)</Title>
	</Header>
	<HelpTopic><AimSection><Paragraph>Use this session to to map the ManmanHP Operation from the Routing Detail File (RTFIL).</Paragraph>
		</AimSection>
		<GeneralSection><SectionTitle></SectionTitle>
			<Paragraph>Before you can use this session the pre-conversion run must be finished.</Paragraph>
		</GeneralSection>
		<GeneralSection><SectionTitle></SectionTitle>
			<Paragraph>Always mandatory if there are Routing Operations in RTFIL.</Paragraph>
		</GeneralSection>
		<GeneralSection><SectionTitle></SectionTitle>
			<Paragraph>Why is a mapping of Routing Operation required? :</Paragraph>
			<Paragraph>In <GUIRef href="" role="manual">bcmti102</GUIRef> per Main Item (RTFIL.RTPART) and Routing Code (RTFIL.ALTCODE) and operation number (RTFIL.RTSEQ) one or more records can be maintained, each having its own specific Effective Date (RTFIL.EDATE) and Obsolete Date (RTFIL.ODATE). Together, these 5 fields form the unique index on the Mapping Table for Routing Operations <GUIRef href="" role="manual">(bcmti102)</GUIRef>.</Paragraph>
			<Paragraph>The effectivity dates/periods within one operation do not overlap. That also means, that it is possible to have multiple instances of one and same operation number (RTSEQ), if date effectivity is applied.</Paragraph>
			<Paragraph>The equivalent for Transit Hours in ManmanHP in ERP LN 6.1 is: Move Time. In ERP LN 6.1 Move Time means: Move Time to next operation’s W/C. This creates some difficulties during migration.</Paragraph>
			<Paragraph>Transit Hours is before operation’s production time, whereas Move Time is after operation’s production time. Therefore it has to be migrated to the Move Time of the directly preceeding operation. This –however- is a problem for the first operation. We decided to migrate Transit Hours of first operation into Queue Time of that operation. So if the first operation in a routing has both Transit- and Queue Time defined, then the sum of these two will be migrated to first operation’s Queue Time in ERP LN 6.1. The above difficulty becomes even more complex, if date effectivity is applied also. In that case we have multiple instances of one operation, of which each is valid during a certain period in time.</Paragraph>
			<ExampleSection><SectionTitle>Example</SectionTitle>
				<TABLE border="5" cellpadding="3" cellspacing="6"><TBODY><TR><TH>Operation:</TH>
							<TH>Transit Time</TH>
							<TH>Effective Date</TH>
							<TH>Obsolete Date</TH>
						</TR>
						<TR><TD>10 (/1)</TD>
							<TD>0</TD>
							<TD>01/01/2003</TD>
							<TD>31/06/2003</TD>
						</TR>
						<TR><TD>10 (/2)</TD>
							<TD>0</TD>
							<TD>01/07/2003</TD>
							<TD>31/12/2003</TD>
						</TR>
						<TR><TD>20 (/1)</TD>
							<TD>2 hours</TD>
							<TD>01/01/2003</TD>
							<TD>31/01/2003</TD>
						</TR>
						<TR><TD>20 (/2)</TD>
							<TD>8 hours</TD>
							<TD>01/02/2003</TD>
							<TD>31/12/2003</TD>
						</TR>
					</TBODY>
				</TABLE>
				<Paragraph>This Table must be migrated to:</Paragraph>
				<TABLE border="5" cellpadding="3" cellspacing="6"><THEAD><TR><TD>Operation:</TD>
							<TD width="49">Seqn:</TD>
							<TD width="167">Move Time:</TD>
						</TR>
					</THEAD>
					<TBODY><TR><TD>10</TD>
							<TD width="49">1</TD>
							<TD width="167">8 hours</TD>
						</TR>
						<TR><TD>10</TD>
							<TD width="49">2</TD>
							<TD width="167">8 hours</TD>
						</TR>
						<TR><TD>20</TD>
							<TD width="49">1</TD>
							<TD width="167">..from operation 30...</TD>
						</TR>
						<TR><TD>20</TD>
							<TD width="49">2</TD>
							<TD width="167">..from operation 30...</TD>
						</TR>
					</TBODY>
				</TABLE>
				<Paragraph>Here we see, that for the Move Time of operation 10 the Transit Time is taken of the date effective instance of operation 20 for which the effective period overlaps the most. Both operations 10 will get the 8 hours Transit Time from operation 20/2, because the 2 hours Transit Time of operation 20/1 is only valid the first month of 2003 while it is 8 hours for all other months of 2003. In fact, operation 10/1 (in ERP LN 6.1 ) must have a Move Time of 2 hours, during the first month of 2003. However, because we are tight to the date effectivity as defined for operation 10, we decided to (always) select the Transit Time of next operation for which the effective period overlaps the most. And, as operation 10/1 overlaps operation 20/2 for 5 months, we choose the 8 hoursTransit Time of operation 20/2, also for operation 10/1.</Paragraph>
				<Paragraph>In ManmanHP, sometimes the field RTDESC (the operation description) has to be extended. ( ManmanHP Help explains: If more space is needed for the description, add additional sequences to the routing and zero all the hours fields.) In this case the operation number (RTSEQ) is increased with 1. Normally operation numbering in ManmanHP starts with 10 and has increments of 10 (so: 10, 20, 30 etc.). If for example operation 10 needs more space for the description, then the RTFIL-record is copied to a ‘dummy’ operation with RTSEQ=10+1 := 11. In this record only field RTDESC is meaningful, and can be maintained to continue the description. Due to the above mentioned complexities, we decided to handle migration of Routing Operations in 4 stages:</Paragraph>
				<ProcedureList><ListItem>Fill BCMTI102 - Mapping Table for Routing Operations, during pre-migration. After step 1, in session <GUIRef href="" role="manual">Mapping Table for Routing Operations (bcmti1102m000)</GUIRef> 2 steps must be taken:</ListItem>
					<ListItem>Renumber Operation/Seqn. This is necessary, because the pre-migration was not fully able to smoothly generate (1) the Mapped Operation Numbers and (2) the Mapped Sequence Numbers. This step will take care, that all routings will start with operation number 10 with increments of 10 (if more than 99 operations are present for the routing, increments of 1 will be used). Furthermore the Sequence Number is grouped by Effective- &amp; Expiry Date. This is necessary for the next step, in order to be able to correctly combine the RTDESC fields to 1 Routing Text per Operation &amp; Sequence Number in ERP LN 6.1.</ListItem>
					<ListItem>Migrate Routing Texts. This will migrate the RTDESC contents to pre-migration table <GUIRef href="" role="manual">bcmtt101</GUIRef>. From this table, during final migration the Tools Texts will be created, with the textnumber already generated in <GUIRef href="" role="manual">bcmtt101</GUIRef>.</ListItem>
					<ListItem>Fill target table TIROU102 – Routing Operations, during final migration, by using the mapping table, filled during pre-migration. The final migration of Routing Operations in <GUIRef href="" role="manual">tirou102</GUIRef> will take care, that all routing operations will get (1) the right Operation- and Sequence Number, (2)the right Text Number and (3)the right Queue- and Move Time. This will all be read from <GUIRef href="" role="manual">bcmti102</GUIRef> and <GUIRef href="" role="manual">bcmtt101</GUIRef>, as resulting from previous steps.</ListItem>
				</ProcedureList>
			</ExampleSection>
		</GeneralSection>
		<GeneralSection><SectionTitle></SectionTitle>
			<Paragraph>Execution of this session may take some time if there is a huge amount of Routing Operations.</Paragraph>
		</GeneralSection>
		<GeneralSection><SectionTitle></SectionTitle>
			<Paragraph>It is always possible to restart the Specific Options. After the Migrate Routing Texts is done, do not change the Mapped Operation/Sequence Numbers anymore. During the final migration the (migrated) Texts can not be found anymore (in <GUIRef href="" role="manual">bcmtt101</GUIRef> ). Therefore any change in Mapped Operation/Sequence Numbers will delete the migrated Texts from <GUIRef href="" role="manual">bcmtt101</GUIRef>, and than you must run the Migrate Routing Texts again.</Paragraph>
		</GeneralSection>
	</HelpTopic>
	<FormCommands><CommandHelp ID="renumber"><Header>
				<Title xmlns:ssa="http://www.ssaglobal.com" xmlns:HTML="http://www.w3.org/TR/REC-html40">Renumber Operation/Seqn</Title>
			</Header>
			<FuncDesc>This command is necessary, because the pre-migration was not fully able to smoothly generate (1) the Mapped Operation Numbers and (2) the Mapped Sequence Numbers. This step will take care, that all routings will start with operation number 10 with increments of 10 (if more than 99 operations are present for the routing, increments of 1 will be used). Furthermore the Sequence Number is grouped by Effective- &amp; Expiry Date. This is necessary for the next step, in order to be able to correctly combine the RTDESC fields to 1 Routing Text per Operation &amp; Sequence Number in ERP LN 6.1</FuncDesc>
		</CommandHelp>
		<CommandHelp ID="migrate.texts"><Header>
				<Title xmlns:ssa="http://www.ssaglobal.com" xmlns:HTML="http://www.w3.org/TR/REC-html40">Migrate Routing Texts</Title>
			</Header>
			<FuncDesc>This command will migrate the RTDESC contents to pre-migration table <GUIRef href="" role="manual">bcmtt101</GUIRef>. From this table, during final migration the Tools Texts will be created, with the textnumber already generated in <GUIRef href="" role="manual">bcmtt101</GUIRef>.</FuncDesc>
		</CommandHelp>
		<CommandHelp ID="validate.record"><Header>
				<Title xmlns:ssa="http://www.ssaglobal.com" xmlns:HTML="http://www.w3.org/TR/REC-html40">Validate</Title>
			</Header>
			<FuncDesc>Click <GUIRef href="" role="manual">Validate</GUIRef> to check references, duplicates and if all mandatory fields are filled. A so called integrity check of the supplied data. It is mandatory to run validate.</FuncDesc>
		</CommandHelp>
	</FormCommands>
</Session>
