Oracle Sales Order Import with FBDI and the Oracle Fusion Sales Order Import Template from Customer PO PDFs

How Oracle Fusion imports sales orders

Oracle Fusion Cloud Order Management has two standard ways to create sales orders without someone in the order entry screen. The first is File-Based Data Import (FBDI). You download the SourceSalesOrderImportTemplate.xlsm workbook from the FBDI guide for Oracle SCM, fill one worksheet per interface table, click Generate CSV File and save the result as a zip. Then you run the scheduled process Load Interface File for Import to move the files into the interface tables, and Import Sales Orders (older releases call it Manage Imported Sales Orders) to create the orders. The second route is the REST API, where the salesOrdersForOrderHub resource creates orders from JSON. Oracle also documents combining the two for very large volumes.

Both routes expect structured data. Neither one reads a PDF. Customers on EDI or a B2B portal can be wired in by your integration team; the customers who email a purchase order land on the order desk and get keyed by hand, one line at a time. PurchaseOrders closes that gap at the front. It reads the customer PO and hands you the rows. FBDI or your integration does the rest.

The template tabs that matter

The workbook has one tab per interface table. Four are required: DOO_ORDER_HEADERS_ALL_INT for the order header, DOO_ORDER_LINES_ALL_INT for the lines, DOO_ORDER_ADDRESSES_INT for ship-to and bill-to, and DOO_ORDER_TXN_ATTRIBUTES_INT for transaction attributes. The rest are optional, including sales credits, payments, lot and serial numbers, document references and manual price adjustments. Two of them, DOO_ORDER_CHARGES_INT and DOO_ORDER_CHARGE_COMPS_INT, become required when you do not let Oracle Pricing calculate the price, which is exactly the case when you want to load the price the customer printed.

On the header, the fields a customer PO feeds are SOURCE_TRANSACTION_ID and SOURCE_TRANSACTION_SYSTEM (together they identify the order), SOURCE_TRANSACTION_NUMBER, BUYING_PARTY_NAME or BUYING_PARTY_NUMBER for the sold-to customer, TRANSACTIONAL_CURRENCY_CODE and CUSTOMER_PO_NUMBER, which Oracle describes as the purchase order number the customer sends to identify the order. SUBMIT_FLAG decides whether the order is only created or also submitted to fulfillment. On the lines, each row repeats the source transaction identifier and system, then adds its own source line identifier, the product number, the ordered quantity and the ordered unit of measure.

Shaping the export for FBDI

The export from PurchaseOrders is one row per line with the header values repeated. Splitting it is mechanical: keep one row per customer PO for the header tab, keep every row for the lines tab, give each PO a source transaction identifier (the customer PO number prefixed with the customer code works well and stays unique), and use the line sequence as the source line identifier. Dates go in the format the template asks for, and amounts use a period for decimals. Most order desks build that workbook once and reuse it for every batch. For the purchase side of the same company, where you load the purchase orders you issue to suppliers, see purchase order FBDI template and Oracle purchase order import.

Matching customer part numbers to your items

The most common reason an imported line errors is the item. Buyers print their own part numbers, and Oracle validates the product against your item master. You can keep a mapping column in the import workbook that turns each buyer part into your item number, or maintain customer item cross-references in Oracle so the customer part resolves to the right item. Either way you set it up once per customer. The extracted data keeps the buyer part number and description side by side, which makes the first mapping quick. Errors show up under Manage Order Orchestration Messages; fix the source rows, regenerate the CSV and rerun until the status is Succeeded.

Who uses this

Distributors and manufacturers on Oracle Fusion Cloud whose larger customers still send purchase orders as PDF attachments: industrial and electrical distributors, medical and lab supply companies, packaging suppliers and contract manufacturers. Typical volume runs from a few dozen to several hundred customer POs a week, enough that hand entry ties up people and puts quantity and price errors into orders. Running the same workflow on another system? The steps carry over to NetSuite sales order import and JD Edwards sales order import, and the general version lives on the sales order entry automation page. If Monday starts with 40 POs in the shared inbox, use bulk purchase order upload to run them in one pass.

What it does not do

PurchaseOrders does not connect to Oracle Fusion, does not upload files to Oracle, does not run scheduled processes and does not write to the interface tables. It reads customer purchase orders and returns Excel, CSV or JSON. You load the rows with FBDI, a REST integration your team or partner builds, or an integration platform you already use. Your Order Management pricing, credit checks and orchestration rules stay exactly as they are.