No new screens, outside of Part Condition Template, have been created for part conditions. Instead, the part conditions concept has been introduced into existing screens and processes.
The user must be able to select and view condition tracked parts anywhere in the application that parts are selected or viewed. Using condition tracked parts within HxGN EAM has been implemented in a consistent manner within the application. Therefore, these places will not be discussed in detail.
Instead, we will examine the Issue/Return Parts screen to provide an overall perspective of how part conditions have been woven into the existing application.
In general, the following is true:
-
It is not possible to select a parent part record and save, anywhere in the system, unless you then select the appropriate Condition (i.e., Condition is required when a condition tracked parent part is selected).
-
Most Part lookups in the system will include both the parent and child condition parts.
-
When selecting a condition tracked parent part the user must then use the new Condition field to identify the part condition for which they are selecting. When the Condition is selected the system replaces the parent part selected with the child part that equates to the selected Condition.
-
If a condition tracked child part is directly selected/entered using the Part field the system will automatically populate Condition with the condition associated to the child part (i.e., from the part record view).
-
The system will keep the Part and Condition lookup in sync. In other words, if a child Part is selected then Condition is automatically populated with the condition of the child part. If Condition is updated the system will change Part to the part associated to the condition. If Part is changed from one child part to another the system will update Condition accordingly.
-
Some Part lookups do not display parent parts. In these instances, the user will select the child part directly.
The Condition field is delivered as protected. However, in this case a parent condition tracked child part is selected. As stated above you cannot create any kind of record, including transactions, against parent parts. Therefore, the Condition field becomes required, and the contents of the lookup are shown in the figure below.
-
The Used-0% condition is not shown in the lookup because it is flagged to Prevent Issues on the Conditions tab for Part Condition Template screen.
-
Bin, Lot, and Available Qty. for non-condition tracked parts can be known once the Part is selected (i.e., Store is already selected in the header). However, as you can see in the screenshot above, Bin, Lot, and Available Qty. will remain empty until a Condition (i.e., child part) is selected.
-
If a non-condition tracked part is selected the Condition field remains protected and empty.
By selecting a Condition, the user is identifying a child part for the system. The child part is populated into the Part field, replacing the parent part that was originally selected. At this point, the system can lookup which Bins and Lots are available, populate the default Bin for the selected child part, and populate the Available Qty.
So, the child part (not the parent part) is saved to the grid and is used to create the issue transaction. Therefore, the Qty. on Hand for Part 44250020-A (‘new’ condition part) is reduced.
Returns work exactly as they did pre-v11 except that with the introduction of part conditions it is possible to return a part to store in a different condition from which it was issued. This is also a highly likely scenario unless the issued parts were simply not necessary in the repair, so they are returned in the same condition in which they were issued.
The new field Return Condition is used for this purpose (see screenshot below). Notice the originally issued part 44250020-A was issued. However, two of them are being returned in condition Used-75% (i.e., child part 44250020-B). In the case of returns the Part value does not flip to represent the Return Condition, but we know that part 44250020-B needs to have its Qty. on Hand increased by 2 when the transaction is submitted.
How does this happen? When Return transactions are submitted the system creates the transaction for the Return Condition part (i.e., 44250020-B). So TRL_PART = 44250020-B.
But what about the installation RTNANY, which, when disabled, prevents users from returning any part that was not issued to the work order? Only 44250020-A was issued. How is it possible in this example to return 44250020-B when 44250020-A was issued? A new field called TRL_ISSUEDPART exists in R5TRANSLINES. When the return is created for a different condition (i.e., part) than was issued the system stores the issued part (i.e., 44250020-A) in TRL_ISSUEDPART. The logic for RTNANY has been modified to look at this new field. If it is populated, then it uses this part to compare against the issued parts to validate its return.
-
TRL_ISSUEDPART is not populated when returning non-condition tracked parts.
-
Conditions in Return Condition lookup come from Return to Store Condition List on Conditions for Part Condition Template screen if Core Return is not checked on return. If Core Return is checked, Conditions come from Core Return Condition List on Conditions for Part Condition Template screen.
