# Receipt and Referral User Group Meeting

**Date:** March 22, 2002

**Time:** 11:00 a.m.--12:30 p.m.

**Location:** Rockledge 2, Room 3014

**Facilitator:** Sara Silver

**Next Meeting:** Fri., May 31, 10:30--12, Rockledge 2, TBD

## Action Items

-   (Mike) Compare the 901 capabilities with assignment validation to
    assess feasibility of 901 validation.

-   (Sara) Close loop with Help Desk regarding the resolution of the
    problem of possible data discrepancies between the RR and Review
    modules. The issue has been resolved.

-   (Lisa) Investigate why Table 10 is not correct and determine a fix.

-   (Lisa) Fix the code next week so that mailers only pull the data for
    the Primary IRG chief.

-   (Scarlett, Toni) Meet to determine how to create new letters.

-   (Sara) Send a request to the CM redesign group that they incorporate
    business rules in the redesigned module to ensure that all necessary
    information is entered for each SRA.

-   (Sara) Ask Scarlett Gibb to send a list of the SRAs who are still
    missing data to Suzanne Fisher.

-   (All) Send suggestions for sort alternatives for mailer lists to
    Sara Silver.

-   (Lisa) Add a parameter to sort mailer list that reflects sort
    alternatives from above action.

## RR Module Problems Pending

The group discussed the following action items, from a list presented by
Suzanne Fisher.

### 901

#### Validation of 901 changes

The users are concerned that 901 changes are not always requiring a SEP
identifier. This happens when the committee has been put in the system
as a chartered committee, but without an approved slate. If Receipt and
Referral is changed to look for an approved slate and to require a SEP
identifier if there is no approved slate, problems would come up with
committees that are not SEPs, but have no approved slate in the system.
With this change, those committees would not be accepted unless a SEP
identifier was included.

It was agreed that if the current 901 validation matches the current
assignment validation, no change will need to be made.

**Action: (Mike) Compare the 901 capabilities with assignment validation
to assess feasibility of 901 validation.**

#### Dual Assignments

It is important that no dual assignments disappear, which has happened.
Testing still needs to take place to replicate this problem.

### Bridge Award

When data was bridged from IMPAC I to IMPAC II, certain data affected
the application status codes. An initial fix was made, which made some
correction, but it was determined that a problem still exists. A new fix
is expected in April, and will be done outside the regular release
schedule.

### Coordination of Modules

It appeared that a grant's application status information in the RR
module was different than that in the Review module. Upon discussion,
however, it was determined that the information was in agreement but had
been viewed at different stages of the review process. ***Resolved***.

**Action: (Sara) Close loop with Help Desk regarding the resolution of
the problem of possible data discrepancies between the RR and Review
modules. The issue has been resolved.**

### Council Deferral

When IMPAC I logic was copied to IMPAC II, some of the logic did not
transfer over, which is probably causing this problem of the correct
applications not appearing in Table 10.

**Action: Investigate why Table 10 data is not correct and determine a
fix.**

### Duplicate Applications

When the system runs slowly, it is possible for the same number to be
assigned to two different applications by two people working at the same
time. The chances of it happening when the system is working a normal to
fast speed are slim. However, the system has been slow and one number
was assigned to two applications.

It was agreed that the problem should resolve itself when the system is
functioning at full speed, but that, as a precaution, the User Support
Branch will monitor a weekly report of the accession numbers for three
months. Should the problem reappear with some frequency, she will report
it for further investigation and request a fix. Should it not appear or
only very occasionally and only when the system has been reported to be
slow, she will continue to monitor the accession numbers but will not
report the problem.

### Type 5 Disaggregation

RR should not be processing Type 5s. However, should RR try to process a
Type 5, it will no longer shut down the system, but rather a warning
will appear.

### IRG Chief

The system stores data referring to past IRG chiefs for archival
purposes. The current IRG chief is designated as "Primary." However, the
code on a mailer did not designate to pull the Primary IRG chief so that
mailer was sent to all IRG chiefs, past and present.

Action: (Lisa) Fix the code next week so that mailers only pull the data
for the Primary IRG chief.

### Letters

Action: (Scarlett, Toni) Meet to determine how to create new letters.

### Mailers

There have been numerous problems with *assignment* and *change of
assignment* mailers, including: lack of SRA work addresses; lack of
return address on mailer; changes in font that, in turn, creates
problems with information fitting into the window; placement of
information on page to fit in window properly; and delivery from CIT.
***All problems except the first (SRA work address) have been
resolved.***

The major issues affecting this remaining problem are: Committee
Management control of data and insufficient means of getting all of the
data from the SRAs.

