Requirements Planning Generation - Calculations

RP100E

A. Housekeeping

1. Work fields are initialized.

2. The company name is retrieved from the Company Name Record (COMNAM) on the System Control file (CT100M) for output on the System Error report (CT010X). If it is not found, a message is sent to the system operator, a message is moved to the company name print field, and processing continues.

3. Additional information is retrieved from the following control records on the System Control file (CT100M). If any of this information is not found, the program aborts.

Control Record	Information Retrieved
Inventory Control (ICCTL1)	Lot control and potency control environment flags (LOTOPT, POTOPT).
Inventory Control (ICCTL2)	Order Planning Codes (MOPAC2, MOPAC3, MOPAC4) Distribution codes (DSTAC2, DSTAC3, DSTAC4, for distribution warehouses available for planning).

4. 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 applications installed records (categories 011 and 012) are retrieved. The Shop Floor and Synchro installation flags are checked, and an indicator is set appropriately. The Repetitive Supply flag is checked. In addition, if the Future Three module is installed, Reference File category D26 (Future Three Interface Defaults) is retrieved to use the four EDI demand types in analyzing forecast. All EDI forecast is planned for, regardless of the RP actual demand window from Reference File category D85.

c. The quantity field sizes record (category 446) is retrieved. If this record is not found, the program terminates abnormally.

d. The transfer control system defaults record (category D05) is retrieved. If this record is not found, the program terminates abnormally.

e. 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.

f. File access codes are retrieved from Reference File category 015. VAT types are retrieved from Reference File category 024. Tax information is retrieved from Reference File category 230 and loaded in an array along with the rate that is effective at the RP generation date. Requirements Planning defaults are retrieved from Reference File category D85 (actual demand window and family to exclude). The Manual Priority code is retrieved from Reference File category 491.

5. The priming read is performed on the Logical Part Master file (DE100L12). This will provide the file information needed to enter into the processing loop which will control the processing of all parts to be processed.

6. Read the Requirements Planning Generation Request file (RP110AP) until all of the records have been processed. The program terminates abnormally if no request records exist on this file. All valid requests will be stored on the plant parameters data structure (RPPLDS).

7. The Requirements Planning Selection Flag (CZSBMR) is checked. If it is set to X then the record is further processed; otherwise, the record is skipped. The request file is read until all records have been processed.

a. The Front End program Flag (CZFREN) is checked. If it is set to N, the System Error report (CT010X) is printed, and windup processing is performed. A parameter is passed to halt the off-line processing normal end of job.

b. Retrieve the calendar code that is associated with the requested plant from the Warehouse Description file (IC170ML2). The program terminates abnormally if the record is not found on this file. All the calendar code specific information will be stored in the calendar code data structure (MPXCAL).

c. The Tax Environment is retrieved from Reference File category 132 (keyed by company/location) and stored in an array.

d. The arrays containing Calendar Dates (ACAL) and Shop Dates (ASHP) are loaded if this calendar code has not already been processed. These arrays are used for converting calendar dates to shop dates and shop dates to calendar dates for calculations.

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

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

e. The Order Starting Numbers Record (category 465) is retrieved to obtain the starting planned manufacturing order, purchase requisition, and transfer requisition prefixes and numbers. The program terminates abnormally if no records are found. This is done for both actual and simulated RP run modes, because two records per plant exist for Reference File category 465.

f. The RP planning parameters are retrieved from Reference File category D84 (Planned Order Deletion of MOs, Transfer Requisitions, and PO Requisitions). Also, the Replan Past FA flag is retrieved for replanning past-due flow authorizations within the RP firm horizon.

g. The Firm Horizon flag by plant is retrieved from Reference File category G52 and is stored in an array.

h. The actual demand horizon is converted to a calendar date.

i. The planning horizon date is calculated as follows:

RP Run Shop Date + Generation Days = Planning Horizon Shop Date

The RP Generation Days field (CZHZDY) is used to determine the RP stop date (RPSTOP) after which supply and demand will no longer be analyzed and netted. Supply and demand will only be totaled and summarized in the Trailer Supply (TRLSUP) and Demand (TRLREQ) fields on the RP planning action part header record (RP100AP1).

The planning horizon date is retrieved from the calendar.

B. Mainline

The program processing loop will perform the processing described below for each part selected.

1. 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 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.

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

(b) If the part belongs to one of the five families to exclude, the Planning flag is set to N.

(c) If the RP run mode is set to simulation, and the part’s By-Pass flag (PMMSFL) is on, then the Planning flag is set to N.

(d) If the part is daily master scheduled, requirements planning, or service, and the Select flag from RP110AP for the part is N, then the Planning flag is set to N.

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

2. The part is a job-controlled part (PMJCFL = Y).

a. The logical Part Master file is unlocked.

b. The Requirements Planning Generation for Job-Controlled Parts program (RP106E) is called. RP106E will continue processing parts until a part is retrieved that is not job controlled.

c. The pointer for the Part Master file is positioned after the last record processed by RP106E.

3. The part’s production type is equal to JIT (PMPDTP=2), the part type is manufactured (MTYPN=2) or build-through (MTYPN=6), and the make/buy flag is Make.

a. The JIT Requirements Planning Generation program (RP105E) is called. RP105E will continue processing parts until a part is retrieved which does not have a production type of JIT (PMPDTP=1), or until a purchased part (MTYPN=1), raw material part (MTYPN=3), transfer part (MTYPN=8), or by-product (MTYPN=8) is retrieved.

b. Position the Part Master file pointer after the last record processed by RP105E.

4. Retrieve the appropriate occurrence of plant specific planning parameters from the plant data structure (RPPLDS) if the part’s plant is not equal to the saved plant code.

a. Set the occurrence in the plant data structure (RPPLDS) if the plant code/RP run mode combination is found in the requested plant array. The program terminates abnormally if the part’s plant code has not been requested.

b. Set the occurrence in the calendar code data structure (MPXCAL) if the requested plant’s calendar code is not equal to the saved calendar code. The program terminates abnormally if the plant’s calendar code is not found in the calendar code array.

5 If the Part Master RP Firm Horizon Days field (SUFHDY) is non-zero, then the RP firm horizon date defined at the plant level (CZFMDT) is overridden by adding the part’s RP firm horizon days to the current RP run date (RPRNDT) in shop calendar days, and then recalculating the appropriate new calendar firm horizon date.

