Mapping the IFS Data Model: A Navigator's Guide

The IFS data model is vast. With thousands of tables, views, and business entities spanning multiple modules, navigating it can feel like exploring a labyrinth without a map. Whether you're writing reports, building integrations, or troubleshooting data issues, understanding the structure and relationships between core tables is essential for IFS developers, report writers, and integration architects.

This guide provides a practical roadmap to the IFS data model, focusing on the key tables and cross-module relationships you'll encounter most frequently. We'll walk through Finance, Projects, Manufacturing, and Supply Chain modules—the pillars of most IFS implementations—and show you how to navigate the underlying data dictionary.

Understanding the IFS Data Architecture

Before diving into specific modules, it's important to understand how IFS organizes its data. Unlike traditional ERPs with simple foreign key relationships, IFS uses a sophisticated architecture where relationships are defined through metadata rather than database constraints.

Key Concepts

Entities & Logical Units (LUs) In IFS Cloud, entities are business objects (like "Customer" or "Sales Part") that represent real-world concepts. Logical Units (LUs) are the database manifestation of entities—they define the core structure, validations, and business logic. Every table belongs to an LU, and understanding the LU structure is fundamental to navigating the data model.

Projections & OData APIs IFS Cloud exposes data through OData projections—RESTful API endpoints that combine tables and views to present business information. For developers working directly with the database, understanding which views sit on top of which tables is crucial.

Views & Table Relationships IFS stores data in two layers:

• Tables (suffixed with _TAB): Core data storage. Examples: CUSTOMER_INFO_TAB, INVOICE_TAB, PURCHASE_ORDER_TAB
• Views (suffixed with _RPV for reporting, or other conventions): Business-logic enhanced views that join tables, apply validations, and present denormalized data for reporting

The relationships between tables are defined through metadata in REFERENCE_SYS_TAB, not through physical foreign keys.

The Data Dictionary Every table and view in IFS has metadata stored in the system dictionary. You can discover the active entities in your system by querying:

This returns all active logical units in the Finance module. Similar queries work for other modules.

---

Finance Module: The Foundation of Financial Data

The Finance module is often the starting point for data exploration because financial transactions flow through virtually every other module. Here are the critical tables and their relationships.

Core Finance Tables

General Ledger & Accounting

• ACCOUNTING_GROUP_TAB: Defines accounting groups (configurations for how transactions are accounted)
• ACCOUNT_TAB: Chart of accounts
• ACCOUNTING_TRANSACTION_TAB (or similar): Individual transaction entries
• COMPANY_TAB: Company master data
• COMPANY_SITE_TAB: Company sites and operating units

The relationship flows like this: Transactions are created in ACCOUNTING_TRANSACTION_TAB, linked to ACCOUNT_TAB (via account code), and organized by ACCOUNTING_GROUP_TAB and COMPANY_TAB.

Accounts Receivable

• CUSTOMER_INFO_TAB: Customer master records (core entity)
• CUSTOMER_ORDER_TAB: Sales orders (header)
• CUSTOMER_ORDER_LINE_TAB: Sales order lines (child records)
• INVOICE_TAB: All invoices (both customer and supplier; filtered by ROWTYPE)
• INVOICE_ITEM_TAB: Invoice line items
• INVOICE_SERIES_TAB: Invoice numbering sequences

Key insight: The INVOICE_TAB is a catch-all table containing multiple invoice types. Filter by ROWTYPE (e.g., 'CustomerInvoice', 'SupplierInvoice', 'ProjectInvoice') to distinguish them.

Accounts Payable

• SUPPLIER_TAB: Supplier master data
• SUPPLIER_INFO_TAB: Extended supplier information
• PURCHASE_ORDER_TAB: Purchase orders (header)
• PURCHASE_ORDER_LINE_TAB: Purchase order lines
• PURCHASE_ORDER_INVOICE_TAB: Supplier invoices linked to POs
• INVOICE_TAB: Again, stores supplier invoices (filter by ROWTYPE)

Fixed Assets

• ASSET_CLASS_TAB: Asset classifications
• FIXED_ASSET_TAB (or similar): Individual fixed asset records
• DEPRECIATION_TAB: Depreciation schedules and calculations
• LEASE_TAB: Lease accounting records (if using lease module)

Cash & Payments

• PAYMENT_TERM_TAB: Payment terms (discount structures, due dates)
• BANK_ACCOUNT_TAB: Company bank accounts
• BANK_TRANSACTION_TAB (or reconciliation views): Bank statements and reconciliations

Sample Query: Get All Invoices for a Customer

This demonstrates a key pattern: use ROWTYPE to filter invoice type, join through item tables for line detail, and use customer ID relationships to get master data.

---

Projects Module: Multi-Dimensional Cost & Schedule Tracking

The Projects module is one of the most complex in IFS because it integrates with Finance, Manufacturing, and Supply Chain while maintaining its own hierarchical structure (Work Breakdown Structure, Cost Breakdown Structure).

Core Projects Tables

Project Master

