A Yes/No flag indicating whether the proposal was awarded funding under ARRA (the American Recovery and Reinvestment Act of 2009, also known as the Recovery Act or the federal economic stimulus program). ARRA_AWARD_FLAG is 'Y' if the proposal has 'ARRA (Stimulus) Funding Award' listed as one of its Terms and Conditions. Proposals with awarded ARRA funding are flagged so that the University can satisfy the reporting requirements specified under federal regulations for ARRA funding recipients.

Note:

• A proposal might have ARRA funding awarded even if the proposal was not submitted in response to a Recovery Act funding opportunity and did not otherwise request ARRA funding.
• When ARRA_AWARD_FLAG is 'Y' , the proposal ought to have at least one increment whose status is 'Awarded' and whose awarded total sponsor costs were funded under ARRA.
• If a proposal has awarded ARRA funding, that does not necessarily mean that all of its funded project sponsor costs are ARRA dollars. AWD_PROJECT_SPON_COSTS in the PENNERA_PROPOSAL table stores the total of the AWARDED_TOT_SPON_COSTS for all of the PENNERA_INCREMENT records for the proposal. When reporting on ARRA dollars, rather than using AWD_PROJECT_SPON_COSTS, you might want to summarize the AWARDED_TOT_SPON_COSTS for specified PENNERA_INCREMENT records for the ARRA proposals. Business Objects users can get that summarized value by using SUM Awarded Tot Spon Costs (INCR), found in the Universe's Pennera Increment folder. When specifying conditions for the PENNERA_INCREMENT records, remember that:
  • besides ARRA funding, the proposal might or might not also have other (non-ARRA) awarded funding. (See the ARRA_FUNDED_INCREMENT_FLAG in the PENNERA_INCREMENT table.)
  • some increments whose ARRA_FUNDED_INCREMENT_FLAG is 'Y' might have a status other than 'Awarded'. (See INCREMENT_STATUS in the PENNERA_INCREMENT table.) Depending on the requirements of a particular report on ARRA proposals, you might or might not want to specify a condition on INCREMENT_STATUS.

See also ARRA_SUBMISSION_FLAG and PROJECT_MAJOR_GOALS in the PENNERA_PROPOSAL table, and ARRA_FUNDED_INCREMENT_FLAG in the PENNERA_INCREMENT table.

Values:
Y yes, the proposal was awarded 
  funding under ARRA
N no, the proposal was not awarded 
  funding under ARRA

A Yes/No flag indicating whether the proposal was submitted in response to a Recovery Act funding opportunity, or otherwise requested funding under ARRA (the American Recovery and Reinvestment Act of 2009, also known as the Recovery Act or the federal economic stimulus program). Proposals with requested ARRA funding are flagged so that the University can monitor its success rate for these proposals.

See also ARRA_AWARD_FLAG and PROJECT_MAJOR_GOALS in the PENNERA_PROPOSAL table, and ARRA_FUNDED_INCREMENT_FLAG in the PENNERA_INCREMENT table.

Values:
Y yes, the proposal requested 
  funding under ARRA
N no, the proposal did not request 
  funding under ARRA

The ending date for the awarded project period for the proposal, as defined by the sponsor. The project period, or funding cycle, is a discrete period of time for which a sponsor has committed funds that can be expended by the University for the sponsored project. A project period may include one or more budget periods.

Example: 01/31/2004

Values:

List of values not available.

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): Budget; Awarded; Awarded Project Period Dates section; date to the right of the ‘-‘

The fiscal year at Penn in which the AWARDED_PROJECT_END falls. Penn's fiscal year begins July 1 of one calendar year and ends June 30 of the next calendar year.

Example: 2004 (for a budget period whose
AWARDED_PROJECT_END is December 31, 2003)

Values:
List of values not available.

The fiscal year at Penn in which the AWARDED_PROJECT_START falls. Penn's fiscal year begins July 1 of one calendar year and ends June 30 of the next calendar year.

Example: 2004 (for a budget period whose
AWARDED_PROJECT_START is December 31, 2003)

Values:
List of values not available.

The beginning date for the awarded project period for the proposal, as defined by the sponsor. The project period, or funding cycle, is a discrete period of time for which a sponsor has committed funds that can be expended by the University for the sponsored project. A project period may include one or more budget periods.

Example: 2/15/2002

Values:

List of values not available.

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): Budget; Awarded; Awarded Project Period Dates section; date to the left of the ‘-‘

Values:
Y yes, the award includes cost sharing
N no, the award does not include cost sharing

The total dollar amount designated to be paid by the sponsor for direct costs for all of the increments associated with the proposal (project period). Direct costs are clearly identifiable costs related to a specific project. (For example, salaries, wages, and equipment fall under direct costs.)

AWD_PROJECT_DIR_COSTS + AWD_PROJECT_INDIR_COSTS =
AWD_PROJECT_SPON_COSTS

Note that AWD_PROJECT_DIR_COSTS is calculated based on all of the increments associated with the proposal, regardless of the current status of the increment ('Advance Account', 'Awarded', or 'Future').

Values:
0 to 99,999,999,999.99

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): General; Budget; Budget Information Awarded section; Project row; Direct column

AWD_PROJECT_DIR_COSTS + AWD_PROJECT_INDIR_COSTS =
AWD_PROJECT_SPON_COSTS

Note that AWD_PROJECT_INDIR_COSTS is calculated based on all of the increments associated with the proposal, regardless of the current status of the increment ('Advance Account', 'Awarded', or 'Future').

Values:
0 to 99,999,999,999.99

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): General; Budget; Budget Information Awarded section; Project row; Indirect column

AWD_PROJECT_NONSPON_COSTS + AWD_PROJECT_SPON_COSTS =
AWD_PROJECT_TOTAL_COSTS

Note that AWD_PROJECT_NONSPON_COSTS is calculated based on all of the increments associated with the proposal, regardless of the current status of the increment ('Advance Account', 'Awarded', or 'Future').

Values:
0 to 99,999,999,999.99

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): Budget; Awarded; Award Summary section; Total row; Inst column

The total dollar amount designated for sponsor costs for all of the increments associated with the proposal (project period). The sponsor costs are the total costs (direct and indirect) that are paid for by the sponsor.

AWD_PROJECT_DIR_COSTS + AWD_PROJECT_INDIR_COSTS =
AWD_PROJECT_SPON_COSTS

AWD_PROJECT_NONSPON_COSTS + AWD_PROJECT_SPON_COSTS =
AWD_PROJECT_TOTAL_COSTS

Note that AWD_PROJECT_SPON_COSTS is calculated based on all of the increments associated with the proposal, regardless of the current status of the increment ('Advance Account', 'Awarded', or 'Future').

Values:
0 to 99,999,999,999.99

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): Budget; Awarded; Award Summary section; Total row; Sponsor column

The total dollar amount designated for all costs for all of the increments associated with the proposal (project period). The total costs include all costs (direct and indirect) that are paid for by all funding sources combined.

AWD_PROJECT_NONSPON_COSTS + AWD_PROJECT_SPON_COSTS =
AWD_PROJECT_TOTAL_COSTS

Note that AWD_PROJECT_TOTAL_COSTS is calculated based on all of the increments associated with the proposal, regardless of the current status of the increment ('Advance Account', 'Awarded', or 'Future').

Values:
0 to 99,999,999,999.99

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): Budget; Awarded; Award Summary section; Total row; Project column

Example: 93.371

Values:

List of values not available.

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): General; Sponsor; CFDA

