Infor Sales Order Import into CloudSuite Industrial Customer Orders and Infor LN from Customer PO PDFs

How Infor brings in customer orders

Infor sells two ERPs that US manufacturers and distributors run order entry in. CloudSuite Industrial, still called SyteLine by most of its users, calls a sales order a customer order and keeps it on the Customer Orders form. Infor LN calls it a sales order and keeps the header in the Sales Orders session, tdsls4100m000. Both have a supported inbound route. In CloudSuite Industrial, a customer 850 comes in through the EDI Transaction Load Routine, which creates EDI customer orders you review on the EDI Customer Orders and EDI Customer Order Lines forms before they post. Both products also take the Process.SalesOrder BOD through Infor ION, which is what a partner integration or ION API flow uses to create orders from structured data.

Every one of those routes expects data, either an EDI transaction or a BOD. None of them reads the PDF a customer attaches to an email. Customers on EDI are already handled. The ones who still email a purchase order end up with someone keying lines into the Customer Orders form or tdsls4100m000. PurchaseOrders handles that front step. It reads the customer PO and gives you the rows, and your EDI mapping, BOD flow or order desk does the rest.

Posting EDI customer orders in CloudSuite Industrial

Once an order is loaded, the Auto-Post setting on the EDI Customer Profiles form decides what happens. Set to Inbound or Both, CloudSuite Industrial validates and posts the order on its own. Set to Outbound or Neither, someone opens the EDI Customer Orders form and uses Actions, Post Current for one order or Actions, Post All for every valid one. Posted EDI orders become regular customer orders. When an order will not post, Actions, List Errors shows why for that order, and the Inbound Purchase Order Error Report lists every failure at once.

The posting errors that matter for PDF orders

Infor documents about twenty errors that stop an EDI customer order from posting. Five of them account for most of the trouble when the source was a PDF. Cust-PO is Blank means the customer PO number is missing, and it maps to the cust_po column of the EDI order header. Invalid Customer means the buyer name was never matched to a customer number. Invalid Item and Invalid Unit of Measure come from buyer part numbers and units such as CS or BX that were never mapped to yours. Invalid Unit Price means the price the buyer printed differs from the price CloudSuite Industrial calculates. Extracting the PO into a clean table first lets you fix all five before the load instead of after it.

Customer PO, sold-to and ship-to in Infor LN

On an Infor LN sales order header, the buyer PO number belongs in Customer Order. The Sold-to Business Partner drives most header defaults, and the invoice-to and ship-to business partners each carry their own address and contact. The Sales Office comes from the Sales User Profiles session (tdsls0139m000) first and the sold-to business partner second, so an order that arrives without one still gets a default if either is set. Watch the Origin field too. Orders created with origin EDI can only be changed later if Modifying EDI Orders Allowed is selected in the Sales Order Parameters session (tdsls0100s400), which surprises order desks the first time a buyer calls with a change.

Matching customer part numbers to your items

Most rejected lines fail on the item. Buyers print their own part numbers, and both Infor products validate the item against your item master. Keep a mapping column in the workbook that turns each buyer part into your item, or maintain customer item cross references inside Infor so the translation lives in the ERP. Either way it is set up once per customer. The extracted data keeps the buyer part number and the description side by side, which makes the first mapping quick. For the purchase side of the same company, where you load the POs you send to suppliers, see purchase order data for Infor M3, LN and CloudSuite.

Who uses this

Manufacturers and distributors on CloudSuite Industrial or Infor LN whose larger customers still send purchase orders as PDF attachments: make-to-order and engineer-to-order shops, industrial equipment builders, fabricated metal and plastics suppliers, and aerospace and automotive tier suppliers. Typical volume is a few dozen to a few hundred customer POs a week. The general version of the workflow lives on the sales order entry automation page, and a Monday inbox of 40 POs goes through bulk purchase order upload in one pass. Running Epicor instead? Epicor sales order import covers the same job on Kinetic, and Prophet 21 order entry automation covers P21.

What it does not do

PurchaseOrders does not connect to Infor, does not run the EDI Transaction Load Routine and does not send BODs through ION. It reads customer purchase orders and returns Excel, CSV or JSON. You load the rows through your EDI mapping, an ION integration your partner builds or the order desk. Your pricing, credit limits, contracts and posting rules in Infor stay exactly as they are.