Capability (C019):— assigning_approvals Date: 2008/01/15 06:30:31
Revision: 1.51
CoverContentsIntro.Overview Info. modelTemplatesCapabilities.Ref. dataIssues

Issue raised against: assigning_approvals

OTHER issues

Closed issue Issue: Sb-3 by Sean Barker (2004-06-07) editorial issue
Resolution: Accept. Status: closed

The capability should describe how to hold the status in the Reference Data Library, rather than in the string attibute status.
Comment: (mikeward 2004-08-16)
Agreed. Capability revised.

Closed issue Issue: Sb-2 by Sean Barker (2004-06-07) editorial issue
Resolution: Accept. Status: closed

The capability should give guidance on what the various dates mean, together with any requirements on applying dates, and any reference data applicable.
Comment: (mikeward 2004-08-20)
Agreed. Capability revised.

Closed issue Issue: Sb-1 by Sean Barker (2004-06-07) editorial issue
Resolution: Accept. Status: closed

The relationship between approval status and state needs to be defined, since multilevel approvals are equivalent to a state-machine.
Comment: (Rob Bodington 04-08-19)
The approval status should continue to be used. Reference data should be used to provide the possible statuses.
Comment: (mikeward 2004-08-20)
Note added to State capability.

Closed issue Issue: Sb-4 by Sean Barker (2004-09-16) editorial issue
Resolution: Accept. Status: closed

The classification of "Approval_assignment_role" should be identified as an abstract reference data class, and some examples given of possible values at least "legal requirement", as the example in the module.
Comment: (Mike Ward 2005-01-07)
Agreed. Capability revised.

Closed issue Issue: Sb-5 by Sean Barker (2005-11-04) editorial issue
Resolution: Accept. Status: closed

The capability should make clear the different functions of reference data for approval assignment, approval and approval status, and provide guidence on how such classes be extended.
Comment: (Rob Bodington 06-06-20)
It is not obvious what the different functions of reference data for approval assignment and approval are. Hence, only approval is classified. The text has been expanded.

Closed issue Issue: NN-1 by Nigel Newling (2005-11-16) editorial issue
Resolution: Accept. Status: closed

To update with template notation.
Comment: (Peter Bergstrom 2006-04-15)
Templates added.

Closed issue Issue: TJT-1 by Tim Turner (2006-01-21) editorial issue
Resolution: Accept. Status: closed

Templates use "/IGNORE" for values of the approval.planned_date and approval.actual_date. However, when the template is expanded, these values are not valid EXPRESS since the data type is not of type string. They are of type Date_time_select (i.e. either an instance of calendar_date or date_time). The attributes are, however, optional, which means that "?" can be used instead.
Comment: (Rob Bodington 06-01-23)
I have just removed the offending /IGNORES from the path The same problem occurs in Approving_person_organization.approval_date = '/IGNORE' The diagrams still need to be updated.
Comment: (Peter Bergstrom 2006-04-15)
Diagrams corrected.

Closed issue Issue: TJT-2 by Tim Turner (2006-01-30) major_technical issue
Resolution: Accept. Status: closed

Currently there are two templates for Approvals. One assigning_approval_person (asg_apr_pers) assigns a person, and organization to an instance of Person_in_organization, which is the person_organization referenced from an instance of Approving_person_organization. There are 5 optional characterizations to this template which must be attributed outside of the template usage for which three variables are declared (^organization [the Organization], ^pers_in_org [the Person_in_organization] and ^app_pers_org [the Approving_person_organization]). The second template assigning_approval (asg_apr) provides the instances of approval, approval_status and approval_assignment entities. The instance of approval provides a target for an occurrence of the template assigning_approval_person (see above). The arrangement is such that one template is used within another. This is no problem. However, *as I understand it*, only those variables exposed can be referenced from outside the template. Hence, the latterly defined "enclosing" template only exposes 3 locally defined variables for characterization outside of this definition (^app_status [Approval_status], ^approval [Approval] and ^approval_assignment [Approval_assignment]). Given the current definition, if one uses the assigning_approval template, it is not possible to characterize the instances created by the internal (enclosed) template as the variables are not explicitly exposed by the second (enclosing) template. Hence, it is impossible to assign the optional reference_data or calendar dates etc., to the authorization defined. There are several options, either; 1. expose the three variables declared (^organization [the Organization], ^pers_in_org [the Person_in_organization] and ^app_pers_org [the Approving_person_organization]) from within assigning_approval. This results in a total of 6 (cumulative) for the assigning_approval template. 2. enforce the population of the optional attributes in assigning_approval_person (and therefore, in assigning_approval, from where it is called). 3. Create a new template, possibly a combination of the two currently defined which provides access to the 6 optional characterizations. 4. Someone put me right.
Comment: (Rob Bodington 06-02-01)
I would prefer Option 1. The EXPRESS-G and the path should be updated accordingly.
Comment: (Peter Bergstrom 2006-04-15)
I chose a different solution, because of the following: An approval may authorized by a person (in an organization) or by an organization (no person identified or mentioned), at least thats my understanding of the business overview. I therefore created a third template, assigning_approving_organization (and renamed the other one to assigning_approving_person), and the three templates are now not within each other (since there is a choise of a person or organization, they cannot be). This poses another syntactical problem in that it is now possible to assign only an assigning_approval, without either a person or an organization, and I cannot enforce that in the path syntax. See further issue PBM-1. However, it is no longer a problem of not accessing the reference_parameters...

Closed issue Issue: RBN-1 by Rob Bodington (05-11-23) minor_technical issue
Resolution: Accept. Status: closed