A Yes/No flag that indicates whether the proposal is for an industry-sponsored clinical trial.

The CLINICAL_TRIAL_FLAG is set to 'Y' if at least one of the following is true:

• the INSTRUMENT_TYPE is 'Clinical Trial Agreement'
• the PROGRAM_TYPE is ' Upenn - CTA Single Site' or 'Upenn - CTA Multiple Sites'
• the proposal requires a clinical trial approval (PENNERA_PROPOSAL.INSTITUTION_NO = PENNERA_PROP_REGULATORY_APPR.INSTITUTION_NO and PENNERA_PROP_REGULATORY_APPR.REGULATORY_TYPE = 'CL APPROVAL').

Otherwise, the CLINICAL_TRIAL_FLAG is set to 'N'.

Values:
Y yes, the proposal is a clinical trial
N no, the proposal is not a clinical trial

CLINICAL_TRIAL_PROTOCOL_ID is populated only for proposals for industry-sponsored clinical trials that were entered or updated since October 14, 2003. The value is null for all other records.

Example: 028-003

Values:

List of values not available.

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): General; Sponsor; Award No. (Only if the INSTRUMENT_TYPE is ‘Clinical Trial Agreement' will the Award No. field store both the ID assigned by the sponsor to the award and the clinical trial protocol ID.)

Notes (if any) regarding special conditions that apply to the proposal, as entered in PennERA by Office of Research Services staff.  As stored in the Data Warehouse, the COMMENTS value may have 2,000 characters at most, but it may be longer in PennERA.

The data for COMMENTS is reliable only if the proposal was active in August, 2018 or later.  Before then, PennERA did not capture data for this field.   

Values:
List of values not available.

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): Submissions; [proposal type]; Sponsor; Special Conditions section; Comments

CONFLICT_OF_INT_FLAG is reliable only for records that were entered or updated since October 14, 2003. (The system used before then did not include data for this field.)

Values:
[null] no conflict of interest information has 
      been entered for the proposal
Y yes, the proposal may involve a conflict of 
      interest that needs to be managed
N no, the proposal does not involve a conflict
      of interest that needs to be managed

Cost sharing is funding provided for the sponsored project that does not come from the sponsor. For example, the University receives a grant for a project estimated to have a total cost of $100,000. The sponsor agrees to pay 75% ($75,000) and the University agrees to pay 25% ($25,000). The $25,000 is the cost-sharing component.

PennERA stores more detailed data on cost sharing than was available in the system used before October 14, 2003. Records converted from the legacy system for proposals involving cost sharing have a COST_SHARE_TYPE of ‘Undetermined’.

Values:
Mandatory—the sponsor requires that cost  
     sharing be included in the proposal
Mandatory and Voluntary Committed—the proposal 
     includes both cost sharing required by the  
	 sponsor and cost sharing that the University   
	 has voluntarily committed to provide
None—the proposal involves no cost sharing
Undetermined—the proposal involves cost
     sharing, but the type of commitment has   
	 not been entered into PennERA
Voluntary Committed—the proposal includes 
     cost sharing that the University has  
	 voluntarily committed to provide

The sequence number uniquely identifying the budget period (within the project period) that is the current awarded budget period for the proposal.

The current awarded budget period is the one where the awarded budget period includes the LAST_EXTRACT_DATE and where there is at least one increment whose PENNERA_INCREMENT.INCREMENT_STATUS = 'Awarded'. In other words, the value for CURRENT_PERIOD is the value for PENNERA_PERIOD.PERIOD_NUMBER where PENNERA_PROPOSAL.PROP_NO = PENNERA_PERIOD.PROP_NO and PENNERA_PERIOD.CURRENT_AWARDED_FLAG = 'C'.

The value of the current awarded budget period may be null.

Examples: 2 (the LAST_EXTRACT_DATE falls between the awarded budget period start and end dates for budget period 2, and budget period 2 has at least one increment in 'Awarded' status); [null] (either there is no budget period where the LAST_EXTRACT_DATE falls between the awarded period start and end dates, or such a budget period has no increments in 'Awarded' status)

Values:

List of values not available.

Funding for a proposal may be tracked by more than one fund. For example, if some of the work for the sponsored project is being done on campus, and some is being done off campus, the proposal has two funds with different F&A rates. The prime fund is the one used to track most of the funding for the proposal.

As of October 14, 2003, a fund may be used by one and only one proposal. A proposal whose activity ended before that date might have a fund that was used by another proposal whose activity ended before that date, but such a fund is now disabled.

See also PREVIOUS_PRIME_FUND.

Examples: 537997 (‘5-R01-AI48117-02’); 541102 (‘2003-2005 SCHOLAR AWARD’)

Values:
Refer to the FUND_CODES table for values.

DEADLINE_DATE is reliable only for records that were entered or updated since October 14, 2003. (The system used before then did not include data for this field.)

Example: 06/01/2004 (June 1, 2004)

Values:

List of values not available.

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): General; Summary; Deadline

DISAPPROVED_DATE is reliable only for records that were entered or updated since October 14, 2003. (The system used before then did not include data for this field.)

Example: 11/02/2004 (November 2, 2004)

Values:

List of values not available.

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): General; Summary; Disapproved

DISAPPROVED_FY is reliable only for records that were entered or updated since October 14, 2003. (The system used before then did not include data for this field.)

Example: 2005 (for a proposal disapproved November 2, 2004)

Values:

List of values not available.

A Yes/No flag indicating whether the work entailed in the proposal will produce results that are subject to export control laws. See also INTERNATIONAL_COMPONENT_FLAG, INTERNATIONAL_ACTIVITY_FLAG, and INTERNATIONAL_SUBCONTRACT_FLAG.

Export control laws are federal regulations that govern how certain information, technologies, and commodities can be transmitted overseas to anyone, including U.S. citizens, or to a foreign national on U.S. soil. The Office of Research Services' Web page on Export Control Laws provides further information about these laws, including a decision tree to help investigators determine whether their proposals are subject to export control laws.

The data for the EXPORT_CONTROL_LAW_IMPACT_FLAG is reliable only if the proposal was created using PennERA's Proposal Development (PD) module and the Certification by Principal Investigator was completed after April 19, 2010. (Before then, PennERA did not capture data for this field.) The PD_FLAG indicates whether or not the proposal was created using PD. The Data Warehouse does not store information on when the Certification by Principal Investigator was completed.

Values:
Y yes, the proposal is subject to export control laws
N no, the proposal is not subject to export control laws

The FDP_FLAG is reliable only for records that were entered or updated since October 14, 2003. (The system used before then did not include data for this field.) In some records, FDP_FLAG has a null value.

Values:
[null] no information is available regarding
       whether or not the proposal is issued
       under FDP
Y yes, the proposal is issued under FDP
N no, the proposal is not issued under FDP

Example: 00216424

Values:
List of values not available.

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): If the proposal that includes the budget period is the first proposal for the project, FIRST_INSTITUTION_NO is the same as the INSTITUTION_NO (the number on the first line of the Proposal Header [the unlabelled, stationary section at the top of the screen]). If the proposal for the budget period is not the first proposal for the project, FIRST_INSTITUTION_NO is found by using the Previous Prop No
(General; Summary; Previous Prop No) to trace back to the first proposal for the project (the one that has no Previous Prop No).

For example, if the project has only one F&A rate for this awarded project period, and the FUND_USE_FLAG is 'Y', the project uses one fund number to track the awarded sponsor costs throughout this awarded project period (regardless of the budget period). If the FUND_USE_FLAG is 'N', the project uses multiple fund numbers to track the awarded sponsor costs throughout this awarded project period--the fund number changes from budget period to budget period.

