Infor LN Incoming EDI Message Not Processed or Stuck
Infor LN incoming EDI message not processed stuck in status
Also searched as
- Infor LN EDI inbound order not creating sales order
- LN EDI message error conversion failed
- Baan EDI incoming message stuck in received status
- Infor LN EDI messages not converting to business documents
Short answer
An inbound EDI message that never becomes a sales order or schedule has stopped at one of three stages: receipt into the EDI message tables, conversion from the external format to the LN business document, or the application update that writes the order. Find the stage from the message status and log, fix the mapping, trading partner or master data cause, then reprocess the message rather than re-sending the file.
Applies to: Infor LN 10.x with the LN EDI module (Baan-heritage EDI) and LN with ION-based B2B; behaviour is similar in Baan 5.x and FP releases
How to trace and unstick an inbound EDI message
- 1Open the EDI message overview for incoming messages and filter on the trading partner (network and business partner) and the date the file arrived.
- 2Read the status: a message that stays at the received or unprocessed status never converted, a message with an error status converted but failed in the application update.
- 3Open the log or error view for that message and read the first error, not the last. Later errors are usually knock-on effects.
- 4Check the EDI master data the error points at: the trading partner relation, the EDI message code to message type mapping, and the code conversion tables for items, units and ship-to addresses.
- 5Confirm the business partner, item and ship-to address referenced in the message exist in LN and are active, with a customer item cross reference if the buyer uses its own part numbers.
- 6Correct the master data or the conversion setup, then use the reprocess or convert function on the failed message so the original audit trail is preserved.
- 7Verify the result in the target session, for example the sales order or sales schedule, and confirm the message status moved to processed.
- 8If every message from one partner fails, check the network or ION connection, not each message.
The three stages and where each one breaks
An inbound message passes through three stages. First it is received: a file or ION document arrives and is stored in the EDI message tables with a sender and a message code. Second it is converted: the standard message (EDIFACT, ANSI X12, VDA, or an XML format) is translated through the message layout and conversion setup into LN's own business document structure. Third the application update runs: the order, schedule or invoice logic in the target module validates the document and writes real records.
Failures at stage one are almost always transport: a file that never arrived, a rejected envelope, or a sender identifier that does not match any trading partner. Failures at stage two are mapping and code conversion: an element the layout does not know, a mandatory field that is blank, an item code with no cross reference. Failures at stage three are business validation: a closed customer, a blocked item, a missing price list, a delivery date outside calendar rules.
Naming the stage first saves hours. People often re-send the file from the customer side, which creates a duplicate message and does not fix a mapping or master data cause.
Conversion errors and code conversion tables
Most conversion errors trace to the code conversion setup. The buyer's EDI uses its own item numbers, unit of measure codes, ship-to location codes and sometimes currency or payment terms codes. LN must translate each into an internal value. If the translation is missing, the converter either leaves the field empty or stops with a conversion error.
Check these in order: the buyer part number to your item (customer item data, or the EDI conversion table for items), unit of measure conversion (EA, PCE, and C62 style codes are common mismatches), and the ship-to address code mapped to an LN address record. Case and trailing spaces matter. A code that reads ABC123 in the file and abc123 in the table will not match in some configurations.
When fixing the table, change it once for the partner, not message by message. Then reprocess all failed messages for that partner in one run so the whole backlog clears in order.
Application update failures and business validation
If conversion succeeded but the message still fails, the log will show a message from the target module as if a user had keyed the order. Typical causes are a customer on credit hold, an item with no sales data for the selling company, a price that cannot be determined because no price book applies, a requested delivery date earlier than lead time allows, and a missing order type.
These are fixed in the ordinary master data screens, then the message is reprocessed. Do not edit the message content to force it through unless your process owner agrees, because the stored message is your evidence of what the customer actually sent.
For sales schedules, an additional cause is a schedule release number out of sequence. LN may reject a release older than the one already held, which is correct behaviour and should be answered with the trading partner, not forced.
Checklist per failed message 1. Stage reached: received / converted / applied 2. First error text 3. Trading partner relation active? 4. Item, unit, ship-to conversions present? 5. Business partner and item active in the target company? 6. Reprocess, then verify target record
Duplicates, ordering and reprocessing safely
Reprocessing a message should be idempotent for a sales order: LN uses the buyer's order reference from the message to detect that an order already exists. Check how your setup treats a repeated purchase order number before bulk reprocessing, because configurations that allow duplicates will create a second order.
Process messages in the order received. Schedules and change orders depend on earlier documents, and a cancellation processed before the original order leaves a stray record. If you have a backlog, sort by receipt time and process oldest first.
After clearing a backlog, archive or purge old processed messages on your normal schedule so the overview stays readable. Keep error messages until the root cause is documented.
Common pitfalls
- !Asking the customer to resend the file creates duplicate messages and does not fix mapping or master data causes.
- !Reading the last error in the log instead of the first. Later lines are often consequences.
- !Editing converted content to push it through, which destroys the audit trail of what the partner sent.
- !Fixing one message by hand while the same missing code conversion fails every new message.
- !Reprocessing a change order before the original order, leaving orphan lines.
- !Treating a rejected out-of-sequence schedule release as a bug when it is the intended protection.
How an ERP-grounded AI assistant handles this
ERPray can answer read-only questions such as which inbound messages from a partner failed this week and what the first error was, then group them by cause so you see that forty messages share one missing unit code. It shows the query it ran and respects LN roles. Fixes to master data or reprocessing stay with an authorised user, with approval on any write-back.
Frequently asked questions
How do I know whether the message failed in conversion or in the order update?
Check the status and the log. A message that never moved past the received status did not convert. A message that converted but carries an error from the sales module, such as a missing price or blocked item, failed in the application update. The log text normally names the module that rejected it.
Can I just reprocess every failed message?
Only after the cause is fixed, and in order of receipt. Reprocessing without a fix repeats the same error. Also confirm how your setup handles repeated purchase order numbers so you do not create duplicate orders.
Why does only one trading partner fail?
Usually because that partner's code conversions, trading partner relation or message mapping differ from the others. Compare its setup with a working partner for item cross references, unit codes and ship-to codes.
Does this apply when LN receives EDI through ION?
The stages are similar but the transport and mapping may sit in ION and its connection points. Check the ION monitoring for the document first, then the LN application update. Conversion errors may then appear in the mapping layer rather than the LN code tables.
Related
How Sales Schedules Work in Infor LN: Releases and Cumulative Quantities
A sales schedule in Infor LN holds a customer's rolling demand as a series of releases, each replacing the last, with lines split into firm and planned quantities. LN tracks cumulative quantities shipped against the customer's cumulative received so that a new release can be reconciled without double counting or dropping demand.
Error fixInfor LN: BOD mapping errors when publishing to ION
This error means the outbound Business Object Document from LN could not translate a field, code, or reference value into the ION-standard BOD schema, most often a missing code list mapping or an unmapped custom field, not a bug in ION itself. Fix the mapping on the correct side and reprocess from ION Desk rather than resending from LN.
How-toHow to publish a BOD from Infor LN to Infor ION
Publishing a Business Object Document from Infor LN means flagging the relevant table or session for BOD publish, confirming LN's connection point to Infor ION is active, and building the document flow in ION Desk so changes like a new sales order are broadcast as a standard OAGIS-style XML message that other applications can subscribe to.
How-toHow to process a sales order to invoice in Infor LN
In Infor LN a sales order moves from order entry to cash through four linked steps: create and approve the Sales Orders session, release the order lines to Warehousing so a warehouse order is generated, confirm the outbound shipment, and then run the invoicing session that composes and posts the sales invoice to Financials. Each step hands off through an integration document, so a stuck invoice almost always traces back to a missing or unconfirmed step earlier in the chain.
Error fixInfor LN bshell Process Stuck at 100% CPU: How to Diagnose and Fix It
A bshell process pinned at 100% CPU on the Infor LN application server almost always means one session is stuck in a 4GL loop, scanning an unindexed table, or waiting on a database lock. End the session from the Sessions Monitor first, then kill the OS process only if that fails, and check for a blocking database transaction before assuming it is a bug.
Error fixInfor LN Not Authorized to Run This Session: How to Fix It
Infor LN refuses to open a session with a not authorized message when the logged-in user's assigned role does not include that session, or when the session is blocked for the company they are logged into. Grant the session through Common > Authorization Management > Roles, or check the user's role and company context, and the session opens on retry. In most cases this is a permissions configuration issue, not a bug.
AI for ERPAI for Infor LN: Sessions, BODs, and Engineer-to-Order Work
Add grounded AI to Infor LN 10.x or CloudSuite: natural-language answers over sessions and BODs, agents for project and engineer-to-order work, on-prem options.
AI for ERPInfor LN AI for Engineer-to-Order Industrial Machinery Builders
Private AI on Infor LN for engineer-to-order machinery builders: project cost, engineering BOM changes, long-lead purchasing and CE file support, on-prem.
Stuck on Infor LN?
Talk to engineers who work inside Infor LN every week, and who build private AI that answers these questions from your own ERP data.