Infor LN

Extending Standard Infor LN Tables: Developer Guide

Extending standard Infor LN tables with custom fields is one of the most common customization requirements—and one of the most dangerous if done incorrectly. Adding a column directly to a standard table like tcibd001 (Item Master) or tdsls400 (Sales Order Header) works in the short term but creates a nightmare during LN upgrades when the standard table definition is overwritten. Infor provides sanctioned extension mechanisms that survive upgrades, and this guide covers how to use them properly.

Extension Table Pattern (Recommended Approach)

The extension table pattern creates a separate custom table with a one-to-one relationship to the standard table, linked by the same primary key. For example, to add custom fields to the Item Master (tcibd001), create a custom table tcspc001 (using your custom module prefix) with the same primary key structure (comp + item) plus your custom columns. This pattern completely isolates custom data from standard tables, ensuring zero upgrade impact.

  • Create the extension table in the data dictionary (ttadv4500m000): use your custom module code as the table prefix (e.g., tcspc for 'SPC' module); define the primary key to exactly match the standard table's primary key segments
  • Link the extension table to the standard table: in the session BShell script, after every db.select on the standard table, immediately db.select on your extension table using the same key values; use db.select.and.lock() when updating to prevent concurrency issues
  • Auto-create extension records: in the standard table's after.insert trigger (via a DAL hook), automatically insert a default record into the extension table to ensure every standard record has a corresponding extension record
  • Display extension fields on standard forms: use the LN Form Personalization framework to add a custom tab or group box to the standard session form that shows fields from your extension table; this avoids modifying the standard form XML
  • Cascade delete: register a before.delete trigger on the standard table's DAL that deletes the corresponding extension table record; alternatively, define a parent-child relationship in the data dictionary with cascade delete enabled

DAL Hooks for Standard Table Logic Extension

DAL (Data Access Layer) hooks allow you to inject custom BShell logic that executes whenever the standard table is accessed—without modifying the standard BShell source code. Hooks fire on before.open, after.read, before.save, after.save, before.delete, and after.delete events. This is the safest way to add custom validation, auto-population, and business logic to standard LN tables because the hook code lives in your custom module and is not touched during upgrades.

  • Register a DAL hook: create a BShell function in your custom module's library (e.g., tcspc.dal.hooks.bc) that matches the hook signature; register it using dal.register.hook("tcibd001", HOOK.AFTER.SAVE, tcspc.item.after.save) in your module's initialization session
  • Validate custom business rules: in a before.save hook on tdsls401 (Sales Order Lines), check your custom extension table for item-specific restrictions: 'if tcspc001.blocked = true then mess(3, "Item is blocked for sales"); dal.set.error(); return endif'
  • Auto-populate extension fields: in an after.save hook on the standard table, read the saved record's key values and update your extension table with calculated or derived values; use db.retry.point/db.retry.hit around the extension table update
  • Cross-module hooks: your custom module can hook into any standard module's DAL; for example, a quality module can hook into the Purchase Receipt DAL (tdpur401) to automatically create quality inspection records when goods are received
  • IMPORTANT: DAL hooks execute within the calling session's transaction scope; if your hook fails and calls dal.set.error(), the entire standard operation (including the standard table save) is rolled back—design hooks to fail gracefully with meaningful error messages

Upgrade-Safe Extension Best Practices

The long-term success of table extensions depends on disciplined adherence to upgrade-safe patterns. Infor releases LN updates 2-4 times per year, and each update may modify standard table structures, session logic, and DAL behavior. Extensions that follow the sanctioned patterns survive these updates seamlessly. Extensions that take shortcuts—modifying standard tables directly, editing standard BShell source, or altering standard form XML—create compounding technical debt that eventually makes upgrades impossible.

  • Never add columns to standard tables: use the extension table pattern; if you have existing direct modifications, plan a migration project to move custom columns to extension tables before your next LN upgrade
  • Never modify standard BShell source: use DAL hooks, session exit points, and form personalization instead; if a standard session does not have the exit point you need, request it from Infor through a product enhancement request
  • Version your custom module: maintain a version number in your custom module's configuration that tracks which LN version it was tested against; during upgrade planning, compare your module version against the LN upgrade release notes for breaking changes
  • Regression testing: maintain a test suite of BShell scripts that exercise every DAL hook, extension table operation, and custom session in your module; run this suite after every LN update in a test environment before promoting to production
  • Document all extensions: maintain a technical design document for each table extension that includes the standard table impacted, the extension mechanism used (extension table, DAL hook, form personalization), the business requirement it fulfills, and the LN version it was built against

Ensure your Infor LN customizations survive every upgrade—let Netray's AI agents audit your extensions and recommend upgrade-safe refactoring.