To give another example, if the project has two F&A rates for this awarded project period, and the FUND_USE_FLAG is 'Y', the project uses two fund numbers (one per F&A rate) to track the awarded sponsor costs throughout this awarded project period (regardless of the budget period). If the FUND_USE_FLAG is 'N', the project uses multiple fund numbers per F&A rate to track the awarded sponsor costs throughout this awarded project period--the fund number for a given F&A rate changes from budget period to budget period.

Note that the FUND_USE_FLAG does not indicate whether or not more than one fund number is used for the project for this awarded project period. For example, a project might have one F&A rate and have FUND_USE_FLAG = 'Y', but have two funds--one for awarded sponsor costs, and one for awarded non-sponsor costs (cost sharing).

Values:
Y - yes (the project uses the same fund number to track the awarded 
         sponsor costs for a given F&A rate throughout this awarded 
         project period)
N - no  (the project uses a different fund number for each budget 
         period to track the awarded sponsor costs for a given F&A 
         rate throughout this awarded project period)
null - no funds have been set up for this project    

Records with an INSTITUTION_NO less than or equal to 05017400 were converted from the Research Services System (RSS, the system used to track proposals and awards before October 14, 2003). Other records are for proposals created in PennERA.

There are two different unique identifiers for a proposal: INSTITUTION_NO and PROP_NO. INSTITUTION_NO is used by the University. PROP_NO is used internally by the PennERA system. For a given record, INSTITUTION_NO will not have the same value as PROP_NO. While either one may be used when joining PennERA Proposals tables, INSTITUTION_NO is the one recommended for display in reports.

There is one PENNERA_PROPOSAL record per proposal (INSTITUTION_NO or PROP_NO)

Example: 00216424

Values:
List of values not available.

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): any screen for the proposal; the Proposal Header (unlabelled, stationary section at the top of the screen); the number on the first line of the Proposal Header text

The type of arrangement under which funding is provided for the proposal.

Values:
Clinical Trial Agreement
Contract
Cooperative Agreement
Corporate
Grant
Non-Federal
Sponsored Research Agreement

A Yes/No flag indicating whether the proposal involves intellectual property (research results such as inventions, copyrightable materials, and tangible research materials).

Values:
Y yes, the proposal involves intellectual property
N no, the proposal does not involve intellectual property

A Yes/No flag indicating whether the work included under the proposal entails activities occurring outside the United States of America. If the value of the INTERNATIONAL_COMPONENT_FLAG is 'Y', the value of the INTERNATIONAL_ACTIVITY_FLAG may be 'Y' or 'N'. If the value of the INTERNATIONAL_COMPONENT_FLAG is 'N', the value of the INTERNATIONAL_ACTIVITY_FLAG is 'N'.

If the value of the INTERNATIONAL_ACTIVITY_FLAG is 'Y', see the PENNERA_PROPOSAL_INTL_LOCATION table for the countries and regions where this proposal's international activities take place.

See also INTERNATIONAL_COMPONENT_FLAG, INTERNATIONAL_SUBCONTRACT_FLAG, and EXPORT_CONTROL_LAW_IMPACT_FLAG.

The data for the INTERNATIONAL_ACTIVITY_FLAG is reliable only if the proposal was created using PennERA's Proposal Development (PD) module and the Certification by Principal Investigator was completed after April 19, 2010. (Before then, PennERA did not capture data for this field.) The PD_FLAG indicates whether or not the proposal was created using PD. The Data Warehouse does not store information on when the Certification by Principal Investigator was completed.

Values:
Y yes, the proposal entails activities occurring outside the USA
N no, the proposal does not entail any activities occurring outside the USA

A Yes/No flag indicating whether the proposal has a component that in some way involves one or more countries other than the United States of America. A proposal with an international component might or might not entail activities occurring outside the United States of America. It also might or might not include a subcontract, or a consortium agreement, with an entity based outside the USA.

See also INTERNATIONAL_ACTIVITY_FLAG, INTERNATIONAL_SUBCONTRACT_FLAG, and EXPORT_CONTROL_LAW_IMPACT_FLAG.

The data for the INTERNATIONAL_COMPONENT_FLAG is reliable only if the proposal was created using PennERA's Proposal Development (PD) module and the Certification by Principal Investigator was completed after April 19, 2010. (Before then, PennERA did not capture data for this field.) The PD_FLAG indicates whether or not the proposal was created using PD. The Data Warehouse does not store information on when the Certification by Principal Investigator was completed.

Values:
Y yes, the proposal has an international component
N no, the proposal does not have an international component

A Yes/No flag indicating whether the proposal includes a subcontract, or a consortium agreement, with an entity based outside the United States of America. If the value of the INTERNATIONAL_COMPONENT_FLAG is 'Y', the value of the INTERNATIONAL_SUBCONTRACT_FLAG may be 'Y' or 'N'. If the value of the INTERNATIONAL_COMPONENT_FLAG is 'N', the value of the INTERNATIONAL_SUBCONTRACT_FLAG is 'N'.

See also INTERNATIONAL_COMPONENT_FLAG, INTERNATIONAL_ACTIVITY_FLAG, and EXPORT_CONTROL_LAW_IMPACT_FLAG.

The data for the INTERNATIONAL_SUBCONTRACT_FLAG is reliable only if the proposal was created using PennERA's Proposal Development (PD) module and the Certification by Principal Investigator was completed after April 19, 2010. (Before then, PennERA did not capture data for this field.) The PD_FLAG indicates whether or not the proposal was created using PD. The Data Warehouse does not store information on when the Certification by Principal Investigator was completed.

Values:
Y yes, the proposal includes a subcontract, or a consortium 
  agreement, with an international entity
N no, the proposal does not include a subcontract, or a consortium 
  agreement, with an international entity

Example: 10/28/2003

Values:
List of values not available.

In most cases, the value of MODIFIED_BY is the PennID of the person who last modified the proposal by hand. The proposal is considered modified if any change has been made to any information related to the proposal, its budget periods, its requests, or its increments. For records that were converted from the Research Services System (RSS, the system used to track proposals and awards before October 14, 2003), and that have not been updated since then, MODIFIED_BY is ‘CONVERSION’. If the proposal was last modified by a program (rather than by hand), MODIFIED_BY is null.

The name of the person who modified the proposal is PENNERA_PEOPLE.NAME where PENNERA_PEOPLE.PENN_ID = PENNERA_PROPOSAL.MODIFIED_BY

Examples: ‘10014514’, ‘CONVERSION’

Values:
List of values not available.

Example: 10/30/2003

Values:
List of values not available.

Note that the type of the funding source is not necessarily the same as the type of the originating sponsor.

ORIG_SPON_FUNDING_SOURCE is reliable only for records that were entered or updated since October 14, 2003. For records converted from the Research Services System (RSS, the system used to track proposals and awards before October 14, 2003), ORIG_SPON_FUNDING_SOURCE was available only for proposals whose sponsor costs were covered with ‘federal flow through’ dollars (ORIG_SPON_FUNDING_SOURCE= ‘Federal’).

See also ORIGINATING_SPONSOR_CODE

Values:
Commercial/Industrial
Commonwealth of Pennsylvania
Federal
Foreign Governments
Foundations
Hospital/Medical Centers
Other Non-Federal Governments
Other Non-Profit Organizations
Private Associations
Universities

