Jenzabar to Oracle Fusion Data Mapping — Field by Field

Field-level jenzabar data mapping translates every operationally relevant column from the Jenzabar SQL Server backend to the corresponding Oracle Fusion target — FBDI Journal Import columns for GL, HDL Worker.dat attributes for HCM, FBDI Supplier Import for vendor master, FBDI Procurement payloads for POs. The Jenzabar Student table doesn't map to a direct Fusion Student equivalent (Fusion has none) — it routes to Fusion HCM Worker for alumni who become employees, and to the Parquet archive for the full historical record. Course tables map to Fusion HCM Curriculum Course for development tracking. GL/AP/AR map to Fusion Finance with fund-accounting translation. Faculty Assignment patterns require special handling because Jenzabar models academic appointments differently than Fusion HCM.

Because Oracle Fusion deliberately does not include a Student Information System. The Fusion product family covers institutional ERP — Finance, HCM/Payroll, Procurement, SCM — not student admissions, enrollment, registration, transcripts or financial aid. Jenzabar Student records therefore split during jenzabar data mapping: students who later become employees of the institution (very common pattern at religious colleges and small liberal-arts schools where graduates return as staff or adjunct faculty) map to Fusion HCM Worker via the SSN/Person Number reconciliation pattern. The full Student record — admissions, enrollment, grades, transcripts, financial aid, degree-audit — preserves in the Parquet archive with academic-year partitioning.

Jenzabar's fund accounting structure (current funds operating, current funds restricted, plant funds unexpended, plant funds invested, loan funds, endowment funds quasi-endowment, endowment funds true endowment) translates to a combination of Fusion ledger design and Fusion COA segment design. Restricted-vs-unrestricted classification, required for ASU/FASB reporting, preserves as a dedicated COA segment with values aligned to the institution's reporting standards. Donor restriction language (purpose restriction, time restriction, perpetual restriction) preserves as DFFs on the journal entry plus archive linkage to the originating gift document. The jenzabar data mapping document spells out every fund-to-segment translation with sample journal lines before any GL load runs.

Jenzabar Course (the SIS course catalog) holds course definitions: course number, title, credit hours, description, prerequisites, distribution requirements, grade modes, departmental ownership. Fusion HCM has a Curriculum Course model used for employee learning and development tracking — it's not the same purpose, but the jenzabar data mapping uses it to preserve course definitions that need to surface in employee development records for faculty teaching loads, staff certifications and required institutional training. The full historical course catalog (with revisions across decades, special topics, retired courses, cross-listed courses) preserves in the Parquet archive linked to the transcript dataset so transcripts can always render the historical course title and credit hours as they appeared on the original record.

Jenzabar GL strings (typically a 3-7 segment account string with fund, organization, account, program, activity, location segments) map to a Fusion 6-segment COA via a governed crosswalk. The crosswalk is built collaboratively with the controller's office during weeks 3-5 of the project. Jenzabar AP (institutional accounts payable, not student account credits) maps to Fusion AP Invoice with vendor reconciliation; the invoice header carries the originating Jenzabar invoice number as a DFF for trace-back. Jenzabar AR (institutional receivables — grant draws, contract billings, miscellaneous receivables — not student account billings, which stay in the SIS layer) maps to Fusion AR Transaction with the same trace-back pattern. Multi-year balance history preserves at the period-end snapshot level.

Faculty Assignment in Jenzabar models the academic appointment hierarchy: faculty member → primary appointment (department, rank, tenure status, FTE) → secondary/joint appointments (cross-department, cross-college) → course assignments per term → administrative assignments (department chair, program director, committee chair). Fusion HCM's Assignment model handles much of this but doesn't natively understand tenure tracks or joint appointments the way Jenzabar does. The jenzabar data mapping uses Fusion HCM Assignment plus carefully designed DFFs to preserve tenure status, tenure clock dates, rank progression, sabbatical history and joint-appointment FTE splits. Course-level teaching assignments per term route to the Parquet archive as part of the academic dataset rather than into Fusion HCM, because they're term-bound and don't model cleanly as Fusion assignments.

Yes, with split routing. The donor master record routes to Fusion (Supplier or Customer depending on the relationship — many donors are also vendors or contract counterparties) with gift transaction history. The donor cultivation history, prospect ratings, moves-management notes, planned-giving correspondence and constituent relationship data routes to the Parquet archive with development-office self-serve access — these aren't financial transactions and don't belong in Fusion's transactional record. The split keeps Fusion clean and gives the Advancement office a queryable archive with the same access patterns they had in Jenzabar. Gift records that hit the GL (cash gifts, pledge payments, in-kind gift valuations) flow to Fusion as journal entries with archive linkage to the originating donor record.

A signed, versioned Field-Level Mapping Specification — typically 60-120 pages depending on institutional complexity — that the CFO, VP HR, Registrar and Financial Aid Director sign off on before any load runs. The spec covers every Jenzabar table in scope, every source column, the target system (Fusion or archive), the target table/file (FBDI Journal Import, HDL Worker.dat, archive table name), the target column, the transformation rule (direct copy, lookup, crosswalk, derivation), the data type translation, the null-handling rule, and a sample row showing source and target side-by-side. Subsequent crosswalk changes are tracked in the spec's revision log. The document becomes the authoritative source for any post-migration audit question about why a value landed where it did.