6. If the Repetitive Supply module is installed and the part is eligible to be processed by Repetitive Supply (the part is non-job controlled; has a part type of 1 or 3, or has a Make/Buy flag of 1; and has a PO Generation flag set to anything other than Yes or No), then RP processes the following steps (only if Requirements Planning is running in actual mode).

a. If the firm horizon is handled by RS (Reference File category G52), the firm horizon equals the last firm horizon stored in the Part Master plus the dock-to-stock leadtime plus 2. If it less than the RP generation request, it is set to the firm horizon of the request. If the firm horizon is not handled by Repetitive Supply, the firm horizon equals the firm horizon of the RP generation request.

b. A record is written in the RS Selected Parts file (RS100AP) so that the part will be processed by Repetitive Supply after the RP generation programs.

c. All requisitions and comments that are associated with repetitive supply selected parts are deleted, regardless of status.

d. PO blanket order lines (issued from manufacturing sites) are retrieved for repetitive supply selected parts. The line’s initial total ordered quantity is saved. For each order line:

(1) The releases are deleted beyond the new firm horizon. If the firm horizon is handled by Repetitive Supply, the firm horizon is:

Last Firm Horizon (from the Part Master file) plus Dock-to-Stock Leadtime plus 1

If the firm horizon is not handled by Repetitive Supply, the firm horizon is the End Firm Horizon that was entered on the RP generation request.

(2) The ordered quantity and the received quantity in PU units and SKU units are summed. One is added to the number of deleted releases.

(3) The remaining to receive of deleted releases is calculated in terms of both PU units and SKU units.

(4) The on-order quantity of the Warehouse Balance is updated as follows:

On-Order Quantity (of the Warehouse Balance)

minus

Remaining to Receive in SKU of Deleted Releases

equals

New On-Order Quantity (of the Warehouse Balance)

The Warehouse Balance update counter is incremented by one. The date of the last maintenance is set to the RP run date. The last program that updates the Warehouse Balance is set to RP100E.

e. If the number of releases that are deleted is greater than zero, the following fields of the PO line are updated as follows:

New total ordered quantity equals old total ordered quantity minus ordered quantity of deleted releases.

New current ordered quantity equals old current ordered quantity minus ordered quantity of deleted releases.

The over receipt quantity of deleted releases is assigned to the closes release within the firm horizon, if one exists. Otherwise, the over receipt quantity is subtracted from the current received quantity in SKU and PU of the line and the total received quantity.

The date of the last maintenance is set to the RP run date.

The time of the last maintenance is set to the time of the update.

The last program that updates the line is set to RP100E.

The new number of active PO releases equals the old number of active PO releases minus the number of deleted PO releases.

The greatest number of releases is retrieved by reading the last release. The total number of releases on the order line is updated with the greatest number of releases.

f. If the number of releases deleted is greater than zero, the PO header is updated as follows:

1. The change in the PO line quantity is calculated and the associated price change is determined. This amount is added/subtracted from the total purchase amount.

2. Tax is then determined. To properly calculate the tax amount at the current tax rate, the “old” tax is determined and subtracted from the tax amount. The “new” tax is calculated and added to the tax amount. In a VAT or GST tax environment, the old VAT/GST rate is determined by the last maintenance date on the PO line. The new rate is determined according to the system date. In a U.S. tax environment, the tax rate on the header is used. In addition to the total purchase amount and tax/VAT amount fields, the last maintenance date and time are updated as well.

7. If the Synchro module is installed, the in-process shipments are retrieved from the Item Delivery Point file (GA120MLF). For each Part/Delivery Point, the valid endorsement is searched (only one endorsement is valid at a time for a specific Blanket Order, customer, ship to, delivery point, part across plants). If this one is for the same company/warehouse as the processed part, the in-process shipment of the Part/Delivery Point is calculated: (using WKISHP = DPTSDV - DPTSHP). If WKISHP is negative (advance), it defaults to zero, otherwise it is cumulated (QTYCUM). The calculation of the in-process quantity is done by the common subroutine INPSHP. The in-process requirement is due at the end of the firm horizon, if there is one; otherwise, it equals today’s date. These calculations are accomplished by calling the RP/Synchro In-Process Shipment Quantity program (GA225E).

8. The part’s Production Type is MRPII (PMPDTP=1), or the Production Type is JIT (PMPDTP=2) and the make/buy flag is Buy, or the part is purchased (MTYPN=1), raw material (MTYPN=3), transfer (MTYPN=8), or by-product (MTYPN=8).

a. If the Planning Action report has been requested (CPLNAR=Y), a Planning Action Report Detail Record is written for the safety stock requirement. The system date is assumed to be the Requirement Date for safety stock. The output file receiving the record is the Planning Action Report Detail-Demand file (RP100AP3). The appropriate Requirements Planning run mode (A - actual, S - simulation) is written to the record as well.

b1. The Beginning Inventory for Part (HDRINV) is calculated, if the part is not potency controlled.

(1) The Part Number and manufacturing company/warehouse are used to retrieve the corresponding record from the Warehouse Balance file (IC140M).

(2) If the record is found, the first Balance Type Quantity (WBBLT1) is added to the inventory.

(3) The remaining Balance Type Quantities (WBBLT2, WBBLT3, WBBLT4) are added to the inventory only if indicated by their respective Order Planning Codes (MOPAC2 = Y, MOPAC3 = Y, MOPAC4 = Y).

(4) The Work-in-Process Balance Quantity (WBWIPB) is added to inventory (only for parts which are not potency controlled).

(6) 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.

(7) If the resulting Beginning Inventory for Part is less than zero, the negative inventory is treated as additional safety stock. A negative planning balance requirement record is written. This balance will print as a requirement on the greater of today’s date or the firm horizon date on the Planning Action report. The Projected Inventory (PRJINV) is set to zero.

(8) If the warehouse balance record is not found, the Beginning Inventory and Projected Inventory are assumed to be zero.

b2. The beginning inventory for part (HDRINV) is calculated, if the part is potency controlled.

(1) The part number and manufacturing company/warehouse are used to retrieve the appropriate records from the multiple location logical file (IC130ML6). This process continues in a loop until all records for the part/company/warehouse are read.

