Items & Relationships


In SPAERC, there is a logical hierarchy of items related to a project as it moves through time from proposal application to awarded project and eventual completion of research and close-out.

There are five types of items you can process in SPAERC:

  • Applications (eGC1s)
  • Administrative actions (NAA, PAN, PAC, CO, AA)
  • Funding actions (FA)
  • Cycles (C)
  • Subawards (SC)

Note: You may also see Advance Budget Number Requests (ADV) in SPAERC. The research team creates these items in SAGE. They are processed by Grants and Contract Accounting (GCA). You can view, but not modify, an ADV in SPAERC.

When an item of one type is related to another, they are referred to as parent and child. A “parent” item might be a cycle, application, or action and its “child” might be an application or another action.

The Cycle is the top of the hierarchy and so it has no parent. Cycles contain three possible types of children:

  • NAA
  • PAN
  • eGC1

Generally, but not always, the parent item is created first. You can then create child items from within the parent item. For example, you can create a funding action from within an application. If you create the child from within the parent item, it inherits basic project information (PI, sponsor, etc.) from that parent item.

Some parent-child relationships are specifically defined, while others are more general. The following table indicates the typical relationships between items, with current exceptions noted.

Item Type Parent Children
Cycle (none) NAA, PAN, or eGC1
eGC1 Cycle [1] FA, NAA, CO, AA, ADV
PAN Cycle [2] (none)
FA eGC1 [3] PAC, SC
PAC FA (none)
NAA Cycle, eGC1, or FA (none)
CO eGC1 (none)
AA Cycle, eGC1, or FA (none)
SC (subaward) FA (none)
ADV (advance budget number request) eGC1 (none)

Currently, the system also allows

  1. An eGC1 to be the child of another eGC1.
  2. A PAN to be the child of an eGC1 or an FA.
  3. A CO to be the child of a Cycle, eGC1, or an FA.


You can create administrative actions and funding actions as independent items (“orphans”) rather than from a parent item. This enables you, for example, to start a Funding Action while the research team creates and routes the after-the-fact parent eGC1. Once you have access to the parent, you should related the orphan action to it.

0 people found this article helpful.