ORIGINATING_SPONSOR_CODE is reliable only for records that were entered or updated since October 14, 2003. (The system used before then did not include data for this field.)

See also ORIG_SPON_FUNDING_SOURCE and SPONSOR_CODE

Example: 09470 (NATIONAL INSTITUTES OF HEALTH)

Values:
Refer to the PENNERA_SPONSOR Table for values.

This data element is reserved for future use.

This data element is reserved for future use.

This data element is reserved for future use.

This data element is reserved for future use.

This data element is reserved for future use.

This data element is reserved for future use.

This data element is reserved for future use.

This data element is reserved for future use.

This data element is reserved for future use.

This data element is reserved for future use.

This data element is reserved for future use.

This data element is reserved for future use.

This data element is reserved for future use.

A Yes/No flag that indicates whether the PennERA record for the proposal was created in Proposal Tracking (PT) or in Proposal Development (PD). PennERA's PT module is used to manage the pre- and post-award information needed by research administrators. The PD module enables PI's and others to create proposal applications to be submitted to sponsors. If a given proposal record was created in PD, the amount of data available for it depends on where it is in the proposal development process.

See also PROPOSAL_STATUS.

Values:
Y yes, the PennERA record for the proposal 
  was created in PD
N no, the PennERA record for the proposal 
  was not created in PD; it was created in PT

The ERA primary org. is the org. flagged as the primary department in the person’s PennERA Profile. Although it is used to secure certain data elements in the Data Warehouse, the ERA primary org. is not used by the University’s business processes.

For Penn staff, the ERA primary org. is the primary (job) appointment org. For Penn faculty, it is the primary academic (job) appointment org., which will not be the same as primary appointment org. for those faculty holding administrative positions. For Penn employees whose job appointments are all on the executive payroll, ERA primary org. is ‘8000’ ('General University Special '). For Penn students, the ERA primary org. is the organizational equivalent of their home Division (for example, ‘0200’, School of Arts and Sciences.) For investigators from the University of Pennsylvania Health System (UPHS), the ERA primary org. is ‘2100’ ('Health System '). For members of the research community who are otherwise not affiliated with Penn, the ERA primary org. is ‘8760' ('Research Services').

PI_ERA_PRIMARY_ORG_CODE reflects the ERA primary org. of the PI for the proposal, as it was at the time of the proposal (funding cycle). Once the funding cycle has ended, the PI_ERA_PRIMARY_ORG_CODE is no longer updated. The dates for the funding cycle are the AWARDED_PROJECT_START and AWARDED_PROJECT_END in the PENNERA_PROPOSAL table. (If the proposal was not awarded, the dates for the funding cycle are the REQUESTED_PROJECT_START and REQUESTED_PROJECT_END in the PENNERA_PROPOSAL table.)

To facilitate Organization-based security, PI_ERA_PRIMARY_ORG_CODE is set to '.' if it would otherwise be null.

Example: 4261 (DM-Rheumatology)

Values:
Refer to the ORG_CODES table for values.

Source: PENNERA_PROPOSAL_INVESTIGATOR. ERA_PRIMARY_ORG_CODE where PENNERA_PROPOSAL_INVESTIGATOR. PENN_ID = PENNERA_PROPOSAL.PI_PENN_ID

The 2-character code for the school or center for the PI_ERA_PRIMARY_ORG_CODE. That identifies the ERA primary organization (‘org.’) for the person identified by the PI_PENN_ID--the Principal Investigator for the proposal.

The ERA primary org. is the org. flagged as the primary department in the person’s PennERA Profile. Although it is used to secure certain data elements in the Data Warehouse, the ERA primary org. is not used by the University’s business processes.

PI_ERA_PRIMARY_SCHOOL_CODE reflects the ERA primary school of the PI for the proposal, as it was at the time of the proposal (funding cycle). Once the funding cycle has ended, the PI_ERA_PRIMARY_SCHOOL_CODE is no longer updated. The dates for the funding cycle are the AWARDED_PROJECT_START and AWARDED_PROJECT_END in the PENNERA_PROPOSAL table. (If the proposal was not awarded, the dates for the funding cycle are the REQUESTED_PROJECT_START and REQUESTED_PROJECT_END in the PENNERA_PROPOSAL table.)

If the PI_ERA_PRIMARY_ORG_CODE is '.', the PI_ERA_PRIMARY_SCHOOL_CODE is also '.'.

Example: 40 (School of Medicine)

Values:
Refer to the CNAC_CODES Table for values. The 
code for a school or center is the same as the 
first 2 characters of the CNAC.

The home org. is the org. that owns the person's employee record and is responsible for its maintenance.

PI_HOME_ORG_CODE reflects the home org. of the PI for the proposal, as it was at the time of the proposal (funding cycle). Once the funding cycle has ended, the PI_HOME_ORG_CODE is no longer updated. The dates for the funding cycle are the AWARDED_PROJECT_START and AWARDED_PROJECT_END in the PENNERA_PROPOSAL table. (If the proposal was not awarded, the dates for the funding cycle are the REQUESTED_PROJECT_START and REQUESTED_PROJECT_END in the PENNERA_PROPOSAL table.) If the PI for the proposal has no employee information dating back to the time of the funding cycle, PI_HOME_ORG_CODE is '.'. (Because the PI_HOME_ORG_CODE is one of the data elements used to secure the data, it is set to '.' if it would otherwise be null.)

Example: 4261 (DM-Rheumatology)

Values:
Refer to the ORG_CODES table for values.

Source: PENNERA_PROPOSAL_INVESTIGATOR. HOME_ORG_CODE where PENNERA_PROPOSAL_INVESTIGATOR. PENN_ID = PENNERA_PROPOSAL. PI_PENN_ID

The home org. is the org. that owns the person's employee record and is responsible for its maintenance.

PI_HOME_SCHOOL_CODE reflects the home school of the PI for the proposal, as it was at the time of the proposal (funding cycle). Once the funding cycle has ended, the PI_HOME_SCHOOL_CODE is no longer updated. The dates for the funding cycle are the AWARDED_PROJECT_START and AWARDED_PROJECT_END in the PENNERA_PROPOSAL table. (If the proposal was not awarded, the dates for the funding cycle are the REQUESTED_PROJECT_START and REQUESTED_PROJECT_END in the PENNERA_PROPOSAL table.) If the PI for the proposal has no employee information dating back to the time of the funding cycle, PI_HOME_SCHOOL_CODE is '.'.

Example: 40 (School of Medicine)

Values:
Refer to the CNAC_CODES Table for values. The 
code for a school or center is the same as the 
first 2 characters of the CNAC.

Although it is used to secure certain data elements in the Data Warehouse, the investigator org. is not used by the University’s business processes.

For a given investigator associated with a proposal, the investigator org. is the org. specified (on the Office of Research Services Proposal Transmittal and Approval Form) as the 'Dept. Administering Project' (the PROPOSAL_RESP_ORG_CODE). An exception to this rule is that, if the PROPOSAL_RESP_ORG_CODE is neither the investigator's ERA primary org. nor an org. where the investigator has a job appointment, when the investigator's data is entered for the proposal in PennERA, the investigator org. is chosen from among those orgs., based on its being the one that is most closely related to the PROPOSAL_RESP_ORG_CODE. In other words:

• if the investigator has only one org, then that org. is chosen; otherwise,
• if the investigator has an org. that is the same as the PROPOSAL_RESP_ORG_CODE, then that org. is chosen; otherwise
• the investigator's orgs. are sorted in ascending order, and the first org. whose org. code is greater than or equal to the PROPOSAL_RESP_ORG_CODE is chosen; otherwise,
• if the investigator has no org. whose org. code is greater than or equal to the PROPOSAL_RESP_ORG_CODE, the investigator's ERA primary org. is chosen