(2) If at least one record is found, the first multiple location balance type quantity (LLBLT1) is multiplied by the internally calculated potency factor (PTFCTR, derived by dividing the actual potency, LCACPT, from IC150M for the location’s lot number, LLLTNO, by the saved part master standard potency, SAVSPT, from DE100M), yielding the equivalent potent units. This process occurs in subroutine POTCLC, after which the potent units (POTLBQ) is added the inventory. If the lot master available for planning, LCAUPL, is N, then the effective potent units are considered to be zero.

(3) The remaining balance type quantities (LLBLT2, LLBLT3, LLBLT4) are processed similarly to LLBLT1 and added to the inventory only if indicated by their respective order planning codes (MOPAC2=Y, MOPAC3=Y, MOPAC4=Y).

(4) Since the multiple location file does not have a work-in-process balance (WBWIPB) similar to that on IC140M, this is not directly taken into account. The quantity which 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.

(5) 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 and transfer orders is subtracted from the total. For potency controlled parts, the inventory reserved quantity for customer and transfer order lines is subtracted from the aforementioned total at standard potency (i.e., stockkeeping, not potent, units) because not all of warehouse balance reserved quantity (WBRSOQ) will be guaranteed also to be reserved at the multiple location file (LUPSV2, LLRSV3, LLRSV4).

(7) If the resulting Beginning Inventory for Part is less than zero, the negative inventory is treated as additional safety stock. A negative planning balance requirement record is written. This balance will print as a requirement on today’s date on the Planning Action report. The Projected Inventory (PRJINV) is set to zero.

(8) If the warehouse balance record is not found (and thus no multiple location records would be found), the potency calculations are not performed and the beginning inventory and projected inventory are assumed to be zero.

c. The Planning Action Horizon Date (CALHOR) for the part is calculated. This horizon date determines the number of days from the system date that order action and detail information are to be included on the Planning Action report (RP520B).. The RP stop date (RPSTOP) is calculated as the greater of the date of the last planned supply record (IC100L29) or the RP generation horizon days/date (RPHZDT), if the part’s Net Change flag is set to replan (=2). This is because planned orders that are deleted will need to be readded. If the part’s cumulative leadtime (MLTCUM) is zero, then the planning action report cumulative leadtime date (HDRCUM) and horizon date (CMPHRZ) are set to the lesser of the RP generation horizon date or the last calendar date, and the appropriate warning flag is set to Y (yes) (TRLWN3). The internal Shop and Calendar Horizon fields are also set (SHPHOR, CALHOR).

(1) The Planning Horizon Date (RPHZDT) calculated for the plant based upon the RP generation days is adjusted if the net change flag equals 2 (replan). If the flag is set to 2, the last planned order is retrieved from IC100L29, the new planning horizon is set to the due date of the last planned order (RPSTOP), if there is one. The system keeps the greater of RPHZDT and RPSTOP as the Planning Horizon Date (RPSTHR).

(2) If the Cumulative Lead Time (MLTCUM) of the part is zero, the Planning Action Horizon Date is set to the Planning Horizon Date or the last calendar date (if the last calendar date is earlier than the Planning Horizon Date) so that all order action detail is shown on the Planning Action report. A warning flag is set to print a message on the Planning Action report.

(3) If the Cumulative Lead Time is not zero, the Planning Action Horizon Date is calculated as follows, and order action is highlighted on the Planning Action report.

(a) The Cumulative Lead Time is multiplied by the Planning Horizon Factor (CPLNHF) on the Requirements Planning Control Record (RP110AP). The resulting amount is compared with the RP Planning Horizon, and the lesser amount is used.

(b) If the Planning Horizon Factor is set to zero, the Planning Action Horizon Date is set so that all order action detail is shown prior to the RP planning horizon date or the end of the calendar file on the Planning Action report.

(c) The shop date equivalent of the system date is retrieved from the logical Calendar Date file (CT140ML), and is added to the result of the calculation in step (1). The calendar date equivalent of this new shop date is then retrieved from the Calendar Date file (CT140M). This date is the Planning Action Horizon Date.

(d) If the calculation in step (a) results in an overflow, or if the resulting Planning Action Horizon Date is beyond the last date on the Calendar Date file (CT140M), the Planning Action Horizon Date is set to the last date on the Calendar Date file. A warning flag is set to print a message on the Planning Action report.

(e) If the calculation in step (a) results in a Planning Action Horizon Date within 20 days of the last date on the Calendar Date file, a warning flag is set to print a message on the Planning Action report.

d. The part print flag (HDRPRT) is set. This flag is used in conjunction with several other indicators to determine whether part information will be printed on the Planning Action report.

(1) If the Planning Action Report Option (CPLNAR) is set to N, the part print flag is set to N.* No part information is printed on the report, even if order action is needed on a non-planned manufacturing order/requisition.

* If order action is needed on a firm or open manufacturing order/requisitions, the flag is set to Y so that the Planning Action Report program (RP520E) recognizes that the part has exceptions. An order action message for the order will be written to the Order Action Inquiry file.

(2) If the Planning Action Report Option is set to Y, and the Part (exceptions only) Print Option (CPPO) is set to N, the part print flag is set to Y. All part information is printed on the report regardless of order action needs.

(3) If the Planning Action Report Option, the Part Print Option, and the Requirements Planning Force Print Option (MPEGCD) from the Part Master file (DE100M) are all set to Y, the part print flag is set to Y. All part information is printed on the Planning Action report.

(4) Otherwise, if the first two options are set to Y, and the Requirements Planning Force Print Option for the part is N, the part print flag is set to Y based on the Requirement Planning Print parameter. If the print planned exception flag (CPPOE) equals Y, then either a change to firmed or planned order will cause the part print flag to be set to Y. If the print errors beyond horizon flag (CPEBH) equals Y, then a change to an order beyond the horizon will cause the report to be written, and all order action messages will be displayed on the Planning Action report.

e. Ten scenarios for the part print flag are summarized in the following table:

Conditions	1	2	3	4	5	6	7	8	9
Planning Action Report Option	N	N	Y	Y	Y	Y	Y	Y	Y
Part (exception only) Print Option	-	-	N	Y	Y	Y	Y	Y	Y
Requirements Planning Force Print Option	-	-	-	Y	N	N	N	N	N
Print Errors Beyond Horizon Option	-	-	-	-	-	-	Y**	-	Y**
Print Planned Order Exception Option	-	-	-	-	-	-	-	Y	N
Order Action Needed on Firm Flow Authorization within Horizon	N	Y	-	-	Y	N	N	N	N
Order Action Needed on Firm Flow Authorization beyond Horizon	-	-	-	-	-	N	Y	N	N
Order Action Needed on Planned Part Only	-	-	-	-	-	N	-	Y	Y
Part Print Flag on Report Header Record	N	Y*	Y	Y	Y	N	Y	Y	N
Will Part Print on Planning Action report	N	Y	Y	Y	Y	N	Y	Y	N

