FPSBASE.GEN_FACILITIES

FACILITY

VARCHAR2(6)

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.

ADD_LOTGRP_TO_GP_SUBFAMILY

CHAR(1)

If this is set to Y we split each subfamily into separate GP_subfamily values for each lot group. This usually means that we set goals by prod and dev separately.

ADD_MINS_TO_EXP_STEP_ENT

NUMBER(5)

The purpose of this column is to prepare an incoming lot from being scheduled within the first x minutes of the schedule unless it is a priority lot or is in the middle of a queue timer or is processing at the previous step when we have higher confidence in our arrival estimate. For all other lots that do not meet any of these criteria we add this many minutes to our normal estimated arrival. For purposes of determining the previous step we exclude skippable steps and staging steps so if the lot is processing at step 100 and step 101 is a skippable metrology step and step 102 is a staging step then we will not add this penalty to the expected arrival. Also please note that we must add the same penalty for the entire facility in order to maintain integrity of the order. If we added a different penalty for different sched groups then the lot could arrive at step 104 before step 103 which would cause trouble. Finally please note that we apply the penalty even if all steps are in the same sched group but that it does not matter to the Scheduler because the Scheduler only cares about the expected arrival to the first step in a contiguous group of steps in the same sched group. The Scheduler manages the arrival for all subsequent steps of the same sched group internally based on the scheduled end of the previous step.

ALLOW_MERGE_VALID_FIN_CT

CHAR(1)

Normally lots that finish by merging into another lot are not counted as valid because they do not reach the end of the main route. But if a lot is merged at the last operation then we normally count this as a valid finished lot since it progressed through the entire route. Therefore the default value for this column is Y. If you do not want to count lots that merge at the last step as valid then set this to N.

ALLOW_SCRAP_VALID_FIN_CT

CHAR(1)

If a lot is scrapped at the last operation then we normally count this as a valid finished lot since it progresses through the entire route. Therefore the default value for this column is Y. If you do not want to count lots that scrap at the last step as valid then set this to N.

APPEND_CUST_TO_PRD_FOR_SCRAP

CHAR(1)

This is a bit of hack to append the customer to the prd column in DASH_P_H_SCRAP for purpose of displaying customer on the Dashboard Scrap page. When that DASH-3715 is completed to make the columns on the Scrap page configurable, we should drop this column and remove the logic from DASH_P_H_SCRAP.

ARE_ALL_STEPS_IN_WSF_PRTY_LOTS

CHAR(1)

By default, we include all future steps for priority lots but loading all future steps can take a few seconds which is significant during the RealTime job at slower sites. Setting this column to N will load the normal amount of steps for priority lots as defined in steps_for_wip_step_fut.

AVG_QTY_PER_CARR_FOR_UPH

NUMBER(7)

Throughput calculations like EET, MPU, and UPH all include wafer_interval_sec which must be multiplied by wafer qty. When calculating for a specific lot, we can use its qty but when calculating generically we use this value which should be set close to the average lot size for the facility. This value can be overridden for an eqp type with exp_qty_per_job.

BG_COLOR

VARCHAR2(24)

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. (* from FPSINPUT.GEN_CUSTOMERS)

COUNT_ALL_SHIPS_VALID_FIN_CT

CHAR(1)

Normally we do not count lots that have skipped the first operation as valid for finished lot CT. This configuration allows the user to count all shipped lots for FLCT even if they skipped the first operation.

COUNT_MV_TO_BANK_AS_OPER_MOVE

CHAR(1)

Some facilities count moves to bank as oper moves and some do not. The default when this flag is N is to not count these so set to Y if you wish to count them.

COUNT_SHIP_AS_OPER_MOVE

CHAR(1)

When is_ship_event is set to Y then the normal oper moves logic is ignored and we only use these two COUNT_SHIP flags. If the ship results in a qty greater than zero then we use this flag. Ships that also set qty to 0 and therefore terminate the lot are subject to COUNT_SHIP_TO_ZERO_AS_OPER_MV

COUNT_SHIP_TO_ZERO_AS_OPER_MV

CHAR(1)

Normally we do not count any move that results in terminating the lot as an oper move. However ships can be the exception to this rule. If this flag is Y then moves where is_ship_event is Y and qty is 0 are counted as an oper move.

CTA_MIN_ACTIVE_NUM_LOTS_BY_PRD

NUMBER(2)

To reduce the size of CTA tables, we filter low runner prds where the number of active lots (not test wafers and not in bank) is less than this number. The default is 1 which means we keep all prds with any active lots. Setting this to 2 means we filter out prds with just a single active lot. Setting this to 0 means we keep all prds even without any active lots which may be desired at smaller sites. We count by prd rather than route so we are not affected by rework routes.

