D365 Sales Order Import into Dynamics 365 Sales Orders from Customer PO PDFs

How Dynamics 365 imports sales orders

Dynamics 365 Supply Chain Management and Dynamics 365 Finance create sales orders in bulk through data entities. Microsoft documents two of them for this job. Sales order headers V2 creates the order header with the customer, delivery and payment details, and Sales order lines V2 creates the lines with items, quantities and prices. You load them in the Data management workspace: create an import project, add both entities, attach an Excel or CSV source file for each, put the header entity first in the sequence and run the import. The same entities are exposed over OData as the SalesOrderHeadersV2 and SalesOrderLines collections, which is what an integration or a Power Automate flow calls.

Every one of those routes expects rows. None of them reads the PDF a customer attaches to an email. Customers on EDI or a portal can be connected by your partner; the ones who still email a purchase order end up with someone on the order desk keying lines into All sales orders. PurchaseOrders handles that front step. It reads the customer PO and gives you the rows, and Data management or your integration does the rest.

Required fields on Sales order headers V2

Microsoft marks four header fields as required. SALESORDERNUMBER is the primary key, ORDERINGCUSTOMERACCOUNTNUMBER is the customer who placed the order, INVOICECUSTOMERACCOUNTNUMBER is the account that gets the invoice (usually the same customer) and REQUESTEDSHIPPINGDATE is the date the customer wants the goods to ship. Optional fields that a customer PO often fills are CURRENCYCODE, PAYMENTTERMSNAME, DELIVERYTERMSCODE and REQUESTEDRECEIPTDATE. Each of those values has to exist in your setup first, so a PO that says Net 30 needs a matching terms of payment code.

The buyer purchase order number belongs in CUSTOMERREQUISITIONNUMBER, shown on the order as Customer requisition, and many companies also copy it into CUSTOMERSORDERREFERENCE, the Customer reference field. Fill it every time. When a buyer calls about an order, they quote their own PO number, not yours.

Required fields on Sales order lines V2

On the lines, Microsoft lists SALESORDERNUMBER (the link to the header), ITEMNUMBER, REQUESTEDSHIPPINGDATE and DELIVERYADDRESSLOCATIONID as required. Quantity goes in ORDEREDSALESQUANTITY, the unit in SALESUNITSYMBOL, and the price in SALESPRICE with LINEAMOUNT for the extended amount. The line key is INVENTORYLOTID, which needs the inventory lot number sequence set up; if you do not want to supply it, change the entity mapping to Auto-generated. Microsoft recommends a single thread for both entities, so large batches run one after the other rather than in parallel.

Shaping the export for Data management

The export from PurchaseOrders is one row per line with the header values repeated. Keep one row per customer PO for the header file and every row for the lines file, give each PO the sales order number you will use in both files, and map the customer, the item and the unit. The customer usually resolves from the bill-to name and address on the PO; the delivery address location comes from the ship-to block, matched to an address already on the customer record. Build the mapping workbook once and reuse it for every batch. For the purchase side of the same company, where you load the POs you issue to suppliers, see purchase order import for D365 Finance and Operations, and for table level detail on that side, D365 purchase order tables.

Matching customer part numbers to your items

Most rejected lines fail on the item. Buyers print their own part numbers and Dynamics 365 validates ITEMNUMBER against your released products. You can keep a mapping column in the workbook that turns each buyer part into your item number, or maintain external item descriptions for the customer so the cross reference lives in Dynamics 365 itself. Either way it is set up once per customer. The extracted data keeps the buyer part number and description next to each other, which makes the first mapping fast. After the run, open the import project, check the execution summary and the staging data for errors, correct the source rows and import again.

Who uses this

Distributors and manufacturers on Dynamics 365 Supply Chain Management whose larger customers still send purchase orders as PDF attachments: industrial and electrical supply houses, food and packaging suppliers, contract manufacturers and medical distributors. Typical volume is a few dozen to several hundred customer POs a week. Running a smaller Microsoft system? Business Central sales order import covers the same workflow with configuration packages. 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.

What it does not do

PurchaseOrders does not connect to Dynamics 365, does not run Data management projects and does not call OData. It reads customer purchase orders and returns Excel, CSV or JSON. You load the rows through Data management, the Excel add-in, an integration your partner builds or a flow you already run. Your pricing, credit limits, reservations and release rules in Dynamics 365 stay exactly as they are.