* If order action is needed on a non-planned manufacturing order/requisitions, the flag is set to Y so that the Planning Action Report program (RP520E) recognizes that the part has exceptions. Note that no report is printed for the part; however, an order action message will be written to the Order Action Inquiry file.

** If the Print Errors Beyond Horizon flag is set to Y, exceptions beyond the horizon are printed on the Planning Action report.

f. If the RP planning mode is selective, then RP102E is called to retrieve the RP forecast consumption period value from RP110AP2 for the part, family ID, or planner, to which the part belongs. This is used as an override value for the forecast consumption period value on RP110AP.

g. If Requirements Planning is currently running in simulation mode, then RP Delete/Copy of Simulated Supply/Demand (RP110E) is called. This program deletes previously generated “copies” of firmed/open manufacturing orders and component requirements, released transfer requisitions, open/released/shipped/partially shipped transfer order lines, released purchase requisitions, open purchase order release records, and firmed flow authorizations, and respective flow requirements. It then “recopies” the latest actual records that fit the above criteria, using RP101CLP, which utilizes OPNQRYF techniques. These “copied” records are then placed in RP140AP1/RP140AP2 (MRP Point Supply/Demand Simulated files) or RP140AP3/RP140AP4 (JIT Flow Supply/Demand Simulated files), as appropriate.

h. If the Forecast Consumption Period flag is a value other than N, then RP130E is called to perform the batch forecast consumption and target inventory days calculations, in either actual or simulated RP run mode. After the consumption process, any remaining unconsumed, consolidated forecast quantity is written to RP130AP1, and target inventory quantities, if any, are written to RP130AP2. These records are analyzed in the RP demand logicals, RP095ML4 and RP140AL6.

i. If the RP run mode is simulated, then Simulated Demand Sourcing (SDMSRC) is called to determine whether actual or simulated point demand and actual or simulated flow demand will drive the demand analysis processing. The flags ACTSRC, SIMSRC, ACTFLW, and SIMFLW are set accordingly in the program, depending on whether demand records for the part exist in RP140AP2 (Simulated MRP Point Demand) or RP140AP4 (Simulated JIT Flow Demand). These flags drive the appropriate file processing later in the RP generation.

j. The Order Policy Code (SVOPOC) is checked to determine the type of processing to be performed.

(1) If this field contains a value of 5 (physical control), Physical Control Processing is performed.

(2) If this field contains a value of 1 (as required), 2 (fixed time period), or 3 (fixed quantity), Firm Horizon Processing is performed then Analysis Processing is performed.

k. Once the appropriate processing is completed, the header record for the part is written to the Planning Action Report Header file (RP100AP1). The net change processing flag (PMNCFL) and the Requirements Planning Generation Selection Flag (PMRPSF) on the Part Master file (DE100M) are reset to 0.

l. The Logical Part Master file (DE100L12) is read sequentially. Necessary fields are saved for future processing.

C. Physical Control Processing

1. The part print flag (HDRPRT) on the report header record is checked. If this field contains N, physical control processing is omitted, since physical control parts are only printed on the Planning Action report. No additional processing is needed.

2. The requirements for the part are read sequentially from the logical Requirements Planning Demand file (RP095ML4) and from the Logical Flow Requirements file (JT120ML2), in RP run mode is actual, or if ACTSRC = Y and ACTFLW = Y in RP run mode is simulated. If RP run mode is simulation, and SIMSRC = Y and SIMFLW = Y, then the simulated MRP Point Demand logical (RP140AL6) and Simulated JIT Flow Demand logical (RP140AL4) are read.

a. If the requirement record is a sales order, the record is processed only if the following conditions are met:

(1) The sales order is sourced from the requested manufacturing plant. If the relief code on the sales order is M (manufacturing), the order is always processed. If the relief code on the sales order is D (distribution), the order is processed only if the Sales Order Planning flag on the Warehouse Description file is Y.

(2) The sales order type is a regular or blanket release order.

If the requirements record is an offset release, it is only processed if it is not issued from a distribution company/warehouse.

b. If the requirement record is a component requirement (actual or simulated) or a flow requirement (actual or simulated), the usage code is checked for produced and consumed components. Consumed components are processed as demand, while produced components (by-products) are processed as supply.

c. If the requirement record is an offset release, it is taken into account only it is issued from a manufacturing company/warehouse.

d. The fields of each requirements record are formatted into the corresponding fields on the Planning Action Report Detail-Demand file (RP100AP3).

e. If the Requirements Due Date (REQDTE) is less than or equal to the Planning Action Horizon Date, the record is written.

f. If the Requirements Due Date is greater than the Planning Action Horizon Date, the Requirement Quantity (REQQTY) is accumulated into the Trailer Requirements field (TRLREQ).

3. The supply records for the part are read sequentially from the logical Requirements Planning Supply file (RP095ML8) and from the Logical Flow Authorization file (JT100ML3), if RP is running in actual mode, and from the Simulated RP Supply file (RP140AL1), if RP is running in simulation mode.

a. If the supply record is flow authorization, the production type is JIT, and the part type is transfer, the FA record is unlocked and control is transferred to FA reorganization for MRPII Parts (DE080E). DE080E will close past FAs, break in-process FAs, and delete future FAs. This occurs if RP is running in actual mode only because simulated FAs are never copies or created for MRP parts.

b. If the supply record is a purchase order or requisition, the record is processed only if the order originated from the manufacturing company and warehouse.

c. The Supply Yield (SUPYLD) is calculated:

(1) If the Supply Quantity (Order Quantity adjusted for Cumulative Scrap and Quantity Received) is less than zero, the Supply Quantity and Supply Yield are set to zero.

(2) If the Supply Quantity is greater than zero, the Supply Yield is calculated as:

Order Qty times (1 minus IC Scrap Factor) divided by 100) minus Quantity Received.

(3) If Shop Floor is installed, Supply Yield is calculated again as:

Order Qty minus Cumulative Scrap, minus Quantity Received.

(4) If the calculations in steps (2) and (3) are both performed, the results are compared. The Supply Yield is set to the lesser of the two.

