Master Schedule Rollover - Calculations

MS180E

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. A parameter list is set up to receive parameters passed from another program.

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

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

5. The company name is retrieved from the company name record (COMNAM) on the System Control file (CT100M).

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

a. The date format (category 049) is retrieved. If this record is not found, the date format defaults to MMDDYY, a message is sent to the system operator, and processing continues.

b. The order quantity decimal position is retrieved from the quantity field sizes record (category 446). If this record is not found, a message is sent to the system operator and the program aborts.

c. The Capacity Planning and Shop Floor Control installed flags are retrieved from the applications installed record (category 012) to determine whether the two applications are installed.

If the Capacity Planning module is installed, when manufacturing orders are changed or deleted their Capacity Planning labor requirements will also be changed or deleted. If the Shop Floor Control application is installed, the actual scrap on a manufacturing order may be used for converting yield to order units rather than the scrap factor.

d. The part status codes, decodes, and planning flags are retrieved from Reference File category D88. All part status data and corresponding information is loaded into corresponding arrays.

7. The Master Schedule Rollover Request file (MS330AP) is checked to determine if it is empty. If so, a warning message is written and processing ends.

B. Mainline

1. The Rollover Request file (MS330AP) is read sequentially until end of file.

2. If the plant is new, load in all plant relevant data.

a. The manufacturing company and warehouse codes are retrieved from the Warehouse Description file (IC170ML2).

b. The next manufacturing order and requisition numbers are retrieved from the starting order numbers record (category 465) of the Reference file (REFERP). If no record is found, starting numbers of M000001 and R000001 are used, a message is sent to the system operator, and processing continues.

c. If the calendar code for the plant has been previously loaded, set the occurrence of the calendar data structure (MPXCAL). Otherwise, perform the following:

(1) The last date in the calendar file is retrieved from the calendar file record (category C14) or the Reference file (REFERP).

(2) The arrays containing calendar dates (ACAL) and shop dates (ASHP) are loaded. These arrays are used for consulting calendar dates to shop dates and vice versa.

(a) The starting date for each array is 50 shop days before the system date. The ending date of each array is 149 shop days after the system date.

(b) The logical Shop Calendar Date file (CT140ML) is read sequentially to retrieve the information for the arrays.

(3) The current week start date is determined from the logical Week Start Date file (CT140ML1). This will be used for determining the Rollover Request Start Date.

(4) The next week start date is determined from the Logical Work Start Date file (CT140ML1). This will be used to determine the first week eligible for the rollover.

3. If the output queue is new, close the current report file if one exists. Assign the new output queue and open a new report file.

4. The transaction sequence number (CZTRSQ) is determined. If the transaction sequence number exceeds 999, a rollover request error is printed on the Action report (MS180) and processing ends.

5. The planning mode request option (CRPLMD) is determined. It can be selected in three modes, all three modes will be plant specific.

a. Rollover of all master scheduled parts (option = 1)

b. Rollover of all parts for one planner (option = 2)

c. Rollover of one part (option = 3)

6. The initial rollover period start date is determined:

a. The Week Start Date file (CT140ML1) is read to position the date to a week start date.

b. If the rollover week start date is less than the current week start date, the next week start date is used as default.

7. The initial rollover horizon date is determined.

a. The Week Start Date file (CT140ML1) is read to position this date to a week start date.

b. If this week start date is blank or greater than the last date for the calendar code, the last date for the calendar code is used as a default.

c. If this week start date is less than or equal to the start date, a message is output and processing stops.

8. If the print option was selected, the limiting dates for printing the reports are determined.

a. The print start date is determined, as in step 4 above.

b. The print horizon date is determined according to the date limit option that was selected by the user.

(1) For option 1 (print all periods), the print horizon date is the same as that determined in step 5 above.

(2) For option 2 (print to the last action message) and 3 (print to the last message), no horizon date is determined, since this will be determined during processing.

