Data Dictionary
>
FPSAPP Views
> FPSAPP.WIP_WAFER_HIST_LOOP
View FPSBASE.RTG_REF_PRDS_PLUS
IMPORTANT NOTE: This view is an exception to our normal rule that PLUS objects have the same rows as their parent object. In this case, RTG_PRDS includes all prds in the MES regardless of whether or not they are active. This is because we want all prds in the supply chain of an active prd to be active. But we only want to use active prds in all other uses so this view joins on RTG_ACTIVE_PRD_ROUTES so that inactive prds are filtered out. The other key logic here is when prd_to_use_for_ct is set that we get the cycle time from that other prd. Therefore any time we are pulling commit and target cycle time we need to pull from this view.
|
Column |
Comment |
|---|---|
|
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) |
|
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) |
|
DESCRIPTION |
Tool desciption. This value is only used to display in the Dashboard. (* inherited from FPSINPUT.EQP_TOOLS) |
|
IS_TW_ONLY |
IS_TW_ONLY indicates that a PRD or ROUTE has only test wafer lots. This flag is slightly different than IS_TW, which is associated with lots via their LOT_GROUP. Some PRDS/ROUTEs are mixed and this is set to N if there are any non-TW lots. (* inherited from FPSBASE.RTG_ACTIVE_PRD_ROUTES_BASE) |
|
ROUTE |
Route that has threading requirements (* inherited from FPSINPUT.RTG_STEP_THREADING) |
|
ROUTE_FAMILY |
Route_family indicates that all routes within the family have similar or even identical steps and have the same segments. At facilities where various prds share the same route it is likely that the route will be the route_family. This is sometimes referred to as the main process flow. It is used on Segment Summary and Line Viewer to group similar routes. (* inherited from FPSINPUT.RTG_ROUTE_FAMILIES) |
|
ROUTE_GROUP |
Route_group is the parent of route_family. Route_group is used on the Dashboard and other applications as a large grouping for filtering. At many sites this is referred to as technology. (* inherited from FPSINPUT.RTG_ROUTE_GROUPS) |
|
SMP_GROUP |
Product group to be used for sampling, generally something like high/medium/low based on volume of the product. (* inherited from FPSINPUT.RTG_PRDS) |
|
RETICLE_SET |
Reticle set used for the product. (* inherited from FPSINPUT.RTG_PRDS) |
|
WAFER_SIZE |
If the facility only has one wafer size then this column should be null in both RTG_PRDS and EQP_TYPES. If the facility has more than one wafer size then a value of null in EQP_TYPES means that those tools can run all wafer sizes. See column IS_ANY_WAFER_SIZE for details. (* inherited from FPSINPUT.GEN_WAFER_SIZES) |
|
WAFER_SIZE_DISPLAY |
The name of the wafer_size displayed on all dashboards and reports. We allow a longer more descriptive name here although often this will be the same as the wafer_size. (* inherited from FPSINPUT.GEN_WAFER_SIZES) |
|
GROSS_DIE_PER_WFR |
Expected gross die per wafer for the product. This is a critical field for planning die shipments. Note this is gross so we multiply by line yield and by sort yield for remaining steps of remaining products. (* inherited from FPSINPUT.RTG_PRDS) |
|
OUTSIDE_SOURCE |
For all PRDs that are externally sourced (e.g. purchased or produced at an external site), this field describes their source. (* inherited from FPSINPUT.RTG_PRDS) |
|
COMMIT_CT_DAYS |
Number of days of cycle time committed to the customer for the prd or bank. This commit is published externally. This should be greater than or equal to the target. (* inherited from FPSINPUT.RTG_BANKS) |
|
TARGET_CT_DAYS |
Number of days of cycle time targeted for the prd or bank. This target is only published internally which often means it is not even published to corporate planning. This should be less than or equal to the commit. (* inherited from FPSINPUT.RTG_BANKS) |
|
OVR_PROC_CT_DAYS_FOR_FLCT_XF |
Some sites prefer to use a fixed number for the processing time of each prd in the denominator of their X-Factor calculation. The FLCT app will use this value if populated in the X-Factor calculation instead of the calculation processing time. For sites which combine prd in the same facility to report a sequence of prds in FLCT, this value must be populated for the last prd in the same sequence but it should have the value of the total processing time for all prds in the sequence. (* inherited from FPSINPUT.RTG_PRDS) |
|
PRD_TO_USE_FOR_PROBE_CARD |
Use value from another product for the probe card required (* inherited from FPSINPUT.RTG_PRDS) |
|
PRD_TO_USE_FOR_CT |
We often have many prds and routes which are similar and we want to report CT as a group and we can use this field for this. You either enter the target_ct_days and commit_ct_days or you enter prd_to_use_for_ct to use the target and commit for another prd. For example we have prds A and B which are similar. You enter 80 days as target and commit for A then enter A as the prd_to_use_for_ct for B. Then all lots of A and B will be reported with the CT for A and we will not report CT for B. (* inherited from FPSINPUT.RTG_PRDS) |
|
DEFAULT_PLANPRD |
The normal or most frequently used planprd for this prd. At most sites each prd will only use one planprd which is this default_planprd but multiple planprds is allowed. For detailed information, see table comments in RTG_PLANPRDS. (* inherited from FPSINPUT.RTG_PRDS) |
|
DEFAULT_CUSTOMER |
|
|
PRD_MSO_GROUP |
Product group to be used for the Metrology Sampling Optimizer, generally based on similarity of technology or volume. (* inherited from FPSINPUT.RTG_PRDS) |
|
KEEP_ACTIVE |
Manual flag to keep record active even if no activity for the prd-route (* inherited from FPSINPUT.RTG_PRDS) |
|
ACTIVE_VERSION |
The most recent version of the route. (* inherited from FPSINPUT.RTG_ROUTES) |
|
LINE_SECTION_IF_NO_MAIN_RT |
Line section is in RTG_ROUTE_STEPS but the Dashboard uses this filter for the bank spotlight too so this allows us to put lots of this prd which are in a bank and not on a main route into a specific line section. (* inherited from FPSINPUT.RTG_PRDS) |
|
RORP |
The Capacity Model does its calculations by rorp which stands for "route or prd" although it could technically be something in between route and prd. This is controlled by the ovr_rorp column in FPSINPUT.RTG_PRDS. In FPSBASE.RTG_PRDS_PLUS, rorp is set to prd by default if ovr_rorp is null. Populating ovr_rorp in the ETL (with route, for example) will override the default and set rorp = ovr_rorp. (* inherited from FPSAPP.CM_P_RORP_STEP_EQPTYPES) |
|
BG_COLOR |
Background color assigned. BG_COLOR is in English like red or blue or light green and we look up the HTML color like #FF0000 in the GEN_COLORS table. BG_COLOR must be set manually but the FPSADMIN view BLD_POPULATE_COLORS will generate queries to randomly set bg_color for all values in a table. (* inherited from FPSINPUT.GEN_CUSTOMERS) |
|
PRODUCT_SCORE |
Scheduler Evaluation slider value for product priority slider (* inherited from FPSINPUT.RTG_PRDS) |