Migrate from Oracle PeopleSoft to Dolibarr ERP

PeopleSoft ACCOUNT_TBL and related COA records (SetID-scoped, effective-dated) map to Dolibarr's llx_accounting_account table. We extract all active and historical rows, mapping DT_EFFECTIVE and ACCOUNT_NBR to account_number and fk_pcg_version. Dolibarr supports PCG (France), Belgium, Spain, and generic English charts; we match or build the destination chart during scoping and preserve the original PeopleSoft account code as a label suffix for audit continuity.

PeopleSoft GL_JRNL_HEADER and GL_JRNL_LINE map to Dolibarr's llx_accounting_bookkeeping table. We preserve the source journal ID, line number, ledger, and fiscal year. PeopleSoft's accounting date becomes Dolibarr's piece_date; PeopleSoft's debit and credit amounts map directly. Fiscal period calendar differences require mapping: Dolibarr enforces a strict 12-period or 13-period fiscal year; PeopleSoft calendars may be non-standard and must be reconciled during scoping.

PeopleSoft AP_INVOICE_HEADER and AP_INVOICE_LINE (voucher schema) map to Dolibarr's llx_facture_fournisseur. We extract payment status, vendor ID, GL distribution lines, and invoice date. VENDOR_TABLE references resolve to Dolibarr llx_societe entries. PeopleSoft's voucher ID becomes the Dolibarr ref_supplier field; the original PeopleSoft voucher number is preserved as a custom label field.

PeopleSoft AR_BILL_LINE and associated records map to Dolibarr's llx_facture. We extract customer ID (CUST_TABLE), billing cycle, amount, and payment terms. Sold-To and Ship-To addresses from PeopleSoft's multi-address structure collapse into Dolibarr's single address fields on the llx_societe record. Payment terms from PeopleSoft's PAY_TERMS_TBL map to Dolibarr's cond_reglement.

PeopleSoft CUST_TABLE records (from both CRM and FSCM modules) de-duplicate across modules and map to Dolibarr llx_societe with client = 1. We preserve Sold-To address, credit limit, and customer profile flags. The PeopleSoft customer ID becomes Dolibarr's ref_customer field for dedupe validation during import. Multi-address support in Dolibarr uses llx_societe_address records.

PeopleSoft VENDOR_TABLE maps to Dolibarr llx_societe with fournisseur = 1. We extract address, payment terms, W-9 status, and tax IDs. Vendor routing rules tied to business unit are not structurally migratable; we document them as a process note for the customer's admin to reconfigure in Dolibarr's supplier module settings.

PeopleSoft PO_HDR and PO_LINE map to Dolibarr's llx_commande_fournisseur. We extract open and historical PO rows, preserving PO ID and line numbers as ref and line reference fields. Approval status from PeopleSoft maps to Dolibarr's fk_statut (status field). Closed and cancelled POs from PeopleSoft do not typically need full line detail; we migrate open POs with line items and flag historical POs for optional archival migration.

PeopleSoft INV_ITEM_MASTER maps to Dolibarr llx_product. Unit of measure, cost, and category codes from PeopleSoft map to Dolibarr's unite, cost_price, and category linkages. Business-unit-specific inventory flags require resolution: Dolibarr's stock management is site-level, not business-unit-scoped. We either create separate Dolibarr warehouse records per business unit or consolidate to a single warehouse depending on the customer's operational requirements.

PeopleSoft EMPLOYEES and PERSONAL_DATA map to Dolibarr llx_user for active system users or llx_socpeople for the broader employee roster. EMPLID remapping is the primary configuration decision: we can preserve original EMPLID as a custom field on the Dolibarr record, assign new sequential IDs, or implement both during a coexistence period. Hire date, termination date, HR status, and manager hierarchy map to Dolibarr's corresponding fields. Dolibarr does not have a native position-management or job-data model; historical job data requires custom field columns or a separate HR addon module.

PeopleSoft JOB and JOBCODE_TBL with effective-date sequences cannot map directly to any native Dolibarr object. We extract the current active job row and carry forward job title, job code, department, and FLSA status as custom fields on llx_user. Full effective-date history requires a separate HR addon table that we create and document during migration. The customer's admin chooses whether to activate a third-party Dolibarr HR module or manage job data via custom fields.

PeopleSoft DEPT_TBL organizational hierarchy maps to Dolibarr llx_project as cost-center entities, or to a dedicated cost-center table if the customer uses a third-party accounting addon. The department SetID relationship to the Chart of Accounts is not natively modeled in Dolibarr; we document it as a configuration note for the admin to re-implement through Dolibarr's accounting module settings or a custom addon. Effective-date rows require a current-only cutoff decision during scoping.

PeopleSoft BENEFIT_PARTICIPATION records carry enrollment, plan assignments, and coverage dates that have no equivalent in standard Dolibarr. We extract current benefit elections and carry plan names as text custom fields on llx_user. For organizations that need active benefits administration, we recommend pairing Dolibarr with a dedicated HRIS addon or external benefits platform and document the data handoff. Full historical benefit elections require a separate archive table.

PeopleSoft PAY_EARNINGS and DEDUCTION_RESULT carry year-to-date amounts and last pay date that can be extracted as a payroll summary record for reference in Dolibarr. However, payroll processing itself is outside Dolibarr's core capabilities without third-party modules. We extract the payroll summary data and document it as a reference record; the customer's admin sets up a compatible payroll integration or addon post-migration. Tax ID (EIN/SSN) from PeopleSoft PERSONAL_DATA maps to a custom field on llx_user with appropriate access controls.

PeopleSoft Content References point to file systems, Oracle Content Manager, or SharePoint — the database holds only URLs and metadata. We extract attachment metadata and file paths, then copy binary files to Dolibarr's documents directory using the naming convention Dolibarr expects for each module (invoices, contacts, products). The document migration is a separate file-transfer phase from the database migration and must be coordinated with the customer's IT team for SharePoint and network drive access.