Translate Project ID and Project Costing business units into a target project structure, and confront the resource type, category and subcategory rationalisation that the source rules mark as required before any project posting design can settle.
Project Costing occupies an unusual position in this source package. It is in scope — the playbook names it alongside General Ledger, Payables, Receivables and Billing, Purchasing, Inventory and Asset Management. It has a documented posting pattern. It has a concept mapping.
The source describes the Project ID and PC business unit mapping as composite because two source concepts resolve into different target places.
This is the centre of the domain and the reason the posting pattern is marked partial.
The posting rule debits project cost, work-in-progress or burden accounts and credits payroll, payable, inventory or overhead offsets, mapping to project group and category posting in the target. Status: partial.
The target expresses project structure through projects, sub-projects and a work breakdown structure of tasks. The source expresses it through projects and activities, with estates using varying depth.
Where billing is project-driven, this module and the trade module have to be designed together rather than in sequence.
The adapter excludes HCM process design and payroll transformation. The gap register nonetheless keeps a specific entry for it: adapter excludes HCM, but employee, payroll, expense, and project-labour interfaces may still be dependencies, at medium business impact.
Projects sit in the playbook's wave sequence alongside production and assets, after inventory positions and before open receivables and payables. Four decisions govern the load.
To close honestly, here is what this module cannot tell you about a specific estate, because the source package does not carry it.
Projects on a PeopleSoft programme are an object mapping wrapped around a classification problem, and the classification problem is where the effort sits.