CTM_COLUMN_FOR_CRIT_RATIO

VARCHAR2(30)

This tells our Critical Ratio logic which column to use to estimate expected days remaining. We recommend using FIFO for Critical Ratio because this column is not impacted by the desired cycle time for the prd or route and therefore the highest priority lots will have the highest Critical Ratio. COMMIT and TARGET are also allowed.

CTM_COLUMN_FOR_DAYS_BEHIND

VARCHAR2(30)

This tells our Days Behind logic which column to use to estimate expected days remaining. We recommend using COMMIT for Days Behind because then a lot which is perfectly paced on its Commit cycle time plan will show 0 days behind. Note that does not necessarily mean that it should be prioritized ahead of another lot which is 1 day behind because the other lot might have a much slower expectation. Using FIFO would always prioritize the highest priority lots but it would show lots that are progressing evenly but driven to a faster cycle time as behind. TARGET is also allowed.

CTM_COLUMN_FOR_EST_SMP_PCT

VARCHAR2(30)

This tells our CTM_SUMMARY logic which column to use to estimate sampling percentage. This is either FULL or LONG or 7D. The Dashboard hover message shows this configuration but it is not linked so if you change this column then you need to update DASH_C_CATEGORY_TABLE_COLS to match using the query from DWH-2030.

CTM_COLUMN_FOR_WIP_STEP_FUT

VARCHAR2(30)

This tells our WIP_STEP_FUTURE logic which column to use from CTM_SUMMARY to estimate cycle time to future steps. FULL and LONG are configurable in GEN_FACILITIES but usually 4 weeks and 2 weeks except for small fabs where we make them longer. These as well as 7D and 2D are weighted averages for only time during the period. TARGET and COMMIT are two varieties of plan cycle time. The total for each prd is set by the client via ETL in RTG_PRDS then we adjust the wait time of each step so that the total CT adds up to the total for the prd in a reasonably intelligent balance based on the history. For example, if history was 20 days proc and 50 days wait and commit is 60 then we multiply the wait time of each step by 4/5 so the total wait adds up to 40 and the total cycle time adds up to the commit value of 60. FIFO is the average for the entire process family so this represents what the cycle time would be if we ran the entire fab in FIFO order without any priority.

CTM_FULL_WINDOW_WEEKS

NUMBER(3)

Number of weeks covered by full cycle time columns, e.g. step_sec_wavg_full. Please note this includes the current week-to-date so a value of 4 means the last 4 weeks plus the current week-to-date and therefore will range from 28 to 35 days. Our default for this is 4 weeks but some smaller facilities might prefer an extended window. This should be coordinated with ctm_long_window_weeks.

CTM_IDEAL_TRANSIT_CALC_TYPE

VARCHAR2(8)

The type of calculation used to determine ideal transit time for cycle time X-factor. Best bay means we pick the most likely bay a lot would go to between steps based on the tool ranks assigned generically in the flow but not specifically for the lot. Wavg bay means we take the weighted average of all delivery time options between steps based on how many tools are allowed in each bay. For both calculations, if there is an option to stay in the same bay between steps then the intrabay delivery time is always used.

CTM_LONG_WINDOW_WEEKS

NUMBER(2)

Number of weeks covered by long cycle time columns, e.g. step_sec_wavg_long. Please note this includes the current week-to-date so a value of 2 means the last 2 weeks plus the current week-to-date and therefore will range from 14 to 21 days. Our default for this is 2 weeks but some smaller facilities might prefer an extended window. This should be coordinated with ctm_full_window_weeks.

CTM_VALID_LOTS_2D

NUMBER(4)

Minimum number of lots over the 2 day period required for 2 day cycle time to be considered valid. This number includes both moved lots and lots in WIP at the end of the period. In addition you must have at least one lot moved.

CTM_VALID_LOTS_7D

NUMBER(4)

Minimum number of lots over the 7 day period required for 7 day cycle time to be considered valid. This number includes both moved lots and lots in WIP at the end of the period. In addition you must have at least one lot moved.

CTM_VALID_LOTS_FULL

NUMBER(4)

Minimum number of lots over the number of weeks defined in ctm_full_window_weeks required for full cycle time to be considered valid. This number includes both moved lots and lots in WIP at the end of the period. In addition you must have at least one lot moved.

CTM_VALID_LOTS_LONG

NUMBER(4)

Minimum number of lots over the number of weeks defined in ctm_long_window_weeks required for long cycle time to be considered valid. This number includes both moved lots and lots in WIP at the end of the period. In addition you must have at least one lot moved.

