# Infor LN Incoming EDI Message Not Processed or Stuck > Source: https://netray.co/erp-help/ln-incoming-edi-message-not-processed-stuck-fix > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## 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. ## Kind error ## System infor-ln ## Erp Infor LN ## Module Electronic Data Interchange / ION ## Query Infor LN incoming EDI message not processed stuck in status ## Alternate Queries - 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 ## 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 ## Steps ### How to trace and unstick an inbound EDI message **Items:** - Open the EDI message overview for incoming messages and filter on the trading partner (network and business partner) and the date the file arrived. - Read 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. - Open the log or error view for that message and read the first error, not the last. Later errors are usually knock-on effects. - Check 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. - Confirm 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. - Correct 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. - Verify the result in the target session, for example the sales order or sales schedule, and confirm the message status moved to processed. - If every message from one partner fails, check the network or ION connection, not each message. ## Sections ### The three stages and where each one breaks **Body:** 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 **Body:** 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 **Body:** 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. **Code:** 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 **Body:** 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. ## 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. ## Ai Angle 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. ## Faq ### How do I know whether the message failed in conversion or in the order update? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms Infor LN EDI, LN incoming EDI message error, Baan EDI inbound, EDI message not processed, LN EDI code conversion, LN EDI reprocess message, EDI sales order not created LN, ION B2B Infor LN --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json