data-dictionary

FPSAPP.DASH_W_MNT_FUTURE_OVR

Data Dictionary

>

FPSAPP Tables

> FPSAPP.DASH_W_MNT_FUTURE_OVR

Table FPSAPP.DASH_W_MNT_FUTURE_OVR"

Stores override to the maintenance event information in EQP_MNT_FUTURE made within the Maintenance Manager web application. Here we can only override certain fields for existing events. In MNT_W_FUTURE_ADD we can create new maintenance events which are not already in EQP_MNT_FUTURE.

  • Schema: FPSAPP

  • Tablespace: FPSDATA

  • Primary key: FACILITY, EVENT_ID

  • Foreign keys: DASH_W_MNT_FUTURE_OVR_FK: FACILITY, EVENT_ID REFERENCES FPSINPUT.EQP_MNT_FUTURE (FACILITY, EVENT_ID)

  • Referenced by: FPSAPP.DASH_W_MNT_FUTURE_OVR_TECH (FACILITY, EVENT_ID)


Column

Type

Nullable

Comment

FACILITY

VARCHAR2(6)

N

Facility is included in almost every join in the DWH so this represents a definitive split. A route must have all steps on tools in the same facility. A tool must process all lots in the same facility. If your site has multiple buildings where lots run on routes using tools in multiple buildings then everything should be one facility. For example, multiple Fab buildings. But if your site has independent facilities like Fab and Test and Assembly where lot may progress from one to the next but on different routes then these should be different facilities. Since this column is in virtually every table it is critical that the value here is exactly matches what is in the MES if the MES has facility. Use facility_display for the display friendly name displayed in applications. See site_name comment for client/site/facility example. (* from FPSINPUT.GEN_FACILITIES)

EVENT_ID

VARCHAR2(64)

N

Field that uniquely identifies the maintenance task definition in the facility. `Event_id` is usually a number or code from the maintenance system, but it could also be defined as `logged_entity` concatenated with `mnt_name`, since that combination also uniquely represents an event. It is important to ensure that our definition of `event_id` represents repeated instances of the same maintenance event with the same `event_id`. For example, if we have a monthly PM on tool T1, there will be instances of this event each month. The field used as `event_id` could be something like T1 monthly PM; it should *not* be something like T1 monthly PM Jan, T1 monthly PM Feb, etc., since this would cause the `event_id` to change every month. (* from FPSINPUT.EQP_MNT_FUTURE)

ADJUSTED_START_INST

DATE

EST_MNT_DURATION_SEC

NUMBER(8)

Est_mnt_duration_sec is the estimate of the total duration of the maintenance in seconds including work time, wait time, and qual time. Est_mnt_duration_sec is required then if desired, this total can be broken down into est_mnt_work_sec, est_mnt_wait_sec, and est_mnt_qual_sec. These three breakdown columns are optional but if any of those three columns are populated then they must sum to the value of est_mnt_duration_sec. Only est_mnt_duration_sec is used in FPS applications. The other three are available for informational purposes and to use for custom reporting but are not currently used in any FPS application. (* from FPSINPUT.EQP_MNT_FUTURE)

IS_FIXED_FOR_SCHED

CHAR(1)

Y indicates that this upcoming maintenance time is fixed and should be scheduled around by the Scheduler. (* from FPSINPUT.EQP_MNT_FUTURE)

IS_WAITING_FOR_PARTS

CHAR(1)

If this is set then the maintenance event is effectively on hold waiting for parts. (* from FPSINPUT.EQP_MNT_FUTURE)

MNT_COMMENT

VARCHAR2(200)

MNT_TECH_USERNAME

VARCHAR2(64)

DROPPABLE: This column is obsolete as of Dashboard version 6.14 and is replaced by a separate table, DASH_W_MNT_FUTURE_OVR_TECH, which allows for multiple technicians to be assigned to an event_id. Reference: DWH-4754, DASH-4333. Dashboard app queries this table directly in 6.13 and earlier so even though this column is not used elsewhere in the DWH, it must be kept to avoid Dashboard Error 500.