How Does A Field Order Get Completed?

When fieldwork is performed at a service point, the system must be told what happened. We refer to the process of telling the system what happened in the field as "field order completion".

Note:

Between dispatched and completed states. If you want, you can indicate a field order's fieldwork is done before you actually complete the field order. You do this by changing the field order's status from dispatched to work done, not recorded. You don't have to do this; it's really a question of whether you care about this intermittent state.

You can't complete a field order until all of its non-optional activities are either Complete or Canceled. To complete a field activity, you update the system to reflect what happened in respect of the activity's steps. After which, you must have each step reference the object that was updated or created. For example, if a step initiated the installation of a meter at a service point, you must add a new SP/Meter Installation History record and the step should then reference the new SP/Meter Installation History record.

You may wonder why a step needs to reference the object that was updated or created. The reason is a little complex, but it's important you understand the following points:

  • After you complete a field activity that is linked to a pending start service agreement, the system automatically activates the service agreement. As part of the activation, if the service point is metered, the system extracts any read that was entered to complete the field activity and uses this as the initial read for the service point. The system extracts the meter read by looking for reads linked to the activity's step(s). Reads may be linked directly (via a reference to a meter read), or indirectly (via a reference to SP/Meter History). If the step doesn't reference a meter read, the system cannot automatically activate the related service agreement when the field activity is completed.
  • An analogous process occurs for field activities linked to pending stop service agreements. The major difference is that the system uses any read linked to the field activity as the service agreement / service point's final read.
  • Steps on field activities that are not linked to pending start or stop service agreements exist purely for audit purposes.

The following diagram may help understand the relationship between an activity's read and the service agreement(s) that use the read to start or stop service.

The process of telling the system when fieldwork is performed at a service point is "field order completion". This illustrates the relationship between an activity's read and the service agreement(s) that use the read to start or stop service.

The next thing you may be wondering about is how to reference the updated or created object on a step? There are three ways to do this:

  • You can enter completion details on the field activity page. Refer to Field Activity Maintenance for more information.
  • An operator can enter completion details on the field activity upload staging pages. Refer to Field Activity Upload Staging for the page used to do this. This is the easiest way to complete a field activity.
  • You can have your interface team insert rows onto the field activity upload staging tables and let the field activity upload background process complete the activities and orders for you. Refer to Uploading Field Order Completion Information for more information about the batch completion process.

Completing most field activities is straightforward because the steps performed in the field correspond to the steps on the field activity. Complications arise if a field crew is unable to perform an activity's steps because of any number of reasons (e.g., a field activity instructs a meter to be installed but there's already a meter at the service point). When what took place in the field differs from what was instructed to take place the operator may either:

  • Change the activity type on the activity to reflect what happened.
  • Cancel the existing field activity and add a new one with the appropriate activity type.
Warning:

If a field activity is linked to a service agreement or a severance event, and what took place in the field isn't consistent with the field activity's steps, we recommend changing the activity type rather than canceling the field activity and adding a new one. Why? Because the object to which a field activity is linked continually checks if the field activity is complete to see if it can take the next logical step in its lifecycle. If you add a new field activity, you'll need to link it to the same object(s) that the original activity was linked. This is a cumbersome process (but possible). It's much easier to simply change the activity's activity type.