What Is Exchange Scheme?
Also known as: LN exchange scheme, Baan exchange module, exchange batch
Definition
An exchange scheme is the reusable definition in the Baan and Infor LN Exchange module that maps external flat-file records to LN tables field by field, in either direction, so data can be imported or exported in batches without writing custom programs.
Exchange Scheme Explained
The Exchange module is the built-in bulk data movement facility of Baan and Infor LN, and the exchange scheme is its central object. A scheme names a direction - import or export - and then, for each table involved, defines which external fields map to which table fields, in what sequence, with what separators or fixed positions, and with what conversions applied along the way. Schemes are grouped into batches so a related set of loads runs in a controlled order.
Conversion setups handle the reality that external data rarely matches internal codes. A conversion can map an external customer number to an internal business partner code, translate a unit of measure, apply a constant, or derive a value where the source file has none. Because conversions are configuration rather than code, they can be maintained by functional consultants and adjusted between test runs without a compile cycle.
The most consequential option on a scheme is whether it processes records through the data access layer. Running with the DAL means every business rule, default and validation that applies to manual entry also applies to the load, which is slower but safe. Running without it writes rows more or less directly, which is fast and is exactly how environments end up with orders whose totals do not match their lines or items missing required defaults.
Operationally, exchange schemes are used for far more than initial data migration. They underpin recurring interfaces with suppliers and customers, extracts for external reporting systems, mass master data updates, and reference data synchronization between environments. Because they are configuration objects rather than compiled code, they are easy to change and easy to lose track of, so they should be inventoried, version controlled and promoted deliberately between environments rather than rebuilt by hand in each one.
Why It Matters
- Exchange schemes make bulk data movement a configuration exercise instead of a development project, cutting migration cost.
- Choosing to bypass the data access layer for speed is the single most common cause of corrupt migrated data.
- Reusable schemes and batches make repeated test-load cycles cheap, which is what makes data migration rehearsals practical.
- Undocumented production exchange schemes are a hidden integration surface that upgrade projects routinely miss.
In Practice
Always run a scheme in a test or check mode first and reconcile counts before committing. The failure mode that hurts most is a partially successful import: a few thousand rows loaded, several hundred rejected, and no clean way to identify which source records need reprocessing. Keep a rejected-record log and a repeatable rerun procedure for every production scheme.
Frequently Asked Questions
Should exchange schemes run with or without the DAL?
Run with the data access layer wherever correctness matters, which is almost always. The DAL applies the same validation, defaulting and business rules as manual entry, so loaded data behaves like data users created. Running without it is faster and occasionally justified for very large, fully pre-validated technical loads, but it puts the entire burden of correctness on your source file.
Can exchange schemes be used for ongoing interfaces?
Yes. Many production environments run scheduled exchange batches for recurring supplier files, customer feeds, reference data updates and extracts to external reporting systems. They are file-based and batch-oriented, so they suit periodic bulk movement rather than real-time integration, for which message-based or API integration is the better fit in modern LN deployments.
Related Terms
Baan/LN Tools Package
The Tools package is Baan and Infor LN's own development and administration layer. It holds the data dictionary, session and form definitions, the 3GL and 4GL compilers, VRC software layering, authorization management, job scheduling, company setup and the Exchange module.
Baan 3GL and 4GL
Baan 3GL and 4GL are the two programming languages of Baan and Infor LN. 4GL is the event-driven script attached to a session and its form fields, while 3GL is the C-like language used for libraries, DAL objects and standalone programs.
Integration Transaction
An integration transaction is the record Infor LN creates when a logistic event such as a receipt, issue, shipment or production completion must post to finance. Mapping schemes translate each transaction into the correct debit and credit ledger accounts and dimensions.
Go Deeper
Baan to Infor LN Migration Readiness Assessment
Score your organization's readiness to migrate from Baan IV or Baan V to Infor LN across ten dimensions, from data quality to executive sponsorship.
Baan ERP: History, Versions, and Modern Migration Paths
Baan ERP history from Triton to Baan IV, Baan V, and Infor LN, plus practical migration paths for manufacturers still running Baan today. Get a proven roadmap.
Infor LN to CloudSuite: Migration Playbook
Infor LN to CloudSuite migration playbook: Baan and LN version paths, extension conversion, ION integration rework, timelines, and defense compliance steps.
Working with Exchange Scheme in a live environment? Our engineers do this every day - and our AI agents automate most of it.