Skip to content

Allotment Intake

Epic summary

The Allotment Intake epic receives candidate results from a counselling authority and converts them into controlled MedCES allotment records.

The workspace supports structured import, authorised manual entry, revisions, cancellations, and validation. It never changes the meaning of the authority’s published result.

Actors and access

ActorAccess
Counselling CoordinatorImports, maps, validates, and corrects staged data
Admission Nodal OfficerApproves or rejects an import batch
Admission ClerkSees only accepted and actionable allotments
Admission Scrutiny Committee MemberSees the accepted seat, quota, and declared category
Authorised Dean/PrincipalResolves material source or seat conflicts
Internal AuditorReviews source files, versions, errors, and approvals
Counselling Integration ServiceMay submit a staged batch but cannot approve it

Screen structure and data captured

The workspace contains Batch Header, Column Mapping, Validation Summary, Candidate Rows, Exceptions, and Approval History.

Allotment-batch fields

FieldEntry typeRequiredMeaning and validation
Admission cycleSelectedYesParent intake context
Counselling processSelectedYesMust belong to the selected cycle
Counselling roundSelectedYesMust belong to the selected process
Result typeSelectedYesProvisional, final, revised, cancelled, upgrade, or joined list
Authority referenceEntered/importedYesResult number, publication date/time, and issuing authority
Supersedes batchSelectedConditionalRequired for a revised or cancelled result
Source fileUploaded/integrationYesOriginal source retained unchanged with checksum
Import mappingSelected/configuredYesVersioned mapping from authority columns to MedCES fields
Imported by/atSystem capturedYesIntegration or user and timestamp
Batch statusSystem controlledYesUploaded, Mapping, Validating, Staged, Approved, Rejected, or Superseded

Candidate-allotment fields

Field groupImported fields
Candidate identityAuthority candidate ID, application/roll number, examination ID, name, date of birth, gender, contact where supplied
ExaminationExamination name/year, rank types and values, score/percentile where supplied
SeatInstitution code, programme/speciality code, seat-pool/quota code, allotted category, candidate category
AllotmentAllotment number, status, round, upgrade/retention flag, allotment date
DeadlinesReporting location, reporting start/end, joining deadline where published
Source traceSource row number and original unmapped values

System-derived information

MedCES calculates accepted, warning, rejected, duplicate, changed, upgraded, and cancelled row counts. Each row receives mapping, identity, offering, seat-pool, matrix-availability, duplicate-person, and existing-case validation results. Manual mappings retain the original value, corrected value, reason, and user.

Use case 1: Import an allotment result

As a Counselling Coordinator
I want to import an authority’s published allotment file
So that allotted candidates become available for institutional processing.

Acceptance criteria

  • The Counselling Coordinator selects the cycle, counselling process, round, and result type.
  • The original source file is retained unchanged.
  • The system maps candidate, examination, programme, seat pool, category, allotment, and deadline fields.
  • The import produces a staged batch with accepted, warning, and rejected row counts.
  • No staged record reaches the reporting desk before batch approval.
  • Re-importing the same source is detected and does not duplicate candidates.

Negative cases and alternate flows

  • Unknown columns: Allow an authorised mapping step and retain the mapping used.
  • Wrong round: Stop the import when the source clearly belongs to another process or round.
  • Unreadable file: Preserve the failed upload and provide a clear technical error.
  • Partial validity: Accept valid rows into staging while keeping invalid rows in an exception list.

Use case 2: Validate candidate and seat data

As a Counselling Coordinator
I want to review import exceptions
So that no candidate is processed against the wrong seat.

Acceptance criteria

  • The system checks duplicate candidate identifiers and allotment numbers.
  • The allotted programme and speciality must match an active offering.
  • The seat pool must belong to the selected counselling process.
  • The allotment is checked against the applicable round matrix.
  • Existing candidate cases are matched rather than duplicated.
  • Every manual correction records the original value, corrected mapping, user, and reason.

Negative cases and alternate flows

  • Allotment exceeds availability: Place the record in a blocking exception queue.
  • Candidate already joined elsewhere in the cycle: Flag the conflict for review; do not silently reject or replace either history.
  • Unknown category code: Require mapping or authority clarification.
  • Name mismatch with the existing person: Require identity review before linking.

Use case 3: Approve the allotment batch

As an Admission Nodal Officer
I want to approve a validated batch
So that only reviewed allotments become operational.

Acceptance criteria

  • The approving user sees the source, row totals, corrections, warnings, and blocking exceptions.
  • A batch with unresolved blocking errors cannot be approved.
  • The importer cannot approve their own batch where maker-checker control is active.
  • Approval creates or updates admission cases and marks actionable allotments.
  • Reporting Desk users can immediately find accepted candidates.
  • Approval is recorded with the exact batch version.

Negative cases and alternate flows

  • Batch rejected: Record the reason and return it to the importer without deleting evidence.
  • Approval attempted after round closure: Require controlled reopening or reject the operation.
  • Concurrent revision: Prevent approval of an older version after a newer source has been staged.

Use case 4: Process a revised or cancelled result

As a Counselling Coordinator
I want to import a revised result
So that candidate cases reflect the authority’s current decision while preserving history.

Acceptance criteria

  • The revised batch references the earlier batch.
  • The system identifies added, changed, upgraded, and cancelled allotments.
  • Existing reporting or verification work is not erased.
  • Affected cases receive a visible source-revision alert.
  • A cancellation does not automatically delete a valid institutional decision; it starts the required review and movement process.
  • The revised batch follows the same validation and approval controls.

Negative cases and alternate flows

  • Revision lacks source authority: Keep it staged and non-operational.
  • Candidate already enrolled: Escalate to the Authorised Dean/Principal and Student Section Officer.
  • Earlier version imported twice: Detect the duplicate and make no change.

Success outcome

The institution can prove exactly which authority result it received, how it mapped the data, which exceptions were resolved, and which version became operational.