Odoo order automation should start by checking what the buyer can already send. When structured order data is available, reading a rendered PDF may add an unnecessary conversion step. When the buyer sends only documents, extraction and review can prepare the records for a controlled import.
The right choice depends on the customer's Odoo version, installed applications, hosting arrangement and trading partners. This guide uses Odoo 19 documentation to compare three routes: native purchase-to-sales exchange, file import and a separately designed API integration. Each route still needs correct customer, product and order-line relationships.
Check native purchase-to-sales exchange first
Odoo 19 documents an EDI workflow in which a buyer exports a purchase order as XML and a seller imports it into another Odoo database. The documented exchange uses UBL and carries customer and order-line information into the selling workflow. This is worth evaluating when both trading parties can use that route.
Ask whether the buyer can provide the structured file consistently and who handles revisions. Validate product references and commercial values in the receiving database rather than assuming the exchange is correct because both businesses use Odoo. If another system produces the XML, verify the supported schema and actual fields; a file extension alone does not establish compatibility.
Use a reviewed import when the source is a document
When the customer supplies a PDF or spreadsheet that needs interpretation, preserve its source values while resolving the seller's customer and product records. Review units, quantities and prices before preparing the import file. Keep the buyer's PO reference separate from any identifier generated for the receiving system.
Odoo documents importing business objects through CSV or XLSX and provides a Test step before import. Use a sample export or an appropriate template from the actual customer database to establish field names. A generic approved-order CSV may still need transformation and additional references before it fits that database's model and installed modules.
Make external identifiers and relationships explicit
Odoo's import guidance recommends retaining the External ID column and using unique identifiers. For order work, define identities for the transaction and the records it references. An order line needs to remain connected to its parent order and the intended product; matching by a display name becomes fragile when names repeat.
Build a small test containing two customers with similar names and several orders sharing a product. Verify each relationship in Odoo after import. Decide whether subsequent files create new records or update existing ones, and keep identifiers stable for that chosen behavior. Record how a changed customer PO is represented so a correction cannot silently become an unrelated order.
Review the product variant and commercial context
A customer's product description may identify a general item while the seller needs a particular size, finish or pack. Resolve the intended variant before treating quantity and price as comparable values. Keep the customer's own item code as evidence even when a controlled internal reference is selected.
Work through one order using a non-default delivery destination and another containing a unit mismatch. Check the imported order against the reviewed values, including any defaults supplied by the customer's Odoo configuration. If the ERP recalculates a commercial value, agree whether that result is expected and who approves the difference before the order progresses.
Evaluate API fit against the installed version
Odoo 19 documents the External JSON-2 API and its security model. An integration plan should identify the actual version, accessible models and methods, authentication and available API access before choosing an implementation. Do not assume a connector written for another Odoo interface has the same request or permission behavior.
Separate catalog reads from order creation and subsequent business actions. A generic HTTPS connection needs a compatible method and response shape, not merely a valid hostname. Have the administrator provide a narrowly scoped test route and define what happens when access expires or a required module changes. Keep credentials outside the order-review form and record who owns their rotation and removal.
Use the import test, then inspect the result
Start in an approved test database with a few representative orders. Use Odoo's import validation, then inspect the created records and their lines. Confirm the customer, product references, destination, quantities, prices and intended stage in the selling process. Check any custom fields introduced by the customer's modules.
Repeat the same input and test an amended PO before expanding volume. Record how the chosen route handles already existing records and which failures need an operator. For a batch with mixed results, keep a transaction-level record of what was accepted. Resubmitting the entire batch without reconciliation can turn a small correction into a duplicate-order problem.
Choose the route that fits the trading relationship
Use Odoo's native structured exchange where it meets the requirement. For document-led orders, Ordinon provides source-side review, human approval and approved CSV exports, with manual product pulls through a compatible configured HTTPS endpoint. An Odoo-specific mapping or API adapter is separate implementation work; scheduled sync and automatic order creation are outside the current Ordinon workflow.