(3) For option 4 (print periods between entered dates), the user-entered horizon date is used to determine the print horizon date, as in step 5 above.

9. A priming read is performed on the Part Master file.

a. If the rollover request is for full rollover, the logical Part Master file (DE100L13) is read sequentially.

b. If the rollover request is for rollover for a particular plant/planner, the logical Part Master file (DE100L13) is read keyed by planner (analyst) code.

c. If the rollover request is for rollover by part, the Part Master file (DE100M) is read.

(1) The part's status is checked. If the part is not active, processing for the request is terminated.

10. The part status (IZACD) and part status planning flag (RD88PL) are validated.

a. The part status array is searched for the current part status.

(1) If the part status is not found in the array, the part is written to the MS Part Status Exception Report file (RP100AP8) for processing at the end of the program, and the part is bypassed by the conversation.

(2) The part status found in the array is used to find the corresponding planning flag in the planning flag array.

(i) If the planning flag is N, the part is written to the MS Part Status Exception Report file and bypassed by the conversation.

(ii) If the planning flag is Y, the part is processed by the conversation.

11. The Master Schedule Generation Bypass Flag (PMMSFL), which can be set on by the user in the online Tentative Master Schedule Generation program to bypass the batch Tentative Master Schedule Generation program, is set off.

12. The lot size for the part is determined to prevent overflow later in processing. For a manufacturing part, the lot size is the largest possible number for an order (all nines).

13. The JIT Master Schedule Rollover program (MS185E) is called under one of the following conditions:

a. The part has a part type of transfer (MTYPN=B).

b. The part has a production type of JIT (PMPDTP=2), a part type or manufactured (MTYPN=2) or build-through (MTYPN=6), and a make/buy flag of Make.

Control is passed back to the Master Schedule Rollover (MS180E) when the request is completed, a part is encountered which does not have the above characteristics, a processing error occurs, or if the part does not have any tentative schedule records. If there is no tentative schedule for the part, an error message is printed on the Action report (MS180) and processing for the request terminates.

14. The part has a Production Type of MRPII (PMPDTP=1) or a Part Type of Purchased (MTYPN=1) or Raw Material (MTYPN=3) or a Production of JIT (PMPDTP=2) and a make/buy flag of Buy.

a. The Tentative Master Schedule file (MS160M) is prime read. If there is no tentative schedule for the part, an error message is printed on the Action report (MS180) and processing for the request terminates. If current or future flow authorizations exist for the part, the FA reorganization program (DE080E) is called. Past flow authorizations are closed, in-process FAs are broken, and future FAs are deleted.

b. The tentative master schedule quantities from the Tentative Master Schedule file (MS160M) are accumulated on a weekly basis for the period between the Rollover Request Start Date and Request Horizon Date and written to the MS Action Report Schedule file (MS180AP2).

c. The tentative master schedule, which is stored in yield units, is converted to order units by inflating by the scrap factor.

d. The current master schedule quantities (from both purchase orders and manufacturing orders) from the Availability file (IC100MLA) between the Rollover Request Start Date and Request Horizon Date are accumulated on a weekly basis.

(1) For closed or Inventory Accounting closed manufacturing orders, the quantity received is used. If the order is not closed, the order quantity is used.

(2) Only purchase orders for the manufacturing company/warehouse that are not direct ship and not phantom orders are accumulated. If closed, the quantity received is used. If not closed, the release quantity is used.

(3) Purchase requisitions are accumulated if they are not closed or canceled, and the Uncovered Quantity is greater than zero.

(4) For transfer orders that are fully shipped, the quantity received is used. If the order is not fully shipped, the quantity orders is used.

(5) Only transfer requisitions that are not closed, canceled or covered are accumulated.

The weekly planned orders (WKQTY1) are accumulated separately from the weekly order quantities (WKQTY), which includes open and firm orders.

e. The rollover is analyzed and the relation between the tentative schedule accumulated weekly quantity (CSOQTY) and the current schedule accumulated weekly quantity (WKQTY and WKQTY1) is determined. Action is taken as follows:

Tentative Schedule = Current Schedule	No action.
Tentative Schedule + Current Schedule
No firm/open orders/requisitions;	Add planned.
No planned orders/requisitions
No firm/open orders/requisitions;	Increase planned.
Planned orders/requisitions
Firm or open orders/requisitions;	"Increase" action
No planned orders/requisitions	message.
Firm or open orders/requisitions;	Increase planned.
Planned orders/requisitions
Tentative Schedule - Current Schedule
No firm/open orders/requisitions;	Abort.
No planned orders/requisitions
No firm/open orders/requisitions;	Decrease planned.
Planned orders/requisitions	Delete planned orders if required.
Firm or open orders/requisitions;	"Decrease" action
No planned orders/requisitions	message.
Firm or open orders/requisitions;	Decrease planned.
Planned orders/requisitions	Delete planned orders if required.

f. The output from the rollover processing is as follows:

(1) If an "increase" or "decrease" message is required for the period, the increase or decrease quantity and the period start date are written to the MS Action Report Message file (MS180AP3).

(2) If a planned supply record is to be added, deleted, increased or decreased, planned order maintenance is initiated and a message is written to the MS Action Report Planned Order Message file (MS180AP4). See Section "D. Planned Supply Record Maintenance" for a detailed description of this processing.

g. The remaining tentative master schedule quantities beyond the rollover request horizon date are accumulated for printing at the end of the Action report. This quantity (CSOREQ) is inflated by the scrap factor.

h. The remaining current schedule quantities beyond the rollover request horizon date are also accumulated and printed at the end of the Action report.

i. The details for the part are formatted and the MS Action Report Header file (MS180AP1) is written.

C. Windup

1. The next Manufacturing Order, Transfer and Purchase Requisition numbers are updated on the order starting numbers record (category 465) on the Reference file (REFERP).

D. Planned Supply Record Maintenance

1. Add a Planned Order.

a. Since the tentative master schedule quantity is a larger field than the order quantity, several orders may have to be planned to cover the requirement. Therefore, planned manufacturing orders, Purchase and Transfer Requisitions are generated until the order quantity satisfies the requirement.

b. The Order Start Date is determined by the part's Leadtime Code.

(1) If the part has a fixed lead time, the Fixed Leadtime Days (SVLTPU) is subtracted from the shop date of the Order Due Date. The Order Start Date is the calendar equivalent of this amount, which is retrieved from the logical Calendar Date file (CT140ML). If no equivalent date is found, the Order Start Date is set to the first date on the logical Calendar file.

(2) If the part has a variable lead time, the Order Quantity (REMQTY) is multiplied by the Run Days Per Piece (SVLTRH), giving the total run days needed for the order. This amount is incremented by the Setup Days (SVLTSU) and Transit Days (SVLTQM). The result is always rounded up.

This amount is then subtracted from the shop date of the Order Due Date. The Order Start Date is the calendar date equivalent of this final amount, which is retrieved from the logical Calendar Date file. If no equivalent date is found, the Order Start Date is set to the first date on the logical Calendar Date file.

c. The master file fields are formatted.

(1) The Planned Order Number is determined by linking the Order Prefix (CMOPRE - manufacturing; CRQPRE - requisition) with the Order Number Suffix (CMOORD - manufacturing; CRQORO - requisition).

(2) If the resulting Planned Order Number already exists on the master file, the suffix is increased by one, then retried.

(3) Two prefixes, Y and Z, are reserved in case all of the original prefixes have been used. There are approximately two million numbers reserved if the Y and Z prefixes are not in use.

d. The Part Type (SVTYPN) is used to determine whether the planned order will be purchased, manufactured or transferred. If it is a raw material or purchased part, a purchase order is added. If it is a transfer part, a transfer requisition is added. If it is a manufactured part, a manufacturing order is added.

