RP Generation for Job Controlled Parts - Calculations

RP106E

A. Housekeeping

1. Parameter lists and key lists are defined. Work fields and constants are defined and initialized.

2. The company name is retrieved from the company name record 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. 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.

4. The date format is retrieved from Reference File category 049. If the record is not found, a message is sent to the system operator, the date format defaults to MMDDYY, and processing continues.

5. System calendar data, the shop paperwork option, balance type data, and RP control record data are retrieved from the System Control file. If any of these records is not found, the program ends abnormally.

Control Record	Information Retrieved
Inventory Control (ICCTL1)	Lot Control and Potency Control Environment (LOTOPT, POTOPT).
Inventory Control (ICCTL2)	Order Planning Codes (MOPAC2, MOPAC3, MOPAC4) Distribution Codes (DSTAC2, DSTAC3, DSTAC4) Last Calendar Date (LCALDT)

7. Calendar date information is processed. If records are not found, the program ends abnormally.

a. Date arrays are loaded and today’s shop date is determined.

b. The current date is saved in YYMMDD format. The current time of RP generation is also saved. These values are required for audit trail and other processing.

8. Bill-to information is retrieved from the Warehouse Description file.

9. The program retrieves the applications installed record from the Reference File (category 012) to determine whether the Shop Floor Control and Capacity Planning modules are installed. If this record is not found, the program ends abnormally.

10. EDI/Future 3 demand types are retrieved from Reference File category D26. If Future 3 is installed (R012F3 = Yes), the demand types are used to plan for EDI/Future 3 demand as actual demand, regardless of when they occur.

11. Reference File category D85 is retrieved for the five families to exclude for RP planning. Any part that belongs to one of these families (provided the family is non-blank) is excluded from RP processing.

12. Quantity field sizes are retrieved from Reference File category 446. If this record is not found, the program ends abnormally. The value of the Decimal Precision field, used to adjust purchase order quantities, is calculated.

13. Plant arrays and data structures are loaded with data from the RP Generation Request file (RP110AP). If no plants have been defined, the program ends abnormally. 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). No RP firm horizon processing exists in RP106E, due to the nature of job control demand.

14. The On-Hand Inventory Work file is opened.

B. Mainline

1. The Part Master File pointer is positioned after the last record processed by RP100E.

2. The program processing loop performs the processing described below for each part selected.

3. The part status (IZACD) and part status planning flag (RD88PL) are validate.

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.

4. The appropriate occurrence of plant-specific planning parameters is retrieved from the plant data structure (RPPLDS) if the part’s plant/RP run mode are not equal to the saved plant/RP run mode code.

a. The occurrence is set in the plant data structure (RPPLDS) if the plant code is found in the requested plant array. The program terminates abnormally if the part’s plant code has not been requested.

b. The occurrence is set 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. The program initializes the inventory work file.

6. The beginning inventory for the part is accumulated by job number, group number, or common.

a. The part number and manufacturing company/warehouse are used to retrieve the corresponding records from the Multiple Location file.

b. If a record is found, the first balance type quantity (LLBLT1) is added to the inventory. If the part is potency controlled, then 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 flag, LCAVPL, is N, then the effective potent units are considered to be zero.

c. The remaining balance type quantities (LLBLT2, LLBLT3, LLBLT4) are added to the inventory only if indicated by their respective order planning codes (MOPAC2 = Y, MOPAC3 = Y, MOPAC3 = Y, MOPAC = Y). If part is potency controlled, LLBLT2, LLBLT3, LLBLT4 are all first converted to potent units in a similar manner as LLBLT1.

d. For every distribution warehouse associated with the plant, the Warehouse Distribution file is read to determine if balances at the warehouse are available for planning. If so, any distribution balance in the multiple location records of the warehouse from the balance type fields LLBLT2, LLBLT3, and/or LLBLT4 is added to the total (if the part is potency controlled, the quantities are first converted into potent units via the same calculations in B, then added to the total).

e. If the resulting beginning inventory for the job or for common is less than zero, 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 available inventory (JSAVL) is set to zero.

7. 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). This processing is described in the program description for RP100E. 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).

8. 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. See part print flag processing described in RP100E.

9. The order policy code (SVOPOC) for job-controlled parts is As-Required.

10. 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) on the Part Master file (DE100M) is reset to 0, if RP is running in actual mode. The RP Select flag (PMRPSF) is reset to 0 regardless of the RP run mode.

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

C. Analysis Processing

1. The projected inventory (WKAVL) for a part/job combination determines whether requirements or supply orders should be retrieved at any point in analysis processing.

a. If the available inventory is positive or zero, the program reads the inventory work file to check for negative inventory balances.

b. If no negative inventory balances exist and no requirements exist, supply orders are processed.

c. If no negative inventory balances exist and available inventory is negative, the projected inventory is processed as a positive requirement.

d. If available inventory is positive, and no negative inventory balance is being processed, requirements are netted against the available quantity.

2. Net Requirement Records:

a. Requirement records for a part/job are read sequentially from the logical Requirements Planning Demand file (RP095ML4), if RP is running in actual mode, or in simulation mode when ACTSRC = Y (actual requirements are used because simulation requirements do not exist). If RP is running in simulation mode with SIMSRC = Y, then the logical Simulated RP Demand file (RP140AL6) is read. If the available inventory for the job is positive or equal to zero, and no requirements record is found, a requirement for another job is retrieved until no more requirements for the part are found. Requirements beyond the RP stop date (RPSTOP) are not planned for or netted and are bypassed.

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

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