d. The fields of each supply record are formatted into the corresponding fields on the Planning Action Report Detail-Supply file (RP100AP2).

e. If the Supply Quantity is greater than zero and the Supply Due Date (SUPDDT) is less than or equal to the Planning Action Horizon Date, the record is written.

f. If the Supply Quantity is greater than zero and the Supply Due Date (SUPDDT) is greater than the Planning Action Horizon Date, the Supply Yield (SUPYLD) is accumulated into the Trailer Supply field (TRLSUP).

D. Firm Horizon Processing (Actual or Simulation Mode)

1. Process Supply Records

a. If RP is running in actual mode, manufacturing orders, purchase order detail records, PO requisitions, transfer supply orders, and transfer supply requisitions are retrieved from the Requirements Planning Supply file (RP095ML8) while the start date of supply is within the firm horizon date. If RP is running in simulation mode, then the same simulated records are retrieved from the Simulated RP Supply file (RP140AL1) and are processed.

b. Planned orders are deleted (in actual RP run mode) if:

the part is flagged for replanning (PMNCFL = 2)

the part is flagged for reanalyzing (PMNCFL = 1) and the Delete Planned flag is set to yes. (This flag is found on Reference File category D84. There is one flag for MOs, one for PO requisitions, and one for transfer requisitions.)

c. The supply yield is calculated as noted in Physical Control Processing.

d. If the supply quantity has not been fully received, and it is within the firm horizon, a supply record is written to the Planning Action Report Detail Supply file (RP100AP2). The supply quantity is added to the projected inventory. Actual or simulated mode is noted when writing the report records.

e. Flow authorizations are retrieved from the Flow Authorization file (JT100ML3). If the supply record is a flow authorization and the part is not JIT transferred, the flow authorization record is unlocked and control is transferred to Flow Authorization Reorganization for MRPII parts (DE080E). This file will close past flow authorizations, break in-process flow authorizations, and delete future flow authorizations. This occurs if RP is running in actual mode only, because simulated FAs are never copied or created for MRP parts.

2. Process Requirements Records

a. Requirements records for the part are read sequentially from the Flow Requirements file (JT120ML2) and the Requirements Planning Demand file (RP095ML4) while the requirement due date is less than or equal to the firm horizon date, if RP is running in actual mode, or if RP is running in simulated mode, but the flags ACTSRC and ACTFLW both are Y. If SIMSRC and SIMFLW = Y, then the Simulated RP Demand file (RP140AL6) and Simulated Flow Requirements file (RP140AL4) are reread instead.

The requirement quantity calculation is the same as the one described in Analysis Processing for non-FR requirements.

b. The requirement record is written to the Planning Action Report Detail Requirement file (RP100AP3) if the usage code is consumed. It is written to the Planning Action Report Supply file (RP100AP2) if the usage code is produced. Actual or simulation mode is noted when writing the report records.

c. The requirement quantity is subtracted from the projected inventory if the usage code is consumed, and added to the projected inventory if the usage code is produced.

d. For FR requirements, the expected quantity within the firm horizon is calculated as explained in Analysis Processing. The flow requirements, however, are not accumulated into the Actual Demand Array (ADA). The flow requirement record is written to the Planning Action Report Detail Requirement file and subtracted from the projected inventory, if the quantity expected is greater than zero and the usage code is defined as “consumed.” If the usage code is defined as “produced,” the quantity expected is used to format the Planning Action Report Detail Supply file, and it is added to the projected inventory.

E. Analysis Processing

1. The Projected Inventory (PRJINV) for the part determines whether requirements or supply orders should be retrieved at any point in analysis processing.

a. If the Projected Inventory is positive or zero, requirements records are netted against the Projected Inventory until the Projected Inventory becomes negative. Refer to step 2 for details.

b. If the Projected Inventory is negative, supply order records are retrieved or added until the Projected Inventory is no longer negative. Refer to step 3 for details.

2. Net Requirements Records:

a. If RP is running in actual mode, or running in simulated mode with ACTSRC and ACTFLW = Y, then requirements records for the part are read sequentially from the logical Requirements Planning Demand file (RP095ML4) and from the Logical Flow Requirements file (JT120ML2). If the Projected Inventory is still positive or equal to zero, and no requirements record is found, the Safety Stock (AMSSK) is subtracted from the Projected Inventory, a flag is set, and analysis processing ends. If in-process shipment quantity exists and its date (today’s date) is less than or equal to the requirement date retrieved, it is processed.

(1) An offset release record.

Requirement Quantity

equals

Net Quantity
(ROQNSK)

b. If a requirements record is found, the Requirement Quantity (REQQTY) is calculated according to one of the following formulas:

(2) Sales Order Records. These are processed only if the following conditions are met:

(a) The sales order is sourced from the requested manufacturing plant.

(b) The sales order type is a regular or blanket release order.

Requirement Quantity

equals

SKU Sales Order Quantity (SLRQTY)

minus

SKU Quantity Shipped (SLSQTY)

(3) Component Requirement Records (Actual or Simulated):

* Requirement Quantity

equals

Component Required Quantity (MZRQTY or SDRQTY)

minus

Quantity Issued (MZIQTY or SD)

*Note: This quantity is also the supply quantity for produced components.

(4) Projected Demand Records:

Requirement Quantity

equals

Demand Quantity (FCQTY)

minus

Shipped Quantity (FCSQTY)

(5) Consolidated Projected Demand Records:

Requirement Quantity

equals

Demand Quantity
(UFUQTY)

(6) Target Inventory Demand Records:

Requirement Quantity

equals

Target Inventory Quantity
(TCTNVQ)

(7) Transfer Order Records (Actual or Simulated):

Requirement Quantity

equals

Order Quantity (TLORQY or SDRQTY)

minus

Shipped Quantity (TLSHSQY or SDIQTY)

(8) Transfer Requisition Records (Actual or Simulated):

Requirement Quantity

equals

Requisition Quantity (QTRQTY or SDRQTY)

minus

Received Quantity (QTRCQT or SDIQTY)

(9) Flow Requirements Records (Actual or Simulated):

(a) The Requirement Date (FRSDTE or FDSTDT) is earlier than or equal to the processing date.

· The Quantity Issued (FRIQTY or FDIQTY) is less than the FR Demand Quantity (FRDQTY or FDDQTY).

**Requirement Quantity

equals

