Data Dictionary
>
FPSAPP Views
> FPSAPP.WIP_WAFER_HIST_LOOP
View FPSAPP.WFM_P_FLUSH_FORWARD
UPDATED NOTE: This version is not completely correct! However the previous version was not only incorrect but very slow. Since this is a simple view on WIP_FLUSH there is no reason to keep as REF. To make this completely correct, we need a perfect version of RTG_PRD_FACILITY_REVERSE that gets all of the "starting" planprds for a given planprd by tracing back through each branch of RTG_PRD_FACILITY_NEXT until it ends. Then we know that a given planprd requires those "starting" planprds. Then we do the same reverse lookup for each current lot to find out all of the "starting" planprds which is represents. Then we can make a plot for each of the "starting" planprds of the given planprd which is the desired result. DWH-2865 is the JIRA task to do this. ORIGINAL COMMENT FROM REF VIEW: Multi-facility, multi-path WIP flush view. This view is used to build the "outs graph" for multi-facility WIP flush, which plots the expected number of dies (est_dies_to_dest) reaching EOL for a given end-product vs. date (days_to_dest). Because each end-product (in RTG_END_PRDS) may depend on multiple starting or intermediate products (from RTG_START_PRDS or RTG_PATH_PRDS), the outs graph may include multiple traces--one for each input product. The intent is for each input product's trace to estimate the number of expected dies out *if* the availability of that input product were the one limiting the total outs of the finished product. For example, if end-product X requires input-products A and B in equal quantity, then the graph for A shows the number of outs assuming infinite availability of B, and vice versa. Important: in multi-facility WIP flush, each product can go to multiple destinations. (RTG_PRD_SPLIT_30DAY contains the recent split ratios.) In order to forecast the number of outs based on recent split pattern, EST_DIES_TO_DEST from this view should be multiplied by PROB_TO_DEST. These columns are kept separate here to facilitate speculative "what if?" adjustments of the PROB_TO_DEST.
|
Column |
Comment |
|---|---|
|
LOT |
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. (* inherited from FPSINPUT.WIP_LOTS_STATIC) |
|
START_FACILITY |
|
|
START_PRD |
|
|
CURRENT_FACILITY |
|
|
CURRENT_PRD |
|
|
CURRENT_BANK |
|
|
DEST_FACILITY |
Facility where the lot will go after it completes its route in the current facility. (* inherited from FPSINPUT.RTG_PRD_FACILITY_NEXT) |
|
DEST_PRD |
Prd which will the lot will assume after it completes its route in the current facility. This could be the same as the current prd. (* inherited from FPSINPUT.RTG_PRD_FACILITY_NEXT) |
|
DEST_BANK |
|
|
DAYS_TO_DEST |
|
|
EST_DIES_TO_DEST |
|
|
PROB_TO_DEST |
|
|
QTY |
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. (* inherited from FPSINPUT.WIP_EVENT_HIST) |
|
QTY_UNIT |
Defines the unit used to measure number of quantity. The key here is that this quantity must be known throughout the entire route through the facility. For example in a sort facility where lots enter in wafers and are broken into die but the number of wafers is still known when the lot completes the facility then the qty_unit must be wafer. It cannot be die because die is not known when the lot enters so die will be the sec_qty_unit. Similarly at a final test facility where the lots enter with both wafers and die known but only die are known when the lot completes the facility then the qty_unit must be die. It cannot be wafer because wafer is not known when the lot completes so wafer will be the sec_qty_unit. Please note the entire process from only wafers to only die must be split into at least two facilities because of this requirement. (* inherited from FPSINPUT.GEN_FACILITIES) |
|
FACILITY_OR_BANK_MOVES_TO_DEST |
|
|
PATH_TO_DEST |