PDM-UG: Approval Cycles and Multiple Sign-off Scenarios
From WikiSTEP
This page belongs to the PDM Usage Guide.
A number of STEP APs have constructs that require an approval, but are allowed only one approval assignment. This might lead to the misconception that only one person at one date/time can approve something. This is not the case. The approval constructs actually support an approval cycle. An approval cycle typically requires multiple signatures to achieve a given status for the overall approval.
Representation of an approval cycle may be done in one of two ways in the PDM Schema, depending upon the specific requirements of the use scenario:
- Single approval with multiple person/organizations,
- Multiple approvals with hierarchical relationships.
If multiple people/organizations are required to sign off in an approval cycle, but only a single status value is maintained for the overall approval, then the single approval with multiple person organization approach is recommended. If individual, possibly different, status values are necessary for each of the multiple sign-offs required in an approval cycle, then the multiple approval with hierarchical relationship structure is recommended.
In all scenarios the approval_date_time records the date/time that the status of an approval was last changed. Year values for dates should always be expressed with four digits, e.g., 1999. The approval_date_time entity may have a role associated it through the entity role_association and its related object_role entity.
The single approval with multiple person/organization type of approval cycle requires multiple signatures but maintains a single approval status. This explains the need for the approval_status of 'not yet approved' - until all signatures are available to switch this status to 'approved'. Each individual sign off should have an associated date/time, through the use of a date_assignment (or date_and_time_assignment) applied directly to the approval_person_organization, to represent the sign off date with the date_time_role of 'sign off'. As always, the approval_date_time indicates when the status of the overall approval was last changed.
Contents |
The Instance Model: EXPRESS entities and attributes
The EXPRESS entities and attributes used to support the requirements for a cycle involving a single approval with multiple sign-offs are illustrated in Diagram 57. Although a date_time_assignment is used in this example to illustrate a date_and_time, a date_assignment can also be used if only a date without a time specification is required.
Diagram 57: Single Approval Cycle Instance Diagram
Approval relationship
An approval_relationship is a relationship between two approvals, i.e., approval objects. The meaning of the approval relationship is given by its name attribute. An approval_relationship may be used to define an approval as part of some higher level approval, or to express some dependency such as sequential relationship in time, between two approval objects.
Attributes
- The name attribute specifies the meaning of the relationship.
- The description attribute specifies additional information text that characterizes the approval_relationship.
- The relating_approval specifies the first approval, which is related by the approval_relationship. The relating_approval usually identifies the approval on which the definition of the related_approval is based, e.g., from which it is derived or on which it is dependent. The semantics of this attribute should be defined by the name attribute.
- The related_approval specifies the second approval related by the approval_relationship. The related_approval usually identifies the approval which is based on the definition of the relating_approval. The semantics of this attribute should be defined by the name attribute.
| ENTITY approval_relationship | Attribute Population | Remarks |
| name | type: label = string | |
| description | type: text = string | OPTIONAL |
| relating_approval | type: entity = approval | |
| related_approval | type: entity = approval |
===Preprocessor Recommendations=== The name attribute is used to specify the type of the approval_relationship and therefore should be populated with predefined values that both sides of the exchange have a common understanding of. The value ’decomposition’ for the name attribute should be used to indicate that the related_approval is one of potentially more components into which the relating_approval is broken down. The value ’precedence’ for the name attribute should be used to indicate that the related_approval has higher priority than the relating_approval. The value ’sequence’ for the name attribute should be used to indicate that the relating_approval shall be completed before the related_approval is given. There are no further standard mappings specified for the name attribute. Additional values must be mutually agreed upon.
There is no standard mapping for the description attribute. The description attribute is optional, but may contain any appropriate/mutually-agreed-upon string.
===Postprocessor Recommendations=== There are no specific postprocessor recommendations.
===Related Entities=== There are no specific related entities.
The Instance Model: STEP exchange file format (ISO10303 Part 21 syntax)
ISO-10303-21;
HEADER;
FILE_DESCRIPTION(('pdm_schema data', 'pdm_schema'), '2;1');
FILE_NAME('C:\approval_example.stp', '1999-5-20 T12:39:1', (''), (), '', '', '');
FILE_SCHEMA(('PDM_SCHEMA {1.2}'));
ENDSEC;
DATA;
/* part version to which an approval is applied */
#10 = PRODUCT_DEFINITION_FORMATION('02', 'lever modified', #20);
#20 = PRODUCT('K01-42051', 'Bicycle Bell RX25B', , (#30));
#30 = PRODUCT_CONTEXT('', #40, '');
#40 = APPLICATION_CONTEXT('mechanical design');
#50 = PRODUCT_RELATED_PRODUCT_CATEGORY('part', '', (#20));
#60=APPLICATION_PROTOCOL_DEFINITION('version 1.2','pdm_schema',20002000,#40;
/* approval definition / association to product_definition_formation */
#880 = APPROVAL(#870, '');
#870 = APPROVAL_STATUS('not yet approved');
#890 = APPLIED_APPROVAL_ASSIGNMENT(#880, (#10));
/* definition of overall approval date (when status was set) */
#940 = APPROVAL_DATE_TIME(#970,#880);
#950 = ROLE_ASSOCIATION(#960, #940);
#960 = OBJECT_ROLE('actual', $);
#970 = DATE_AND_TIME(#980, #990);
#980 = CALENDAR_DATE(1999, 14, 5);
#990 = LOCAL_TIME(0, 0, 0.0E+000, #1000);
#1000 = COORDINATED_UNIVERSAL_TIME_OFFSET(0, $, .EXACT.);
/* identification of an approver (one of possibly many) */
#900 = APPROVAL_PERSON_ORGANIZATION(#330, #880, #910);
#910 = APPROVAL_ROLE('approver');
#330 = PERSON_AND_ORGANIZATION(#340, #280);
#280 = ORGANIZATION('O-0709', 'Logus GmbH', 'company');
#340 = PERSON('P-0661', 'Rose', 'Peter', $, $, $);
#350 = NAME_ATTRIBUTE('employee', #330);
/* individual approver sign-off date */
#920 = APPLIED_DATE_AND_TIME_ASSIGNMENT(#1070, #930, (#900));
#930 = DATE_TIME_ROLE('sign off');
#1070 = DATE_AND_TIME(#1080, #1090);
#1080 = CALENDAR_DATE(1999, 12, 5);
#1090 = LOCAL_TIME(0, 0, 0.0E+000, #1000);
ENDSEC;
END-ISO-10303-21;
The multiple approval with hierarchical relationship type of approval cycle requires multiple signatures, each with individual status values, to achieve a given status value of the overall approval. In this case, each sign-off is itself an approval – a sub-approval of the overall approval. Thus the overall approval is hierarchically broken down into component sub-approvals, each with an individual status, date/time, and person/organization.
The Instance Model: EXPRESS entities and attributes
The EXPRESS entities and attributes used to support the requirements for a cycle involving a multiple approvals with hierarchical approval relationships are illustrated in Diagram 58.
Diagram 58: Multiple Approval Cycle Instance Diagram
The Instance Model: STEP exchange file format (ISO10303 Part 21 syntax)
ISO-10303-21;
HEADER;
FILE_DESCRIPTION((''), '2;1');
FILE_NAME('', '14.10.1999, 11:35:31', ('N.N.'), (''), '', '', '');
FILE_SCHEMA(('PDM_SCHEMA {1.2}'));
ENDSEC;
DATA;
/* part master data for product g1 (#4 */
#10 = PRODUCT_CATEGORY_RELATIONSHIP('', $, #20, #30);
#20 = PRODUCT_RELATED_PRODUCT_CATEGORY('Part', '', (#40));
#30 = PRODUCT_RELATED_PRODUCT_CATEGORY('Detail', $, (#40));
#40 = PRODUCT('g1', 'gear box v1', '', (#60));
#50 = PRODUCT_RELATED_PRODUCT_CATEGORY('part', '', (#40));
#60 = PRODUCT_CONTEXT('', #70, '');
#70 = APPLICATION_CONTEXT('');
#80 = APPLICATION_PROTOCOL_DEFINITION('version 1.2', 'pdm_schema', 20002000, #70);
#90 = PRODUCT_DEFINITION_FORMATION('1', '', #40);
/* #100 is the top-level approval in the c */
/* It is via the relationships #235 and #375 decomposed in two */
/* approval parts. The status in #120 reflects the overall status */
#100 = APPROVAL(#120, '');
#110 = APPLIED_APPROVAL_ASSIGNMENT(#100, (#90));
#120 = APPROVAL_STATUS('not yet approved');
#130 = ORGANIZATION('dep1', 'department 1', '');
#160 = APPROVAL_PERSON_ORGANIZATION(#130, #100, #170);
#170 = APPROVAL_ROLE('approver');
#180 = APPLIED_DATE_AND_TIME_ASSIGNMENT(#200, #190, (#160));
#190 = DATE_TIME_ROLE('sign off');
#200 = DATE_AND_TIME(#210, #220);
#210 = CALENDAR_DATE(2000, 1, 1);
#220 = LOCAL_TIME(0, 0, 0.0000E+000, #230);
#230 = COORDINATED_UNIVERSAL_TIME_OFFSET(1, $, .AHEAD.);
/* #240 is a decomposed part of the top-level approval #10 */
/* This approval has two signing organizations (#270, #32 */
/*attached to it */
/* The status is reflected in #240 */
#235 = APPROVAL_RELATIONSHIP('decomposition',$,#100,#250);
#240 = APPROVAL_STATUS('approved');
#250 = APPROVAL(#240, '');
#260 = APPLIED_APPROVAL_ASSIGNMENT(#250, (#90));
/* #270 is the 1st organization given the approval #240 */
#270 = ORGANIZATION('g1', 'group 1', '');
#280 = APPROVAL_PERSON_ORGANIZATION(#270, #250, #285);
#285 = APPROVAL_ROLE('approver');
#290 = APPLIED_DATE_AND_TIME_ASSIGNMENT(#300, #295, (#280));
#295 = DATE_TIME_ROLE('sign off');
#300 = DATE_AND_TIME(#310, #320);
#310 = CALENDAR_DATE(2000, 1, 1);
#320 = LOCAL_TIME(0, 0, 0.0000E+000, #230);
/* #325 is the 2nd organization given the approval #240 */
#325 = ORGANIZATION('g3', 'group 3', '');
#330 = APPROVAL_PERSON_ORGANIZATION(#325, #250, #335);
#335 = APPROVAL_ROLE('approver');
#340 = APPLIED_DATE_AND_TIME_ASSIGNMENT(#350, #345, (#330));
#345 = DATE_TIME_ROLE('sign off');
#350 = DATE_AND_TIME(#360, #370);
#360 = CALENDAR_DATE(2000, 1, 2);
#370 = LOCAL_TIME(0, 0, 0.0000E+000, #230);
/* #380 is a decomposed approval part of the top-level approval #100*/
/* The status is reflected in #400 */
#375 = APPROVAL_RELATIONSHIP('decomposition',$,#100,#380);
#380 = APPROVAL(#400, '');
#390 = APPLIED_APPROVAL_ASSIGNMENT(#380, (#90));
#400 = APPROVAL_STATUS('withdrawn');
#405 = ORGANIZATION('g2', 'group 2', '');
#410 = APPROVAL_PERSON_ORGANIZATION(#405, #380, #415);
#415 = APPROVAL_ROLE('approver');
#420 = APPLIED_DATE_AND_TIME_ASSIGNMENT(#430, #425, (#410));
#425 = DATE_TIME_ROLE('sign off');
#430 = DATE_AND_TIME(#440, #450);
#440 = CALENDAR_DATE(2000, 1, 2);
#450 = LOCAL_TIME(0, 0, 0.0000E+000, #230);
ENDSEC;
END-ISO-10303-21;
