Tentative Master Schedule Generation - Batch - Calculations

MS170E

A. Housekeeping

1. See the Common Processing Routines - Housekeeping section of this manual for a general discussion of this subroutine. Processing specific to this program is described below.

2. Key lists are defined for each keyed file the program retrieves.

3. Work fields are defined and program constants are initialized.

4. The following information is retrieved from the Reference file (REFERP):

a. The applications installed record (category 012) is retrieved to determine if Shop Floor, Synchro, EDI, or Future 3 Interface modules are installed. If the Shop Floor Control module is installed, actual scrap rates will be used in calculations.

b. If EDI or the Future 3 Interface module is installed, demand types are retrieved from category D26.

c. The date format is retrieved from the date format record (category 049).

d. Part types are retrieved from category 405 and loaded into an array.

e. The production type codes are retrieved from category C01. These codes are used to determine if a part is MRP or JIT.

f. Order policy codes and descriptions are retrieved from the order policy codes record (category 404) and loaded into arrays. If this record is not found, blanks are used.

g. The number of decimal places is retrieved from Reference File category 446.

5. The following information is retrieved from the System Control file (CT100M):

a. The potency and lot control options (POTOPT, LOTOPT) are retrieved from the first Inventory Control control record (ICCTL1). Both flags must be set to yes (Y) for the environment to be potency controlled.

b. The warehouse balances available for manufacturing (MOPAC1, MOPAC2, MOPAC3, MOPAC4) and distribution (DSTAC2, DSTAC3, DSTAC4) are retrieved from the second Inventory Control control record (ICCTL2).

6. Headings for the Tentative Master Schedule Generation Request report (MS170A) are printed.

B. Mainline

1. The program is driven by the Tentative Master Schedule Generation Request file (MS320AP). After performing Housekeeping, the program reads the first request in the request file.

a. If no requests are found, a warning message is written on the Tentative Master Schedule Generation Request report (MS170A), and processing stops.

b. If any requests are found, they are processed in order, until the end of the file is reached.

c. Once all the requests have been processed and the Tentative Master Schedule program (MS170E) is completed, the request file (MS320AP) is cleared by the Tentative Master Schedule Generation Control Language program (MS170CLP).

2. For each plant:

a. The associated company and location are retrieved from the Warehouse Description file (IC170ML2).

b. The last calendar date is retrieved from Reference File category C14.

c. Calendar and shop floor date arrays are loaded, based on the calendar code for the plant.

d. The planning period mask array is loaded from the Planning Period Definition file (MS025M). If no mask is found, a flag is set up (MSKAVB) to prevent requests selecting a planning period mask option from being processed.

e. The dates of the current period are retrieved, and calendar and shop date arrays are built.

f. The system date is reformatted to YYMMDD. Using this reformatted date, the following dates are determined:

Current week start date with its equivalent shop date	First working day of the week in which this date falls (CURWEK, CURSHP)
Current month start date	First working day of the month in which this date falls (CRMOCL)
Current mask period start date	First working day of the period in which this date falls (CRMKCL)

g. The actual demand fence and the demand fence period are retrieved from Reference File category 464, Master Scheduling Defaults.

h. The demand fence date is calculated by calling MS090E (Planning Horizon Date Calculation). The actual demand fence and the demand fence period are passed. See program documentation for MS090E for detailed processing information. This demand fence date is displayed on the tentative master schedule.

i. The demand window is retrieved from Reference File category D84. This window indicates the number of weeks after which the entire schedule should be placed in a single bucket.

3. If the user specified a printer on the request screen, the command outq is set to the requested output queue.

4. For each request processed, the generation request type (REQTYP) is determined according to the parameters on the generation request record. The request type is determined as shown on the table below:

Generation Mode	Part Number	Planner Code	Request Type
Full (F)	Not checked	Not checked	FULLGN (1)
Selective (S)	Not blanks	Not checked	PARTGN (2)
Selective (S)	Blanks	Not checked	PLANER (3)

5. This request type determines which logical view of the Part Master file (DE100M) will be used to drive the processing:

a. If the request type is full generation (FULLGN), a tentative master schedule will be generated for every master scheduled part for a specified plant on the Part Master file (DE100M). However, since parent parts contribute to the demand for child parts in the product structure, the driving Part Master file (DE100L15) is used, keyed by low-level code and part number. This way, the tentative master schedule is calculated first for the higher-level parts and is made available for calculations related to the lower-level parts processing.

b. If the request type is generation by part (PARTGN), a tentative master schedule will be generated for the specified part in the specified period. The Part Master file (DE100M) is used.

c. If the request type is generation by planner (PLANER), a tentative master schedule will be generated for each master scheduled part assigned to the particular planner in a specified plant during the period specified on the request record. The driving Part Master file (DE100L13) is used, keyed by low-level code, analyst (planner) code and part number, and plant.

6. The generation dates for the request are determined and validated as follows:

a. The starting date for the planning period containing the current date is determined according to the planning period option selected.

b. The requested generation start date (REQDAT) is checked to ensure it is not before the beginning of the current week. If it is, the current week start date is used and a warning message is written on the Tentative Master Schedule Generation Request report (MS170A).

c. The generation horizon date (GENHRZ) is determined by obtaining the next week start date after the user's requested horizon date from the calendar date array. If such a date is not found, the last calendar date is used, and a warning message is written on the Tentative Master Schedule Generation Request report (MS170A).

d. The generation horizon date (GENHRZ) is checked to ensure it is after the requested generation start date (REQDAT). If it is not, the transaction is rejected, a message is written on the Tentative Master Schedule Generation Request report (MS170A), and the next request is processed.

e. If the planning period option is by planning periods, the requested generation start date (REQDAT) is checked against the Planning Periods array. If the Planning Periods array begins after the start of the week in which the requested generation start date falls, the transaction is rejected, a message is written on the Tentative Master Schedule Generation Request report (MS170A), and the next request is processed.

7. A priming read of the appropriate logical view of the Part Master file is performed according to the request type. Part validation is performed as follows:

a. The part number must exist in the Part Master file.

b. The part must be an active part (Activity Code (IZACD) does not equal *).

c. The part must be a master scheduled part (Demand Code (PMDMND) = M).

d. The Master Schedule Generation Flag (PMMSFL) must be equal to zero. If this flag equals 1, it indicates that the part has been scheduled online, and the schedule should not be changed by the Master Schedule Generation program.

8. The tentative master schedule is generated for each valid part included in the request for the period. Each part is processed in turn.

C. Part Processing

1. Fields are initialized and data structures are set up.

a. Accumulators, work fields and flags are initialized. Data structures are filled with zeros (numeric fields).

b. The name of the buyer/analyst associated with the part is retrieved from Reference File category 235 for printing on the report.

c. The part's relevant attributes that will be used as processing options in further processing are saved.

If the part is MRP or has inventory netting flag (PMNETF) equal to yes, safety stock will be processed as a requirement.

If the part is not manufactured, transfer, or bundled, , the order policy parameters (quantity and increment) are converted from the purchasing unit of measure to stockkeeping units of measure. The conversion also occurs if the part has a make/buy flag on the Part Master File (DE100M) of Buy.

If the part has a scrap factor and the order policy is fixed quantity or fixed time, the order policy parameters are reduced by the scrap quantity.

d. The time fences are calculated by adding to the current date the value of each fence defined for the part on the Part Master file. There are four time fences, which are defined as follows:

(1) Volume time fence: The user-defined period within which changes in the quantity may not be cost-effective.

(2) Mix time fence: The user-defined period within which changes in the mix of products to be made (the ratio of one item to another) may not be cost effective.

(3) Cumulative leadtime time fence: The part's cumulative leadtime. Changes that fall within the cumulative leadtime might not be feasible.

(4) Actual demand time fence: The user defined period (category 464) within which the forecast demand should not be considered. Net demand is set to actual demand irrespective of the size of forecast demand.

These time fences are used only to print warning messages on the master schedule report to indicate to the user when a time fence has been reached; they do not affect the processing of the master schedule quantities.

e. The date to start calculating the tentative master schedule is determined. This depends on the Requested Generation Start Date and the Planning Period Option selected in the request, as follows:

(1) If the Planning Period Option is calendar weeks, the first working day of the week containing the Requested Generation Start Date is used.

(2) If the Planning Period Option is calendar months, the first working day of the month containing the Requested Generation Start Date is used.

(3) If the Planning Period Option is calendar periods, the first day of the period containing the Requested Generation Start Date is used.

The first dates to start netting demand and calculating projected inventory are set on the weekly and projected demand data structures. Full netting is performed from the current date in order to obtain accurate projected inventory values regardless of how far in the future the Requested Generation Start Date is.

f. Parent part data structures are built.

(1) The Product Structure Where-Used file (DE120ML) is read to find all of the requested part's parents. Only product structures in effect during the period are used. Reference parts are not processed. If the parent part is a build-thru part, its parents are retrieved.

Each parent part is checked to determine whether it is a planning, master scheduled, or requirements planning part by chaining to the Part Master file (DE100M). The part type determines which file will be read to retrieve the parent's dependent demand during the master schedule calculation.

(a) Planning parents are saved in the Planning Parent Part Data Structure, along with the part being processed itself. Parent indirect demand for these parts will come from the Forecast file (MS150M). If the parent part is a transfer part, DE100L25 is accessed to determine the sourcing plant for the part. Requirements for the part will be added to the demand in that plant.

(b) Master scheduled parents are saved in the Master Scheduling Parent Parts Data Structure. These parts' dependent demand will come from the Tentative Master Schedule file (MS160M).

(c) For each parent part, the quantity per batch is divided by the batch quantity to determine the quantity per unit. The quantity per and scrap factor from the product structure record are stored in the corresponding arrays.

(d) Requirements planning parents are ignored. The dependent demand contributed by these parents will be on the Components Requirements file.

2. For JIT parts that do not net from existing inventory, inventory balances are ignored. If the part is JIT manufactured but has a make/buy flag on the Part Master File (DE100M) of Buy, the parent demand should be processed like a non-JIT part. For all other parts, the Beginning Inventory Balance is calculated for the current period. The basic calculation is as follows:

BEGINNING INVENTORY BALANCE

CURRENT INVENTORY BALANCE

minus

PAST DUE DEMAND

plus

PAST DUE SUPPLY

Each operand is explained in more detail below.

a. For parts that are not potency-controlled, Current Inventory Balance is calculated in subroutine GTCURI. The balance is retrieved from the Warehouse Balance file (IC140M), and is the sum of the work-in-process balance, on-hand balance and planning balance. This total is calculated as follows:

(1) For the manufacturing warehouse, if the Order Planning flag on the balance type is Y, the quantity is added to the total. (Note that the Order Planning flag for the On-Hand balance type is Y, so on-hand inventory is included in the total.)

(2) The work-in-process balance is added to the total.

(4) For every distribution warehouse associated with the plant, the Warehouse Description file is read to determine if balances at the warehouse are available for planning. If so, any distribution balance at the warehouse is added to the total.

b. For potency-controlled parts, the Current Inventory Balance is calculated in subroutine BPCURI). The balance is retrieved from the multiple location logical file (IC130ML6) for each balance type on the applicable records (LLBLT1 through LLBLT4). This balance is calculated, or converted into, potent units as shown below, and is the sum of the on-hand and planning balances. If the totals in potent units are calculated as follows:

(1) For the manufacturing warehouse, if the order planning flag (MOPAC2, MOPAC3, MOPAC4) on the balance type (LLBLT2, LLBLT3, LLBLT4) is Y for each multiple location record read, the quantity is converted into potent units and added to the total. Potent units for each applicable balance type are calculated as follows:

Potent Units	equals	Balance Type Quantity	times	Actual Potency of lot (LCACPT) from IC150M)
				Master standard potency (SVSTFT) from DE100M

This process occurs in subroutine POTCLC, after which the equivalent potent units (POTBLQ) is added to the current inventory balance.

(2) Since the multiple location file does not have a work-in-process balance quantity (WBWIPB) similar to that on IC140M, this is not directly taken into account. The quantity that resides in WBWIPB on IC140M would also be accounted in some multiple location record, so the equivalent work-in-process multiple location records will be converted into potent units and added to the inventory.