To facilitate Organization-based security, PI_INVESTIGATOR_ORG_CODE is set to '.' if it would otherwise be null.

Example: 4261 (DM-Rheumatology)

Values:
Refer to the ORG_CODES table for values.

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): General; Personnel; the code in the Department column for the person flagged as the PI

Although it is used to secure certain data elements in the Data Warehouse, the investigator org. is not used by the University’s business processes.

If the PI_INVESTIGATOR_ORG_CODE is '.', the PI_INVESTIGATOR_SCHOOL_CODE is also '.'.

Example: 40 (School of Medicine)

Values:
Refer to the CNAC_CODES Table for values. 
The code for a school or center is the same 
as the first 2 characters of the CNAC.

Source: ORG_CODES.CENTER_CODE where PENNERA_PROPOSAL. PI_INVESTIGATOR_ORG_CODE =ORG_CODES.ORGANIZATION_CODE

The PennID is the 8-digit identification number assigned to a person by the Penn Community system. No two persons have the same PennID. However, a person may have more than one PennID. For example, say Dr. John Doe had a sponsored project in 1990, but his Social Security number was not recorded in the Research Services System (RSS, the system then used to track proposals and awards). Dr. Doe left the University after project ended. When the RSS data was converted to PennERA, there was no record in Penn Community for Dr. Doe. Because his Social Security number was not available, a PennERA-specific PennID (beginning with a ‘P’) was created for him. In 2003, Dr. Doe returned to the University, and was assigned a numeric PennID (for example, 10039706). Dr. Doe would then have two PennIDs, but one could not tell from looking at the data that both PennIDs identify the same person.

See also PARENT_PI_PENN_ID

Examples: ‘P1000194’ (Lisa Jay); ‘10006336’ (Herman Gluck)

Values:
Refer to the PENNERA_PEOPLE Table for values. 

The primary academic appointment org. is the org. where the person has his or her primary academic job appointment. If the person has more than one academic job appointment, the primary academic appointment is the one with the most important faculty class. For further information on how the primary academic appointment is determined, see the explanation in the Cautions section of the documentation for the EMPLOYEE_GENERAL table.

PI_PRI_ACAD_APPT_ORG_CODE reflects the primary academic appointment org. of the PI for the proposal, as it was at the time of the proposal (funding cycle). Once the funding cycle has ended, the PI_PRI_ACAD_APPT_ORG_CODE is no longer updated. The dates for the funding cycle are the AWARDED_PROJECT_START and AWARDED_PROJECT_END in the PENNERA_PROPOSAL table. (If the proposal was not awarded, the dates for the funding cycle are the REQUESTED_PROJECT_START and REQUESTED_PROJECT_END in the PENNERA_PROPOSAL table.) If the PI for the proposal has no employee information about a faculty job appointment dating back to the time of the funding cycle, PI_PRI_ACAD_APPT_ORG_CODE is '.'. (Because the PI_PRI_ACAD_APPT_ORG_CODE is one of the data elements used to secure the data, it is set to '.' if it would otherwise be null.)

Example: 4261 (DM-Rheumatology)

Values:
Refer to the ORG_CODES table for values.

Source: PENNERA_PROPOSAL_INVESTIGATOR. PRIMARY_ACADEMIC_ORG_CODE where PENNERA_PROPOSAL_INVESTIGATOR. PENN_ID = PENNERA_PROPOSAL.PI_PENN_ID

The primary academic appointment org. is the org. where the person has his or her primary academic job appointment. If the person has more than one academic job appointment, the primary academic appointment is the one with the most important faculty class. For further information on how the primary academic appointment is determined, see the explanation in the Cautions section of the documentation for the EMPLOYEE_GENERAL table.

PI_PRI_ACAD_APPT_SCHOOL_CODE reflects the primary academic appointment school of the PI for the proposal, as it was at the time of the proposal (funding cycle). Once the funding cycle has ended, the PI_PRI_ACAD_APPT_SCHOOL_CODE is no longer updated. The dates for the funding cycle are the AWARDED_PROJECT_START and AWARDED_PROJECT_END in the PENNERA_PROPOSAL table. (If the proposal was not awarded, the dates for the funding cycle are the REQUESTED_PROJECT_START and REQUESTED_PROJECT_END in the PENNERA_PROPOSAL table.) If the PI for the proposal has no employee information about a faculty job appointment dating back to the time of the funding cycle, PI_PRI_ACAD_APPT_SCHOOL_CODE is '.'.

Example: 40 (School of Medicine)

Values:
Refer to the CNAC_CODES Table for values. 
The code for a school or center is the same 
as the first 2 characters of the CNAC.

Source: PENNERA_PROPOSAL_INVESTIGATOR. PRIMARY_ACADEMIC_SCHOOL_CODE where PENNERA_PROPOSAL_INVESTIGATOR. PENN_ID = PENNERA_PROPOSAL.PI_PENN_ID

The primary appointment org. is the org. where the person has his or her primary job appointment, per the University’s employee census logic. For information on how the primary appointment is determined, see the explanation in the Cautions section of the documentation for the EMPLOYEE_GENERAL table.

PI_PRI_APPT_ORG_CODE reflects the primary appointment org. of the PI for the proposal, as it was at the time of the proposal (funding cycle). Once the funding cycle has ended, the PI_PRI_APPT_ORG_CODE is no longer updated. The dates for the funding cycle are the AWARDED_PROJECT_START and AWARDED_PROJECT_END in the PENNERA_PROPOSAL table. (If the proposal was not awarded, the dates for the funding cycle are the REQUESTED_PROJECT_START and REQUESTED_PROJECT_END in the PENNERA_PROPOSAL table.) If the PI for the proposal has no employee information dating back to the time of the funding cycle, PI_PRI_APPT_ORG_CODE is '.'. (Because the PI_PRI_APPT_ORG_CODE is one of the data elements used to secure the data, it is set to '.' if it would otherwise be null.)

Example: 4261 (DM-Rheumatology)

Values:
Refer to the ORG_CODES table for values.

Source: PENNERA_PROPOSAL_INVESTIGATOR. PRIMARY_APPT_ORG_CODE where PENNERA_PROPOSAL_INVESTIGATOR. PENN_ID = PENNERA_PROPOSAL.PI_PENN_ID

The primary appointment org. is the org. where the person has his or her primary job appointment, per the University’s employee census logic. For information on how the primary appointment is determined, see the explanation in the Cautions section of the documentation for the EMPLOYEE_GENERAL table.

PI_PRI_APPT_SCHOOL_CODE reflects the primary appointment school of the PI for the proposal, as it was at the time of the proposal (funding cycle). Once the funding cycle has ended, the PI_PRI_APPT_SCHOOL_CODE is no longer updated. The dates for the funding cycle are the AWARDED_PROJECT_START and AWARDED_PROJECT_END in the PENNERA_PROPOSAL table. (If the proposal was not awarded, the dates for the funding cycle are the REQUESTED_PROJECT_START and REQUESTED_PROJECT_END in the PENNERA_PROPOSAL table.) If the PI for the proposal has no employee information dating back to the time of the funding cycle, PI_PRI_APPT_SCHOOL_CODE is '.'.

Example: 40 (School of Medicine)

Values:
Refer to the CNAC_CODES Table for values. 
The code for a school or center is the same 
as the first 2 characters of the CNAC.

