# SyteLine EDI or BOD inbound document fails to create a sales order > Source: https://netray.co/erp-help/syteline-edi-bod-inbound-processing-failure > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer An inbound EDI 850 or ION SyncSalesOrder / ProcessSalesOrder BOD that does not turn into a SyteLine order almost always fails validation before it ever reaches order entry logic - most often a customer, ship-to, or item cross-reference that the mapping expects but SyteLine does not have on file. Check the EDI translator's error log or the ION BOD document inbox first; the rejection reason is usually recorded there, not just a generic SyteLine error. ## Kind error ## System syteline ## Erp Infor SyteLine (CloudSuite Industrial) ## Module EDI / ION BOD Integration ## Query SyteLine EDI order import fails to create sales order BOD processing error ## Alternate Queries - syteline ION BOD failed to process - syteline inbound 850 does not create order - syteline EDI error log stuck documents ## Applies To SyteLine 8.x, 9.x, CloudSuite Industrial using ERP Integrator/ION BODs or a third-party EDI translator ## Steps ### Trace and fix a stuck inbound EDI/BOD document **Items:** Check the integration layer first, not SyteLine: the EDI translator's outbound-to-SyteLine log, or the ION document inbox/Connect flow history for the BOD's status and error text. Common rejection reasons to check in order: unmapped customer number, unmapped ship-to, unmapped item/customer-item cross-reference, invalid unit of measure, and invalid site code on the document. For a mapping-layer failure, confirm the customer's EDI trading partner setup and item cross-reference tables (Customer Items, or the mapping tool's own cross-reference) have the values the incoming document is sending. For a BOD that reached SyteLine but failed IDO validation, check the SyteLine Business Object / integration error log (or the standard SyteLine Errors form) for the specific IDO validation message. Reprocess the corrected document from the EDI translator or ION rather than trying to key the order manually, so the trading partner acknowledgment (997/999 or BOD response) stays accurate. If failures cluster around one trading partner, verify their EDI implementation guide version matches what the mapping was built against - partners do change 850 formats without much notice. Set up a monitoring alert on the error queue so a stuck document is caught same-day rather than discovered when the customer calls asking where their order is. ## Sections ### Two different layers, two different logs **Body:** SyteLine EDI/BOD integrations typically run through two distinct layers: the EDI translator (or ION Connect) that receives the raw X12/EDIFACT document or partner API call and maps it to a BOD or an import format, and SyteLine's own IDO validation that runs once the mapped data actually tries to create the order. A document can fail in either layer, and the error you see - or do not see - depends on which one rejected it. Most silent failures (order simply never appears, no obvious error) are stuck at the translator/mapping layer, not inside SyteLine. ### The usual suspects **Body:** Customer and ship-to cross-references are the single most common cause: the trading partner sends their own customer or location code, and the mapping has to translate that to SyteLine's customer number and ship-to ID. A new ship-to added by the customer without a corresponding cross-reference entry will reject every order to that address until someone adds the mapping. Item cross-references are the second most common cause, especially when a customer orders by their own part number rather than yours - SyteLine's Customer Items table (or an equivalent cross-reference in the EDI tool) needs an entry, and a typo or a discontinued customer-item mapping will reject the whole document rather than just skip the line. ### When it is a genuine SyteLine-side validation **Body:** If the document reaches SyteLine's IDO layer and fails there, the error is usually more specific - an invalid site, a credit hold, a unit of measure the item does not support, or a required field the BOD did not populate. These show up in SyteLine's own error/integration log rather than the translator's, and read like a normal IDO validation error because that is exactly what they are. ## Pitfalls Manually keying the order to unblock the customer, without also fixing the mapping, guarantees the same document (or the next one from that partner) fails again. Not checking both logs (translator and SyteLine IDO) wastes time - a translator-layer rejection will not appear anywhere inside SyteLine at all. New ship-to addresses and new customer items are the most common day-to-day cause of stuck EDI orders and are easy to miss because they only affect one order until noticed. Reprocessing a corrected document from inside SyteLine instead of from the EDI/ION layer can break the trading partner acknowledgment flow (997/999), leaving the partner's system still showing the order as unacknowledged. Assuming a stuck order is a SyteLine bug before checking the mapping layer wastes support time on the wrong system. ## Ai Angle ERPray can be pointed at both the EDI/ION error queue and SyteLine's customer, ship-to, and item cross-reference tables at once, so a question like 'why did order from customer ABC not create' gets answered with the actual missing cross-reference entry, rather than the support team manually cross-checking translator logs against SyteLine master data by hand. ## Faq ### Where do I look first when an EDI order just never appears in SyteLine? **Answer:** Start with the EDI translator or ION Connect document history, not SyteLine itself. Most silent failures are rejected before they ever reach SyteLine's order entry logic, so SyteLine's own logs will show nothing at all. ### Does a rejected BOD send an error back to the trading partner automatically? **Answer:** It depends on the setup. Standard X12 acknowledgments (997/999) confirm the document was received and syntactically valid, but a business-level rejection (unmapped customer, invalid item) typically does not automatically notify the partner unless a functional acknowledgment or exception process was specifically built for it. ### Can one bad line item block an entire multi-line order? **Answer:** In most SyteLine EDI implementations, yes - order header and line creation typically happens as a single IDO transaction, so one invalid item cross-reference on any line can reject the whole order rather than just skip that line. ### How do I prevent this from recurring with the same trading partner? **Answer:** Set up proactive cross-reference maintenance whenever a partner adds a new ship-to or item, and monitor the error queue daily so a new mismatch is caught the same day rather than after a customer complaint. ## Search terms syteline edi order import failure, syteline ion bod error, syteline edi 850 not creating order, syteline customer cross reference edi, syteline item cross reference edi, syteline erp integrator error, syteline stuck edi document, syteline bod processing failed --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json