FR Required Quantity (FRRQTY or FDRQTY)

minus

Quantity Issued (FRIQTY or FDIQTY)

· The Quantity Issued (FRIQTY or FDIQTY) is greater than or equal to the FR Demand Quantity (FRDQTY or FDDQTY).

Requirement Quantity = zero

(b) The Requirement Date (FRSDTE or FDSTDT) is beyond the processing date.

**Requirement Quantity = FR Required Quantity (FRRQTY or FRDQTY)

*Note. Multiple flow requirements may exist for a single day. The flow requirements are accumulated into the Actual Demand Array (ADA). The array quantities are used as the flow requirements demand.

**Note. This quantity is also the supply quantity for produced components.

(c) The fields of the Flow Requirement Record are formatted into the corresponding fields of the Planning Action Report Detail-Demand file if the quantity expected is not zero and the usage code is consumed. Otherwise, if the usage code is produced, the quantity expected is used to format the Planning Action Report Detail-Supply file.

· If the FR date is less than or equal to the Planning Action Horizon Date, the report record is written to the Planning Action Report Detail-Demand file or to the Detail Supply file.

· If the FR date is greater than the Planning Action Horizon Date, Expected Quantity (QTYEXP) is added to the Trailer Requirements (TRLREQ) or the Trailer Supply Quantity (TRLSUP).

c. If the Requirement Due Date is greater than or equal to the Safety Stock Due Date (i.e., the requirement is not past due), and the Safety Stock (AMSSK) has not yet been processed, the Safety Stock is subtracted from the Projected Inventory before the requirements record is processed.

d. The fields of the requirements record are formatted into the corresponding fields of the Planning Action Report Detail-Demand file. At this time, requirements records for flow requirements have already been written.

(1) If the Requirement Due Date (REQDTE) is less than or equal to the Planning Action Horizon Date, the report record is written to the Planning Action Report Detail-Demand file.

(2) If the Requirement Due Date is greater than the Planning Action Horizon Date, the Requirement Quantity is added to the Trailer Requirements (TRLREQ).

e. The Requirement Quantity is subtracted from the Projected Inventory. If the requirement was a produced component record, the quantity is negative so that it will increase the projected inventory. The target inventory requirement quantity will not be subtracted from projected inventory because it is only a requirement to “pull demand” forward in time to build inventory levels in anticipation of the actual demand.

f. If the Projected Inventory does not become negative, the next requirements record for the part is retrieved. If no record is found, a message is formatted to decrease the quantity of the last non-planned supply order processed.

g. If the Order Policy Code (SVOPOC) of the part is fixed time (2), the Fixed Time Horizon Date (FZHORZ) is calculated the first time a requirements record drives the Projected Inventory negative.

(1) The Shop Date (CRDSHP) of the record that drove the Projected Inventory negative is added to the Order Policy Quantity (SVOPOQ) for the part, giving a new shop date.

(2) If an overflow occurs, the Fixed Time Horizon Date is set so that all remaining requirements records are retrieved.

(3) Otherwise, the Fixed Time Horizon Date is the calendar date equivalent of the new shop date. This date is retrieved from the logical Calendar Date file (CT140ML).

(4) Requirements records are retrieved until there are no more requirements for the part, or until the Requirements Due Date of a record falls beyond the Fixed Time Horizon Date. Netting ends at this point.

h. If the order policy of the part is not fixed time, netting ends when the Projected Inventory becomes negative, or when no more requirements are found.

3. Process Supply Records:

a. If the Projected Inventory for the part becomes negative, supply records for the part (manufacturing orders, purchase order detail records, requisitions, transfer supply orders, transfer supply requisitions, or flow authorizations) are retrieved from the logical Requirements Planning Supply file (RP095ML8) and from the Logical Flow Authorization file (JT100ML3). If no supply records are found, a flag is set.

b. If the supply record is a flow authorization and the part is not a JIT transferred, the FA record is unlocked and control is transferred to FA reorganization for MRPII parts (DE080E). DE080E will close past FAs, break in-process FAs, and delete future FAs. This occurs only if RP is running in actual mode because simulated FAs are never copied or created for MRP parts.

c. If the supply record is a purchase order or requisition, the record is processed only if the order originated from the manufacturing company and warehouse. (If the Purchase Order Type is phantom, the record is not included in the logical file and so is not processed. Also, if the purchase order release was generated by the EDI/CID process, it is likewise ignored in the logical file).

d. The Supply Yield (SUPYLD) is calculated as in Physical Control Processing, step 3b.

e. If the supply order has not been fully received (Supply Quantity is greater than 0), a supply record is written to the Planning Action Report Detail-Supply file (RP100AP2).

f. If the supply order is a planned manufacturing order/requisition (HSTATS or RQSTS = P, or SSSTAT = P) and the part is flagged for replanning (PMNCFL = 2), the order is deleted. (It is added later if needed.)

g. Supply order records are retrieved until one is found that is not fully received. This record is compared to the previously retrieved requirements record. If the order date occurs after the RP process horizon (it is also called the generation stop date), no message is triggered. Quantities are added to the trailer; no planned orders are created or updated.

h. If there are no more requirements records, and supply records still exist, a cancel order action message is formatted.

i. If the supply order is not a planned manufacturing order/requisition, and its calculated Supply Yield and Due Date do not meet the Requirement Quantity and Due Date, adjustments to the order are suggested through order action messages. The order and its component requirements are not altered in any way. RP treats simulated planned orders and requisitions whose RP Freeze flag (SSRPFZ) on RP140AP1 (RP140AL1) like a firmed, actual order or requisition.

(1) If either due date is within the Planning Action Horizon Date, order action is suggested. Otherwise, the Supply is added to the Trailer Supply field (TRLSUP).

(2) If the Requirements Due Date is prior to the Supply Due Date, an expedite order action message is formatted, provided that the number of shop days the order is to be expedited is greater than the Expedite Filter (CSHEAR).

(3) If the Requirements Due Date is after the Supply Due Date, a defer order action message is formatted, provided that the number of shop days the order is to be deferred is greater than the Defer Filter (CSHLAT).

(4) If the Requirements Quantity is less than the Order Quantity:

(a) If there are no more requirements and the surplus was not caused by order policy, a quantity decrease order action message is formatted. The order quantity needed to satisfy the current requirement is calculated based on the part’s order policy. This order quantity is subtracted from the current order quantity to determine the order decrease quantity.

