SAP Business One Sales Order Import with DTW oOrders and SAP B1 Sales Order Templates from Customer PO PDFs
SAP Business One loads sales orders in bulk through the Data Transfer Workbench oOrders object, and DTW only takes rows.
PDF, JPG, PNG, BMP, HEIC, TIFF
Submit your purchase orders
Drop documents here, or choose a file
Up to 50 files per batch
Uploading...
Overview
SAP Business One loads sales orders in bulk through the Data Transfer Workbench oOrders object, and DTW only takes rows. Upload the purchase order a customer emailed and get the PO number, ship-to, dates and every line with part, quantity and price, ready for the Documents and Document_Lines templates.
Why customer POs still get typed into the sales order screen
SAP Business One has a perfectly good bulk route for sales orders. It just starts from a spreadsheet, and your customers send PDFs.
DTW wants two linked files
A sales order is a Documents header file plus a Document_Lines file. Every line needs the header RecordKey in its ParentKey column, or the order fails.
LineNum starts at zero
The first line of each order is 0, the second is 1. Teams that number lines 1, 2, 3 from the PDF get shifted or rejected rows.
Buyer part numbers are not your ItemCode
Customers order by their own part numbers. Unless the row carries your ItemCode or a BP catalog number set up for that customer, the line will not import.
The customer PO number gets lost
If nobody puts the buyer PO number in Customer Ref. No. (NumAtCard), the order desk cannot find the sales order when the buyer calls with only their reference.
From customer PO to DTW sales order rows
Upload the purchase order your customer sent. The AI reads the header and every line and returns a spreadsheet with one row per line and the header values repeated, ready to split into the oOrders Documents and Document_Lines templates.
Reads any PO layout
No per-customer template. Digital PDFs, scans and photographed pages from any buyer system come back in the same column layout.
Line order preserved
Lines return in document order with a sequence number, so LineNum becomes 0, 1, 2 with one formula and ParentKey stays matched.
Customer PO in its own column
The buyer PO number lands in a dedicated column that maps straight to NumAtCard, so every sales order is searchable by the customer reference.
The price the buyer printed
Unit price comes off the document for each line, so you can load it as the line price or compare it with your SAP Business One price list first.
How SAP Business One imports sales orders
SAP Business One has two standard routes for creating sales orders without a person in the Sales Order screen. The first is the Data Transfer Workbench (DTW), which ships with SAP Business One and imports business objects from CSV or tab-delimited text files. Sales orders are the oOrders object, and like every marketing document they come as two templates: Documents for the header and Document_Lines for the rows. The second route is the Service Layer, the REST API, where a POST to the Orders entity with a CardCode, a DocDueDate and a DocumentLines array creates the order. Either way the result lands in the same tables, ORDR for the header and RDR1 for the lines, as object type 17.
Both routes expect structured data. Neither one reads a PDF. That is the whole gap: customers on EDI or a B2B portal can be wired in, while the customers who email a purchase order land on the order desk and get keyed by hand, line by line. PurchaseOrders closes that gap at the front. It reads the customer PO and gives you the rows; DTW or your Service Layer integration does the rest.
The DTW oOrders templates, field by field
The DTW templates have two header rows. The first holds the object field names (RecordKey, CardCode, DocDate) and the second holds the database column names; your data starts on the third row. Header fields that matter for a customer order are RecordKey (your own running number, 1, 2, 3 per order in the batch), CardCode (the customer business partner code, not the name), DocDate, DocDueDate (the delivery date, required on sales orders) and NumAtCard (Customer Ref. No., where the buyer PO number belongs). On the lines, ParentKey repeats the RecordKey of the header it belongs to, LineNum counts from 0, and ItemCode, Quantity and usually Price, WarehouseCode and a tax code complete the row, depending on how your company is set up.
The export from PurchaseOrders is one row per line with the header values repeated. Splitting it is mechanical: keep one row per PO number for the Documents file, keep every row for Document_Lines, number the orders with RecordKey, and derive LineNum from the line sequence minus one. Most order desks save that workbook once and reuse it for every batch. For the purchase side of the same company, where you load the POs you issue to vendors, see SAP Business One purchase order import with DTW.
Matching customer part numbers to your items
The most common reason a DTW sales order line fails is the item. Buyers print their own part numbers, and SAP Business One validates ItemCode against your item master. Two fixes work. You can keep a mapping column in the import workbook that turns each buyer part into your ItemCode, or you can maintain Business Partner Catalog Numbers in SAP Business One so the customer part number is recognized against the right item. Either way you set it up once per customer and every later order from that buyer goes through. The extracted data keeps the buyer part number and description side by side, which makes the first mapping fast.
Who uses this
Distributors and manufacturers on SAP Business One whose largest customers still send purchase orders as PDF attachments: industrial supply houses, food and beverage wholesalers, packaging and electrical distributors, and contract manufacturers. Typical volume is anywhere from a few dozen to several hundred customer POs a week, enough that hand entry costs a person or two and introduces errors in quantity and price. If you run the same workflow on another system, the steps are the same for NetSuite sales order import and Acumatica sales order import, and the general version lives on the sales order entry automation page.
What it does not do
PurchaseOrders does not install in SAP Business One, does not write to ORDR or RDR1, and is not an add-on certified by SAP. It reads customer purchase orders and returns Excel, CSV or JSON. You load the rows with DTW, a Service Layer integration your partner builds, or an integration platform you already use. That separation is deliberate: nothing about your SAP Business One validation, pricing or approval setup changes.
Customer PO field to DTW oOrders field
What comes off the customer document and which oOrders template field it usually fills. Confirm the columns against the template that ships with your DTW version before the first load.
| Field | Template | Where it comes from | Notes |
|---|---|---|---|
| RecordKey | Documents | Your running number for each order in the batch. | 1, 2, 3, one per customer PO |
| CardCode | Documents | The buyer on the PO, matched to a customer business partner code. | Code, not the name |
| DocDate | Documents | The PO date or the date you enter the order. | Posting date of the sales order |
| DocDueDate | Documents | The requested delivery date on the PO. | Required on sales orders |
| NumAtCard | Documents | The purchase order number the customer printed. | Customer Ref. No. field |
| ShipToCode | Documents | The ship-to address on the PO, matched to a customer address ID. | Optional, else the default ship-to |
| ParentKey | Document_Lines | The RecordKey of the order the line belongs to. | Must match the header exactly |
| LineNum | Document_Lines | Line sequence from the document, minus one. | Starts at 0 |
| ItemCode | Document_Lines | Your item, from the buyer part number via a mapping or BP catalog number. | Validated against the item master |
| Quantity | Document_Lines | Ordered quantity on each line. | Required |
| Price | Document_Lines | The unit price the buyer printed. | Leave empty to use your price list |
| WarehouseCode | Document_Lines | Your shipping warehouse for the line. | Else the item default warehouse |
How the import runs
Four steps from the customer attachment to sales orders in SAP Business One.
Upload the customer PO
Drop in the PDF, the scan or the email attachment. Up to 50 files per bulk upload, with no per-customer setup.
Tip: Portal downloads and forwarded attachments work the same way.
Review and Map
Check the header and lines on screen, then map the buyer to a CardCode and confirm each part has an ItemCode or a BP catalog number.
Tip: Add a missing catalog number once and every later order from that buyer matches.
Build the two DTW files
Download CSV, keep one row per order for Documents and every row for Document_Lines, set RecordKey and ParentKey, and turn the line sequence into LineNum 0, 1, 2.
Tip: Save the workbook as the template for every future batch.
Run DTW and check the log
Choose the oOrders object in DTW, simulate first, then import and review the orders in the Sales Order screen.
Tip: Start with one two-line PO before a full batch.
Why order desks use this in front of SAP business one
Security and privacy
- Bank-grade TLS encryption in transit
- Your PO data is never sold or shared
- US-based cloud infrastructure
SAP business one sales order import questions
Use the Data Transfer Workbench with the oOrders object. Fill the Documents template with one header row per order and the Document_Lines template with one row per line, linked by RecordKey and ParentKey, then simulate and run the import. The Service Layer Orders endpoint is the API alternative for an integration.
The oOrders object uses two templates, Documents and Document_Lines, found in the DTW templates folder under the marketing documents. Each has two header rows: object field names first, database column names second. Your data starts on row three, and you should not delete template columns you leave empty.
On the header, RecordKey, CardCode, DocDate and DocDueDate, since sales orders need a delivery date. On each line, ParentKey matching the header RecordKey, LineNum starting at 0, ItemCode and Quantity. Price, warehouse and tax code are needed or defaulted depending on how your company is configured.
The ParentKey on the line does not match any RecordKey in the Documents file loaded in the same run. Check for trailing spaces, a different numbering start, or a header row that was filtered out. Every line must point at a header that exists in the same import.
In Customer Ref. No., the NumAtCard field on the header. Load it from the PO number on the customer document, and the order desk can search sales orders by the buyer reference when a customer calls without your order number.
ORDR holds the sales order header and RDR1 holds the lines, linked by DocEntry. The object type for a sales order is 17. DTW and the Service Layer both write through the business object, so you never insert into these tables directly.
Not natively. DTW and the Service Layer expect structured rows or JSON. A customer PO that arrives as a PDF has to become data first, typed into the Sales Order screen or extracted, before SAP Business One can create the order in bulk.
No. PurchaseOrders reads the customer purchase order and returns structured data as Excel, CSV or JSON. It does not install in SAP Business One or write to ORDR. You load the rows with DTW, a Service Layer integration or an integration platform you already run.
Related resources
SAP business one purchase order import
The buying side: POs you issue.
SAP sales order upload
The same workflow on SAP S/4HANA and ECC.
NetSuite sales order import
The same workflow on NetSuite.
Acumatica sales order import
The same workflow on Acumatica.
JD Edwards sales order import
The same workflow on JD Edwards.
Sales order entry automation
The full order entry workflow.