Hi Kim,
Thanks for that clarification. I'm wondering if we can diagnose the issue as coming from the setup of the Consolidate Academic Statistics process (i.e., in the configuration of academic statistics periods, typically defined by a list of distinct term/career combinations) or from the setup of the NSC enrollment extract (e.g., some customization being applied after the consolidate statistics process...). When you query the EMPLID of a student duplicated on the NSC report from the Student Consolidated Stats record (STDNT_CONS_STAT), selecting ACAD_STATS_PERIOD, are you seeing multiple rows per EMPLID and ACAD_STATS_PERIOD? If you bring in all fields from the STDNT_CONS_STAT record, do any of the fields vary across these multiple rows, particularly any that might explain the duplication issue as it might relate to the multiple sessions? For instance, do Career (ACAD_CAREER) or term (STRM) vary across these rows for the same ID and stats period? What about TERM_TYPE? You said it's different sessions within the same program, so I'm assuming the career is the same and there's not some issue with the career or program primacy setup... but perhaps a session was set up at the same level as the term (i.e., as a statistics period key)? Or you could write a super quick query that selects fields of interest (e.g., career, term, etc.) using the DISTINCT keyword to see the general setup without bringing in individual student IDs, like the following:
|
SELECT DISTINCT A.ACAD_STATS_PERIOD, A.ACAD_CAREER, A.STRM, A.TERM_TYPE
FROM PS_STDNT_CONS_STAT A
WHERE ( A.ACAD_STATS_PERIOD = '[INSERT APPLICABLE STATS PERIOD VALUE]')
|
If there are no duplicate rows for a given stats period, career, and term, then the problem is most likely occurring in the generation of the NSC report itself, and you may want to investigate whether your technical team had modified anything related to the NSC extract process (SRNSLCEX.SQR) or the consolidate academic statistics setup (SRPCCONP) for that matter.
If you DO see multiple rows per student per statistics period, or multiple rows per student per term, you can look at how the statistics periods are defined (navigation: Records and Enrollment Enrollment Reporting àConsolidated Statistics àDefine Statistics Period).
Hope this helps!
Robert
------------------------------
Robert Lang
Business Systems Analyst
Duke University
------------------------------
Message from the HEUG Marketplace:
------------------------------
Find, Review, and Engage with Higher Education-focused solution providers, products, and services using the HEUG Marketplace.
------------------------------
Original Message:
Sent: 06-23-2026 05:06 PM
From: Kim Carmen
Subject: Need fix for IDs in Multiple Sessions in NSC enrollment reporting
Yes the report is duplicating the student's enrollment for separate sessions within a term for the final NSC file. For example, student A is enrolled in both AP1 and AP2 Summer sessions; the NSC report is showing both records instead of just one combined record. I just don't know where within the setup to correct this error on the file we import to NSC.
Original Message:
Sent: 6/5/2026 2:45:00 PM
From: Robert Lang
Subject: RE: Need fix for IDs in Multiple Sessions in NSC enrollment reporting
Hi Carmen! Are you still having this issue? I assume you're using the report generated by PeopleSoft's delivered NSC report via its Consolidate Academic Statistics Process? Can you clarify what you mean by two "profiles"--are you referring to duplicate records for the same student identifier? When you say that the Clearinghouse is "rejecting the report", do you mean the entire file, or just individual student rows impacted by the multiple sessions issue? If the former, what is the reason given by the analyst at the Clearinghouse for the entire file being rejected? As far as I can tell from my review of the Error Resolution Report Guide, only the duplicate records should be dropped (for security reasons)... I believe the PeopleSoft NSC report should be able to account for multiple sessions without producing duplicate campus-level records, so any more details you could provide here would be informative.
Hope you get this resolved soon if you haven't already! These kinds of "black box" quirks of the PeopleSoft process are one of the main reasons we've recently switched away from using that process to an in-house one that generates the report from queried data, which has been very useful for us since everything is transparent and derived from our own institution-specific logic implemented in our program. I'd be curious to know if others are experiencing the issue you're describing or if it's specific to some idiosyncrasy of your system.
Thanks!
Robert
------------------------------
Robert Lang
Business Systems Analyst
Duke University
------------------------------
Message from the HEUG Marketplace:
------------------------------
Find, Review, and Engage with Higher Education-focused solution providers, products, and services using the HEUG Marketplace.
------------------------------