(b) If there are no more requirements and the order policy is fixed time or order increment, the Order Quantity is recalculated to satisfy the requirement.

(5) If defer or expedite order action is needed, the new Order Due Date and Start Date are calculated. The Order Action Due Date (SUPDDT) is set to the Requirements Due Date. The Order Action Start Date (SUPSDT) is determined by the part’s Leadtime Code.

(a) If the part has a fixed lead time, the Leadtime Days (SVLTPU) is subtracted from the shop date of the Requirements Due Date. If the part is a purchased or raw material the dock-to-stock leadtime days (SVDKLT) is added to the fixed leadtime days and the sum is subtracted from the Requirements Due Date. The Order Action Start Date is the calendar date equivalent of this amount. This date is retrieved from the logical Calendar Date file (CT140ML). If no equivalent date is found, a warning message will print on the Planning Action report, and the Order Action Start Date is set to zeros.

(b) If the part is manufactured or build through and has a variable lead time, the Order Yield (ORDQTY) is multiplied by the Run Days Per Piece (SVLTRH), giving the total run days 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 Requirements Due Date. The Order Action Start Date is the calendar date equivalent of this final amount, which is retrieved from the logical Calendar Date file. If an overflow occurs in the above calculations, or if no equivalent date is found, a warning message will be printed on the Planning Action report. The Order Action Start Date is set to zeros.

The Order Action Start Date is the calendar date equivalent of this amount. This date is retrieved from the logical Calendar Date file (CT140ML). If no equivalent date is found, a warning message will print on the Planning Action report, and the Order Action Start Date is set to zeros.

(6) A supply record is written to the Planning Action Report Detail-Supply file (RP100AP2). This record contains: all of the retrieved supply order data from the logical Requirements Planning Supply file (RP095ML8) or the Simulated RP Supply file (RP140AL1); the order action message; and the Order Action Start and Due Dates.

(7) The Projected Inventory is adjusted by the Order Yield, and/or by any QUANTITY DECREASE recommendation amount.

j. If the supply order retrieved is a planned manufacturing order, purchase requisition, or transfer requisition (Actual mode only. Planned simulated supply records can never be adjusted because they are unconditionally deleted by RP101E for each part before MRP analysis), and its quantity and due date do not meet the Requirements Quantity and Due Date, the order is adjusted to meet the requirements through planned order maintenance.

k. If there are no more supply orders and net requirements still exist, planned order maintenance is performed to add planned orders.

F. Planned Supply Maintenance (Actual or Simulated Mode)

1. Add a Planned Supply Record.

a. Since the Component Requirement Required Quantity is a larger field than Order Quantity, several manufacturing orders/purchase requisitions/transfer requisitions may have to be planned to cover the requirement. Therefore planned manufacturing orders/purchase requisitions/transfer requisitions are generated until the Order Quantity satisfies the requirement.

b. The Order Quantity (LSORDQ), Order Yield (LSYLD), Start Date (LSSTDT), and Due Date (LSDUDT) are calculated.

(1) If the order policy is not fixed quantity or fixed time, the Order Yield is set equal to the Requirement Quantity. The Order Yield is then converted to an Order Quantity (allowances for scrap added back) according to the following formula:

Order Quantity = order Yield divided by (1 + (IC Scrap Factor x .01))

The result is always rounded up.

(2) If the order policy is fixed quantity or fixed time, with zero as the order increment, the Order Quantity is first calculated as in the previous step. The fixed quantity or fixed time order policy requires an Order Quantity equal to the Order Policy Quantity (SVOPOQ). Therefore, multiple orders may be generated to satisfy a single requirement. The Order Yield is then calculated according to the following formula:

Order Yield = Order Quantity times (1 - (IC Scrap Factor x .01))

The result is always rounded down.

(3) If the order policy is fixed quantity or fixed time with a non-zero order increment policy, the Order Quantity is calculated as in step (1) and then divided by the Order Policy Quantity as in step (2). If there is no remainder, the result is the Order Quantity. If there is a remainder, it is then divided by the Order Policy Increment Quantity (PMOPIN). If there is still a remainder, and if this is the last order needed for the current requirement, the Order Policy Increment Quantity is set to its next highest multiple. The Order Policy Increment Quantity is added to the Order Quantity, and the Order Yield is calculated as in step (2).

(4) If an overflow occurs in any of the above calculations, the Order Quantity is set to all nines, and multiple orders are planned for the requirement.

(5) The Order Due Date is set to the working day prior to the Requirement Due Date.

(6) The Order Start Date is determined by the part’s Leadtime Code. If the projected inventory became negative within the RP firm horizon (if defined), then the planned supply record is added outside the firm horizon. The start date is the day after the firm horizon date and the due date is forward scheduled based upon lead time parameters. Appropriate add and expedite messages are sent for MRP manufactured and build-thru parts that have MOs generated. For purchase and transfer requisitions, the due date is set to be the date after the RP firm horizon, because requisition start dates are external dates relative to RP shop floor firm horizon processing.

(a) If the part has a fixed lead time, the Fixed Leadtime Days (SVLTPU) is subtracted from the shop date of the Order Due Date. If the part is purchased or raw material the Dock-to-Stock Leadtime Days (SVDKLT) is added to the fixed leadtime days and the sum is subtracted from the Requirement 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, a warning message will print on the Planning Action report. The Order Start Date is set to the first date on the logical Calendar Date file.

(b) If the part is manufactured or build through and has a variable lead time, the Order Quantity (LSORDQ) 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), Fixed Leadtime Days (SVLTPU), 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 an overflow occurs in any of the above calculations, or if no equivalent date is found, a warning message will be printed on the Planning Action report. The Order Start Date is set to the first date on the logical Calendar Date file.

(c) If the part is transferred, the Transit Leadtime Days is retrieved from the Transfer Order Leadtime (category D17) of the Reference file and this number is added to the Dock-to-Stock Leadtime (SVDKLT). The sum is subtracted from the shop date of the Requirement Due Date. The Order Action Start Date is the calendar date equivalent of this amount. This date is retrieved from the logical Calendar Date file (CT140ML). If no equivalent date is found, a warning message will print on the Planning Action report, and the Order Action Start Date is set to zeros.

c. The master file fields are formatted.

