Handling work completed on the wrong task

If a technician or other role accidentally completes the wrong task and the work has to be redone, you can mark the task as completed in error and add another instance of the task to the work package. Only complete or canceled tasks can be marked as errors.

Tasks are created based on executable requirements, requirements with one or more job cards (JICs), or can be created ad hoc. The following table outlines how you handle marking a task as completed in error in various scenarios where your intent is to complete a new version of the task in the same work package. After you mark the task, you'll need to communicate the issue and involve others such as crew leads or production planners in the next steps.

Also be aware that if an ACTV requirement (that isn't on-condition) is unassigned from a work package, baseline synchronization recreates any of the requirement's JICs that were completed or marked as error - all of the labor rows and steps are newly created and need to be completed and signed. This default behavior is controlled with the UNASSIGN_RECREATE_JIC configuration parameter.

The scenarios below refer to marking parent requirements, JICs, or tasks as errors. If you're a technician, looking at a Task Details page, you are likely looking at a job card, executable requirement, or ad hoc task. To get to the parent requirement from this page, go to the Task Information tab, Subtask Of link. If you are able to view the Assigned Tasks tab, you can more easily see parent requirements with their JIC sub-tasks.

If you mark a requirement as an error, its status and the status of any JIC sub-tasks changes to ERROR. If you mark a JIC as an error, its status changes to ERROR, but the status of its parent requirement does not change.

Mark task as error variations
Scenario What to mark as error Result and next steps
A recurring requirement has only one JIC sub-task. The JIC is completed accidentally.

Requirement status: COMPLETE

Next instance of the requirement is ACTV outside work package

The JIC's parent requirement
  • Requirement and JIC have ERROR status.
  • Baseline synchronization links the next ACTV instance of the requirement to the previously COMPLETE instance (the ERROR instance is dropped from the previous-next chain). The start values on the next ACTV instance are updated based on the ending values of the previously COMPLETE instance.
  • Go to the Work Package's Unassigned, Unassigned Tasks tab and add the requirement to the work package.
A one-time requirement has only one JIC. The JIC is completed accidentally.

Requirement status: COMPLETE

The JIC's parent requirement
  • Requirement and JIC have ERROR status.
  • Baseline synchronization re-creates the requirement and the requirement's JICs. The scheduling is the same as the task marked in error.
  • Go to the Work Package's Unassigned, Unassigned Tasks tab and add the requirement to the work package.
A requirement has multiple JICs, some JICS are complete and some are ACTV. One JIC is completed accidentally.

Requirement status: ACTV

The JIC (task)
  • The JIC has ERROR status.
  • Unassign the requirement from the work package. Baseline synchronization recreates any JICs that had a COMPLETE or ERROR status.
  • Go to the Work Package's Unassigned, Unassigned Tasks tab and add the requirement to the work package.
  • For any complete JICs that were recreated, but that you have already done the work, cancel the JICs.
A requirement created on-condition has one JIC completed accidentally.

Requirement status: COMPLETE

The JIC's parent requirement
  • The requirement has ERROR status.
  • Initialize the requirement manually.
  • Go to the Work Package's Unassigned, Unassigned Tasks tab and add the requirement to the work package.
  • You now have the requirement marked as an error and the recreated requirement in the work package.
An executable requirement has no JIC sub-tasks and is completed accidentally.

Requirement status: COMPLETE

The requirement (task)
  • Requirement has ERROR status.
  • Baseline synchronization re-creates the requirement. The scheduling is the same as the task marked in error.
  • Go to the Work Package's Unassigned, Unassigned Tasks tab and add the requirement to the work package.
  • You now have the requirement marked as an error and the recreated requirement in the work package.
An ad-hoc task, not based on a task definition, is completed accidentally.

Task status: COMPLETE

The task
  • The task status changes to ERROR.
  • Re-create the task.
A fault is accidentally completed.

Task status: COMPLETE

The task
  • The task status changes to ERROR.
  • Re-create the fault.
  • Note: if a fault is raised against an aircraft system and a component is removed as part of the corrective action, the corrective task status for the fault on both the aircraft and the one copied to the component is ACTV. If afterwards, the corrective task on the aircraft is marked as ERROR, the corrective task on the component is not updated and remains ACTV. You need to find the component fault and handle it.

A task that's marked in error, unassigned, and recreated, might be overdue as soon as it's created. This is especially true if the error is caught after a work package is closed.