# How to Create a SYSPRO Sales Order with the SORTOI Business Object > Source: https://netray.co/erp-help/syspro-sortoi-business-object-create-sales-order-xml > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer SORTOI is the SYSPRO e.net business object that enters sales orders from outside the SYSPRO client. You log on to get a session id, call the business object with a Parameter XML and a Document XML describing the order header and lines, then read the XML that comes back for warnings and the new sales order number. Always test in a non-production company first. ## Kind how-to ## System small-erp ## Erp SYSPRO ## Module e.net Solutions / Sales Orders (SORTOI) ## Query SYSPRO SORTOI create sales order XML e.net business object ## Alternate Queries - SYSPRO e.net create sales order from external system - SORTOI XmlIn example SYSPRO - SYSPRO business object sales order integration - SYSPRO post sales order via XML ## Applies To SYSPRO 7 and SYSPRO 8 with e.net Solutions licensed and the e.net service running; exact XML element names vary slightly by release, so check the XSD files that ship with your version ## Steps ### Steps to post a sales order through SORTOI **Items:** - Confirm e.net Solutions is licensed and the e.net communications service is running on the SYSPRO application server. - Create a dedicated SYSPRO operator for the integration, with only the security rights it needs for sales order entry, and a company password if your company requires one. - Call the logon method with operator, operator password, company id and company password. Keep the returned session id (a GUID) for every later call. - Build the Parameter XML (processing options such as whether to ignore warnings and whether to allow non-stocked items) and the Document XML (customer, order date, warehouse, and one stock line per item with quantity and price). - Validate both XML documents against the XSD files shipped in the SYSPRO Base\Schemas folder before sending, so structural errors are caught on your side. - Call the Build method for SORTOI first to validate, then Post for the real order, passing the session id, the business object name, the Parameter XML and the Document XML. - Parse the XmlOut: success returns the order number; failure returns an error number and message. Log both the input and output XML. - Log off to release the licence slot when the batch finishes. ## Sections ### Session and licensing **Body:** Every e.net call needs a valid session. The logon call consumes a SYSPRO user licence the same way an interactive operator would, so a long-running integration that never logs off, or that logs on once per order, can exhaust licences and block real users. The common pattern is one logon per batch, many business object calls, one logoff in a finally block. Use a named integration operator rather than a person's login. That gives you a clean audit trail in the SYSPRO audit and transaction logs, and means a password change for a human does not break the interface. Restrict that operator in Operator Maintenance to the programs and company it needs. ### Shape of the Document XML **Body:** The SORTOI document nests the order header and its lines. The header carries the customer code, the customer purchase order reference, the order date and the requested ship date; each stock line carries the stock code, the warehouse, the order quantity, the unit of measure and optionally a price override. Non-stocked (miscellaneous) lines and comment lines use their own line types. Do not guess element names. SYSPRO ships an XSD for the input and output of each business object, and the sample XML files in the schema folder are the quickest starting point. Build your payload from the sample, then trim. Pricing deserves a decision up front: either let SYSPRO price the line from the price list and contract pricing, or pass a price and enable the price-override option. Mixing the two silently is the most common reason an integrated order total differs from the web shop's total. **Code:** Parameter XML (illustrative, confirm element names against the XSD for your release): N Y ### Reading errors and warnings **Body:** The XmlOut of a failed call contains an error number, a description and usually the element that failed validation: an inactive customer, a stock code that does not exist in the warehouse, a credit hold, or a line quantity below the minimum order quantity. Treat the text as the authority; do not map errors by number alone because numbers are reused across business objects. Warnings are different from errors. With IgnoreWarnings set to N, a warning such as a credit limit exceedance stops the order; with Y it posts the order and you must decide separately whether it should be on hold. Many teams post with N and route warning cases to a human queue. ### Idempotency and retries **Body:** SORTOI does not know your external order id unless you store it. Put it in the customer PO field or a user-defined field, and search for it before retrying after a timeout. Otherwise a network failure after SYSPRO committed the order but before your client read the reply produces a duplicate order on retry. For high volumes, queue orders and post them serially through one or a few sessions. Parallel posts against the same customer or stock code can hit record locks and produce intermittent failures that are hard to reproduce. ## Pitfalls - Logging on for every order and never logging off, which burns licences and eventually locks out interactive users. - Hard-coding XML element names from a blog post written for a different release instead of the XSD in your install. - Posting with IgnoreWarnings set to Y and accidentally bypassing credit-hold logic. - No external reference stored on the order, so retries create duplicate sales orders. - Testing in the live company; a bad loop can create hundreds of orders that are tedious to cancel. - Sending prices without enabling price override, so SYSPRO quietly reprices from the price list. ## Ai Angle An assistant grounded in your SYSPRO company can generate the Parameter and Document XML from a plain-language order, validate stock codes, warehouses and customer status against the database before anything is posted, and explain an e.net error in plain terms. In Netray's design the posting step is a human-approved write-back, not an autonomous action, and the read side is read-only against SYSPRO tables. ## Faq ### Do I need e.net Solutions to use SORTOI? **Answer:** Yes. Business objects are exposed through the e.net Solutions component, which is licensed separately from the base SYSPRO client. Confirm with your SYSPRO reseller that e.net is on your licence and that the e.net service is installed and running on the application server. ### Can I call SORTOI from a language other than .NET or VB? **Answer:** Yes, anything that can call the e.net interface and exchange XML strings can drive it. That includes .NET, Java through a bridge, and the e.net REST service in recent releases, if it is enabled. The XML payloads are the same whichever client you use. ### Why does my order post but the price is wrong? **Answer:** Usually SYSPRO repriced the line from price lists or contract pricing because price override was not enabled, or because the customer's price code differs from what your external system assumed. Decide which system owns pricing and configure the Parameter XML accordingly. ### How do I update an existing order instead of creating one? **Answer:** Use the matching update business object for sales orders rather than SORTOI, which is for new orders. Check the e.net business object list for your release for the current name, and test line changes carefully because they can affect allocations and releases. ## Search terms SYSPRO SORTOI, SYSPRO e.net, SYSPRO business object, SYSPRO sales order XML, SYSPRO integration, SYSPRO e.net logon, SYSPRO XML in XML out, SYSPRO order entry API, SYSPRO REST e.net --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json