SYSPRO Sales Order Automation and SYSPRO Sales Order Import From Customer Purchase Order PDFs

Where SYSPRO sales order automation actually breaks down

SYSPRO is good at what happens after a sales order exists. Credit checks, allocation, back orders, dispatch notes and invoicing all run without anyone touching them. The weak spot is the front door. A distributor or manufacturer on SYSPRO gets customer purchase orders as PDF attachments from dozens of buyers, each printed by a different system, and somebody at the order desk reads each one and keys it into Sales Order Entry. That is the step that eats the morning, and it is where a transposed quantity turns into a wrong pick and a credit note three weeks later.

There are three ways to close that gap. SYSPRO 8 has its own Document Analyzer, which reads a purchase order inside Sales Order Review. Larger shops post orders through the SORTOI business object from an integration. And many teams still want a spreadsheet they can check before anything posts. PurchaseOrders covers the reading step for the second and third routes, and it is the route for any order the Document Analyzer cannot take.

The built-in Document Analyzer and its limits

SYSPRO documents a Purchase Order to Sales Order capability in its 2025 help, run from the Document Analyzer pane in Sales Order Review. You upload a PDF or image of the customer order, enter the customer code, and SYSPRO fills in a new sales order header and lines for review. It is worth knowing exactly what the help says about it before you plan around it. Only single-page documents are currently supported, and SYSPRO warns that multi-page orders may lose data from later pages because of a limitation in the Azure Document Intelligence service underneath. Each purchase order analyzed uses one credit from a bundle you buy and top up through the SYSPRO customer portal. It needs the SYSPRO 8 Cognitive Service installed on a machine with internet access, and the endpoint configured in Setup Options. Lines are matched through the customer stock code cross-reference, so a code that is not mapped comes in as a non-stocked item.

If your customers send one-page orders and your cross-references are clean, try it. If they send a 6 page restocking order from a retail chain, or you run an older SYSPRO release, you need another way to read the document. That is the gap this page is about.

Posting through SORTOI, the sales order import business object

SORTOI is the SYSPRO e.net business object for sales order import. SYSPRO describes it as adding a new sales order and changing or cancelling an existing one, with many orders in one call and any mix of add, change and cancel. It is a Transaction class object in the Sales Orders module, posted with the Post method, and it has been there since SYSPRO 6.1. The Process parameter takes Validate or Import, so an integration can run a whole batch as a dry run first and only post when it comes back clean. That is the setting to use for the first week of any new feed.

Each order is an OrderHeader plus OrderDetails. The header carries CustomerPoNumber, Customer, OrderDate, the ship-to lines and ShipPostalCode, ShippingInstrs, RequestedShipDate and OrderComments. The details hold four line types: StockLine for items, CommentLine, MiscChargeLine and FreightLine. A StockLine takes CustomerPoLine, StockCode, CustomersPartNumber, OrderQty, OrderUom and Price. The response returns the SalesOrder number SYSPRO assigned against each CustomerPoNumber, plus counts of items processed and rejected.

Customer part numbers and the cross-reference

Buyers order with their own part numbers, not your stock codes. SORTOI handles this the same way the Document Analyzer does. When StockCode is blank or invalid, SYSPRO looks up the customer and part number combination in the customer stock code cross-reference. If there is no match, the line is accepted as non-stocked only if the AllowNonStockItems parameter permits it. So the cross-reference is the single biggest factor in how clean an automated feed runs. The extraction gives you the buyer part number in its own column on every line, which is exactly what goes into CustomersPartNumber, and a quick sort shows which codes are missing from the cross-reference before you post.

Duplicate PO numbers, credit holds and other rejections

The SORTOI documentation lists the errors you will actually hit. With the duplicate customer PO number check switched on, a second order carrying the same CustomerPoNumber is rejected unless AllowDuplicateOrderNumbers says otherwise, which is useful protection when the same PDF is forwarded twice. Customers on hold cannot be processed. Credit checks can fail on the credit limit, on the oldest invoice being past terms, or on a manual hold, and the error text comes from the CreditFailMessage parameter if you set one. Orders at status 0 (in process), 9 (complete) or aborted cannot be changed. Running Validate first surfaces all of these before anything posts.

What PurchaseOrders does in the workflow

PurchaseOrders is a document data capture layer. It reads the customer purchase order, any length and any layout, and returns the header and every line as Excel, CSV or JSON. It does not connect to SYSPRO, does not hold your login and does not post orders. Your integration or your team loads the rows. For a SORTOI feed, the JSON output maps onto OrderHeader and StockLine fields directly. For a manual check, the spreadsheet puts one row per line with the customer PO number, date and ship-to repeated beside each, so the order desk reviews instead of typing. Teams that clear a morning pile of attachments use bulk purchase order upload to process up to 50 files at once.

The same approach runs on other mid-market systems. Distributors on Epicor use the Epicor sales order import, wholesale distribution shops on Prophet 21 use Prophet 21 order entry automation, and teams on Infor use the Infor sales order import. The wider picture, including how to measure the time saved per order, is on sales order entry automation.