Odoo for procurement, sourcing and import companies: from 173 Excel columns to one product model

Sourcing and import companies live between two worlds: factories in Asia, and demanding retailers in Europe. In between sits a chain of RFQs, samples, inspections, compliance, article data and invoicing. We recently made a solution assessment for such a company, and one number stuck: a single article row held 173 columns, in 13 field groups, each with a supplying party and a responsible role. That is a complete PIM model that happens to live in Excel. This is how Odoo brings that chain onto one platform, how PIM, EDI and portals work together, and how we build the heart of it with Updoo.

The sourcing model has its own demands

A sourcing or procurement-facilitation company works differently from a standard wholesaler. It helps retailers and online players buy directly from the factory in Asia - OEM and private label - and earns on facilitation, quality and margin. The business model determines what the system must do. In practice we see two variants, often side by side:

• Facilitating for a fee: you bring the customer to the right factory, arrange quality, compliance and logistics, and earn a fee or margin. You hold no stock yourself.
• Buying and reselling: you buy to order, get paid up front, and arrange the import. Here too, goods go directly from the factory to the customer.

Both demand a system that can handle the chain, from the RFQ at the factory to delivery at the retailer, without you managing a warehouse. That is a different question from “inventory management for a wholesaler”, and precisely where generic tools get stuck.

Every product introduction in a new Excel file

At this kind of company the process is often excellent on paper. What is missing is one system. Everything runs via Excel, Teams, email and an ERP with limitations. Every product introduction goes through the same series of milestones - in the assessment more than 25, from shopping list to product evaluation - but each time in a new Excel file. That costs time, causes errors, and makes steering on status impossible. You cannot see at a glance which products sit where in the process, which inspection is scheduled, or which certificate is about to expire.

This is the same dynamic we described in from Excel to Odoo. These companies are mature. They are stuck on loose files. The homework is done well; it lacks a home.

Three building blocks: PIM, EDI and portal

B2B wholesale and import run on three things that must be right. Each is a building block with its own job:

• PIM: the product data. Specifications, variants, prices, images, compliance and documents from one source. This is the foundation: the retailer catalogue, the webshop, the quotes and the portal all draw from it. Wrong product data means wrong specifications, a missing certificate or a portal price that no longer applies.
• EDI: the order flow with large buyers. Orders, order confirmations, delivery notes and invoices go electronically. A small customer emails an order list; a large retailer expects automation, and more and more often makes it a condition for being a supplier at all.
• Portal: self-service. Customers check order history, place repeat orders, fetch documents and invoices. Suppliers upload certificates, photos and packaging data. Both take load off your team.

Separately each works halfway. Together on one data model they form the backbone, with the product data as source.

The architecture: from RFQ to retailer on one data model

What it comes down to is coherence. In Odoo the links of the sourcing chain come together on one data model. From the assessment, with a clear split of what runs standard and what is built:

That split is half the work. It shows what you switch on, what you configure, what you build, and what you move to a later phase on purpose. No hollow “Odoo does everything”.

PIM: the heart of the system

Back to those 173 columns. They fall into 13 field groups - from general product info and price history (FOB, landed cost, sales price per country, margin) to logistics, packaging convenant (grams per material for PPWR), artwork requirements with dozens of compliance markings, certification (BOM, TCF, REACH, RoHS, DPP), test reports per sample phase, and ten product-photo positions. Each field has an owner: the supplier, the compliance department or the merchandiser.

So this is a complete PIM model, including who supplies what. Standard Odoo falls short here, for three reasons:

• Price history with dates. FOB price 1, 2 and 3 with date, plus landed costs and sales prices per country. Odoo keeps the current price. A structured history with margin calculation is missing.
• Ownership per field group. The supplier fills in logistics and packaging, compliance the certifications, the merchandiser the basics. That requires write rights per field group. Standard Odoo sets rights per model.
• Compliance as a living dossier. Certificates and markings expire and determine whether a product may go into inspection. The system must flag a certificate before it expires.

Our proposal: PIM as an Updoo shell around Odoo

Here we make a deliberate architecture choice. We rule out two options. External PIM packages are built for retail catalogues (many SKUs, little process), while this model is the reverse: each article carries a complete dossier with ownership per field group and an approval flow. A heavy custom module inside Odoo fights the framework and ties down your hosting.

What we build is an Updoo product as a shell around Odoo. The shell is the source for the full 173-field model. Odoo only gets the transactional subset that orders, invoices and margins need - article number, EAN, description, cost, HS code, colli, some 15 to 20 fields. And the sync runs one direction: from the shell to Odoo. That is a principle. Syncing back and forth rebuilds the Excel chaos, more expensively. One source of truth means exactly one. That principle, and where the line is, we work out in PIM as a shell around Odoo.

We use the same pattern for the supplier portal: an own portal layer on top of Odoo where suppliers upload certificates, photos and packaging data themselves, with Odoo as the data layer. Faster, more flexible and easier to manage than prising open the standard Odoo portal. Portal and PIM become one environment for the supplier.

What the data does after creation

Article creation is one moment. The real work starts after it, which is why this has to be a living system. The data does four things:

