Migrate from Oracle PeopleSoft to Odoo ERP

PeopleSoft's COA spans ACCOUNT_TBL, DEPT_TBL, PRODUCT_TBL, PROJECT_TBL, and Auxiliary Chart records with setID scoping and effective-date rows. Odoo uses a single account.account model with code, name, and account_type fields plus analytic.account as a separate dimension. We extract all active account rows from PeopleSoft, collapse the multi-record COA into Odoo's flat account structure, and map setID-based segment values to analytic account tags or Odoo's account groups. DT_EFFECTIVE and DT_TERMINATION are preserved in custom fields on account.account for audit.

GL_JRNL_HEADER and GL_JRNL_LINE store journal entries with ledger, fiscal year, and accounting date. We map JOURNAL_ID to account.move.name, LEDGER_ID to a journal selection in Odoo's account.journal configuration, and fiscal period calendars are reconciled during scoping. PeopleSoft's multi-line journal entries become individual account.move.line rows with matched account.account codes. Closed periods in Odoo must be unlocked before loading historical journals; we coordinate this with the customer's Odoo admin.

AP_INVOICE_HEADER and AP_INVOICE_LINE hold open and historical invoices. PeopleSoft distinguishes between voucher and invoice schemas. We map voucher rows to account.move records with move_type='in_invoice', preserve vendor_id references via the Vendor mapping, and carry forward payment status, GL distribution amounts, and invoice date. Odoo validates that the account.move date falls within an open fiscal period before insertion.

AR_BILL_LINE and associated records store receivables with billing cycle, customer ID, and amount. We map to account.move records with move_type='out_invoice', preserving customer references through the Customer/Account mapping and payment terms as Odoo's l10n_generic_coa payment term lines. Odoo's invoice numbering sequence must be coordinated with the customer's existing PeopleSoft invoice numbering convention to avoid gaps.

PeopleSoft FSCM and CRM each maintain customer records in CUST_TABLE and related tables. We de-duplicate across modules, preserving Sold-To and Ship-To addresses, credit limits, and customer profile flags. Odoo's res.partner is the unified model for both vendors and customers; we set the appropriate flags and map PeopleSoft credit_limit to res.partner.credit_limit. Street/address data migrates to res.partner street, city, state, country fields using standard address parsing.

Vendor records live in VENDOR_TABLE with addresses, payment terms, W-9 status, and tax IDs. We extract the full vendor hierarchy and preserve any routing rules tied to purchasing BU as Odoo res.partner property fields. PeopleSoft's VENDOR_ID becomes a custom field ved_vendor_id__c on res.partner to preserve cross-reference integrity. W-9 status and tax ID migrate to l10n_generic_coa fiscal info fields or custom fields.

PO_HDR and PO_LINE store purchase order headers and lines with approval status, buyer ID, and schedule dates. We extract open and historical PO rows, mapping PO_ID and line numbers to Odoo's purchase.order and purchase.order.line. Approval status in PeopleSoft maps to Odoo's state field (draft, sent, purchase, done, cancel), with a note that PeopleSoft's multi-level approval workflow does not migrate and must be rebuilt in Odoo using purchase configuration or workflow.

INV_ITEM_MASTER and INV_ITEMS_CF store item definitions with unit of measure, cost, and category codes. We map PeopleSoft's business-unit-specific inventory flags to Odoo's product.product with type='product' for inventory items and type='consu' for consumables. Category codes from PS_MISC_CAT become Odoo product.category hierarchy. Odoo's product template wraps product.product; we map PeopleSoft item descriptions and UOM conversions using the item's standard unit of measure.

EMPLOYEES and PERSONAL_DATA hold the core employee record with hire date, termination date, HR status, and manager hierarchy. We map each PeopleSoft EMPLID to a new Odoo hr.employee record, create a linked res.users account with the employee's email, and store the original EMPLID as a custom field pe_emplid__c for cross-reference integrity. Manager hierarchy (manager_id) resolves via the Users mapping by email match. Hire date, termination date, and HR status migrate to the employee form and employment contract.

JOB and JOBCODE_TBL store position-based and job-based HR data with effective-date sequences. Odoo's hr.job model holds job titles and headcount planning. We extract active job codes from the most recent effective-date row, preserving job title, pay grade, and job family as Odoo hr.job fields. PeopleSoft's effective-date history is not a native Odoo concept; we preserve the full job history sequence in a custom text field pe_job_history__c on the hr.employee record for compliance audits.

POSITION_DATA stores position details with incumbent assignment, budgeted headcount, and department. Where organizations use position-based structures, we map positions to Odoo hr.job with department linkage, and the incumbent assignment maps via the Employee mapping. Budgeted headcount and filled/ vacant status become Odoo job's no_of_recruitment and employee_ids count. Mixed position-based and job-based structures are separated during scoping with a written mapping decision.

DEPT_TBL contains the organizational hierarchy with effective-date rows and setIDs governing security access. We extract the full department tree, preserving the setID relationship to the Chart of Accounts in a custom field pe_setid__c on hr.department. Parent-child department relationships map directly to Odoo's hr.department parent_id field. Department managers are resolved via the Users mapping. Historical effective-date rows are preserved in a custom field pe_dept_history__c for audit.