CTR_BANK1

VARCHAR2(36)

In Finished Lot Cycle Time we divide the time within a facility by process state like PROC, HOLD, etc. but for banks we can use these columns to have specific common banks be their own process state for this grouping. So rather than just seeing the average time in bank if we populate this with FAB-OUT then we can see the average time in the FAB-OUT bank separately.

CTR_BANK2

VARCHAR2(36)

See comment for CTR_BANK1.

CTR_BANK3

VARCHAR2(36)

See comment for CTR_BANK1.

CTR_BANK4

VARCHAR2(36)

See comment for CTR_BANK1.

CTR_BANK5

VARCHAR2(36)

See comment for CTR_BANK1.

DASH_COMING_HRS_COL1

NUMBER(2)

This column in combination with the other four columns 2, 3, 4, and 5 allow the number of hours in each of the five columns other than This Shift in the WIP Coming hover to be configurable by facility. For example, FAB might want 1 hr, 4 hr, 24 hr, 48 hr, and This Shift while TEST might want 4 hr, 12 hr, 24 hr, 48 hr, and This Shift. Note that all pages (Operations, Module, Toolset, etc.) for a given facility will show the same information.

DASH_COMING_HRS_COL2

NUMBER(2)

See DASH_COMING_HRS1.

DASH_COMING_HRS_COL3

NUMBER(2)

See DASH_COMING_HRS1.

DASH_COMING_HRS_COL4

NUMBER(3)

See DASH_COMING_HRS1.

DASH_COMING_HRS_COL5

NUMBER(3)

See DASH_COMING_HRS1.

DASH_COMING_HRS_COL_FOR_PAGE

NUMBER(3)

This indicates which WIP Coming column which shows on the page (i.e. without hover over) configurable by facility. For example, FAB might want to show This Shift while TEST might want to show 24 hr.

DAYS_TO_KEEP_PRD_ACTIVE

NUMBER(4)

Number of days without activity for which a PRD should remain in FPSBASE.RTG_ACTIVE_PRD_ROUTES_BASE.

DEFAULT_ADD_TO_GP_CUTOFF_MINS

NUMBER(3)

GP cutoff time is one TCT plus one EET plus this number of minutes before the end of the shift. This is usually one hour or less and might be 0.

DEFAULT_GROSS_DIE_PER_WFR

NUMBER(6)

Used if gross_die_per_wfr is not specified for the prd

DEFAULT_LINE_SECTION

VARCHAR2(32)

N

Default line_section to use if not otherwise specified so the line_section field is not null. This should be the most common line_section and some facilities might only have one.

DEFAULT_LOT_TYPE

VARCHAR2(24)

N

Default lot_type which we should rarely use but is our last resort if an event is inserted for a new lot of a new prd which is not in WIP_STARTS. This should probably be the standard test wafer lot type although if you get to this point it is guaranteed to be wrong much of the time.

DEFAULT_MODULE

VARCHAR2(12)

N

Default wip_module to use if not otherwise specified so the wip_module field is not null. This will typically be LOGISTICS or OTHER or NONE or similar.

DEFAULT_PLAN_PRIORITY

VARCHAR2(7)

N

Default plan_priority to use if not otherwise specified so the plan_priority field is not null. This should be the normal or standard priority.

DEFAULT_PROCFAMGRP_FOR_EQP

VARCHAR2(36)

Default process_family as well as process_group for tools where nothing is assigned in RTG_TOOL_ASSIGNMENTS.

DEFAULT_PROC_CT_SEC

NUMBER(4)

See comment on DEFAULT_WAIT_CT_SEC column.

DEFAULT_WAFER_SIZE

VARCHAR2(8)

N

Default wafer_size to use if not otherwise specified so the wafer_size field is not null. Facilities with only one wafer_size should just set this column and then not specify a value by prd. For facilities with more than one this should be the most common wafer_size in the facility.

DEFAULT_WAIT_CT_SEC

NUMBER(5)

The default cycle time for miscellaneous steps that are in process families with no valid cycle time are 10 minutes processing and 20 minutes waiting for a total of 30 minutes. This column along with default_proc_ctm_sec allows us to change these defaults. The most likely change would be to 0 seconds processing and 1 second waiting to essentially ignore all miscellaneous steps.

EVALUATE_TO_MSO_ON_COMP

CHAR(1)

FACILITY_DISPLAY

VARCHAR2(20)

N

The name of the facility displayed on all dashboards and reports. Facility is a short field since it is used in every join so we allow a longer more descriptive name here although often this will be the same as the facility.