Add TEMPLATE: assigning_approval TEMPLATE: assigning_approval_person
Comment: (Peter Bergstrom 2006-04-15)
Three templates have been added: assigning_approval, assigning_approving_person, and assigning_approving_organization.

Closed issue Issue: RBN-2 by Rob Bodington (06-01-23) minor_technical issue
Resolution: Accept. Status: closed

In the template assigning_approval the EXPRESS G diagram in Figure 9 contains incorrect classification data for the approval status and approval person. They should not be hardcoded.
Comment: (Peter Bergstrom 2006-04-15)
corrected.

Closed issue Issue: PBM-1 by Peter Bergstrom (06-01-23) minor_technical issue
Resolution: Accept. Status: closed

Template Assigning_approval_person forces the owner of the identification of a person to be same organization as the organization in which the person is employed. AP239 does not mandate any identification of persons, so the template Assigning_identifier on entity Person ought to be optional, i.e. a characterization of the template Assigning_approval_person. If so, Persons can be identified if need be, and the identifier of a Person can be owned by another organization than that in which the person works.
Comment: (Peter Bergstrom 2006-04-15)
The identification of a person is now optional.

Closed issue Issue: RBN-3 by Rob Bodington (06-01-23) minor_technical issue
Resolution: Accept. Status: closed

The approval_status should be mandatory in the template assigning_approval. This requires additional parameters and the modification of the diagrams
Comment: (Peter Bergstrom 2006-04-15)
Corrected.

Closed issue Issue: RBN-4 by Rob Bodington (06-01-23) minor_technical issue
Resolution: Accept. Status: closed

The organization parameters used to identify the person are missing from the template assigning_approval_person.
Comment: (Peter Bergstrom 2006-04-15)
Corrected, I think...

Closed issue Issue: PBM-2 by Peter Bergstrom (2006-04-15) minor_technical issue
Resolution: Accept. Status: closed

Due to the new template assigning_approving_organization, it is no longer possible to have assigning_approving_person (was assigning_approval_person) inside template assigning_approval. It is therefore no longer enforced by the path syntax that there always has to be at least two templates used for this capability, assigning_approval plus either of assigning_approving_person or assigning_approving_organization. Is this a problem, or can the rule simply be enforced in prose text (as it is now)?
Comment: (Rob Bodington 06-06-20)
The prose text is acceptable

Closed issue Issue: RBN-5 by Rob Bodington (06-06-15) minor_technical issue
Resolution: Accept. Status: closed

The capability has attempted to use the assignment of dates to approvals and Approving_person_organization by using the assigning_calendar_date template rather than the date attributes Approval.planned_date Approval.actual_date and Approving_person_organization.approval_date. The rational being that date assignment should be used everywhere in dexlib to enable the assignment of multiple dates. For example, there may be a requirements to assigned more than one date to the Approving_person_organization.

However, the AP239 model does not permit the assignment of a date time to Approving_person_organization. The options are therefore:

  1. Use the date attributes and the representing_date_time template
  2. Use the date assignment for the Approval and the attribute Approving_person_organization.approval_date
  3. Raise a SEDS against PLCS and use the date assignment everywhere

The proposal is to use option 1 as this in keeping with the original model and raise a SEDS to allow the assignment of a date to Approving_person_organization.

Comment: (Rob Bodington 06-06-20)
Option 3 has been implemented. A SEDS has been raised, and the a modified schema added to dexlib. See dexlib/docs/issues/infrastructure_issues.xml#RBN-58

Closed issue Issue: EML-1 by Ed McNeil (06-06-23) minor_technical issue
Resolution: Accept. Status: closed

Assigning_approval Section 'Instance diagrams': 'Note that one of the two templates assigning_approving_person and assigning_approving_person always must be present to make the approval complete.' Second assigning_approving_person should be assigning_approving_organization.
Comment: (Rob Bodington 06-06-23)
corrected

Closed issue Issue: DNV-09 by Sylvia Schwab on behalf of DNV (07-02-27) major_technical issue
Resolution: Accept. Status: closed

Person_in_organization and organization is represented in templates related to other capabilities. The template assigning_approval doesn't include the entity approving_person_organization which is required.

New template: assigning_approval_person_organization (asg_apr_pers_org) which contains approval, approval_assignment, approval_status, approving_person_organization (with references to proposed new templates repr_person and repr_org.)

Comment: (Peter Bergström 2007-05-22)
This is formally an issue against the templates, not the capability. Therefore I have closed it.
However, I have also commented similar issues in the template, and instead of using the new template I suggest we change the existing one. However, the change is dependent on how templates are reorganized for Organization and Person, so I wait with the changes until I know the resolution of those issues.

Closed issue Issue: DNV-09a by Sylvia Schwab on behalf of DNV (07-02-27) major_technical issue
Resolution: Accept. Status: closed

Assigning_approvals has 3 templates. Currently the the template assigning_approval has to either refer to the template assigning_approving_person or assigning_approving_organization. The templates assigning_approving_person and assigning_approving_organization have both the entity approving_person_organization and then refer to either person or organization. As suggested in issues related to capabilities representing_person_in_organization and assinging_organization the part representing person_in_organization and organization should be part of such capabilities and not part of assigning_approval. If these parts are replaced by references to other templates the two templates only include the entity approving_person_organization.

This leads to the proposal to make the two templates assigning_approving_person and assigning_approving_organization obsolete and either include the entity into assigning_approval or create a new template beside assigning_approval (see DNV-09).

Comment: (Peter Bergström 2007-05-22)
This is formally an issue against the templates, not the capability. Therefore I have closed it.
However, I have also commented similar issues in the template, and instead of using the new template I suggest we change the existing one. However, the change is dependent on how templates are reorganized for Organization and Person, so I wait with the changes until I know the resolution of those issues.