FPSINPUT.WIP_LOTS_VERIFY

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)

BANK

VARCHAR2(36)

N

Lots which are not on a route are considered in a bank and the bank name indicates why the lot is off route. Bank must be NA for lots which are on a route. Our standard filter for active lots is bank = NA. (* from FPSINPUT.RTG_BANKS)

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)

HOLD_FOR

VARCHAR2(48)

The user responsible for the hold lot. Note this is different than the user who put the lot on hold. This is the person who needs to address the hold and potentially release it. (* from FPSINPUT.WIP_EVENT_HIST)

HOLD_NOTE

VARCHAR2(512)

Comment or note entered when the lot went on hold. Normally this should match the comment which was entered in the hold event. The logic to determine the hold note can get tricky when a subsequent comment event is logged to a lot already on hold because we do not know whether to update the hold note with the new comment or keep the comment from the original event that put the lot on hold. Our solution is to not update the hold_note by trigger with this comment event and leave the decision to our logic in WIP_LOTS_VERIFY. If you want to use the subsequent comment then populate it as the hold_note in WLV otherwise keep the original comment in WLV. Then our logic in CHK_WIP_LOTS_REALTIME is that if the hold_note written in WIP_LOTS_VERIFY differs from the hold_note populated by trigger while the hold_type and hold_for agree then we waive the normal 20 minute waiting period and update the hold_note immediately with a MISS-HOLDNOTE event.

HOLD_TYPE

VARCHAR2(24)

Generally hold_type will come directly from the MES. (* from FPSINPUT.WIP_HOLD_TYPES)

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_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)

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)

MES_STEP_ENT_INST

DATE

N

This is the time when the step was entered according to MES. Since we calculate step_ent_inst in the DWH based on the events, we only use this to confirm that any differences in WIP_LOTS_VERIFY are not due to a lag in the data load. Not all MES will have this exact time but we expect most will have something reasonably close. The time entered the current stage or operation or step or process or recipe would all be sufficient.

ORIG_FACILITY

VARCHAR2(6)

See comments in OTHER_FACILITY column (* from FPSINPUT.RTG_ROUTE_STEPS)

ORIG_FAC_LOT

VARCHAR2(32)

When lot is duplicated for shared facilities, this is the original lot. This will also be the part of the duplicated lot before the slash but having this column avoids needing to parse. For example, in the record for lot ABC123.0/FAB1, this value of orig_fac_lot will be ABC123.0.

ORIG_FAC_ROUTE

VARCHAR2(256)

See comments in OTHER_FACILITY column (* from FPSINPUT.RTG_ROUTE_STEPS)

OTHER_FACILITY

VARCHAR2(6)

Used if the step is actually processed in another facility. For example, a lot may go to the Test facility for an electrical test in the middle of the Fab route. In this case, on the Fab route OTHER_FACILITY is set to Test. In the Test facility there will be a fake short route with only this single step and the ORIG_FACILITY and ORIG_FAC_ROUTE will be set to the name of the Fab facility and the Fab route. This case is distinguished by non-NULL values in ORIG_FACILITY, OTHER_FACILITY, and ORIG_FAC_ROUTE columns. (* from FPSINPUT.RTG_ROUTE_STEPS)

OTHER_FAC_LOT

VARCHAR2(32)

When lot is duplicated for shared facilities, this is the other lot. The value here will be the lot plus a slash then a suffix representing the other facility. For example, in the record for lot ABC123.0 duplicated in FAB1, this value of orig_fac_lot will be ABC123.0/FAB1.

OVR_PROCESS_STATE_DETAILS

VARCHAR2(600)

This column will override the process state details for the Dashboard if populated. It is important to note that this column is technically independent from the process_state which is calculated based on events from WIP_EVENT_HIST. For example, immediately after a lot is dispatched, this column might still have a message about WAIT when the process state just changed to DISP. To reduce the duration of these discrepancies, you should refresh WIP_LOTS_VERIFY in the RealTime job or at least every 1-2 minutes if you populate this column.

OVR_RELEASE_INST

DATE

Specify a time when the lot will be released from hold. This will override our normal logic to estimate the release time based on WIP_HOLD_ESTIMATES, CTM_SUMMARY, and WIP_HOLD_TYPES.

OVR_STEP_COMP_INST

DATE

Specify a time when the lot will complete the step. We will use this mainly for banks and staging steps with a release plan. For steps that require processing on a tool, please use ovr_est_end_inst instead.

PLANPRD

VARCHAR2(64)

N

Planning product used for all planning purposes. All lots with the same planprd are interchangeable to ship to the customer regardless of their prd, route, technology, wafer size, etc. For detailed information on prd vs. planprd see table comments in RTG_PLANPRDS. (* from FPSINPUT.RTG_PLANPRDS)

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)

SEC_QTY

NUMBER(7)

Quantity of units in the lot according the sec_qty_unit defined for the facility. See the column comment for the qty column for details and examples. (* from FPSINPUT.WIP_EVENT_HIST)

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)

TOOL

VARCHAR2(16)

Tool is generally just the main tool. The exception is when different entities on the tool run completely independently and it is physically impossible to run wafers of the same lot across multiple entities. In this exception case, we may want to assign the entities to different eqp_types and therefore we should define each entity as a tool. Please note that when we do this there is no indication whatsoever that these different entities are on the same tool. (* from FPSINPUT.EQP_TOOLS)

UPDATED_INST

DATE

Time when the record was updated according to the source data. Note this is not the time when the record was actually updated in this table - it will almost always be earlier. (* from FPSINPUT.GEN_FACILITIES)

VERIFY_PARM1

VARCHAR2(128)

Nine user-defined fields which can store anything the user would like to track relating to the lot and its status. Often this is a value needed for tool assignments ETL like a rework parameter. These columns will have the capability to be displayed in the Dashboard lot search and lot popup tables if configured in DASH_C_CATEGORY_TABLE_COLS.

VERIFY_PARM2

VARCHAR2(128)

See VERIFY_PARM1.

VERIFY_PARM3

VARCHAR2(128)

See VERIFY_PARM1.

VERIFY_PARM4

VARCHAR2(128)

See VERIFY_PARM1.

VERIFY_PARM5

VARCHAR2(128)

See VERIFY_PARM1.

VERIFY_PARM6

VARCHAR2(128)

See VERIFY_PARM1.

VERIFY_PARM7

VARCHAR2(128)

See VERIFY_PARM1.

VERIFY_PARM8

VARCHAR2(128)

See VERIFY_PARM1.