FILLIN_AMR_PCT

NUMBER(3)

This is for our throughput calculations and addresses the case where we get a mix of real values and NA for the actual_machine_recipe for a particular process. If the percentage of real values is higher than this number then we assume that the NA are actually the real value and count all towards the throughput calculation. This avoids the confusing two rows for the same process, one with the real value and one with NA.

FILLIN_EMR_PCT

NUMBER(3)

This is for our throughput calculations and addresses the case where we get a mix of real values and NA for the est_machine_recipe for a particular process. If the percentage of real values is higher than this number then we assume that the NA are actually the real value and count all towards the throughput calculation. This avoids the confusing two rows for the same process, one with the real value and one with NA.

FORCE_VALID_FINISH_EVENT

VARCHAR2(48)

In order to count as a valid finished lot, a lot must complete the last real step in the route, complete at least one step in the last operation of the route, log a ship event, or log the event entered in this field as the event which signifies a valid finish event for the facility. In most facilities, setting this field will not be necessary because even if you have an event that signifies a valid finish event you are likely already setting is_ship_event to Y. The use case where this is necessary is when a lot must go through multiple prds in the same facility and we only want to count the ship out of the last prd as a ship event. Then we can set this field so that we can force the earlier prds to be valid if a lot logs this event.

HASH_EVENT_KEY_IN_WIP_HOLD_FUT

CHAR(1)

If this is set to Y, then WIP_HOLD_FUTURE.EVENT_KEY field is a an opaque event identifier which can be used directly as a key by web apps; if N, then it is a long human-readable string and should be hashed before being used as a key.

HIDE_CTR_WSH_IF_LESS_THAN_SECS

NUMBER(4)

To reduce the number of rows on the Finished Lot Cycle Time lot history page, we hide steps which took less than this number of seconds. The default is 1200 or 20 minutes. We always show the first and last steps even if they were fast.

HIDE_FACILITY_ON_WEB

CHAR(1)

Hide a facility from our applications. Default is N, but setting to Y hides on Dashboard and other applications will not reference hidden facility

HOURS_FOR_NEXT_MOVE

NUMBER(3)

Include lot-step in NextMove Pick List if lot is expected to arrive sooner than hours_for_next_move or if step is less than or equal to this many steps away from the current step. Populates nmv_display_in_pick_list column in WIP_STEP_FUTURE

HOURS_FOR_WIP_STEP_FUT

NUMBER(4)

The maximum number of expected hours to arrival for steps in WIP_STEP_FUTURE. This is used in combination with steps_for_wip_step_fut. For example, if this is 48 and steps is 10 then we write all steps where a lot is expected to arrive within 48 hours or is within 10 steps way. This should likely be 24-72 for a fab and possibly a bit longer for assembly/test.

IGNORE_BANK_TW_ON_DASH

CHAR(1)

The Dashboard spotlight shows a number of Test Wafers in the facility. Usually we want this to include test wafers in a bank so we would set this to N. To ignore test wafers in a bank then set this to Y.

IGNORE_PASS_THRU_PRD_FOR_FLCT

CHAR(1)

Our normal logic to determine whether a finished lot is considered valid for FLCT calculations is to only count as valid if the lot moved through the first step and the last step of the main route (or if they ran on the last step and split from a lot that ran on the first step). But many sites especially those with multiple facilities have prds that we call "pass-through" prds where the prd goes through a bank but no steps. If we want to count any lots as valid for these prds then the only option is to simply count all finished lots as valid because if we used our normal logic then we would never have any lots as valid. Whether or not to do this is configurable here by facility.

INCLUDE_EQP_STATE_IN_DASH_ETP

CHAR(1)

This column will add the MES state of the tool to the end of the ETP_STATE_NAME for Dashboard users to see the MES state of the tool after the ETP state. If set to N then only the ETP state will be shown.

INCLUDE_NST_AS_CAP_ENT

CHAR(1)

Determines whether tools/chambers in NST states should be counted as capacity entities. The default value is N.

INC_BATCH_EQP_STATE

VARCHAR2(48)

This optional column is the eqp_state to use for processing incomplete batch if this is included in the client equipment state model. Populate only if you are passing eqp_inc_batch_pct in EQP_EVENT_HIST.

IS_ANY_VALID_OUTPUT_NEARBY

CHAR(1)

Set this flag to Y to not use bay runner. This means operators will be directed to go get any reserved lot from any valid output rack in their building.

IS_COMP_RQD_FOR_OPER_MOVE

CHAR(1)

This indicates whether a move must have move_type of COMP in order to count as an oper move.

