Data Dictionary
>
FPSBASE Views
> FPSBASE.WIP_WAFER_HIST_LOOP
View FPSBASE.WIP_APD_STARTS_HIST
This view loads the current starts plan into history.
|
Column |
Comment |
|---|---|
|
INST |
Time when the event occurred. (* inherited from FPSINPUT.WIP_EVENT_HIST) |
|
FACILITY |
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. (* inherited from FPSINPUT.GEN_FACILITIES) |
|
LOT_OR_ALT_ID |
This is the primary key of this table which is the actual lot ID if available or an alternate ID if not. That alternate ID would likely be a combination of the product and start date range. Note that we can record starts representing more than one lot with a single record in this table. For example, we might have 200 starts for a product during an upcoming work week and we would enter 200 as start_qty and the start of the work week as inst and the end of the work week as start_range_end_inst. Then we would assume those starts would be distributed in lots matching the max_qty_in_carrier for the facility across the entire work week. Alternatively we might record single lot starts with a specific start time by entering the lot as lot_or_alt_id and the qty as start_qty and the start time as inst and leave start_range_end_inst blank. (* inherited from FPSINPUT.WIP_STARTS) |
|
PRD |
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. (* inherited from FPSINPUT.RTG_PRDS) |
|
PLANPRD |
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. (* inherited from FPSINPUT.RTG_PLANPRDS) |
|
LOT_TYPE |
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. (* inherited from FPSINPUT.WIP_LOT_TYPES) |
|
PLAN_PRIORITY |
Permanent priority of the lot set in the MES generally by planning. (* inherited from FPSINPUT.WIP_EVENT_HIST) |
|
START_QTY |
See comments in LOT_OR_ALT_ID. (* inherited from FPSINPUT.WIP_STARTS) |
|
START_INST |
Time when the lot started. (* inherited from FPSINPUT.WIP_STARTS) |
|
START_RANGE_END_INST |
If populated this means that the starts will occur across a range of time. If blank this means the start will occur at the specific inst. See comments in LOT_OR_ALT_ID for examples. (* inherited from FPSINPUT.WIP_STARTS) |
|
TARGET_CARRIER |
This is the carrier that the future start lots planned to be assigned. (* inherited from FPSINPUT.WIP_STARTS) |
|
INCLUDE_IN_WIP_FLUSH |
Indicates whether this start should be included in the WIP_FLUSH table. Generally this should be Y for near future starts and N for those which are more distant but it is fine to set for all or none depending on your use of WIP_FLUSH. (* inherited from FPSINPUT.WIP_STARTS) |
|
INCLUDE_IN_WSF |
Indicates whether this start should be included in the WIP_STEP_FUTURE table. Please only set this to Y for starts within a week or two because a larger WIP_STEP_FUTURE table can impact the speed of the RealTime job and the overall database. Plus there is no need to have starts in the distant future in WIP_STEP_FUTURE. (* inherited from FPSINPUT.WIP_STARTS) |