Prophet 21 Order Entry Automation and P21 Sales Order Import from Customer PO PDFs

How Prophet 21 takes in customer orders

Epicor Prophet 21 is the ERP a large share of US wholesale distributors run on: industrial supply, plumbing and HVAC, electrical, fluid power, bearings and power transmission, medical and janitorial supply. Its order entry screen is built for an inside sales rep with a phone on one ear, and it is fast for that. It is slow for the other half of the job, the purchase orders customers email as PDF attachments, because every line still has to be typed. P21 has three supported ways to create sales orders without the Order Entry window.

The first is the Scheduled Import Service Manager (SISM). A file in a predefined layout is dropped in an agreed folder, SISM picks it up on its schedule, and each order moves from Submitted to Processing and receives a P21 order number. Orders that fail validation stop in an Import Suspended state where someone corrects them before they commit. The second route is EDI 850 transactions, which P21 converts into sales orders with rules set per trading partner, usually through an EDI provider. The third is the P21 Transaction API, which posts sales orders without driving the user interface. API access is licensed separately, and calls from an unlicensed environment fail with a security exception.

All three need structured data. SISM will not read a file that does not match its template, EDI needs a trading partner sending X12, and the API needs JSON your integration builds. None of them reads the PDF a buyer attaches to an email. That is the step PurchaseOrders handles. It reads the customer PO and returns the header and every line as rows, and your SISM layout, integration or order desk does the rest.

Test the file before it commits

P21 has an edit-only import mode under System Settings, Imports/Exports. With it on, an import validates the file and reports errors and warnings without writing a single order. The safe routine is to run the file once in edit-only mode, fix whatever it reports, switch the mode off and run it again to commit. Most environments leave the mode off, which means a bad file commits immediately, so check that setting before the first load from a new customer.

The fields P21 has to resolve on every order

A customer PO only carries what the buyer knows: their company name, their PO number, a ship-to address, part numbers, quantities, units, prices and dates. P21 needs its own keys for most of that. On the header the order needs a Company Id, Customer Id, Ship To Id, Location Id and Source Location Id, a Carrier Id, an Order Date, a Requested Date and the PO No. On each line it needs a Line No, the item, the Unit Quantity, the Unit Price, a Required Date and a source location. The buyer name, the address and the part numbers on the PDF are not P21 IDs, so each has to be matched once per customer. Ship-to is the one that catches people: a customer with forty branches has forty Ship To Ids, and the right one is usually found by matching the street number and ZIP code on the PO to the ship-to records under that customer.

Matching customer part numbers to your items

Most lines that stop in Import Suspended fail on the item. Buyers print their own part numbers and descriptions, and a distributor with 80,000 SKUs cannot guess which one a buyer means from a short description. Keep a mapping column in the workbook that turns each buyer part into your item ID, or maintain the customer part number cross reference inside P21 so the translation lives in the ERP. The extracted data keeps the buyer part number, your part number when the buyer printed it, and the description side by side, which makes the first mapping fast and every later order nearly automatic. Units deserve the same care: CS, BX, EA, FT and PK come in every spelling, and a case of 12 keyed as 12 eaches is a pricing problem you find on the invoice.

Who uses this

Order desks and inside sales teams at US distributors on Prophet 21 whose contractors, OEMs, hospitals and facilities customers still send purchase orders as PDFs, from a handful a day to several hundred a week. They pay to stop keying lines, to get orders into P21 the same morning they arrive, and to stop the wrong-ship-to and wrong-unit errors that show up later as returns and credit memos. The general version of the workflow is on the sales order entry automation page, and a Monday inbox of 40 POs goes through bulk purchase order upload in one pass. Running Eclipse at some branches? See Epicor Eclipse order entry automation. On Epicor Kinetic instead? Epicor sales order import with DMT covers the Sales Order Combined template.

What it does not do

PurchaseOrders does not connect to Prophet 21, does not write SISM files to your server, does not call the P21 API and is not an EDI translator. It reads customer purchase orders and returns Excel, CSV or JSON. You load the rows through your SISM layout, an integration your Epicor partner builds, or the order desk. Your pricing, contracts, credit holds and allocation rules in P21 stay exactly as they are.