(3) For the manufacturing warehouse, if any balance types are available for both planning and distribution (both Order Planning Flag and Distribution Flag = Y on the balance type), and sales orders are not considered for planning (the Sales Order Planning Flag on the Warehouse Description file is N), then the inventory quantity reserved for customer orders is subtracted from the total. For potency controlled parts, the inventory reserved quantity for customer and transfer order lines (WBRSOQ) is subtracted from the aforementioned total at Standard Potency (i.e. stock keeping, not potent, units) because not all of the warehouse balance reserved quantity (WBRSOQ) will necessarily also be reserved at the multiple location file level (WBRSOQ = LLRSV2 + LLRSV3 + LLRSV4, from IC130ML6).

(4) The following information is retrieved from the System Control file (CT100M). For every distribution warehouse associated with the plant, the Warehouse Description file is read to determine if balances at the warehouse are available for planning. If so, any distribution balance at the warehouse is added to the total in potent units.

For potency controlled JIT parts, the inventory netting flag is checked. If the flag is set to Yes (PMNETF = Y), the multiple location file quantities are processed and converted to potent units. If the flag is set to no (PMNETF = N), the multiple location file quantities are not processed, and the balance is set to zero.

c. Past due demand and past due supply are calculated using subroutine GTPSTA.

(1) Past Due Demand and Supply for JIT parts are retrieved from JT100ML3 (flow authorization) and JT120ML2 (flow requirements). Because multiple flow requirements might exist for the same day, the flow requirements are accumulated into an array. For consumed components, the difference between the quantity produced and the quantity scheduled is added to the past due demand. For produced components, the difference is added to past due supply.

(2) Past Due Demand for non-JIT parts is calculated in subroutine PSTACT. Demand records are retrieved from the Availability file (RP095ML3). This file includes customer orders, offset releases, transfer orders, and transfer requisitions with a promise date before today's date that have not been fully shipped. It also includes component requirements and flow requirements with a start date before today's date that have not been fully issued.

(a) A customer order is included only if the planning flag is Yes. This flag is set to Y if the order is sourced from manufacturing inventory or if it is sourced from distribution inventory at a manufacturing warehouse where the Sales Order Planning Flag = Yes. The quantities are converted from order policy units of measure to stockkeeping units of measure. The difference between the required quantity and the shipped quantity is added to the past due demand. For orders with backorder releases, the backordered quantity is subtracted from the total due. (The backordered quantity is subtracted because it will be included when the release is processed.)

(b) Transfer requisitions and transfer orders are only processed if the relief code is manufacturing. The difference between the required quantity and the quantity shipped is added to the past due demand. Requisitions and orders are ignored if they have a status of closed, canceled, covered, or planned.

(c) Offset releases are only processed if they are sourced from a manufacturing warehouse. The net quantity is added to the past due demand. (It is not necessary to omit releases in the past with a status of planned because Synchro closes them.)

(d) For component requirements, the difference between the required quantity and the issued quantity is added to the past due demand if the component is consumed. It is added to the past due supply if the component is produced. Component requirements are ignored if they have a status of closed, accounting closed, canceled, or planned.

(3) Past Due Supply is retrieved from the Availability file (RP095ML1) and includes manufacturing orders, purchase orders, purchase requisitions, transfer orders, and transfer requisitions with a due date before today's date that have not been fully received. All quantities are adjusted for scrap using the scrap factor. However, if the Shop Floor module is installed, the yield is calculated a second time using the actual scrap quantity; the lesser of the two yields is used. The difference between the calculated yield and the quantity received is added to the past due supply.

d. The quantity shipped (PASTAC) is accumulated for customer orders that were planned and are closed. This total is the total amount of the forecast that has already been consumed for the period. Remaining demand for the period is the difference between the forecast demand and the demand that has already been satisfied in previous weeks. This amount is used in netting demand for weeks that fall within the first forecast period.

7. Once the beginning inventory for the current week is calculated, the program calculates the beginning inventory for the requested week in subroutine STRINV, if the requested week is different than the current week. The basic calculation is as follows:

BEGINNING INVENTORY BALANCE FOR REQUESTED WEEK

BEGINNING INVENTORY BALANCE FOR CURRENT PERIOD

plus

FUTURE ACTIVITY UP TO REQUEST WEEK

This processing is done using the weekly and forecast data structures and number of weeks covered within each processing loop, as discussed in the Week Processing section (step 4) below.

a. Future Activity up to Request Week is calculated as a result of the expected demand for the period between the current week and the requested week, plus the estimated supply for the same period.

(1) Expected demand is calculated in weekly buckets and consists of the following:

(a) Net demand consists of demand for the part's planning parents, for the part from the Projected Demand file (MS150ML1), and from planned customer orders and transfer orders. The netting logic used is discussed in the Demand Netting section of step 4.

(b) Parent (dependent) demand consists of demand from master scheduled and requirements planning parents. Demand from master scheduling parents is retrieved from the Tentative Master Schedule file (MS160M). In this case, all demands from the Availability file are omitted to avoid double-counting. Demand from requirements planning parents is retrieved from the component requirements record on the Availability file (IC100MLA). Demand is also retrieved from the Synchro Part/Delivery Point file (GA120MLF).

(c) Unplanned demand consists of demand from unplanned customer orders, transfer requisitions, and unplanned transfer orders.

For JIT parts, the inventory netting flag is checked. If the flag is set to yes (PMNETF = Y), Warehouse Balance File quantities are processed, if the flag is set to no (PMNETF = N), the Warehouse Balance File quantities are ignored and the balance is set to be zero.

(2) The estimated supply is found from the existing master schedule for the part on the Tentative Master Schedule file (MS160M). This supply is also saved weekly.

b. Beginning Inventory for the requested week is calculated weekly from the current week to the requested week.

BEGINNING INVENTORY
(week n+1)

PROJECTED INVENTORY (week n)

PROJECTED INVENTORY (week n)	=	BEGINNING INVENTORY (week n)	minus	TOTAL DEMAND (week n)	minus	DEMAND ACTIVITY (week n)
			plus	SUPPLY ACTIVITY (week n)	plus	MS QUANTITY (week n)
			plus	BY-PRODUCT ACTIVITY (week n)

This calculation is performed week by week until the requested week.

c. Once the requested week's beginning inventory has been calculated, the weekly data structure is reformatted so that the requested week is at the second occurrence of the data structure. The first occurrence contains the beginning inventory.

C. Week Processing

1. A data structure is built to contain records holding data for display on the screen, plus any additional weeks required for calculation purposes (subroutine CDMTDT).

2. Once the schedule has been calculated, records containing weekly data are formatted and written to the program's internal workfile, the Tentative Master Schedule Generation Workfile (MS170AP).

3. The Tentative Master Schedule file (MS160M) is then updated using the data in the Tentative Master Schedule Generation Workfile (MS170AP). The same update logic used in the Tentative Master Schedule Maintenance - Asynchronous program (MS165E) is used for the update process.

4. The following processing is performed to generate the tentative schedule:

The weekly data structure and the forecast data structure are filled with as many weeks as necessary to calculate all information through the requested end date (horizon date). This is calculated as follows:

(a) The dates in the weekly data structure are retrieved from the calendar date array. The number of working days in each week is calculated. This number will be used later to prorate the forecast.

(b) The program determines the number of weeks required on the data structure to display an accurate subfile page. The data structure will require at least eight weeks, so the subfile can display eight lines. In addition:

(1) If the Order Policy is fixed time, the program must be able to schedule future weeks beyond the last forecast period. Therefore, additional weeks must be included in the weekly data structure.

(2) If the Part Master file specifies that target inventory is required for the part (in terms of a number of weeks supply), additional future weeks are required to project the inventory needs.

(3) Full forecast periods must be covered, because tentative schedule and projected demand are smoothed over a forecast period.

(c) Forecast held in the Projected Demand file (MS150ML1) is retrieved for the requested part and all of the part's planning parents. The forecast is accumulated for each period in the forecast data structure.

