LAWSON → FUSION DATA MAPPING

    Infor Lawson to Oracle Fusion Data Mapping — Field-Level Crosswalks

    Pre-built infor lawson to oracle fusion data mapping for GLMASTER, APINVOICE, ARCUST, HRPER, HRDEPT, EMDEDMASTR, INVMASTER, PURCHORDER. Accounting unit + accounting category collapse into Fusion six-segment COA, HRPER preserved as Fusion HCM Person Number, full S2T documentation for SOX / HIPAA audit.

    Field-level
    Source-to-target S2T
    6-seg COA
    AU + AC collapse
    HDL + FBDI
    Oracle-native load formats
    Mongoose
    Custom table mapping

    Why infor lawson to oracle fusion data mapping is the workstream that decides project success

    Get the mapping right and the rest of the migration flows. Get it wrong and finance can't close the books in Fusion, HR can't run payroll, supply chain can't post receipts.

    Lawson S3 and Oracle Fusion are structurally different ERPs. Lawson's accounting unit + accounting category model isn't Fusion's six-segment COA. Lawson's process level + company model isn't Fusion's business unit + legal entity model. Lawson HRPER isn't Fusion HCM Worker. Lawson PURCHORDER + ITEM isn't Fusion Procurement + Inventory Item. Every field needs a defensible translation rule, every translation needs a business-owner signoff, and every signoff needs to be auditable post-cutover.

    Custom-built mapping spreadsheets — the classic consultant-led artifact — fail this bar. They're impossible to keep in sync with reality, they don't enforce dependencies (load items before lot detail, load customers before sales orders, load workers before assignments), and they don't produce auditable evidence. The first time finance tries to run a Fusion trial balance and the numbers don't match Lawson, the project loses six weeks rebuilding the mapping from scratch.

    Syntra ETL ships the infor lawson to oracle fusion data mapping pre-built. Every Lawson source field is mapped to its Fusion target field with the transformation rule, every mapping is browser-renderable as an interactive S2T with signoff workflow, and every mapping decision is preserved through the load with the original Lawson source field carried as a DFF for forensic traceability. Auditors get a single document. Finance gets reconcilable books on day one.

    The seven domain mappings shipped pre-built

    1
    Finance (GLMASTER)
    Accounting unit + accounting category → Fusion six-segment COA. Process level → business unit. Company → legal entity. GLMASTER journals → FBDI GL Journal Import per AU range per period.
    2
    AP (APINVOICE)
    Lawson vendor numbers preserved as Fusion Supplier Numbers, APINVOICE invoice numbers carried as Fusion Invoice Source Reference, payment terms translated, hold reasons mapped.
    3
    AR (ARCUST)
    Lawson customer master → TCA Party + Customer Account + Customer Site, ARCUST invoice history → FBDI Receivables Import, dunning levels mapped, payment terms translated.
    4
    HR (HRPER + HRDEPT)
    HRPER → HCM Worker (HDL Worker Import), HRDEPT → Fusion Organization, HRJOB → Fusion Job + Position, full effective-dated assignment history preserved into HCM Assignments.
    5
    Benefits (EMDEDMASTR)
    Full effective-dated deductions → Fusion Element Entries, enrollment context → Fusion Benefits, ELC and COBRA-relevant termination events flagged with audit trail.
    6
    Inventory (INVMASTER + ITEM)
    Lawson items → Fusion Inventory Items (FBDI Item Import), warehouse balances → Fusion on-hand, 340B drug attribution → DFFs, lot/serial preserved.
    7
    Procurement (PURCHORDER)
    PURCHORDER → Fusion PO, supplier records → Fusion Suppliers, buyer assignments → Procurement Agent roles, contract pricing → Fusion Procurement Contracts.

    The harder Lawson-to-Fusion translations the mapping engine handles

    The transformations consultant-led projects burn months on. Pre-built in Syntra ETL.

    📊

    AU + AC → six-segment COA

    Lawson accounting unit (organisational) + accounting category (account) + sub-account collapse into Fusion Cost Centre + Account + Product/Project segments. Many-to-many AU translations handled without breaking historical posting integrity.

    🏢

    Process level → business unit

    Lawson process levels (operational entity, often 30–80 per hospital network) translated to Fusion business units. Process-level-driven posting rules preserved, intra-PL vs inter-PL flagging preserved for Fusion intercompany detection.

    👤

    HRPER → HCM Worker

    HRPER employee numbers preserved as Fusion HCM Person Number, full effective-dated assignment history → HCM Assignments, healthcare-specific licensure / certification extensions routed to HCM extension columns.

    💊

    EMDEDMASTR → Benefits

    Effective-dated deductions → Fusion Element Entries with ELC/COBRA-relevant termination events flagged. Enrollment context (plan, coverage tier, dependents, beneficiaries) routed to Fusion Benefits enrollment tables.

    🏥

    340B + GHX preservation

    Healthcare-specific Lawson Supply Chain extensions (340B drug attribution, GHX integration metadata, contract pricing terms) preserved through Fusion Inventory DFFs, OIC remap and Fusion Procurement Contracts.

    🪟

    Mongoose custom tables

    Mongoose-built custom tables inventoried, classified, mapped: lookup tables → FND Lookups, workflow-state tables → VBCS extensions, approval queues → Fusion Workflow. 40–60% typically retire as redundant.

    How infor lawson to oracle fusion data mapping is delivered — the workstream sequence

    Eight weeks elapsed for a typical hospital network. Structured signoff per Lawson productline.

    1

    Mapping Kickoff — Week 1

    Confirm Lawson productlines in scope, confirm Fusion target modules, identify business owner per domain (CFO for GLMASTER, HR Director for HRPER, Supply Chain Director for PURCHORDER). Pre-built mapping templates loaded for review.

    2

    Reference Data Mapping — Weeks 1–2

    Process level → business unit translations, company → legal entity translations, AU + AC → six-segment COA crosswalk. Reviewed and signed off by finance. AU range tested with a representative trial balance load.

    3

    Master Data Mapping — Weeks 2–4

    Vendor master, customer master, item master, employee master mappings. HRPER → HCM Worker for HR, ITEM → Inventory Item for supply chain. Signed off by respective business owners with sample-record review.

    4

    Transactional Mapping — Weeks 3–6

    GLMASTER journals, APINVOICE history, ARCUST history, PAEMPLOYEE payroll, EMDEDMASTR benefits, PURCHORDER history. Effective dating and historical context preserved. Signed off by finance, HR, supply chain.

    5

    Customisation Mapping — Weeks 5–7

    Mongoose custom tables, IPA flows, Smart Notifications, LBI reports mapped to Fusion equivalents (VBCS, OIC, Workflow, OTBI). Retire/replace decisions signed off by IT leadership and respective business owners.

    6

    Validation & S2T Lockdown — Weeks 7–8

    Full S2T browser-rendered for final review, signed off per Lawson productline, version-locked. Becomes the canonical mapping reference used through extraction, load and reconciliation.

    What the mapping engine produces — auditable, version-controlled, browser-renderable

    Five artifacts per domain that drive the rest of the migration.

    📋

    Source-to-target S2T

    Browser-renderable per-domain S2T: Lawson source table → Lawson source field → transformation rule → Fusion target table → Fusion target field. Exportable to Excel for offline review.

    Signoff workflow

    Structured signoff per Lawson productline per domain. CFO signs GLMASTER. HR Director signs HRPER + EMDEDMASTR. Supply Chain Director signs PURCHORDER + INVMASTER. Tracked, versioned.

    🔄

    Transformation rules

    Every translation rule encoded (AU range → BU, deduction code → element entry, AC + sub-account → natural account + product). Tested against sample records before bulk load.

    🏷️

    DFF assignments

    Original Lawson source field preserved as Fusion DFF for forensic traceability. AP invoice retains original Lawson APINVOICE number. Worker retains original HRPER employee_number. Journal retains original Lawson voucher.

    🔁

    Version history

    Every mapping decision version-controlled. Change to a mapping rule produces new version with reason, author and timestamp. Auditors get full history of how the mapping evolved over the project.

    📦

    Reusable across loads

    Same S2T drives extraction, transformation, load and reconciliation. No drift between mapping document and actual load behaviour. Updates to mapping flow through to all downstream load jobs automatically.

    Frequently asked questions

    What is infor lawson to oracle fusion data mapping?+

    Infor lawson to oracle fusion data mapping is the field-level crosswalk between Lawson S3 source structures (GLMASTER, APINVOICE, ARCUST, HRPER, HRDEPT, EMDEDMASTR, INVMASTER, PURCHORDER, PAEMPLOYEE) and Oracle Fusion target structures (Fusion GL, Payables, Receivables, HCM Workers, Inventory, Procurement). The mapping covers data structure (Lawson's accounting unit + accounting category collapsed into Fusion's six-segment COA), reference data (Lawson process levels mapped to Fusion business units, Lawson companies mapped to Fusion legal entities), master data (HRPER worker IDs preserved as Fusion HCM Person Numbers, Lawson vendor numbers preserved as Fusion Supplier Numbers), and transactional data (APINVOICE invoice numbers carried as the Fusion Invoice Source Reference). Syntra ETL ships these mappings pre-built, refined across dozens of Lawson migrations.

    How does Lawson's accounting unit and accounting category map to Fusion's COA?+

    Lawson's chart of accounts is structurally different from Fusion's. Lawson Financials uses GLMASTER with accounting unit (organisational dimension), accounting category (account dimension), sub-account (typically a third dimension for capital projects or grants), and optional accounting unit list filtering. Fusion uses a six-segment COA (typically Company, Cost Centre, Account, Product, Project, Intercompany — though configurable). The infor lawson to oracle fusion data mapping for the COA is a structured crosswalk: Lawson accounting unit → Fusion Cost Centre + Company (depending on AU hierarchy), Lawson accounting category → Fusion Natural Account, Lawson sub-account → Fusion Product or Project segment. Syntra ETL's mapping engine handles many-to-many AU translations (one Lawson AU mapping to multiple Fusion combinations) without losing the historical posting integrity.

    How does Lawson HR data map to Fusion HCM?+

    Lawson HR/Payroll runs on HRPER (the person master), HRDEPT (department), HRJOB (job code), PAEMPLOYEE (the employment record), EMDEDMASTR (deduction master), and EMPLOYEE (the payroll-side employee record). The Fusion HCM mapping preserves HRPER employee numbers as the Fusion HCM Person Number (the load is HDL Worker Import), HRDEPT department codes as Fusion Organization codes, HRJOB job codes as Fusion Jobs and Positions (depending on the customer's Fusion positioning model), EMDEDMASTR deductions as Fusion Element Entries, and the full PAEMPLOYEE assignment history as Fusion HCM Assignments with effective-dated history preserved. Healthcare-specific Lawson extensions for licensure tracking, continuing education and float-pool affiliations get routed to Fusion HCM extension columns or to Talent Management extensions.

    How does Lawson supply chain data map to Fusion Procurement and Inventory?+

    Lawson Supply Chain runs on PURCHORDER (purchase orders), POLINE (PO lines), ITEM (item master), INVMASTER (inventory master), and BUYER (buyer master), with extensive healthcare-specific extension tables for GHX integration, contract pricing and 340B drug compliance. The infor lawson to oracle fusion data mapping carries PURCHORDER numbers as Fusion PO numbers, ITEM item numbers as Fusion Item numbers (Inventory Item Import via FBDI), supplier records as Fusion Suppliers (TCA Party with Supplier Site), buyer assignments as Fusion Procurement Agent roles. Healthcare-specific 340B drug attribution gets routed to Fusion Inventory DFFs, GHX integration metadata gets routed to OIC for re-platforming, and contract pricing terms get migrated as Fusion Procurement Contracts with effective-dated price breaks preserved.

    How are Lawson reference values like process levels and companies translated?+

    Lawson uses process levels as the operational entity dimension and companies as the legal entity dimension. The mapping engine reads the Lawson configuration directly, identifies every process level and company in use across the productlines (often 30–80 process levels in a hospital network), and produces a crosswalk to Fusion business units (operating segments) and legal entities. The translation respects Lawson's process-level-driven posting rules (different process levels can post to different accounting unit ranges), preserves the original Lawson process level as a DFF on every migrated transaction for forensic traceability, and ensures that intra-process-level vs inter-process-level transaction flagging is preserved into Fusion's intercompany detection logic.

    How do you map historical EMDEDMASTR and benefits data without breaking ELC and COBRA?+

    EMDEDMASTR holds employee benefit deductions (medical, dental, vision, retirement, garnishments) with effective dating critical for ELC (Employee Lifecycle) and COBRA compliance. The infor lawson to oracle fusion data mapping preserves the full effective-dated history into Fusion HCM as Element Entries with the correct effective_start_date and effective_end_date, preserves the Lawson deduction code as the source reference, and preserves enrollment context (plan, coverage tier, dependents enrolled, beneficiaries) by routing to Fusion Benefits enrollment tables. COBRA-relevant termination events are flagged with full audit trail so post-termination COBRA continuation eligibility computes correctly. CA-specific deduction reporting requirements and other state-specific quirks are preserved through the migration.

    How does Syntra ETL handle Mongoose-built custom tables in the data mapping?+

    Mongoose framework lets Lawson customers build custom database tables with full CRUD UI on top — and these tables often hold mission-critical workflow data (nursing certifications, equipment maintenance schedules, custom approval queues, department-specific workflows). The mapping engine inventories every Mongoose-built custom table during the assessment, classifies by business intent, and maps to Fusion equivalents: simple lookup tables become Fusion FND Lookups, workflow-state tables become VBCS extension tables, approval-queue tables become Fusion Workflow / BPM destinations. Customers commonly find 40–60% of Mongoose tables are redundant under Fusion native capability and can be retired; the remaining 40–60% are migrated to VBCS or to Fusion extension columns with the full data preserved.

    How is the infor lawson to oracle fusion data mapping documented for auditors?+

    Every mapping decision is documented in a structured source-to-target document (S2T): Lawson source table → Lawson source field → transformation rule → Fusion target table → Fusion target field, with reasoning, signoff, version history and any decoration (DFF assignments, lookup translations, default values). The S2T is browser-renderable, exportable to Excel for offline review, and signed off per Lawson productline by the relevant business owner (finance for GLMASTER mappings, HR for HRPER mappings, supply chain for PURCHORDER mappings). When SOX, HIPAA or state-payroll auditors arrive post-cutover, the S2T is the definitive evidence pack that explains how every Lawson data point traces to its Fusion equivalent. No reconstruction needed.

    Lock down your infor lawson to oracle fusion data mapping

    Book a 30-minute walkthrough. We'll show you the pre-built Lawson-to-Fusion S2T for your productlines, identify gaps specific to your hospital or higher-ed customisations, and scope an 8-week mapping workstream.