(a) The sales order is sourced from the manufacturing company and warehouse.

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

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

Requirement Quantity

equals

Component Required Quantity (MZRQTY or SDRQTY)

minus

Quantity Issued (MZIQTY or SDIQTY)

(3) Projected Demand Records:

Requirement Quantity

equals

Demand Quantity (FCQTY)

minus

Shipped Quantity (FCSQTY)

(4) Consolidated Projected Demand Records:

Requirement Quantity

equals

Demand Quantity (UFUQTY)

(5) Target Inventory Demand Records:

Requirement Quantity

equals

Demand Quantity (TIINVQ)

(6) 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 FDST) is beyond the processing date.

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

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

Synchro Offset Releases.

(1) An offset release record.

Requirement Quantity

equals

Net Quantity
(ROQNSK)

c. The fields of the requirements record are formatted into the corresponding fields of the Planning Action Report Detail-Demand file.

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

d. The requirement quantity for the job is subtracted from the available inventory for that job.

e. If the available 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.

f. If the job available inventory cannot satisfy the requirement, the Job Master File record for the job is checked for a group number, the job requirement is netted against any available Inventory for the group.

g. If a job does not reside in a group or the requirement is still not satisfied, the requirement is netted against any excess inventory available for the part.

3. Process Supply Records:

a. If the available inventory for the part/job is still negative, supply records for the part/job (manufacturing orders, purchase order detail records, or requisitions) are retrieved from the logical Requirements Planning Supply file (RP095ML5).

b. If no supply records for the job are found and the job resides in a group, supply for the group is retrieved.

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

d. The supply yield (SUPYLD) is calculated as in physical control processing step 3b in the program description for RP100E.

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 that supply order is a planned manufacturing order/requisition (HSTATS or RQSTS = 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.

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.

(1) If either due date is within the planning action horizon date, order action is suggested.

(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 ship 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, 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, a quantity decrease order action message is formatted. The order quantity is subtracted from the current order quantity to determine the order decrease quantity.

(b) If there are more requirements, no action is taken, since this order can fill existing requirements.

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

(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 (RP095ML5 if RP is running in actual mode, or the Simulated RP Supply file (RP140AL5), if RP is running in simulated mode); the order action message; and the order action start and due dates.

(7) The available inventory for the job 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 or 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 for the job still exist, planned order maintenance is performed to add planned orders for the job.

D. Planned Supply Maintenance (Actual or Simulated Mode)

1. Add a planned supply record.

a. Because the component requirement required quantity is a larger field than order quantity, several manufacturing orders/requisitions may have to be planned to cover the requirement. Therefore, planned manufacturing orders/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) The order yield is set equal to the requirement quantity. The order yield is then converted to an order quantity (allowances for scrap added) according to the following formula:

Order Quantity

equals

Order Yield divided by (1 plus (IC Scrap Factor times .01)

The result is always rounded up.

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

(3) The order due date is set to the working day prior to the requirement due date.

(4) The order start date is determined by the part’s leadtime code.

(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. The order start date is the calendar equivalent of this amount, which is retrieved from the logical Calendar Date file (CT240ML). 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 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. The master file fields are formatted.

(1) The planned order number is determined by linking the order prefix (CMOPRE - manufacturing; CROPRE - requisition) with the order number suffix (CMOORD - manufacturing; CROORD - requisition).

(2) If the resulting planned manufacturing order/requisition 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 or manufactured. If it is a raw material or purchased part, a requisition is added. If it is a manufactured part, a manufacturing order is added. This is done in both actual or simulated mode.

e. If Capacity Planning is installed and a planned order is added for a 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 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. (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

equals

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 a part, the multiple occurrence data structure of the Requirements Planning Product Structure Data (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 part). 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 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) of a component is calculated by multiplying the order quantity (LSORDQ) 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).

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 for manufacturing order processing.

(7) The Quantity of Component Per Parent field for the components of build-thru parts is computer 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 record is formatted for output to the Component Requirements file (IC120M) or Simulated Component Requirements file (RP140AP2 SDRCTP = ‘CR’).

(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 or Simulated Component Requirements file (RP140AP2 SDRCTP = ‘CR’).

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

(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. 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, 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.

(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 (reanalyze) so that the record will be subsequently processed by this program, if RP is running in actual mode. In simulated mode, the RP Select flag (PMRPSF) is set to 2 (Simulation mode) so that the subsequent record is processed.

2. Change a Supply Record.

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). The required quantity is determined by multiplying the order quantity (LSORDQ) by the quantity of component per parent (MZUQTY).

(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 for manufacturing order processing.

(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 flog (PMNCFL) for each record is set to 1 (reanalyze) so that the components will be subsequently processed by this program, if RP is running in actual mode. In simulated mode, the RP Select flag (PMRPSF) is set to 2 (Simulation mode) so that the subsequent record is processed.

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 RP run 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 requirements 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 RP is running is running in actual mode. If RP is running in simulated mode, the RP Select flag (PMRPSF) is set to 2 (Simulation mode) to achieve this processing.

1. The next requisition and purchase order starting numbers are updated on the Order Starting Numbers record (category 465) on the Reference file (REFERP).

2. If any supply still exists for a group, it is written to the Planning Action Report Group Supply Trailer file (RP100AP5).

3. The next job-controlled part at this level is read and processed. If a valid part is not found, control is returned to RP100E.

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

RP Generation for Job Controlled Parts - Calculations

RP106E Program Menu