5. The demand quantities are calculated. The part availability is determined in subroutine DETAVB.

(a) Flow authorizations and flow requirements are retrieved from JT100L10. The FR quantities for each day are accumulated into an array and added to current schedule quantities.

(b) If Synchro is installed, and the current period is being processed, the in-process shipments are read from GA120MLF and accumulated. The total amount will be added to actual demand.

(c) Other orders are retrieved from the Availability file (IC100L19) and accumulated in subroutine PRCFUT. Orders are accumulated for each week as follows:

(1) Actual Demand. Actual demand includes planned customer orders and Synchro offset releases. The customer orders and offset releases are retrieved from IC100L19.

· An offset release is included only if it is sourced from a manufacturing company/warehouse and is not closed.

· A customer order is included only if the planning flag for the order is Y. This flag is set to Y for orders that are sourced from manufacturing inventory or that are sourced from distribution inventory at a manufacturing warehouse where the Sales Order Planning Flag = Yes.

For a customer order, the program uses either the shipped quantity or the reserved quantity, whichever is greater. Any backordered quantity is subtracted from the total. For an offset release, the net quantity is used. All quantities are converted into stockkeeping units of measure.

(2) Unplanned Demand: actual unplanned customer orders and demand transfer orders/requisitions.

Note that a customer order is included only if the planning flag for the order is Y. This flag is set to Y for orders that are sourced from manufacturing inventory or that are sourced from distribution inventory at a manufacturing warehouse where the Sales Order Planning Flag = Yes.

Also note that the shipped quantity is added to the unplanned quantity for orders that are closed or fully shipped.

(3) Demand Activity: customer shipments, component issues, flow issues, transfer orders, transfer requisitions, and purchase order requisitions. Transfer orders and requisitions are only included if they have a manufacturing relief code.

(4) Current Schedule: purchase orders, manufacturing orders, transfer orders, transfer requisitions, and flow authorizations.

The scheduled quantities are reduced by the scrap percentage. Purchase orders are not considered if they are for direct shipments or phantom orders or if they are closed. If Shop Floor is not installed, the scrap factor is used to calculate the yield. If Shop Floor is installed, yield is calculated a second time using the actual scrap is used for current manufacturing orders; the program then uses the lesser of the two calculations. For future and current periods, the quantity on the flow authorization is consumed on the first day. For past flow authorizations, the quantity is consumed using the daily supply quantity for previous days.

(5) Supply Activity: purchase order, manufacturing order, and flow receipts

(6) Parent Demand: demand from the part's requirements planning and service parents. Component requirements, demand transfer requisitions, and demand transfer orders are only processed if the parent part (as identified on the manufacturing order) is not a master scheduled item. (If the parent is master scheduled, the demand will be retrieved from the Tentative Master Schedule file.) If the status is closed or accounting closed, the issued quantity is considered as the parent demand. Otherwise, the program uses the greater or the issued or required quantity.

Note that this is true if the part has a usage code of consumed. For a usage code of produced, the demand is considered by-product activity.

6. The Dependent Demand is determined in subroutine DETPDM: Demand for the part from master scheduled parents is retrieved from the Tentative Master Schedule file (MS160ML1) and saved in the weekly data structure. For JIT parents, demand is retrieved from MS160ML3, the daily tentative schedule is calculated (MSQTY times Qty Per), and demand is accumulated by week. The JIT calculations are performed in subroutine PRJITP. The required quantity is increased to account for the parent scrap factor.

7. Projected Demand consists of projected demand for the part plus any planning parent demand. All demand for one period is retrieved and saved in the projected demand data structure, and the first week in a period is saved on the weekly data structure. The projected demand per day rate is calculated as follows (in subroutine COMFOR):

RATE (per day)

PROJECTED DEMAND FOR PERIOD
NUMBER OF WORKING DAYS IN PERIOD

8. Demand Netting is performed in subroutine NETDEM. This is a method of examining the Projected Demand for the period and Actual Demand for a week, and ending up with a Net Demand for the week.

