FPSADMIN.MSO_WIP_EVENT_HIST_TMP_LOAD

INST

DATE

Time when the event occurred. (* from FPSINPUT.WIP_EVENT_HIST)

LOT

VARCHAR2(32)

A lot is a group of units that process together. Usually lot_id or lot_number in MES. All units in a lot are in the same carrier but there may be multiple lots in a carrier. (* from FPSINPUT.WIP_LOTS_STATIC)

LOT_SEQ_WITHIN_SEC

NUMBER(6,2)

For rows with identical timestamps, sequence records to get proper sequence (* from FPSINPUT.WIP_EVENT_HIST)

ACTUAL_DURABLE_USED

VARCHAR2(129)

Actual durable used as logged by the tool during processing of the lot. This can be a comma delimited string if multiple durables are used. (* from FPSINPUT.WIP_EVENT_HIST)

ACTUAL_MACHINE_RECIPE

VARCHAR2(100)

Machine recipe used to process the lot as logged during processing by the tool. (* from FPSINPUT.WIP_EVENT_HIST)

EVENT

VARCHAR2(48)

N

This is the event registered in the MES. This is for the historical record and display only. Each event is mapped to an FPS event_type and the event_type is what is used by FPS applications. (* from FPSINPUT.WIP_EVENTS)

EVENT_TYPE

VARCHAR2(12)

N

Event Type (* from FPSINPUT.EQP_SCHED_EVENTS_MANUAL)

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)

FIRST_LOT_IN_JOB

VARCHAR2(32)

The first lot in the job determined by the order of events. When this first lot logs the first tool event which is usually a reserve or dispatch then the job_id is created with only this lot. Then subsequent lots join this job. While we use job_id to identify lots that will process or are processing or processed together, first_lot_in_job is still a useful field. (* from FPSBASE.WIP_LOT_HIST)

INSERTED_TIME

TIMESTAMP(6)

Timestamp field set by trigger storing SYSTIMESTAMP when record was inserted in the table. (* from FPSINPUT.WIP_EVENT_HIST)

IS_HOLD

CHAR(1)

N

This field indicates the lot is on hold after the event is logged. In other words, this will always be Y if is_hold_start is Y and always N if is_hold_end is Y. (* from FPSINPUT.WIP_EVENT_HIST)

IS_HOLD_END

CHAR(1)

N

Event ended hold (* from FPSINPUT.WIP_EVENT_HIST)

IS_HOLD_START

CHAR(1)

N

Event started hold (* from FPSINPUT.WIP_EVENT_HIST)

IS_NEXT

CHAR(1)

N

Indicates record goes into WIP_STEP_HIST (* from FPSBASE.WIP_LOT_HIST)

IS_REWORK

CHAR(1)

N

Y indicates the lot is on a rework route after the event is logged. If a lot is reworked then returns to the main route and repeats some steps, is_rework will be N but we will count those steps as repeats. (* from FPSINPUT.WIP_EVENT_HIST)

IS_REWORK_END

CHAR(1)

N

Event ended rework (* from FPSINPUT.WIP_EVENT_HIST)

IS_REWORK_START

CHAR(1)

N

Event started rework (* from FPSINPUT.WIP_EVENT_HIST)

JOB_ID

VARCHAR2(64)

Automatically set by trigger when the first lot of a job logs an event to the tool. (* from FPSBASE.WIP_LOT_HIST)

LOGGED_ENTITY

VARCHAR2(36)

Entity to which event is logged in the MES. This could be a main tool, subtool, entity, or port. In MNT tables this could be a vehicle or durable as well which is why the column width is wider. If main tool or port, we apply the event to all entities. If subtool we apply to all within the subtool. If entity we apply only to the entity. (* from FPSINPUT.EQP_EVENT_HIST)

LOT_TYPE

VARCHAR2(24)

N

Lot_type is the base of the hierarchy that determines lot_family then lot_group. Ideally lot_type will come straight from the MES with little modification. (* from FPSINPUT.WIP_LOT_TYPES)

MAIN_ROUTE

VARCHAR2(256)

Primary route used by the prd. Excludes rework and alternate routing. We allow this column to be null in WIP_LOTS_VERIFY because we may not be certain what the main route is when we fix for missed events. In that event we trust the WIP_EVENT_HIST triggers has loaded the correct information into WIP_EVENTS_CURR_STEP. (* from FPSINPUT.WIP_EVENT_HIST)

MAIN_RT_STEP

VARCHAR2(256)

When lot is on a rework or alternate route, this is the step where it will return to the main route. We use this for planning purposes so we can calculate remaining steps. We allow this column to be null in WIP_LOTS_VERIFY because we may not be certain what the main route step is when we fix for missed events. In that event we trust the WIP_EVENT_HIST triggers has loaded the correct information into WIP_EVENTS_CURR_STEP. (* from FPSINPUT.WIP_EVENT_HIST)

MEAS_RESULT

VARCHAR2(1)

Result of measurement. For facilities not using FPS Sampling this value is for display purposes only and can be pass/fail or a number or anything. For facilities using FPS Sampling this field is used to dynamically adjust the sampling rules and must be a letter grade A-F. (* from FPSINPUT.WIP_EVENT_HIST)

PLAN_PRIORITY

VARCHAR2(7)

N

Permanent priority of the lot set in the MES generally by planning. (* from FPSINPUT.WIP_EVENT_HIST)

PRD

VARCHAR2(64)

N

Prd determines the route which is used to process the lot in the facility and what tools, recipes, durables, etc. can be used at each step. Prd also determines the next facility for the lot when it finishes its route. For detailed information on prd vs. planprd see table comments in RTG_PLANPRDS. (* from FPSINPUT.RTG_PRDS)

QTY

NUMBER(7)

N

Quantity of units in the lot according the qty_unit defined for the facility. It is required for all lots in each facility to have their qty defined in the same units therefore the change in the unit is critical to defining the facility. For example, a pretest facility might have a sort step in the middle where we learn the qty of die. Prior to this step we know only the wafer qty but after this step we know both wafer and die. Since wafer is the only qty we know throughput the flow then wafer must be defined as the qty unit for this facility. Die can then be populated as sec_qty when it is known. Similarly the wafer saw facility might have a step in the middle where we cut the wafers into die. After this step we no longer know the number of wafers which means that die must be the qty unit for this facility and wafers can be the sec_qty prior to the saw step. Please note that a lot with qty of 0 is allowed but only if the sec_qty is greater than 0. This is unusual but one case is where we know the wafers will be scrapped but cannot be scrapped quite yet. (* from FPSINPUT.WIP_EVENT_HIST)

ROUTE

VARCHAR2(256)

N

Route that has threading requirements (* from FPSINPUT.RTG_STEP_THREADING)

STEP

VARCHAR2(256)

N

A single processing step within a route representing a single tool visit. Step is often a very complex string and should rarely be displayed. Instead we should use process_display. (* from FPSINPUT.RTG_ROUTE_STEPS)

STEP_ENT_INST

DATE

N

Time when the lot entered the step. (* from FPSBASE.WIP_LOT_HIST)