Committee Management is responsible for maintaining the correct data.
However, the CM module is currently in redesign so an immediate
resolution is not feasible. Additionally, there is minimum maintenance
being done on the current module because of the redesign. It was agreed
that CM must address this data issue.

Action: (Sara) Send a request to the CM redesign group that they
incorporate business rules in the redesigned module to ensure that all
necessary information is entered for each SRA.

Action: (Sara) Ask Scarlett Gibb to send a list of the SRAs who are
still missing data to Suzanne Fisher.

It was agreed that each IC should manage their own SRAs and their
associated data in the CM module. In addition, single point of ownership
for federal staff will be implemented in July. At that time, SRAs can
update their own profiles.

#### Order of Mailers

Mailers are listed in random order, making it difficult to find a
particular mailer. It was requested that a parameter be added that
allows the user to sort the list in a specific order.

Action: (All) Send suggestions for sort alternatives for mailer lists to
Sara Silver.

Action: (Lisa) Add a parameter to sort mailer list that reflects sort
alternatives from above action.

### Print Status

This issue---unable to print Status for accession #791815---was fixed in
January.

### Status 70

The incorrect coding of Status 70 for a released application is a
byproduct of the system slowdown, which should be fixed soon.

### Summary Statement Notice

This problem was received from NIGMS and it is a Review module issue.
The person who sent the problem should call the Helpdesk for resolution.

## Working Off-Line

Suzanne Fisher asked if there is a way to work off-line because of the
time lost recently due to system slowdowns. After discussion, where it
was pointed out that the ability to work off-line might require another
module and an API, it was agreed that if Brent Stanfield is interested
in pursuing this issue, his first step would be to present it to the
Project Team for consideration. If the Project Team and JJ agree, then
research would begin to make it possible.

## March Release Fixes

The following problems will be fixed in the March release:

-   Wrong SRA name for SSS N.

-   Default to uppercase letters.

## May Release

The group discussed the following items, which are scheduled for the May
release.

### May Release Fixes

The following problems will be fixed in the May release:

-   SRAs not displaying correctly for pre-1998 meetings.

-   Allow user to generate label when the application is released from
    DRR.

-   Records are being incorrectly displayed on the R&R Council Deferral
    screen.

-   Change position of fields on View Application Status screen.

-   Losing unscored review outcomes if later amended application is
    entered.

### Enter 901 change: Type 8 Processing

Type 8 processing is being incorporated within the 901 screen. The
changes will be added to the User Manual, but not at the time of the
release.

**Grant Application Form 398: Processing Chairman's Grants**

There have been 19 Chairman's Grants since 1994. They are entered
through IMPAC I and bridged to IMPAC II. There must be a way to enter
them directly into IMPAC II. ***No resolution at this time.***

### Enter Referral Data Screen: Grant numbers are not being validated correctly

There will be a warning (e.g., Warning! This number already exists!)
instead of a system lock-up when possible duplicate grant numbers are
entered.

### Data Entry Screens: Preventing some profile-level data from update when profile associated with Commons Version 2 account has been validated.

This issue is related to the single-point-of-ownership for Commons.

The fundamental issue is that if a PI has an account profile in Commons,
which links to IMPAC II, RR will make changes at the role level but not
at the profile level, on selected fields.

QRC is going to clean up the databases, checking discrepancies between
the profiles on Commons and IMPAC II.

### Reset serial numbers for NCI grants

With only 800 new numbers available, NCI is about to run out of 5-digit
serial numbers, and so is going to move to 6-digit serial numbers.
However, because the repercussions on associated systems throughout NIH
(e.g., OFM) that cannot accommodate 6-digit serial numbers yet, the
change will not take place immediately. In the meantime, old, 5-digit
numbers that have never been used will be assigned when the new numbers
are depleted. So that no one questions the use of the old numbers, a
newsletter article will be published to explain their use.

### Social Security number entry

Social security numbers cannot be deleted once they are in the system,
even if incorrect or all zeroes are used. In RR, people were entering
all zeroes since the Social Security number was optional and those
entering data thought the SS field was mandatory. This has caused some
data integrity problems.

For the system to operate properly, the social security field must
either have numbers or be left blank.

## Attendees

**Chen, Lisa,** NGIT

**Cragg, Kimberly,** CSR

**Datoc, Stella,** NGIT

**Dutcher, Sylvia,** Mitretek

**Fato, Mike,** CSR

**Fisher, Suzanne,** CSR

**Panniers, Richard,** CSR

**Seppala, Sandy,** OCO/OD

**Silver, Sara,** OD/OER

**Wright, Judith,** NGIT