(1) If the requested planning period option is weekly, Actual Demand on the weekly data structure is compared to Projected Demand on the projected demand data structure. The larger of the two figures is used as Net Demand if the week falls after the actual demand time fence, otherwise the actual demand is used.

(2) If the requested planning period option is monthly or by planning periods, a more complicated netting process is used. The Projected Demand is allocated over the number of weeks in the month or period, and for each week the Actual Demand is compared to the remaining Projected Demand allocated to that week, and the larger of the two is used as Net Demand, if the week falls after the actual demand time fence, otherwise the actual demand is used. This netting logic is explained in more detail in Exhibit 160-A.

(3) For partial week processing (when a week covers the end of one period and the beginning of another), the week is divided into two fractions, one in each period. A fraction of the full week's demand for the period is then allocated to each section. The total forecast for the week is then calculated from the sum of these two sections. This logic is explained in more detail in Exhibit 160-B.

(4) Once the Net Demand has been calculated, the Total Demand is calculated as follows:

TOTAL DEMAND	=	NET DEMAND	plus	UNPLANNED DEMAND	plus	PARENT DEMAND	plus	EDI DEMAND
TOTAL NET DEMAND	=	TOTAL DEMAND	minus	DEMAND ACTIVITY

9. The Master Schedule is processed. The user has two options: to calculate a new master schedule, or to display and modify an existing master schedule. (subroutine DETMSQ)

a. Calculate a new Master Schedule (subroutine CALCMS)

(1) The master schedule is a list of amounts that should be made each week to satisfy demand, as well as any target inventory or safety stock policies. The master scheduling process attempts to spread the master schedule evenly across the weeks in a planning period, with the target inventory or safety stock being available at the end of the period.

TOTAL DEMAND FOR PERIOD	plus	TARGET INVENTORY	minus	BEGINNING INVENTORY	minus	BY-PRODUCT SUPPLY	=	REQUIREMENT FOR PERIOD
TOTAL DEMAND FOR PERIOD	=	DEMAND ACTIVITY	minus	SUPPLY ACTIVITY

If the number of weeks specified by the Master Scheduling planning window have not passed:

REQUIREMENT FOR PERIOD
NUMBER OF DAYS IN PERIOD

times

DAYS IN WEEK

PROPOSED MASTER SCHEDULE QUANTITY PER WEEK

Otherwise, the entire tentative schedule for the period is placed into the first week.

The detailed logic used is illustrated in Exhibit 160-C at the end of the program description for MS160E.

(2) Once the master schedule has been calculated, the projected inventory is recalculated until it is positive:

PROJECTED INVENTORY

BEGINNING INVENTORY

plus

MASTER SCHEDULE QUANTITY

minus

SUPPLY ACTIVITY

minus

TOTAL DEMAND

plus

DEMAND ACTIVITY

b. Planned manufacturing orders, purchase requisitions, transfer requisitions, or flow requirements are created to cover the requirement for the period.

For parts with a fixed batch size (fixed quantity, zero increment), the master schedule quantity is calculated using multiples of the order policy quantity.

For parts with a fixed time order policy, requirements are accumulated from the specified number of future weeks. The master schedule quantity is set to the total requirement for those periods.

For parts with a fixed quantity and increment, the master schedule quantity is set to the fixed quantity. If the fixed quantity is not enough to cover the requirement, the master schedule quantity is increased by the increment value until it is enough to cover the requirement.

10. The Tentative Master Schedule file (MS160M) is updated.

a. The actual update of the Tentative Master Schedule file (MS160M) is not performed until the Tentative Master Schedule Workfile (MS170AP) contains a record for every week in the generation period requested for the part.

b. The Tentative Master Schedule file (MS160M) is updated with records from the workfile (MS170AP) using matching logic. Each record in the workfile is compared to the Tentative Master Schedule file (MS160M). If the records do not match exactly, the appropriate master file record is updated, added, or deleted.

c. The Tentative Master Schedule Audit Trail (MS160BP) and the Tentative Master Schedule Transaction Register (MS160CP) are written during the updating process.

d. If requested, the Tentative Master Schedule report (MS170B) is printed.

Menu

Tentative Master Schedule Generation - Batch - Calculations

MS170E Program Menu