How to Import Orders into Prophet 21

Path 1: flat-file imports through SISM

SISM, the Scheduled Import Service Manager, is P21's native bulk order intake. A system drops files in an agreed location, SISM picks them up on schedule, moves each order from Submitted to Processing, and assigns it a P21 order number. This is the same mechanism Epicor's B2B Seller web ordering and the Optimizely commerce connector use under the hood, and third-party tools feed it the same way (P21 Connect's Quick Order iPad form, for one, just produces file sets for SISM to pick up), so the path is well trodden.

The limits matter as much as the mechanics. SISM wants strict, predefined layouts and scheduled batch runs, which suits high-volume, template-friendly loads. Orders that fail validation land in an Import Suspended state, where an operator corrects them before they commit. It cannot handle interactive or branching logic, and it cannot read a file that does not match its template.

Edit-only import mode: validate before you commit

There is a system-level toggle under System Settings, Imports/Exports called edit-only import mode. With it on, P21 validates your file and reports every error and warning without writing anything. Consultants recommend running the import with the toggle on to surface problems, fixing what it finds, then switching it off and running again to commit. Most environments never use it, which means every import commits immediately with no dry run. If you import orders in batches, turn this into a habit.

Mass Update is not an order import tool

People sometimes reach for Mass Update to load orders, and it is the wrong tool. Mass Update is for master records, things like item maintenance, driven from an Excel query with an Import XLS button. It also carries real gotchas: scheduled changes cannot be reversed, a failure on one field means none of that item's updates go through, and errors only surface afterward in the Job Status window. It earns its keep on catalog work, but it is not an order path.

Paths 2 and 3: EDI and the API

EDI 850s from trading partners become sales orders through per-partner rules; that path and its exception handling get a full page of their own. The API path is the most flexible. P21's Transaction API posts transactions, sales orders included, without driving the UI, which makes it the natural target for anything programmatic. Two things to know before planning on it: API access is a separately licensed add-on (shops discover this through a security exception the first time an unlicensed call runs), and the official documentation is thin enough that most working knowledge lives in community docs and forums. Budget for handling quirks too. Community threads are full of automation breaking on UI-shaped surprises like "Unexpected response window: Dynachange Alert".

The orders none of these paths cover

Every path above expects structure: a template file, an EDI document, an API payload. The purchase orders your customers email you have none of that, and at most distributors we talk to, they are the majority of the order count. The manual answer is keying them in Order Entry. The automated answer is an AI layer that reads the email or PDF, matches lines against your item master and customer part number cross references, applies contract pricing, and then uses the API or a structured import to stage a draft order for a person to approve. It feeds the same three native paths, just automatically instead of by hand.

This is the system we build for Prophet 21 shops. Talk to us

Frequently asked questions