(1) The Planned Order Number is determined by linking the Order Prefix (MOPRE - manufacturing; RQPRE - purchase requisition - TRPRE - Transfer Requisition) with the Order Number Suffix (MONUM - manufacturing; RQNUM - purchase requisition - TRNUM - Transfer Requisition).

Order prefixes and order number suffixes are stored in a multi-occurrence internal date structure (one occurrence per plant).

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

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, purchased part, or a by-product, a requisition is added. If it is a manufactured part, a manufacturing order is added. If it is a transfer part, a transfer requisition is added. This is done in both actual and simulated mode.

e. If Capacity Planning is installed and a planned order is added for an part, the Capacity Planning schedule flag (HCPFLG) is set to Y to ensure that the new planned order is processed by the Labor Requirements Generation program (CP100E) the next time it is run. This is done in actual RP run mode only because simulated planned labor requirement records do not exist.

f. If a planned purchase requisition is to be added, the Purchase 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. (This is done in actual RP run mode only. Estimated unit cost, purchase order message, and default requisition priority codes are not available on simulated purchase requisitions.)

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.

g. If Capacity Planning is installed and a planned order is changed, existing planned labor requirements for that order have to be rescheduled. The Capacity Planning schedule flag (HCPFLA) is set to Y so the order is selected for processing when the Capacity Planning Labor Requirements Generation program (CP100E) is run next. This is done in actual RP run mode only because simulated planned labor requirements do not exist.

The Capacity Planning schedule flag is set to Y if either of the following occurs:

· The order quantity has changed.

· The order due date has changed.

h. 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 an 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. For 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 (IC100CP1). No component requirement records are written. This is done in actual RP run mode only for manufacturing order processing.

(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 (IC100CP1). Component requirement records are not written for non-effective components. This is done in actual RP run mode only for manufacturing order processing.

(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). This is done in actual RP run mode only for manufacturing order processing.

(5) The Required Quantity (MZRQTY or SDRQTY) of a component is calculated by multiplying the Order Quantity (LSORDQ) by the Quantity of Component Per Parent (MZUQTY or SDUQTY). 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).

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). This is done in actual RP run mode only.

(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 : 500). That is to say, A to D = 12.0.

(8) The Component Required Quantity is divided by the Component scrap - factor (1 - (PSSCRF : 100)) in order to calculate the inflated component Required Quantity. This value will be used to format the Component Requirement Record. Both quantities are saved so that the scrap factor can be recalculated and also stored on the Component Requirement Record.

(9) The component scrap factor for the components of build-thru parts is computed by dividing the quantity not inflated by component scrap (WKRQTY) by the Quantity inflated by component scrap (KNRQTS).

(10) The record is formatted for output to the Component Requirements file (IC120M) or Simulated Component Requirements file (RP140AP2, SDRCTP = ‘CR’).

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

(a) The existing record on the Component Requirements file (IC120M) or on the Simulated Component Requirements file (RP140AP2, SDRCTP = ‘CR’) are retrieved.

(b) The Required Quantities of the duplicate components are added. If the 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]. This is done in actual RP run mode only.

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

(ii) The Decimal Control Code (MZDCC or SDDCC) 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.

(iii) The component scrap factor for the collapsed components is computed by dividing the sum of the quantities not affected by component scrap by the sum of the quantities inflated by component scrap.

(iv) The original component requirement record is up- dated with the new Required Quantity, Decimal Control Code, and Quantity of Component Per Parent.

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

(12) 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 (reanalyze) and the RP Selection Flag (PMRPSF) is set to 1 so that the record will be subsequently processed by this program, if the RP run mode is actual. If the RP run mode is simulated, the net change flag is not maintained, but the RP Selection flag is set to ‘2,’ simulation mode.

(a) If a planned transfer requisition is to be added, the transfer requisition fields are formatted. The supplying company and warehouse are formatted from the Warehouse Description file. All other fields are either calculated or they default from the Part Master file.

2. Change a Supply Record. (Actual mode only. RP101E deletes all previously planned simulated supply records previous to MRP analysis, except those whose RP Freeze flag is Y.)

a. The new Order Quantity (LSORDQ), Order Yield (LSYLD), Start Date (LSSTDT), and Due Date (LSDUDT) are determined as in the processing for adding a planned order (step 1a).

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

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

(1) If the Order Start Date changes, the component requirements must be deleted, then added again, since the product structure may be altered due to product change effectivity.

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

(3) 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). This is done in actual RP run mode only.

(4) If this program is in net change mode (CPLNMD = N), the part master record for each component requirement is retrieved and updated. The net change flag (PMNCFL) for each record is set to 1 (reanalyze) and the RP Selection Flag (PMRPSF) is set to 1 so that the components will be subsequently processed by this program, if the RP run mode is actual. If the RP run mode is simulated, the net change flag is not maintained, but the RP Selection flag is set to ‘2,’ simulation mode.

d. If the new Order Due Date is beyond the Planning Horizon Date, the Order Quantity (LSORDQ) is added to the Trailer Supply field (TRLSUP). Otherwise, the record is formatted and written to the Planning Action Report Detail-Supply file (RP100AP2).

e. The Projected Inventory (PRJINV) is adjusted upward by the Order Yield (LSYLD).

3. Delete a Planned Supply Record. (Actual mode only. RP101E deletes simulated planned supply records.)

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

b. If Capacity Planning is installed and a planned manufacturing order has been deleted, any planned labor requirements for this order on the Planned Labor Requirements file (CP100AP) are deleted.. This is done in actual RP run mode only because simulated planned labor requirement records do not exist.

c. If the planned supply record is a manufacturing order, the manufacturing order and its component requirements are deleted. If this program is in net change mode (CPLNMD=N), the part master records for the component requirements are retrieved and updated. The net change flag of each record is set to 1 (reanalyze) so that the components will be subsequently processed by this program, if the RP run mode is actual. If the RP run mode is simulated, the net change flag is not maintained, but the RP Selection flag is set to ‘2,’ simulation mode.

G. Windup

1. If the program did not abort, the restart flag (RESTRT) is set to N, to indicate that restart processing is not needed.

2. The Requirements Planning Generation file (RP110AP) is updated for each plant processed. The front-end program flag (CZFREN) is set to N. This prevents this program from being run without the Requirements Planning Generation Preparation program (RP010E).

3. If an abort has occurred in any part of the program, the program and the job are canceled as an abnormal end of job. If there was not an abort, the program ends normally.

Menu

Requirements Planning Generation - Calculations

RP100E Program Menu