Source: PENNERA_PROPOSAL_INVESTIGATOR. PRIMARY_APPT_SCHOOL_CODE where PENNERA_PROPOSAL_INVESTIGATOR. PENN_ID = PENNERA_PROPOSAL.PI_PENN_ID

Example: 00216424

Values:
List of values not available.

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): General; Summary; Previous Prop No

One example of a proposal with a PREVIOUS_PRIME_FUND is an awarded proposal in its second year, whose sponsor requires that a different fund be used each year. Another example of a proposal with a PREVIOUS_PRIME_FUND is an awarded proposal for a project that was funded in previous project periods.

As of October 14, 2003, a fund may be used by one and only one proposal. A proposal whose activity ended before that date might have a fund that was used by another proposal whose activity ended before that date, but such a fund is now disabled.

See also CURRENT_PRIME_FUND.

Examples: 537997 (‘5-R01-AI48117-02’); 541102 (‘2003-2005 SCHOLAR AWARD’)

Values:
Refer to the FUND_CODES table for values.

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): General; Summary; Ref Acct

Example: 05/14/2004

Values:

List of values not available.

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): General; Summary; Processed Date

See also SPONSOR_PROGRAM_ID

Values:
Upenn - Community Service
Upenn - Conference
Upenn - CTA Individual Site
Upenn - CTA Multiple Sites
Upenn - Facilities/Equipment
Upenn - Fellowship
Upenn - Other
Upenn - Research
Upenn - RFP/RFA
Upenn - Training

A brief narrative describing the overall purpose of the project to be funded per the proposal. PROJECT_MAJOR_GOALS might or might not be null.

In order for the University to satisfy the reporting requirements specified under federal regulations for ARRA funding recipients, PROJECT_MAJOR_GOALS ought to be populated for proposals that have funding awarded under ARRA (the American Recovery and Reinvestment Act of 2009, also known as the Recovery Act or the federal economic stimulus program). For those proposals, the PROJECT_MAJOR_GOALS ought to describe the project's overall purpose and its expected outputs, outcomes, or results; if applicable, units of measure ought to be specified for significant deliverables. If an ARRA-funded proposal includes multiple projects or activities, such as a formula block grant, the purpose and outcomes or results may be stated in broad terms.

If a query selects PENNERA_PROPOSAL records where PROJECT_MAJOR_GOALS is not null:

• The query results might include some records whose PROJECT_MAJOR_GOALS value looks null (empty), but is not really null. In PennERA, the source field for PROJECT_MAJOR_GOALS might look empty, but might contain blanks or unprintable characters (such as tabs or carriage returns). When a proposal record is exported to the Warehouse, the PROJECT_MAJOR_GOALS data is "scrubbed" so that, if the source field looks empty in PennERA, or if it contains just one character, PROJECT_MAJOR_GOALS is null in the Warehouse. However, the scrubbing algorithm might not cover all cases where non-null source values ought to be exported as null values.
• The query results might include some records whose PROJECT_MAJOR_GOALS value is truncated. PROJECT_MAJOR_GOALS stores just the first 4,000 characters of the narrative stored in PennERA.
• The query results might include some records whose PROJECT_MAJOR_GOALS value is ‘N/A’ (or some other character string) rather than the expected description of the project's purpose. For these records, PROJECT_MAJOR_GOALS stores whatever was entered in the source field in PennERA.

See also ARRA_AWARD_FLAG and ARRA_SUBMISSION_FLAG in the PENNERA_PROPOSAL table, and ARRA_FUNDED_INCREMENT_FLAG in the PENNERA_INCREMENT table.

Examples: ‘N/A’; 'Funds are requested for a shared instrument to support existing NIH and other grants.'

Values:

List of values not available.

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): General; Summary; Major Goals of the project

Example: ‘VECTORS’

Values:

List of values not available.

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): General; Summary; Short Title

Example: ‘LENTIVIRUS VECTORS FOR CYSTIC FIBROSIS GENE THERAPY’

Values:

List of values not available.

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): General; Summary; Project Title

There are two different unique identifiers for a proposal: INSTITUTION_NO and PROP_NO. INSTITUTION_NO is used by the University. PROP_NO is used internally by the PennERA system. For a given record, INSTITUTION_NO will not have the same value as PROP_NO. While either one may be used when joining PennERA Proposals tables, INSTITUTION_NO is the one recommended for display in reports.

There is one PENNERA_PROPOSAL record per proposal (INSTITUTION_NO or PROP_NO

Example: ‘0000000217’

Values:
List of values not available.

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): any screen for the proposal; the Proposal Header (unlabelled, stationary section at the top of the screen); the PROP_NO for the INSTITUTION_NO (INSTITUTION_NO is the number on the first line of the Proposal Header text; PROP_NO is not shown)

To facilitate Organization-based security, PROPOSAL_RESP_ORG_CODE is set to '.' if it would otherwise be null.

Example: 4261 (DM-Rheumatology)

Values:
Refer to the ORG_CODES table for values.

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): General; Summary; Associated Department section; the code listed in the Department column for the row flagged as Primary

The 2-character code for the school or center for the PROPOSAL_RESP_ORG_CODE -- the organization responsible for the proposal.

If the PROPOSAL_RESP_ORG_CODE is '.', the PROPOSAL_RESP_SCHOOL_CODE is also '.'.

Example: 40 (School of Medicine)

Values:
Refer to the CNAC_CODES Table for values. 
The code for a school or center is the same 
as the first 2 characters of the CNAC.

Source: ORG_CODES.CENTER_CODE where PENNERA_PROPOSAL. PROPOSAL_RESP_ORG_CODE =ORG_CODES.ORGANIZATION_CODE

The current status of the proposal, per the sponsor’s response to the first request associated with the proposal.

See also PROPOSAL_STATUS_DATE

Values:
Advance Account—one or more accounts have been 
   created to track an advance paid by the department 
   in expectation of an award
Awarded--the sponsor has awarded funding for the 
   proposal
Closed--the accounts for the proposal have been  
   closed in BEN
In Process--the initial status for all proposal 
   records (and only those proposal records) 
   created in PennERA on or after Sept. 6, 2005 
   via the SOMERA Interface (PennERA’s interface 
   with the School of Medicine’s Electronic 
   Research Administration system); the proposal 
   requires further processing before it is approved 
   for submission to the sponsor.  (This is true 
   even though there may be a non-null value for 
   PENNERA_PROPOSAL.SUBMITTED_DATE.)
Negotiation—the University and the sponsor 
   are negotiating the terms of the proposal
Negotiation Complete— the University and the
   sponsor have agreed upon the terms of the 
   proposal, and the University is awaiting 
   notification from the sponsor regarding awarded
   funding for the proposal
Pending—the Office of Research Services has
   given its approval for the proposal to be
   submitted to the sponsor; the proposal is 
   pending a decision by the sponsor
Revised Budget Requested—the sponsor has 
   requested a revised budget for the proposal
Under Development—the proposal record has 
   been created in the Proposal Development
   module of PennERA, but the proposal has not
   yet been submitted for University approval
Under Review—the proposal record (created
   in the Proposal Development module of 
   PennERA) has been submitted for University 
   approval (required before the proposal can be 
   submitted to the sponsor)
Unfunded—the sponsor has notified the
   University that it will not fund the proposal
Withdrawn—the Principal Investigator has 
   withdrawn the proposal from consideration by 
   the sponsor

Example: 11/15/2004

Values:

List of values not available.

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): General; Summary; Status link; below the Add section; Date shown in the first row