IS_LINE_SECTION_FROM_MAIN_RT

CHAR(1)

When a lot is on a rework route, our default is to use the line section from the main route rather than the line section from the rework route. This is because most facilities do not define a meaningful line section for their rework routes. For those facilities that define meaningful line sections for the rework routes and want to use them as the line section for lots on those routes, we set this value to N.

IS_LOT_ASGN_INFO_RQD_FOR_SCH

CHAR(1)

Populating standard values for setup and batch information in RTG_TOOL_ASSIGNMENTS by process+tool and leaving these columns null in RTG_TOOL_ASSIGNMENTS_LOT/RTG_TOOL_ASGN_LOT_PROCESS in order to use the standard values from RTA is a recommended ETL strategy used at many sites. In contrast to IS_LOT_ASGN_RANK_RQD_FOR_SCH which has a default of Y, the default for this flag is N which means that our defaults are to only schedule lot-steps with ranks in RTAL and get batch/setup from RTA when this information is not populated in RTAL. But some sites want to use RTAL/RTALP exclusively and do not want to use any information from RTA. Setting this flag to Y does this and prevents the information from RTA from being used in WIP_STEP_FUT_ASGN_xxx views. Note if this flag is Y then the RANK flag must also by Y but if this is N then the RANK flag can be Y or N.

IS_LOT_ASGN_RANK_RQD_FOR_SCH

CHAR(1)

Our lot-tool assignments use a hierarchy where if we have any entries in RTG_TOOL_ASSIGNMENTS_LOT or RTG_TOOL_ASGN_LOT_PROCESS for a lot then the lot is only allowed on those tools and any others in RTG_TOOL_ASSIGNMENTS are inhibited. Normally if we have no entries in either lot assignments table then we use RTG_TOOL_ASSIGNMENTS. But for Scheduler we often only want to schedule lots which are included in the lot assignments table. Setting this flag to Y here or in RTG_PROCESS_GROUPS enables this behavior by setting eff_rank to I in WIP_STEP_FUT_ASGN_FOR_SCH for any lot without specific assignments by lot.

IS_OPERATION_FROM_MAIN_ROUTE

CHAR(1)

Operation is a field defined in RTG_ROUTE_STEPS and the operation of a lot is the operation of its current route and step. But some facilities prefer for the operation to be based on the main route and step rather than the current route and step so that lots which are on rework routes will show the operation from their main route. Setting this flag accomplishes this but please note that this only works for current WIP status and not for history.

IS_TOOL_RQD_FLCT_FIRST_STEP

CHAR(1)

For the purpose of Finished Lot Cycle Time calculations, we consider the first step on the route to be the first step with real tools allowed. But some sites have some routes where the first step is a staging step with no tools allowed that we would like to count. This parameter which has default of Y allows us to configure by facility whether to a real tool is required when determining the first step for FLCT.

MAX_QTY_PER_CARR

NUMBER(7)

Maximum number of wafers in a carrier - also known as maximum lot size - which is typically 25 for a wafer fab.

MIN_EST_PCT_OF_SUBFAM

NUMBER(2)

If at least this percentage of the total completes of a subfamily run on a tool then that counts counts as being in the subfamily for purposes of Dashboard and Goal Planner. Please note that a tool can also be in a subfamily by exceeding percentage of min_est_pct_of_tool.

MIN_EST_PCT_OF_TOOL

NUMBER(2)

If a tool runs at least this percentage of its total completes of the subfamily then that tool counts as being in the subfamily for purposes of Dashboard and Goal Planner. Please note that a tool can also be in a subfamily by exceeding percentage of min_est_pct_of_subfam.

MIN_QTY_TO_USE_CTM_WEEK_HIST

NUMBER(7)

We want to avoid using records from CTM_WEEK_HIST with just a few wafers moved which would lead to huge misleading values. We normally want this value to be units in a full lot which is usually 25 for wafer fabs and larger for backend sites where the qty is in units of die. However we might set slightly larger like 26 for wafer fabs to require at least two lots including one full lot.

MIN_SEQ_DELTA_FOR_WSF

NUMBER(2)

At some facilities, the steps on the active routes jump around frequently so we can set this greater than 0 if we choose not refresh WSF for all changes. If we set to 2 then means we would only refresh WSF if seq_num changed by at least 3. Most sites should have this set to the default of 0.

MIN_SETUP_COST_FOR_RANK_S

NUMBER(4)

See comment on MIN_SETUP_SEC_FOR_RANK_S.

MIN_SETUP_SEC_FOR_RANK_S

NUMBER(4)

