Odoo AI import mapping: validate supplier prices

Back

Kevin Riedl

11 min read · 5 Nov 2026
Last reviewed November 5, 2026

Next

Suppose a supplier file quotes EUR 1,200.00 for a box of 24 pieces. The proposed mapping produces a perfectly valid number, 50.00, but leaves the target purchase unit as “box.” The arithmetic is correct. The resulting price means something different from the supplier’s offer.

Use AI to propose an Odoo import mapping, then validate it against independently approved source definitions and reference tables. Preserve existing record identities and the price basis of each purchase unit. Hold unresolved meanings for a data owner, and require a controlled native rehearsal before approving the import.

Research checked: 5 November 2026. Product facts use official Odoo 20 documentation sources. We ran twelve synthetic mapping cases with Python and Decimal arithmetic. The candidate mappings were constructed manually; no AI generated them. We did not import into Odoo or test native unit conversion. Native acceptance checks remain NOT_RUN.

What should AI do in an Odoo import mapping?

AI can propose which source columns correspond to target fields and identify rows that need explanation. A separately reviewed mapping contract should decide whether that proposal is acceptable. The data owner must settle the source meanings, permitted transformations and update identities before a plausible field association becomes an instruction to change business records.

For a supplier price update, “price” is incomplete. You need to know what quantity the price buys and which existing supplier-price line should change. A confident proposal that silently fills those gaps has exceeded the evidence in the source file.

The official import guide uses External IDs to identify records and reconstruct relationships. Our acceptance contract adds the business meanings that the identifier alone cannot supply.

This article owns the decision before import. The migration acceptance guide covers the later comparison of transferred records and workflows. Repeated supplier delivery updates have a different architecture decision, covered in Odoo rules, n8n or an AI agent.

Which source meanings must be fixed first?

Fix the source identity and value conventions before transforming supplier prices. Preserve identifiers as text, define the price and minimum-quantity basis, and resolve product and vendor references against approved lookups. If the source cannot establish a date convention or pack size, the mapping needs a decision from its owner before it can proceed.

Our fictional file has two lines. Both use supplier code 0042 for company A. Another lookup entry uses the same supplier code for company B. The product codes 00123 and 00124 are strings whose leading zeros form part of the agreed identifiers.

The source policy explicitly accepts a decimal comma and an optional dot as a grouped thousands separator. It requires two fractional digits. Under that policy, 1.200,00 becomes the decimal value 1200.00. This parser is deliberately narrow; it is not a universal detector of spreadsheet number formats.

The date convention is also supplied independently. With day/month/year approved, 01/03/2026 becomes 2026-03-01. If that convention is absent, the validator holds the case. A model’s preferred interpretation does not resolve an ambiguous source value.

Keep existing offer identity separate from product identity. A supplier can have more than one price condition for a product in a real catalog. The example’s approved lookup names the exact two existing lines; it does not propose “supplier plus SKU” as a universal identifier for every price break or validity period.

Why must the price and purchase unit stay together?

A supplier price and its purchase unit describe one commercial meaning. Changing the amount without the unit, or changing the unit without the amount, can create a different offer. The minimum purchase quantity must use the same declared basis. Approve that combination as one mapping decision before applying any normalization.

Odoo’s unit-of-measure documentation places purchase units on vendor lines and distinguishes them from inventory units. The correct target unit therefore depends on the actual product and vendor configuration.

For L01, EUR 1,200.00 ÷ 24 pieces = EUR 50.00 per piece. Its minimum of 2 boxes corresponds to 48 pieces. Our approved mapping retains the box basis: purchase unit box-of-24, price 1200.00 and minimum quantity 2.

For L02, EUR 48.00 ÷ 12 = EUR 4.00 per piece, and 3 boxes contain 36 pieces. Those calculations help a reviewer check the source meaning. They are not extra price fields to import alongside the retained box price.

An independently approved conversion to individual units could be valid. It would need the corresponding price and minimum quantity, plus proof that the target workflow uses that basis correctly. The supplied validator enforces one declared contract; it does not prohibit all alternative mappings.

How do you validate the mapping independently?

