Documentation >
MAC-PAC Technical Library >
Manufacturing >
Design Engineering >
Programs >
Product Structure Mass Change - Product >
Product Structure Mass Change - Calculations
Product Structure Mass Change - Calculations
DE125E
A. Housekeeping
1. See the Common Processing Routines Section of this manual for a general discussion of the Housekeeping subroutine. Processing specific to this program is described below.
2. A parameter list is set up for the fast path and help screen parameters.
3. The following records are retrieved from the Reference file (REFERP):
a. The date format record (category 049) is retrieved. If this record is not found, a message is sent to the system operator, the date format defaults to MMDDYY, and processing continues.
b. The current system date is retrieved and saved.
c. The ECO Date Update Option record (category C12) is retrieved. If this record is not found, the program ends abnormally.
4. The company name record (COMNAM) is retrieved from the System Control file (CT100M). If the company name record is not found, a message is sent to the system operator, a default message is used, and processing continues.
5. Reference File category 409 (user/company authorization) is read to determine the plants the user is authorized to access.
6. The default plant is retrieved from Reference File category 428 (workstation authorization).
B. Mainline
1. The program is directed by the Program Status field PGMSTS. The program will execute in a loop until the program status = END or the program ends abnormally.
a. The detail screen is displayed.
b. After the user has entered data, a detailed field validation is performed. See the Design Engineering User Manual for screen validation information.
c. If the transaction is valid, but involves a change of part type between the Component Part to be Replaced (CZCPN) and the Component Part to be Introduced (CZRCPN), then the screen is redisplayed with a warning message to this effect. If the user does not change the parts involved, and presses the ENTER key, the transaction is accepted as valid.
d. If the transaction is accepted as valid, the Product Structure Where-Used file is read in a loop until no more records are found for the part to be replaced For each applicable product structure record found, the necessary transactions (add, change, and delete) are written to the Product Structure Mass Change Transaction file (DE125AP1).
2. The following transactions are written to the Product Structure Mass Change Transaction file (DE125AP1). Exhibit I shows in detail what transactions are written under the possible circumstances.
Change
a. Change transactions are written to take existing components out-of-effect for either replacement parts, which come in on a certain date and the existing part goes out-of-effect the day before, or when a mass delete with *NONE is used as the replacement part. When *NONE is used, the existing component goes out-of-effect today or on the user-specified date.
b. Change transactions are written to modify existing parent/component Quantity Per relationships.
Delete
a. Delete transactions are written to delete existing product structure records.
Add
a. Add transactions are written to bring new components into effect.
b. Add transactions are written to physically replace existing components with another component part and/or replace quantity per relationships between parents and components.
c. Add transactions are written to ensure existing components remain in effect for the desired times.
d. Add transactions are written to ensure that new components are in effect for the desired times.
C. Wind-up
1. If maintenance transactions were written, then the Product Structure Mass Change Transaction file (DE125AP1) is copied (*ADD) to the Product Structure Transaction file (DE120AP1) in the calling CLP program DE125CLP. If no transactions were written to the Product Structure Transaction file, then the Abort Flag field (ABTFLG) is set to YES to avoid copying the file unnecessarily.
EXHIBIT I
The Eng Effectivity Date - In is used to determine the effectivity dates of the component relationships on the affected bills of material. As a result of one product structure mass change transaction, many product structure maintenance (add, change, and delete) transactions can be written. Each product structure record's effectivity dates must be evaluated on an individual basis to determine the effectivity dates of the new component relationship. The following examples show how the effectivity dates are determined for these transactions.
Key:
|
IN
|
=
|
Existing Effectivity Date - In
|
|
OUT
|
=
|
Existing Effectivity Date - Out
|
|
ADD
|
=
|
ADD TRANSACTION
|
|
CHG
|
=
|
CHANGE TRANSACTION
|
|
DEL
|
=
|
DELETE TRANSACTION
|
|
IGN
|
=
|
IGNORE - NO TRANSACTIONS WRITTEN
|
A. The original component record is continually in effect (that is, it has blank in- and out-effectivity dates.) The chart below shows what transactions would be created for this product structure based on the in-effectivity date on the mass change transaction.
<----------------------------------------+
|
|
|
A
time----->
|
REPLACED COMPONENT
|
INTRODUCED COMPONENT
|
|
|
|
|
|
|
|
A
|
BLANK
|
A-1
|
CHG
|
A
|
BLANK
|
ADD
|
B. The original component record has an in-effectivity date of B and an out-effectivity date of D. The chart below shows what transactions would be created for the product structure based on various in-effectivity dates that might be entered on the mass change transaction.
IN OUT
X---------------------------X
| | | | |
| | | | |
A B C D E
time----->
|
|
|
|
|
|
|
|
|
|
|
A
|
-
|
-
|
DEL
|
B
|
D
|
ADD
|
|
B
|
-
|
-
|
DEL
|
B
|
D
|
ADD
|
|
C
|
B
|
C-1
|
CHG
|
C
|
D
|
ADD
|
|
D
|
B
|
D-1
|
CHG
|
D
|
D
|
ADD
|
|
E
|
-
|
-
|
IGN
|
-
|
-
|
IGN
|
|
C. The original component record has an out-effectivity date of B. Its in-effectivity date is blank (that is, it has always been in effect). The chart below shows what transactions would be created for the product structure based on various in-effectivity dates that might be entered on the mass change transaction.
OUT
<----------------------X
| | |
| | |
A B C
time----->
|
|
|
|
|
|
|
|
|
|
A
|
BLANK
|
A-1
|
CHG
|
A
|
B
|
ADD
|
B
|
BLANK
|
B-1
|
CHG
|
B
|
B
|
ADD
|
C
|
-
|
-
|
IGN
|
-
|
-
|
IGN
|
D. The original component record has an in-effectivity date of B. Its out-effectivity date is blank (that is, it is not scheduled to go out of effect). The chart below shows what transactions would be created for the product structure based on various in-effectivity dates that might be entered on the mass change transaction.
IN
X--------------->
| | |
| | |
A B C
time----->
|
REPLACED COMPONENT
|
|
|
|
|
|
|
|
|
A
|
-
|
-
|
DEL
|
B
|
BLANK
|
ADD
|
B
|
-
|
-
|
DEL
|
B
|
BLANK
|
ADD
|
C
|
B
|
C-1
|
CHG
|
C
|
BLANK
|
ADD
|
E. The original component is scheduled to go out of effect at the end of day B and come into effect again at the beginning of day D. It has one product structure record, with an out-effectivity date of B and an in-effectivity date of D. The chart below shows what transactions would be created for the product structure based on various in-effectivity dates that might be entered on the mass change transaction.
OUT IN
<----------X X---------->
| | | | |
| | | | |
A B C D E
time----->
|
|
|
|
|
|
|
|
|
|
A
|
BLANK
|
A-1
|
CHG
|
A
D
|
B
BLANK
|
ADD
ADD
|
B
|
BLANK
|
B-1
|
CHG
|
B
D
|
B
BLANK
|
ADD
ADD
|
C
|
BLANK
|
B
|
CHG
|
D
|
BLANK
|
ADD
|
D
|
BLANK
|
B
|
CHG
|
D
|
BLANK
|
ADD
|
E
|
BLANK
D
|
B
E-1
|
CHG
ADD
|
E
|
BLANK
|
ADD
|
F. The original component record is scheduled to be in effect for one day only. It has an in-effectivity date of B (meaning it will come into effect at the beginning of the day B) and an out-effectivity date of B (meaning it will go out of effect at the end of the day). The chart below shows what transactions would be created for the product structure based on various in-effectivity dates that might be entered on the mass change transaction.
IN/
OUT
X
| | |
| | |
A B C
time----->
|
|
|
|
|
|
|
|
|
|
A
|
-
|
-
|
DEL
|
B
|
B
|
ADD
|
B
|
-
|
-
|
DEL
|
B
|
B
|
ADD
|
C
|
-
|
-
|
IGN
|
-
|
-
|
IGN
|
G. The original component record has always been in effect and will go out-of-effect on date B. The chart below shows the effect of a user-specified mass delete of component product structure records for a given part when *DELETE is used as the replacement part value (all records are physically deleted from the product structure file).
<-----------------------X
| | |
| | |
A B C
|
|
|
|
|
|
|
|
|
|
A
|
-
|
-
|
DEL
|
***
|
NONE
|
***
|
B
|
-
|
-
|
DEL
|
***
|
NONE
|
***
|
C
|
-
|
-
|
DEL
|
***
|
NONE
|
***
|
Note: This example is used to illustrate the point that when using the mass delete feature with *DELETE, all records are physically deleted when the Product Structure Maintenance program (DE120E) is run in off-line (batch) mode, regardless of transaction or effectivity dates.
H. The original component has always been in-effect and will go out-of-effect on date B. In addition, it will come back into effect on date D. The chart below shows the effect of a user-specified mass delete of component product structure records for a given part when *NONE is used as the replacement part value. All parts have their effectivity-out dates changed. If the user did not enter an ECO number or effectivity date, the effectivity-out date is changed to yesterday's date. Otherwise, the effectivity-out date is changed to the date entered by the user, or the day before the date associated with the ECO number entered by the user.
<----------X X---------->
| | | | |
| | | | |
A Today's B C D
Date
time----->
|
|
|
|
|
|
|
|
|
|
A
|
D
|
A-1
|
CHG
|
***
|
NONE
|
***
|
B
|
D
|
B-1
|
CHG
|
***
|
NONE
|
***
|
C
|
D
|
C-1
|
CHG
|
***
|
NONE
|
***
|
D
|
D
|
D-1
|
CHG
|
***
|
NONE
|
***
|
BLANK
|
D
|
Today's Date-1
|
CHG
|
***
|
NONE
|
***
|
'Note: Because the part comes into effect in the future, this future effectivity-in date will not be affected by the change. If the user does not desire the part to be in-effect in the future, the part should be manually changed, or the *DELETE option should be used.