Sometimes we actually have zero setup penalty for certain combinations in EQP_SETUP_CHG_MANUAL and we want to ignore these when we set the rank to S which leads to the ETP state of Standby With Setup Rqd. That will happen which both min_setup_sec_for_rank_s and min_setup_cost_for_rank_s are set to the default values of 0. But we might also want to ignore setups with a tiny albeit nonzero penalty which we can do by setting one or both of these columns to a tiny value greater than zero. Our rank logic will only count the setup change if the setup_sec is more than min_setup_sec_for_rank_s or the setup_cost is more than min_setup_cost_for_rank_s.

NONSTD_CTM_FACTOR

NUMBER(3,2)

Factor to multiply cycle time if non-standard compared to standard is not known. For example, if this is 1.5 and we know the standard CTM is 6 hours and we do not know the non-standard CTM then we would estimate it to be 9 hours.

NUM_ROUTE_GROUPS_IN_COMING_WIP

NUMBER(2)

The coming WIP hover message on the Dashboard can be broken down by route_group and this field sets how many route_groups are shown, based on most current WIP, with the rest being assigned to Other.

PULL_POINT_COLUMN_NAME

VARCHAR2(30)

Either due_inst from WIP_LOTS_STATIC or demand_inst from WIP_FLUSH can be used as the date to calculate pull points for Line Viewer and WIP Flush.

QTY_UNIT

VARCHAR2(12)

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.

QTY_UNIT_PLURAL

VARCHAR2(12)

Plural form of the quantity unit. For example if qty_unit is defined as wafer then the plural form would be wafers.

QTY_UNIT_SHORT

VARCHAR2(3)

Short display of the quantity unit. For example if qty_unit defined is wafer then this could be wfr.

SCHEDULE_STATUS_OFFSET_DAYS

NUMBER(1)

If the expected out inst is more than this many days after the pull point (a.k.a. due or demand) inst then we consider the lot to be late. We also consider it late if it is in the next plan week even if less than this number of days behind.

SEC_QTY_UNIT

VARCHAR2(12)

Secondary quantity unit. See QTY_UNIT comment for details.

SEC_QTY_UNIT_PLURAL

VARCHAR2(12)

Plural form of the secondary quantity unit. For example if sec_qty_unit is defined as wafer then the plural form would be wafers.

SEC_QTY_UNIT_SHORT

VARCHAR2(3)

Short display of the secondary quantity unit. For example if sec_qty_unit defined is wafer then this could be wfr.

SET_ECT_TO_WAIT_TOOLPREV

CHAR(1)

When a lot completes a step and its carrier has the location of a load port of the tool that processed the lot at the previous step, we set the ect_state to WAIT-TOOLPREV (On Tool From Prev Step) by default. When the carrier moves off of the load port then the ect_state changes to a WAIT state. At sites where we do not have accurate carrier location tracking we likely do not want to use this feature and always set the ect_state to a WAIT state when it enters a new step. Setting this to N will do that.

SET_ZERO_GOAL_COMP_IF_NO_MANL

CHAR(1)

Our default goals for completes are based on the activity over last three days. These default goals can be overwritten by populating the DASH_W_TARGETS_xxx tables. The question is what is the goal for a record which has activity in the last three days but has no goal defined at any level in the DASH_W tables. Our default is to set a goal based on the activity. If this flag is set to Y then our goal for all records without manually defined goals will be 0.

SET_ZERO_GOAL_OPMV_IF_NO_MANL

CHAR(1)

Our default goals for oper moves are based on the activity over last three days. These default goals can be overwritten by populating the DASH_W_TARGETS_xxx tables. The question is what is the goal for a record which has activity in the last three days but has no goal defined at any level in the DASH_W tables. Our default is to set a goal based on the activity. If this flag is set to Y then our goal for all records without manually defined goals will be 0.

SET_ZERO_GOAL_WIP_IF_NO_MANL

CHAR(1)

Our default goals for WIP are based on the active WIP over last three days. These default goals can be overwritten by populating the DASH_W_TARGETS_xxx tables. The question is what is the goal for a record which has WIP in the last three days but has no goal defined at any level in the DASH_W tables. Our default is to set a goal based on the WIP. If this flag is set to Y then our goal for all records without manually defined goals will be 0.

SHIP_BEFORE_DAYS

NUMBER(2,1)

Limits the week for due date calculation by x days. For example if the week ends on Sunday and this is specified to 2, we calculate due dates for Monday to Friday. Used in WIP_REF_FLUSH_BASE.

SHOW_COMMIT_ON_FLCT_CHART

CHAR(1)

