Configure Part Removal Reasons
Explanation
The page will set up the necessary data to drive the following part attributes at removal as per the
Removal Reason in maintenance execution:
- Part Tag – Serviceable, Unserviceable, Quarantine
- Part Condition Code – New part condition code at removal
- Operational Condition – Operational status of the part as per Removal Reason
(Operational, Non-Operational)
Removal Reasons can be added to reflect the corresponding Inventory Conditions in CAMO (RFI,
REPREQ, QUAR), which will determine the serviceability of the removed part.
As per any Removal Reason, it is determined that a part can only have 3 states at maintenance execution as
Serviceable or Unserviceable or Quarantine.
The new Part Condition Codes of the removed items can be designated by the Condition Code chosen to reflect the
Serviceability/Unserviceability/Quarantine status of the part:
- Parts that are removed as Unserviceable (e.g. UNSERV-Unserviceable) – as defined in the field
Unserviceable Condition Code
- Parts that are removed as Quarantine (e.g. QUAR-Quarantine) – as defined in the field
Quarantine Condition Code
- Parts that are removed as Serviceable (e.g. SERV-Serviceable)
If the Last Received Condition is known, the new Condition Code of the part will be the Last Received Condition
(similar Part Condition Codes will have to be set up). If the Last Received Condition is NOT known, the new
Condition Code will be as defined in the field Unknown Condition Code (in this example: SERV).
Prerequisites
- Part Condition Codes matching the Last Received Condition of parts identified in CAMO should be set up.
- New Removal Reasons should reflect RFI, REPREQ, and QUAR
Inventory Conditions in CAMO.
- Validity should be set to Active for the Removal Reason entry to be considered.
System Effects
- Part Tags, new Condition Code, and Operational Condition of the removed parts will be determined per the
setup.