• It feeds transactions. The subset in Odoo returns on every PO and SO line, invoice and margin calculation. On a repeat order the system automatically checks whether the data still holds: certificates valid, latest artwork and manual linked.
• It mutates. New FOB prices, changed packaging, new manual versions, articles from New to Active to EOL - each change with date and owner. The history Excel does not keep.
• It expires. Certificates have an expiry date. The shell monitors it and triggers renewal at the supplier via the portal, with the mail signals you need.
• It reports. Packaging data becomes PPWR reporting, DPP is coming, vendor scorecards and margin dashboards draw from the same source. And a customer catalogue or website in a later phase becomes easy: the data already exists.

The pressure from large retailers: EDI and portals

A separate trigger forces your hand. Large retailers do not work with order lists by email. They expect EDI connections, order statuses, a supplier portal and clean article data. In the assessment the orders still arrived in a mailbox and were downloaded by hand. That works up to a certain volume; after that it becomes a bottleneck and a source of errors.

An EDI connection turns incoming orders into sales orders in Odoo automatically, with the right article data from the PIM and statuses back to the buyer. You do need the retailer’s EDI specifications; that is always the first step. How this plays out at a large supermarket chain is in EDI with a large retailer.

On the customer side a B2B customer portal gives buyers their own environment: order history, quick repeat orders, quotes, documents and invoices. Fewer emails and calls for inside sales, better service for the customer. You build it on the standard Odoo portal, with an extension where your process is unique. More in B2B customer portal in Odoo. If you also sell online yourself, a webshop is the fourth channel; see connecting Shopify to Odoo.

How it comes together, and where it goes wrong

On one data model the building blocks feed each other:

• The product data feeds the webshop, the EDI catalogue and the portals. One source, not five.
• Orders from EDI and the portal become sales orders in Odoo, with the same items and prices.
• Availability shown in the channels comes from the same system, and the accounting runs along automatically.

A change in one place is then right everywhere. The pitfalls are always the same:

• PIM as an afterthought. If the product data is a loose end, the problem leaks into every channel. Start with the data.
• Underestimating EDI. Every retailer has its own specifications. “An EDI connection” only exists per buyer.
• A portal that is only a login. Without real self-service (repeat orders, documents, status) a portal does not relieve anyone.
• Separate systems. A separate PIM package, EDI tool and portal kept in sync by hand rebuild the Excel chaos at a higher price.

Multiple entities, China and Europe

Sourcing companies almost always combine multiple countries and entities: sales in the Netherlands (and sometimes Poland), back office in China, a separate entity in Hong Kong. That stacks complexity, and three things need settling up front:

• Bank connections. For European banks an automatic connection is standard; for Chinese and Hong Kong banks you test this per bank. If it cannot be automatic, a daily bank import is the fallback.
• Hosting and performance from China. Access to a cloud environment from China is a known point of attention. The question “Singapore versus Europe” becomes urgent when most of your users sit in China. We work that choice out in the hosting guide.
• Communication. WeChat with factories is daily reality in China, but not a standard Odoo integration. Expect email and portal in the system, WeChat alongside.

Odoo runs the entities as multi-company with consolidated reporting. The local accounting (for example the Chinese one) you often keep local and connect to the group; the trade-off is in international accounting with Odoo. More on multilingual, international deployment in Odoo for international rollouts.

The most important architecture question

One question determines the whole setup, and you ask it in the fit-gap: is the product model yours, or yours-for-a-specific-retailer? If many field groups now carry a large customer’s requirements, and a second retailer comes along, the model has to handle customer-specific layers - own article numbers, own compliance requirements, own artwork. That determines whether you build a dataset per customer or one generic model with customer profiles. It is the most important architecture choice of the whole project, and you make it best up front.

How to approach it

1. Fit-gap on the heaviest parts. The PIM architecture (the customer question above), the EDI specifications and the user landscape across entities.
2. Decide the source of truth. There is one product model. Sync in one direction.
3. Phase in clear steps. Phase 1 = PIM, project management, orders and finance. Dashboards grow along. Website, email marketing and events come after.
4. Test the assumptions. Number of real users versus portal users, bank connections, hosting location. That affects both the licences and the cost. We do the maths in what an Odoo implementation costs.

In short

A sourcing or import company has a chain problem: from the factory in Asia to the retailer in Europe everything has to add up, across multiple languages, currencies and entities. The gain sits in one product model that carries the whole process, with PIM as the source and EDI and portals drawing from it. Odoo brings purchasing, sales, project management, EDI, inspections and accounting together; with Updoo we build the PIM shell and portals where your process is unique. Standard where it can, a smart shell where it has to.

Recognise this in your trading or import company? Schedule a no-obligation Quickscan and we will map your chain, your product data, your order flows and your biggest risks - including a clear split of what runs standard and what becomes custom.

Read more: From Excel to Odoo · PIM as a shell around Odoo · EDI with a large retailer · B2B customer portal in Odoo · Selling without your own warehouse · Odoo for leasing and rental companies · Odoo for international rollouts · Odoo hosting and data residency international · Connect Shopify to Odoo · What does an Odoo implementation cost? · Updoo: extensions on Odoo