e. If a planned purchase requisition is to be added, the Requisition File fields are formatted. The part purchase order message code on the Part Master file (DE100M) is used to retrieve the part purchase order message from the Reference File (category 431). If the part purchase order message code exists on the Reference file, the part purchase order message is used to format the custom message field on the requisition record. The default requisition priority code is retrieved from the Purchasing System Defaults record (category 491). If the record is not found, the default requisition priority code is set to blanks. The estimated unit cost is calculated.

ESTIMATED COST

UNIT COST

times

REQUISITION QUANTITY

The Unit Cost is calculated as follows:

(1) If the company/warehouse is the manufacturing company/warehouse and the Product Costing application is installed, the Unit Cost equals the sum of the Standard Total material, Labor, and Overhead Costs from the Part Master file.

(2) If the company/warehouse is the manufacturing company/warehouse and the Product Costing application is not installed, the Unit Cost equals the sum of the Standard This-Level Material, Labor and Overhead Costs from the Part Master file.

(3) If the company/warehouse is a distribution company/warehouse with moving average costing or the part is non-standard, the Unit Cost is equal to the Moving Average Unit Cost from the Warehouse Balance file.

(4) If the company/warehouse is a distribution company/warehouse with standard costing and the part is not non-standard, the Unit Cost is equal to the Standard Unit Cost from the Warehouse Balance file.

(5) If the company/warehouse is a distribution company/warehouse but no warehouse balance record exists for the part, the Unit Cost is calculated using the Part Master File cost fields as in (1) and (2) above.

f. If a planned transfer requisition is to be added, the Transfer Requisition File fields are formatted. The default transfer requisition priority code is retrieved from the Transfer Control Default Record (category D05). If the record is not found, the default requisition priority code is set to blanks.

g. If the planned supply record is a manufacturing order, its component requirements must be added.

(1) The first time a planned order is added for a part, the multiple occurrence data structure of the Requirements Planning Product Structure Data Structure (RPPSDS) is loaded with the first level of components in the part's bill of material. Planning parts, non-standard parts, and reference structures are omitted (except for reference parts). The Part Master file (DE100M) is accessed for each product structure read into the data structure. The information in the data structure is then used to format the component requirement records.

The data structure itself is used to reduce the retrieval time of product structure records for subsequent additions of planned order component requirements. From this point, the Product Structure file (DE120M) is accessed only for build-thru parts, or if the first level of the part's bill of material is larger than the size of the data structure.

(2) If the part does not have a bill of material, a warning message is formatted and written to the Inventory Control Transaction Error file (IC505AP). A transaction register record is formatted and written to the Manufacturing Order Transaction Register file (IC100CP1). No component requirement records are written.

(3) If the part has a bill of material, each component is checked for effectivity. If no components are effective, a warning message is formatted and written to the Inventory Control Transaction Error file (IC505AP). A transaction register record is formatted and written to the Manufacturing Order Transaction Register file (IC100CP1). Component requirement records are not written for non-effective components.

(4) If a component on the part's bill of material is a build-thru part (MTYPN = 6), that component's bill of material is used. Only non-build-thru and non-planning parts, and non-reference product structures are used as valid components. If a build-thru part does not have a valid component, a warning message is formatted and written to the Inventory Control Transaction Error file (IC505AP). A transaction register record is formatted and written to the Manufacturing Order Transaction Register (IC100CP1).

(5) The Required Quantity (MZRQTY) of a component is calculated by multiplying the Order Quantity (REMQTY) by the Quantity of Component Per Parent (MZUQTY). Components of a build-thru part have their required quantities calculated by multiplying the Required Quantity of the build-thru part by the Quantity of Component Per Parent (build-thru).

Example:

Product Structure

Quantity of Component Per Parent

Build-thru

A to B = 2.0

A to C = 3.0

C to D = 4.0

An order quantity of 500 will produce a component requirement B of 1000 (500 x 2.0) and a component requirement D of 6000 ((500 x 3.0) x 4.0).