Normally we should a point representing the commit cycle time for the prd during the period but these points can be hidden by setting this to Y.

SHOW_ONLY_TRUSTED_ON_THPT

CHAR(1)

At most sites we should all records on the Throughput Tracker but at some sites which have extensively populated their trusted values we only want to show processes with trusted values. Setting this value to Y does that.

SHOW_PROC_STATE_AS_PORT_MODE

CHAR(1)

If this is Y which is the default, the view DASH_P_TOOL_PORTS will overlay whether the port is occupied along with its carrier and the WIP processing states over the port modes as long as the port mode has is_up set to Y.

SHOW_TARGET_ON_FLCT_CHART

CHAR(1)

Normally we should a point representing the target cycle time for the prd during the period but these points can be hidden by setting this to Y.

SMP_PCT_FOR_NUM_STEPS_AWAY

NUMBER(2)

At most sites where we use Scheduler we know the take/skip decision for each lot at the next few steps and we always use this decision if known. But at later steps when this decision is unknown (and for all steps at some sites) then this value determines if we will count the step for num_steps_away. If est_smp_pct is greater than or equal to this number then we will count it. The default is 10 which means we assume that upcoming lots will skip steps with an est_smp_pct less than 10%. If a lot arrives at the step unexpectedly then we will schedule them on the next Scheduler run. The converse is when a lot skips a step with an est_smp_pct greater than 10% in which case it will arrive earlier than expected at the following step. In this case, it should be scheduled but on the next Scheduler run it would be eligible to start immediately. A value of 0 is a special case which means we will count all steps except those where we know that the decision is skip, even steps where the est_smp_pct is exactly 0. To count all steps except those with 0% then set this value to 1.

SMP_PCT_TO_ALLOW_Q_WHEN_DOWN

NUMBER(2)

Normally we do not allow lots to start at the first step in a queue timer sequence if there is a step in the sequence that has no tools available. But we do not want to do this if all tools are down at a metrology step where we know we can skip. This flag sets the threshold for the est_smp_pct below which we will allow lots to start even if all tools are down at this step. The default value is 30 which means that if we have no tools for a step under 30% then we will not block but if we have tools for tools for a step estimated to sample more than 30% then we will block. This can be overriden for specific processes by setting always_allow_q_when_down in RTG_PROCESSES.

SMP_PCT_VALID_LOTS_2D

NUMBER(4)

Minimum number of lots over the 2 day period required for 2 day sample pct to be considered valid. This number includes both moved lots and lots in WIP at the end of the period. In addition you must have at least one lot moved.

SMP_PCT_VALID_LOTS_7D

NUMBER(4)

Minimum number of lots over the 7 day period required for 7 day sample pct to be considered valid. This number includes both moved lots and lots in WIP at the end of the period. In addition you must have at least one lot moved.

SMP_PCT_VALID_LOTS_FULL

NUMBER(4)

Minimum number of lots over the number of weeks defined in ctm_full_window_weeks required for full sample pct to be considered valid. This number includes both moved lots and lots in WIP at the end of the period. In addition you must have at least one lot moved.

SMP_PCT_VALID_LOTS_LONG

NUMBER(4)

Minimum number of lots over the number of weeks defined in ctm_long_window_weeks required for long sample pct to be considered valid. This number includes both moved lots and lots in WIP at the end of the period. In addition you must have at least one lot moved.

SORT_ORDER

NUMBER(4)

This is used to sort within the grouping. SORT_ORDER always has a deferrable unique key to ensure uniqueness while allowing the user to make changes without erroring until the commit is attempted. Because of this you must be careful to not violate the unique key otherwise you will lose all of your edits.

STEPS_FOR_NEXT_MOVE

NUMBER(2)

See comment in hours_for_next_move column

STEPS_FOR_WIP_STEP_FUT

NUMBER(3)

The maximum number of steps away from the current step for steps in WIP_STEP_FUTURE. If this is 999 then include all future steps. This is used in combination with hrs_for_wip_step_fut. For example, if this is 10 and hrs is 48 then we write all steps where a lot is expected to arrive within 48 hours or is within 10 steps way. This should likely be close to 10.

STEPS_TO_FIX_WSF_IF_NEW_SMP

NUMBER(2)

When a new smp_result is available for a faraway step (usually meaning that the step is close enough to appear in RTAL/RTALP) then we do not want to immediately fix WSF. Instead we will just wait for the lot to move to a new step and then use the newly available smp_result with that normal update of WSF. But if a new smp_result is available for a step coming soon then we want to fix immediately. That configuration of "coming soon" vs. "faraway" is set with this column.