• PROJECT_TAB: Main project records
• PROJECT_ACTIVITY_TAB: Activities within projects (WBS breakdown)
• PROJECT_WORK_PACKAGE_TAB: Work packages (further subdivision)

The hierarchy: PROJECT → ACTIVITY → WORK_PACKAGE. Each level can accrue costs independently.

Project Costing & Finance

• PROJECT_COST_TAB: Project cost records (linked to activities/WBS)
• PROJECT_BUDGET_TAB: Budgets allocated to projects/activities
• PROJECT_FORECAST_TAB: Cost forecasts (earned value tracking)
• PROJECT_INVOICE_TAB: Invoices specific to projects
• PROJECT_REVENUE_TAB: Revenue recognition records (milestone-based)

Project Planning

• PROJECT_SCHEDULE_TAB: Schedule/Gantt data
• PROJECT_MILESTONE_TAB: Key milestones and payment milestones
• PROJECT_RESOURCE_ALLOCATION_TAB: Resource assignments (people, equipment)
• PROJECT_MATERIAL_REQUIREMENT_TAB: Material requirements (integration with Supply Chain)

Project Sales & Contracts

• PROJECT_SALES_CONTRACT_TAB: Main contract records
• PROJECT_CONTRACT_LINE_TAB: Contract line items
• PROJECT_SUBCONTRACT_TAB: Subcontractor agreements
• PROJECT_CHANGE_ORDER_TAB: Change order tracking

Critical Relationships

Projects are fully integrated with Finance. When you create project costs, they flow into:

• ACCOUNTING_TRANSACTION_TAB (if capitalized or expensed)
• INVOICE_TAB (when project costs become billable)
• General ledger accounts (via the Finance module's accounting rules)

Projects also link to Supply Chain through:

• Purchase orders tied to project activities (PURCHASE_ORDER_LINE_TAB.PROJECT_ID)
• Material transfers between project and standard inventory
• Project manufacturing shop orders

Sample Query: Project Cost Summary by Activity

This shows how costs cascade from individual activities up to the project level—essential for earned-value and project profitability analysis.

---

Manufacturing Module: Bills of Material, Shop Orders & Work Centers

The Manufacturing module handles product design, work-in-process, and production execution. Its data model is deeply hierarchical.

Core Manufacturing Tables

Product & BOM Structure

• SALES_PART_TAB: Saleable products (end items)
• INVENTORY_PART_TAB: All inventory items (both manufactured and purchased)
• BILL_OF_MATERIAL_TAB: BOM headers (which component parts go into which parent)
• BOM_LINE_TAB: Individual BOM lines (components with quantities, lead times)
• PART_ROUTING_TAB: Manufacturing routings (sequences of operations)
• OPERATION_TAB: Individual operations within routings

The hierarchy: INVENTORY_PART (parent) → BOM_LINE → INVENTORY_PART (component).

Work Orders & Shop Floor Control

• PURCHASE_ORDER_TAB (with ORDER_TYPE='Manufacturing'): Material purchase orders for production
• WORK_ORDER_TAB (or SHOP_ORDER_TAB): Manufacturing work orders
• WORK_ORDER_LINE_TAB: Lines within work orders
• WORK_CENTER_TAB: Production facilities (machines, labor centers)
• OPERATION_EXECUTION_TAB: Actual operations performed on the shop floor

Inventory & Warehouse

• INVENTORY_TAB or INVENTORY_LOCATION_TAB: Stock balances by location
• INVENTORY_MOVEMENT_TAB: All stock transactions (receipts, issues, transfers)
• HANDLING_UNIT_TAB: Pallets, containers, and handling units

Integration with Finance & Supply Chain

When manufacturing occurs:

1. Raw materials are consumed from inventory (recorded in INVENTORY_MOVEMENT_TAB)
2. Labor and overhead costs are applied (recorded in ACCOUNTING_TRANSACTION_TAB)
3. Work-in-progress is tracked (via WORK_ORDER and related tables)
4. Finished goods are created (new inventory records)
5. If the finished item is a sales part, it can be invoiced (INVOICE_TAB)

Key insight: INVENTORY_PART_TAB is central. Every raw material, component, and finished good is an inventory part. Manufacturing is essentially the process of converting one set of inventory parts into another.

Sample Query: BOM Explosion (Find All Components for an End Item)

This recursively expands a BOM to show all components at all levels—critical for planning, costing, and supply chain analysis.

---

Supply Chain Module: Procure-to-Pay, Inventory, Demand Planning

The Supply Chain module is where raw materials enter the system and flow to manufacturing or distribution.

Core Supply Chain Tables

Procurement

• SUPPLIER_TAB: Supplier master (also in Finance, but central here)
• SUPPLIER_INFO_ADDRESS_TAB: Supplier addresses and contacts
• PURCHASE_REQUISITION_TAB: Purchase requests (internal demand)
• PURCHASE_REQUISITION_LINE_TAB: Req lines (what to buy, from whom)
• PURCHASE_ORDER_TAB: Confirmed POs (legal document)
• PURCHASE_ORDER_LINE_TAB: PO lines (individual line items)
• PURCHASE_AGREEMENT_TAB (or SUPPLIER_AGREEMENT_TAB): Master agreements and blanket orders
• PURCHASE_ORDER_INVOICE_TAB: Invoices received against POs

Inventory Management

• INVENTORY_PART_TAB: All stocked items
• INVENTORY_LOCATION_TAB or WAREHOUSE_TAB: Physical storage locations
• INVENTORY_MOVEMENT_TAB (or RECEIPT_INFO_TAB): Every receipt, issue, and transfer
• INVENTORY_BALANCE_TAB (or derived view): Current stock by location and lot

Demand & Supply Planning

• SALES_FORECAST_TAB: Demand forecasts
• INVENTORY_REPLENISHMENT_TAB: Planned replenishment (MRP output)
• SUPPLY_PLAN_TAB: Supply plan records
• DEMAND_PLAN_TAB: Aggregated demand

Shipping & Distribution

• SHIPMENT_TAB: Outbound shipments
• SHIPMENT_LINE_TAB: Shipment details (what's being shipped)
• HANDLING_UNIT_TAB: Pallets and cartons
• INTRASTAT_TAB (if needed): Trade statistics

Cross-Module Linkages

The Supply Chain module bridges Finance and Manufacturing:

• Procure to Pay: PURCHASE_REQUISITION → PURCHASE_ORDER → Receipt (INVENTORY_MOVEMENT) → INVOICE → Accounting
• Manufacturing Integration: INVENTORY_PART → BILL_OF_MATERIAL → WORK_ORDER → consumes materials → INVENTORY_MOVEMENT
• Sales to Distribution: CUSTOMER_ORDER → SHIPMENT → INVOICE

The key to understanding these flows is recognizing that INVENTORY_MOVEMENT_TAB is the "transaction log" for all stock movements. Every purchase receipt, manufacturing consumption, and sales shipment creates records here.

Sample Query: Inventory Status & Valuation

This provides a complete inventory snapshot—essential for financial reporting and operational decision-making.

---

How to Navigate the IFS Data Dictionary

When you need to find a table but don't know where to start, use these techniques:

1. Use System Information in IFS Aurena

In the IFS Cloud UI (Aurena), right-click on any field and select System Info. This shows:

• The view name (e.g., CUSTOMER_ORDER_INV_JOIN)
• The underlying table
• The column mapping

Then explore the view definition in the database.

2. Query the Dictionary

3. Create Your Own Data Dictionary

Rather than memorizing thousands of tables, build an Excel workbook documenting the tables and views relevant to your domain. Include:

• Table/view name
• Description
• Key columns
• Related tables
• Use cases

This becomes a personal reference guide and accelerates analysis work.

4. Build a Metadata Repository

If your organization has a BI tool (Power BI, Tableau), extract metadata and build a searchable metadata catalog. Include:

• Tables and their columns
• Views and their base tables
• Relationships
• Data volumes
• Column usage across reports

This turns the data model from a labyrinth into a navigable landscape.

---

Key Takeaways: Rules for Data Model Navigation

1. ROWTYPE is Your Friend Understand that single tables often contain multiple entity types. Always filter by ROWTYPE or similar discriminators to avoid mixing invoices, requisitions, or other polymorphic entities.

2. Views ≠ Tables Never assume a view name directly corresponds to a table. Always trace the view definition back to its base tables. Many views aggregate or denormalize data in non-obvious ways.

3. Metadata Drives Relationships IFS doesn't use foreign keys. Relationships are defined in the data dictionary (REFERENCE_SYS_TAB). Use System Info or the dictionary to confirm relationships.

4. Module Integration Points Know where modules touch:

   • Finance & Projects: Accounting transactions, capitalization rules
   • Finance & Supply Chain: Invoice matching, payment processing
   • Supply Chain & Manufacturing: Material consumption, BOM
   • Manufacturing & Finance: Work-in-progress, finished goods valuation

5. Explore Before You Query Before writing production queries, browse the tables and views in your development environment. Understand cardinality, data grain, and timing of updates.

6. Document Everything The IFS data model evolves with upgrades. Maintain your own documentation of critical tables, key joins, and business logic interpretations. This protects you against knowledge loss and supports team onboarding.

---

Conclusion

The IFS data model is complex, but it follows consistent patterns. By understanding the core tables in Finance, Projects, Manufacturing, and Supply Chain, recognizing the integration points between modules, and leveraging the data dictionary and System Info tools, you can navigate efficiently.

Start with the tables documented in this guide—they represent 80% of the business logic in most IFS implementations. Build your data dictionary. Ask questions in the IFS community. And remember: the data model isn't a limitation; it's a feature. Its richness enables the flexibility and sophistication that makes IFS powerful for complex organizations.

Next steps: Pick your most-used module, identify its core tables, trace a few business transactions through the data, and document what you find. Your future self will thank you.