(6) If overflow occurs while calculating the Required Quantity, the component requirement is not added. A critical error message is formatted and written to the Inventory Control Transaction Error file (IC505AP). A report record for the component is written to the Component Requirements Transaction Register (IC100CP2).

(7) The Quantity of Component Per Parent field for the components of build-thru parts is computed by dividing the Required Quantity of the build-thru component by the Order Quantity. Using the previous example, the Quantity of Component Per Parent for component requirement D is 12.0 (6000 divided by 500), that is to say, A to D is 12.0.

(8) The record is formatted for output to the Component Requirements file (IC120M).

(9) If the component requirement already exists on the file, a duplicate add situation exists.

(a) The existing record on the Component Requirements file (IC120M) is retrieved.

(b) The Required Quantities of the duplicate components are added. If overflow occurs, the component requirement record is not updated, a critical error message is formatted and written to the Inventory Control Transaction Error file (IC505AP), and a report record for the component is written to the Component Requirements Transaction Register (IC100CP2).

(i) The total Required Quantity is divided by the Order Quantity to obtain the Average Quantity Per Parent.

(ii) The Decimal Control Code (MZDCC) of each component requirement is checked. This code determines the number of digits to the right of the decimal point that will be included in the seven-digit Quantity of Component Per Parent field. The greater of the two codes is used if this will not cause any significant digits to be truncated from the calculated quantity in step (i). Otherwise, the lesser of the two codes is used.

(iii) The original component requirement record is updated with the new Required Quantity, Decimal Control Code, Quantity of Component Per Parent, and Component Scrap Factor.

(iv) The Decimal Control Code (MZDCC) of each component requirement is checked. This code determines the number of digits to the right of the decimal point that will be included in the seven-digit Quantity of Component Per Parent field. The greater of the two codes is used if this will not cause any significant digits to be truncated from the calculated quantity in step (i). Otherwise, the lesser of the two codes is used.

(v) The original component requirement record is updated with the new Required Quantity, Decimal Control Code, Quantity of Component Per Parent, and Component Scrap Factor.

(d) If an overflow occurs in any of the above calculations, the error processing outlined in step (b) is initiated.

(10)The record for the added component is retrieved from the Part Master file (DE100M) and updated. The net change flag (PMNCFL) is set to 1 (re-analyze) for a non-master scheduled component so that the record will be subsequently processed by the Requirements Planning Generation program (RP100E).

2. Change a Planned Supply Record.

a. The new Order Quantity (REMQTY) is determined as in the processing for adding a planned order (step 1.a.).

b. If the changed planned supply record is a purchase requisition, the purchase requisition record is formatted to reflect the changed information.

c. If the changed planned transfer record is a transfer requisition, the transfer requisition record is formatted to reflect the changed information.

d. If the changed planned supply record is a manufacturing order, its component requirements must be adjusted.

(1) If the Order Quantity changes, each component requirement must be retrieved and updated with a new Required Quantity (MZRQTY). The Required Quantity is determined by multiplying the Order Quantity (REMQTY) by the Quantity of Component Per Parent (MZUQTY).

(2) If overflow occurs in the above calculations, the component requirement is not updated and a record is written to the Inventory Control Transaction Error file (IC505AP). A report record for the component is written to the Component Requirements Transaction Register (IC100CP2).

(3) The part master record for each component requirement is retrieved and updated. The net change flag (PMNCFL) for each record is set to 1 (re-analyze) for non-master scheduled components so that the components will be subsequently processed by the Requirements Planning Generation program (RP100E).

3. Delete a Planned Supply Record.

a. If the planned supply record is a purchase requisition, it is deleted.

b. If the planned supply record is a manufacturing order, the manufacturing order and its component requirements are deleted.

c. If the planned supply record is a transfer requisition, it is deleted.

Menu

Master Schedule Rollover - Calculations

MS180E Program Menu