THP_WINDOW_WEEKS

NUMBER(3)

Number of weeks used by our throughput calculations to determine the current estimates. Unlike cycle time which includes the current week-to-date, throughput only uses full weeks. Our default for this is 4 weeks. A longer window would give more stable data but would also take longer to reflect a significant shift in the throughput.

TO_MSO_REQUIRES_SMP_RESULTS

CHAR(1)

If the site does not trust the BEGIN/COMP event type to be and indicator of measurement take for a lot. The MSO_RESULT_HIST table can be populated. If this flag is set to Y then MSO will validate that we have data in this table for the lot and to_mso_process within the time the lot arrived at the step and the time of the event. If there is data the measurement would be considered a valid measurement to clear the rule counters.

TURNS_TGT_FROM_COMP_WIP_GOALS

CHAR(1)

This flag indicates to use the automatic Dashboard calculations or use the existing target entries from the dash_w_targets_xx tables

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.

UPDATE_HOLD_NOTE_W_NEW_COMMENT

CHAR(1)

This flag applies if a lot goes on hold by event E1 with event_comment C1 and then another event is logged in WIP_EVENT_HIST for the lot which does not change the hold status with event_comment C2. By default, the hold_note is the comment from the event that put the lot on hold which is C1. But if you want it to be C2 then set this flag to Y. The hold_note will always be C2 if C1 is blank and it will always be C1 if C2 is blank.

USE_COUNT_AS_OPER_MOVE_FLAG

CHAR(1)

Normally we count an oper move when the lot moves from one operation to another (along with plenty of other configuration options). If we use this flag instead then we count any move from a step where count_as_oper_move is Y and ignore the operation.

USE_CTM_BEF_EST_FOR_RELEASE

CHAR(1)

We calculate the estimated_hold_sec for each process_family, hold_type, lot_group in WIP_HOLD_ESTIMATES. We calculate the hold_sec_comp_for_wsf by prd, route, step, and lot_group in CTM_SUMMARY. This flag determine which value is preferred as our default value for estimated hold seconds. At most sites this is N so we use WIP_HOLD_ESTIMATES. If set to Y then we use CTM_SUMMARY. The values for remaining hold seconds are half of the estimated values. Either way, the default values can be overridden by ovr_estimated_hold_sec and ovr_remaining_hold_sec in WIP_HOLD_TYPES or more specifically by ovr_release_inst in WIP_LOTS_VERIFY. Please see the column comment on ovr_remaining_hold_sec for an example of how estimated and remaining are used to calculate the estimated release inst of all lots currently on hold.

USE_LOT_GOALS_FOR_WEB

CHAR(1)

Flag to display FPS Goal Planner goals in WIP_GOAL_LOT tables on dashboard instead of default WIP_GOAL_EST tables.

USE_LOT_GROUP_IN_CTM_FILLIN_G1

CHAR(1)

See comments on USE_ROUTE_FAM_IN_CTM_FILLIN_G1 column.

USE_ONLY_TRUSTED_FOR_THP_AVG

CHAR(1)

By default, the Auto MPU for each eqp_type shown on our Throughput Tracker is the weighted average of the automated calculated MPU for all processes. But the Auto-Trusted Delta compares the weighted average of the auto MPU only for processes where a trusted value is defined. Therefore if only selected processes have trusted values, we will show something confusing like Auto 7, Trusted 5, A-T Delta 1. If this flag is set then we will show the weighted average only for processes where a trusted value is defined to match the A-T Delta calculation. Then we will show Auto 6, Trusted 5, A-T Delta 1.

USE_ROUTE_FAM_IN_CTM_FILLIN_G1

CHAR(1)

By default, we use route family and lot group in group 1 of our CTM_SUMMARY fill-in logic along with common step. Group 1 is only for est_smp_pct not for cycle time! At some sites, we only want to use common step so we set both of the use_xxx_in_ctm_fillin_g1 columns to N. They are independent so we could also set one or the other.

USE_RT_SECT_FOR_RT_SEG_SORT

CHAR(1)

The default setting of Y for this flag uses route_section_sort from RTG_ROUTE_STEPS to determine the route_segment_sort. Some sites configure their route sections in an unusual way for line balance and at these sites we can set this flag to N to use common_step sort logic instead.

USE_STEP_IN_CTM_FILLIN_G1

CHAR(1)

Almost all sites define common_step as a grouping of identical or similar steps within a route or across routes. Thus this flag should be N which is the default. Some clients define common_step differently, grouping radically different process steps together. In these rare cases, this flag may be set to Y which will enable use of step in the fillin g1 CTM logic instead of common_step.