Validate the candidate against source rules and reference lookups approved separately from the candidate itself. Compare every included row with its expected normalized fields, preserving line coverage and exact target identity. A candidate’s confidence score, explanation or claim that it has checked itself should not determine whether those comparisons pass.

The downloadable fixture contains source rows, an approved-policy object and candidate rows as separate inputs. The validator derives expected values from the source policy, resolves company-scoped vendor references and compares the candidate field by field. It reports mismatches with the source-line key so a reviewer can find the affected row.

This independence is about decision ownership. If the same model invents a pack factor and inserts it into both the mapping and its purported reference table, two matching outputs still rest on one unsupported assumption. The owner should link the pack definition to a supplier specification or an approved product record.

Before using live supplier data with an AI service, apply the approved data-route decision for that service. The Odoo AI data-residency review owns that separate question. The fixture here contains only invented records.

What did the twelve mapping checks show?

All twelve constructed mapping cases received their expected classification: one READY_FOR_REHEARSAL, eight REJECT and three HOLD. These results establish the behavior of the supplied validator on its declared fixture. They do not measure AI mapping accuracy or show that an Odoo import would succeed.

Download the validator and fixture file into the same directory, then run:

python3 mapping-validator.py

Compare the output with the recorded results. A successful process exit means all twelve classifications matched, including the deliberately rejected and held cases. It is not an import approval.

The script accepts the declared JSON shape and source conventions. It does not open arbitrary spreadsheets, discover native fields or handle every tax, currency and pricing rule. The fixture’s normalized keys are an intermediate review format, not a ready-to-upload Odoo CSV.

When should a mapping be held for human review?

Hold a mapping when the authoritative source meaning or target reference is missing. Reject it when the approved meaning is known and the proposal contradicts it. This distinction directs the next action: an incorrect price needs a corrected mapping, while an unknown pack size needs evidence from someone responsible for the data.

The supplied mapping review record keeps the proposed transformation separate from its approval evidence. Record the source file identity and mapping revision, then name the owner who can settle each unresolved field. A hold should have a specific question, such as “does minimum 2 mean boxes or pieces?”

Do not turn a missing product lookup into automatic product creation unless that behavior belongs to the approved import scope. In this example, the task updates existing supplier-price records. Creating a new product or a new offer changes the decision and requires its own acceptance criteria.

The checker also cannot establish whether an approved lookup is true. If company A’s vendor reference was wrongly approved at the source, the candidate may match it perfectly. Review the reference data before relying on a green comparison, and retain the evidence that supports the chosen relationship.

What must the Odoo rehearsal prove?

The Odoo rehearsal must establish that the reviewed mapping uses the actual target fields and produces the intended supplier-price behavior. Check references and units in the configured installation, then verify the intended updates and a representative draft purchasing workflow. The synthetic validator only establishes that the intermediate proposal matches its declared contract.

Odoo’s vendor-pricelist guide recommends exporting existing records as a template and distinguishes price from minimum quantity. Start from that target-specific structure instead of renaming fixture keys and assuming they are native import columns.

The native acceptance pack has fourteen proposed checks, all NOT_RUN with PENDING acceptance. Actual evidence and reviewer fields remain empty.

A draft purchasing check does not authorize sending an order or confirming a purchase. Keep those actions outside this rehearsal unless the business owner separately includes them. The purpose here is to inspect the mapping’s consequences before a production update.

Retain the exact file used in rehearsal and its approved transformation revision. If the source supplier changes a column’s meaning next month, a familiar header is insufficient evidence that the old rule still applies. Reassess the affected mapping and repeat the relevant checks.

What would we approve before importing?

We would approve a specific mapping revision only after its source meanings and target identities are resolved, its known counterexamples are rejected, and the native rehearsal supports the intended update. An unresolved row remains held. The person accepting the supplier-price meaning should be identifiable in the evidence, alongside the person responsible for the import.

Begin with the price/unit/minimum combination and the exact existing offer identity. Those decisions determine whether a successful-looking transformation preserves the supplier’s terms and updates the intended record. Add format and relationship checks around them, keeping the source file available for review.

For the wider release decision, use the software QA checklist. Wavect’s software quality assurance service can help define and independently review the acceptance evidence for an import workflow. Bring the source specification and the mappings whose meaning is still disputed.