Practical guide
Planning purchase-order intake into Odoo
Extracting a purchase-order PDF is only the first step. The important decisions concern customer identity, product mapping, order state and what happens when the destination cannot confirm a write.
Ars Codex · Updated 2026-10-28
Start with the business transaction
A customer purchase order may need to become a sales order in the distributor’s ERP. Do not choose an Odoo object from the document title alone. Confirm who is buying from whom, which company owns the transaction and whether the output should remain a draft.
Write one normal example end to end: source attachment, customer reference, line items, requested date, validation, approval and destination record. Identify which system owns prices, taxes and available stock.
Check the actual Odoo environment
Record the version, hosting model, installed modules, company context and available API access. Use a dedicated account with the required permissions and an environment where test orders cannot trigger real fulfillment.
Consult the official Odoo external API documentation for the interface and access requirements applicable to your version and plan. Confirm these details before committing to a connector or fixed implementation scope.
Map references before writing orders
Customer names and product descriptions are not stable identifiers. Maintain an approved mapping between customer references, product codes and ERP records. A missing product code should produce an explicit exception, not a plausible guessed match.
Check quantities, units, currency, requested dates and delivery addresses. Treat prices extracted from the document as proposed values until the business rules decide which price takes precedence.
Design the uncertain-write case
Suppose the API times out after creating an order. Retrying blindly can create a duplicate. Store a stable source reference, retain the processing state and reconcile with the destination before attempting the operation again.
Keep the source document reference and destination record identifier together. Duplicate detection should consider a business reference and document identity; a filename alone is too weak when a sender resends or renames an attachment.
Test what operations will actually encounter
- The same attachment arrives twice.
- A customer sends a revised order under the same reference.
- A product code is unknown or its unit differs.
- An approver changes a field after review.
- The destination creates a record but the client receives a timeout.
- Permissions expire during processing.
For each case, define the state the operator sees and who can resolve it. Start with draft orders and a reconciliation report before widening the scope.
Related services and example
Explore ERP and API integrations, document automation and the illustrative purchase-order workflow.