Understand the four constructs that define PeopleSoft FSCM — business units, SetIDs and tableset sharing, ChartFields, and Journal Generator — and why deciding which of them survive is the first act of the migration, before any table is mapped.
Every ERP migration carries a hidden prerequisite: understanding what the source system actually is, rather than what it looks like from the outside. PeopleSoft FSCM makes that prerequisite unusually easy to skip, because the estate is legible.
The executive summary for this source reduces the whole migration to five questions. They are worth putting on a wall.
PeopleSoft separates two ideas that most ERP products conflate. A business unit defines the processing scope of a transaction — where a voucher is entered, where an asset is held, where inventory is stocked. A SetID, working through tablesets and record groups, defines which master and reference data that processing scope can see.
The ChartField model looks like the easiest part of the migration, because it appears to map cleanly. Account, Department, Operating Unit, Fund Code, Program, Product, Project — each one looks like a candidate financial dimension, and it is tempting to produce a one-to-one crosswalk in an afternoon.
The fourth abstraction is the one that most changes how the target has to be configured, and it is the one least visible from a data model.
PeopleSoft genuinely has multiple ledgers and ledger groups, and describing them accurately matters. The concept note asks for ledger usage to be classified into four purposes: operational actuals, reporting or statutory, budgets, and commitment control. That classification is the input to the target design.
Where Commitment Control is active — most commonly in public-sector, higher-education and grant-funded estates — it is not a feature within the General Ledger workstream. The source material is unambiguous: treat it as a dedicated fit-gap stream and do not bury it inside a generic GL workstream.
The last thing to establish at orientation is that PeopleSoft's extensibility surface is broad, and the estate built on it is routinely underestimated. The adapter lists the surfaces in scope: PeopleCode, Application Designer, Application Engine, SQR, BI Publisher and XML Publisher, Component Interfaces, Integration Broker, Event…
This path is grounded in the public PeopleSoft FSCM 9.1–9.2 documentation baseline plus a reconciled adapter package. It is worth stating the boundary of that evidence plainly, because a confident-sounding design built on invented specifics is more dangerous than an acknowledged gap.
PeopleSoft FSCM and D365 F&O both produce audit-defensible, period-closed accounting. They get there through different abstractions, and the migration is the work of re-projecting one set onto the other.