Example: 2005 (for a proposal whose status was last updated November 15, 2004)

Values:

List of values not available.

The type of request for funding for the project period (funding cycle). The PROPOSAL_TYPE indicates the reason for requesting funding for this funding cycle, as noted in the 'Type of Proposal' field on the Office of Research Services Proposal Transmittal and Approval Form that was submitted with the first request for funding for this funding cycle.

Note that the PROPOSAL_TYPE may be null if the PROPOSAL_STATUS is ‘Under Development’ and information on the proposal type has not yet been entered for the proposal.

Note that some values of PROPOSAL_TYPE are meant for use only in records that were originally created before October 14, 2003. (Those records were created, not in PennERA, but in the Research Services System (RSS)--the system previously used by the Office of Research Services to track proposals and awards for sponsored projects.) Those values are 'Extension', 'Non-Competing Continuation', 'Revised Budget', and 'Supplemental'.

'Extension' indicates that, in RSS, there was an extension of a budget period beyond the original budget period end date. In PennERA, information on extensions is stored at the increment level (PENNERA_INCREMENT.AWARD_TYPE = 'Extension'.)

'Non-Competing Continuation' indicates that, in RSS, the record applied to a budget period other than the first one for the funding cycle. In PennERA, the non-competing continuations (if any) for a given proposal are stored under budget periods 2 and up. A non-competing continuation request has PENNERA_REQUEST.REQUEST_TYPE = 'Budget Period'. A non-competing continuation increment has PENNERA_INCREMENT.AWARD_TYPE = 'Non-Competing Continuation'.

'Revised Budget' was meant to indicate that, in RSS, there was a revision to the budget. However, there are no PENNERA_PROPOSAL records with PROPOSAL_TYPE = 'Revised Budget'. In PennERA, information on revised budgets is stored at the increment level (PENNERA_INCREMENT.AWARD_TYPE = 'Revised Budget'.)

'Supplemental' indicates that, in RSS, a supplement was requested or awarded for a budget period. In PennERA, information on supplements is stored at the request level and the increment level. A supplement request has PENNERA_REQUEST.REQUEST_TYPE = 'Supplement'. A supplement increment has PENNERA_INCREMENT.AWARD_TYPE = 'Supplement'.

Values:
Change of Grantee Inst
Competing (Renewal)
CTA - Early review
CTA/SRA – Amendment
Extension (used only for 
  records created before Oct. 14, 2003)
New Project
Non-Competing Continuation (used only 
  for records created before Oct. 14, 2003)
Pre-Proposal
Revised Budget (used only for records 
  created before Oct. 14, 2003)
Revision
Supplemental (used only for records 
  created before Oct. 14, 2003)

Values:
Y yes, the proposal requests cost sharing
N no, the proposal does not request cost sharing

REQ_PROJECT_DIR_COSTS + REQ_PROJECT_INDIR_COSTS =
REQ_PROJECT_SPON_COSTS

Note that REQ_PROJECT_DIR_COSTS is calculated based on all of the requests associated with the proposal. Regardless of the current status of the request ('Pending', 'Awarded', etc.), the value of REQ_PROJECT_DIR_COSTS reflects what was requested, not what was awarded. (For the awarded amount, see AWD_PROJECT_DIR_COSTS.)

Values:
0 to 99,999,999,999.99

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): General; Budget; Budget Information Requested section; Project row; Direct column

REQ_PROJECT_DIR_COSTS + REQ_PROJECT_INDIR_COSTS =
REQ_PROJECT_SPON_COSTS

Note that REQ_PROJECT_INDIR_COSTS is calculated based on all of the requests associated with the proposal. Regardless of the current status of the request ('Pending', 'Awarded', etc.), the value of REQ_PROJECT_INDIR_COSTS reflects what was requested, not what was awarded. (For the awarded amount, see AWD_PROJECT_INDIR_COSTS.)

Values:
0 to 99,999,999,999.99

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): General; Budget; Budget Information Requested section; Project row; Indirect column

REQ_PROJECT_NONSPON_COSTS +
REQ _PROJECT_SPON_COSTS =
REQ _PROJECT_TOTAL_COSTS

Note that REQ_PROJECT_NONSPON_COSTS is calculated based on all of the requests associated with the proposal. Regardless of the current status of the request ('Pending', 'Awarded', etc.), the value of REQ_PROJECT_NONSPON_COSTS reflects what was requested, not what was awarded. (For the awarded amount, see AWD_PROJECT_NONSPON_COSTS.)

Values:
0 to 99,999,999,999.99

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): Budget; Requested; Budget Summary section; Total row; Inst column

The total dollar amount designated for sponsor costs for all of the requests associated with the proposal (project period). The sponsor costs are the total costs (direct and indirect) that are being requested from the sponsor.

REQ_PROJECT_DIR_COSTS + REQ_PROJECT_INDIR_COSTS =
REQ_PROJECT_SPON_COSTS

REQ_PROJECT_NONSPON_COSTS +
REQ _PROJECT_SPON_COSTS =
REQ _PROJECT_TOTAL_COSTS

Note that REQ _PROJECT_SPON_COSTS is calculated based on all of the requests associated with the proposal. Regardless of the current status of the request ('Pending', 'Awarded', etc.), the value of REQ_PROJECT_SPON_COSTS reflects what was requested, not what was awarded. (For the awarded amount, see AWD_PROJECT_SPON_COSTS.)

Values:
0 to 99,999,999,999.99

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): Budget; Requested; Budget Summary section; Total row; Sponsor column

REQ_PROJECT_NONSPON_COSTS +
REQ _PROJECT_SPON_COSTS =
REQ _PROJECT_TOTAL_COSTS

Note that REQ _PROJECT_TOTAL_COSTS is calculated based on all of the requests associated with the proposal. Regardless of the current status of the request ('Pending', 'Awarded', etc.), the value of REQ_PROJECT_TOTAL_COSTS reflects what was requested, not what was awarded. (For the awarded amount, see AWD_PROJECT_TOTAL_COSTS.)

Values:
0 to 99,999,999,999.99

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): Budget; Requested; Budget Summary section; Total row; Project column

Example: 2

Values:
List of values not available.

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): Budget; Requested; Budget Summary section; the last number listed in the Year/Period row

Example: 01/31/2004

Values:

List of values not available.

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): Budget; Requested; Requested Project Period Dates section; date to the right of the ‘-‘

Example: 2004 (for a budget period whose
REQUESTED_PROJECT_END is December 31, 2003)

Values:

List of values not available.

Example: 2004 (for a budget period whose
REQUESTED_PROJECT_START is December 31, 2003)

Values:

List of values not available.

Example: 11/1/2001

Values:

List of values not available.

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): Budget; Requested; Requested Project Period Dates section; date to the left of the ‘-‘

Note: RESP_BA_EMAIL stores the Responsible Business Administrator’s e-mail address per the PennERA Proposal Tracking module’s General / Summary screen for the proposal.

• If a typographical error was made by the person who entered the value in the “Resp BA email” field on the proposal’s General / Summary screen, or if that person entered data in the “Resp BA email” field that ought to have been entered in a different field, RESP_BA_EMAIL stores the erroneous value that was entered.
• PennERA Proposal Tracking users may use upper case and/or lower case letters when entering the Responsible Business Administrator’s e-mail address on the proposal’s General / Summary screen. To make record selection and sorting easier for those generating reports, all letters in RESP_BA_EMAIL are stored in upper case.
• If no one has entered the Responsible Business Administrator’s e-mail address on the proposal’s General / Summary screen, RESP_BA_EMAIL is null.
• In some cases, different people may be the responsible BA at different times in the life of the proposal. In such cases, information is available in the Data Warehouse only for the current responsible BA.

Examples:‘SMITH@SEAS.UPENN.EDU’, ‘JONES@MAIL’

Values:

List of values not available.

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): General; Summary; School Specific Information section; Resp BA email

Note: RESP_BA_NAME stores the Responsible Business Administrator’s name per the PennERA Proposal Tracking module’s General / Summary screen for the proposal.

• If a typographical error was made by the person who entered the value in the “Responsible Business Administrator” field on the proposal’s General / Summary screen, or if that person entered data in the “Responsible Business Administrator” field that ought to have been entered in a different field, RESP_BA_EMAIL stores the erroneous value that was entered.
• PennERA Proposal Tracking users may use upper case and/or lower case letters when entering the Responsible Business Administrator’s name on the proposal’s General / Summary screen. To make record selection and sorting easier for those generating reports, all letters in RESP_BA_NAME are stored in upper case.
• PennERA Proposal Tracking users are not required use a particular format when entering the Responsible Business Administrator’s name. For example, if the name includes a middle initial, that initial might or might not be followed by a period.
• If the proposal has a responsible BA, but no one has entered the Responsible Business Administrator’s name on the proposal’s General / Summary screen, RESP_BA_NAME is null.
• In some cases, different people may be the responsible BA at different times in the life of the proposal. In such cases, information is available in the Data Warehouse only for the current responsible BA.
  

Examples: ‘BENJAMIN FRANKLIN’, 'LA TOYA Y. JACKSON', ‘JOHN Q PUBLIC’, ‘JANE SMITH-JONES’

Values:

List of values not available.

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): General; Summary; School Specific Information section; Responsible Business Administrator

Note: RESP_BA_PHONE stores the Responsible Business Administrator’s phone number per the PennERA Proposal Tracking module’s General / Summary screen for the proposal.

• If a typographical error was made by the person who entered the value in the “Resp BA phone” field on the proposal’s General / Summary screen, or if that person entered data in the “Resp BA phone” field that ought to have been entered in a different field, RESP_BA_EMAIL stores the erroneous value that was entered.
• PennERA Proposal Tracking users are not required use a particular format when entering the Responsible Business Administrator’s phone number. The value might or might not include dashes, spaces, periods, and/or parentheses.
• If no one has entered the Responsible Business Administrator’s phone number on the proposal’s General / Summary screen, RESP_BA_PHONE is null.
• In some cases, different people may be the responsible BA at different times in the life of the proposal. In such cases, information is available in the Data Warehouse only for the current responsible BA.

Examples: ‘8-1234’, ’215-417-1234’, ‘573.2345’, ‘215-242-5432 X 123’, ‘(215)746-1234’

Values:

List of values not available.

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): General; Summary; School Specific Information section; Resp BA phone

The date (if any) when the proposal’s revenue recognition rule was reviewed by the Office of Research Services (ORS). 

The data for the REVENUE_REC_RULE_REVIEW_DATE is reliable only if the proposal was active in August, 2018 or later.  Before then, PennERA did not capture data for this field.

For more information about revenue recognition rule reviews, see the Financial Accounting Standards Board article starting on page 12 of the Fall 2018 issue (Volume 14 Issue 1) of the ORS Newsletter, at http://www.upenn.edu/researchservices/pdfs/Newsletter%20Fall%202018.pdf

Example: 8/24/2018

Values:
List of values not available.

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): Submissions; [proposal type]; Sponsor; Special Conditions section; Revenue Rec Rule Review Date

Example: 1/15/2002

Values:
List of values not available.

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): General; Summary; RS Award Recpt

A Yes/No flag indicating whether the proposal’s sponsor has stipulated requirements that involve scientific milestones (identified performance obligations).

Values:
Y yes, the proposal has scientific milestone requirements
N no, the proposal does not have scientific milestone requirements

PennERA source (assuming the proposal record has been opened in the Proposal Development module): Submissions; [proposal type]; Sponsor; Special Conditions section; Scientific Milestone

SNAP_FLAG is reliable only for records that were entered or updated since October 14, 2003. (The system used before then did not include data for this field.) In some records, SNAP_FLAG has a null value.

Values:
[null] no information is available regarding
       whether or not the proposal is subject to SNAP
Y yes, the proposal is subject to SNAP
N no, the proposal is not subject to SNAP

The University has a financial audit of its books and accounts performed by a certified public accountant annually. A review of selected sponsored project accounts is included in this audit, as well as the University's compliance with certain federal regulations. This audit is performed in accordance with OMB Circular A-133 and should satisfy most federal audit requirements.

Occasionally, a sponsor will request that a specific award be audited either by its own staff or by external audit firm. All such audits must be managed by the Office of Research Services, which will coordinate with the principal investigator and the relevant department and school.

SPECIAL_AUDIT_REQRD_FLAG is reliable only for records that were entered or updated since October 14, 2003. (The system used before then did not include data for this field.) In some records, SPECIAL_AUDIT_REQRD_FLAG has a null value.

Values:
[null] no information is available regarding
       whether or not the proposal requires
       a special audit
Y yes, the proposal requires a special audit
N no, the proposal does not require a special audit

Codes less than or equal to 599999 were assigned to the sponsor by InfoEd (the vendor of the PennERA software). Codes greater than or equal to 60000 were assigned to the sponsor by the Office of Research Services.

See also ORIGINATING_SPONSOR_CODE

Example: 09470 (NATIONAL INSTITUTES OF HEALTH)

Values:
Refer to the PENNERA_SPONSOR Table for values.

See also PROGRAM_TYPE

SPONSOR_PROGRAM_ID is reliable only for records that were entered or updated since October 14, 2003. (The system used before then did not include data for this field.)

Example: RFA-HD-08-013 (Course Development in the Neurobiology of Disease)

Values:

List of values not available.

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): General; Sponsor; Special Terms & Conditions section; ID No.

The identification number (if any) that is assigned by the sponsoring agency to the proposal (funding cycle) for the sponsored project. When the value is null or 'N/A', the sponsoring agency has not assigned an identification number to the proposal.

If the proposal is funded by the sponsor, SPONSOR_PROJECT_AWARD_NO ought to have the same value as the SPONSOR_AWARD_ID in the PENNERA_INCREMENT record where INCREMENT_NUMBER = '1'.

Example: 1-R25-MH-076778-01 (an identification number assigned by NIH)

Values:

List of values not available.

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): General; Sponsor; first section; Award No.

Example: 05/14/2004

Values:

List of values not available.

PennERA source (assuming the proposal record has been opened in the Proposal Tracking module): General; Summary; Submitted

Example: 2004 (for a proposal submitted 05/14/2004)

Values:

List of values not available.

Not currently used.

If the proposal is a parent proposal (for example, if it is for a program project), SUBPROJECT_COUNT is the number of ‘child’ proposals associated with the parent proposal. If the proposal is not a parent proposal, SUBPROJECT_COUNT is ‘0’. Note that SUBPROJECT_COUNT is a character, not a numeric field.

Examples: ‘3’ (The proposal is a parent proposal that is associated with three other proposals for its subprojects (subaccounts).); ‘0’ (The proposal has no subprojects. It may be a subproject (subaccount) of another proposal, or it may be a ‘free-standing’ proposal—neither a parent nor a subproject.)
See also PARENT_INSTITUTION_NO

Values:

List of values not available.