Southeast Asia Marketplace Pack

Key Features

Dedicated `marketplace.channel` model holding credentials, currency, fee profile, fiscal position and per-channel sequences

Order ingestion via scheduled `ir.cron` polling or a webhook controller, whichever the marketplace exposes, with retry and dead-letter handling

Idempotent import: a database unique constraint on (channel, external order id) so a replayed webhook or overlapping cron never duplicates a `sale.order`

`marketplace.listing` bridge mapping many channel SKUs to one `product.product`, including variants and bundle components

Per-channel stock buffers on a `marketplace.stock.buffer` model — fixed, percentage or computed from forecasted quantity — with an `@api.depends` compute publishing adjusted availability

Push-back of adjusted stock to each channel on a configurable cadence, with a per-channel throttle so campaign-day rate limits are respected

`marketplace.settlement` document with typed fee lines (commission, service, shipping subsidy, campaign, adjustment, refund) mapped to accounts through an editable fee profile

Payout reconciliation matching settlement lines to originating invoices and the bank statement, leaving unmatched items on an exception list with order references attached

Per-channel and per-region fiscal positions and tax mappings, so an invoice raised for a Malaysian buyer carries different treatment from an Indonesian one without manual intervention

Channel-specific invoice and packing document layouts as inheritable QWeb templates rather than hard-coded HTML

Marketplace-initiated returns modelled end to end: reverse picking, credit note, and the channel return id preserved on both records

Multi-currency handling that records the settlement's own FX figures, so the realised difference posts instead of being absorbed into revenue

Record rules plus `ir.model.access.csv` entries so a country or brand team sees only its own channels and settlements

Automated actions for routine escalations — stalled imports, unreconciled settlement lines older than N days, buffer breaches

Full XML-RPC/JSON-RPC exposure of every model, so BI tools, WMS devices and your own scripts read the same data the UI does

Built to order, done for you

No DIY setup — a working app, built, installed and supported by ECOSIRE.

You order

Start with a one-time build price. We scope it with you at kickoff.

We build & install

ECOSIRE builds, configures and installs it on your Odoo.

Go live + support

You go live in about 2–4 weeks, with a post-launch support window.

About this Product

Sellers running three or four Southeast-Asian marketplaces at once end up running three or four businesses. Each channel has its own order states, its own fee schedule, its own settlement cycle, its own returns window and its own idea of what an invoice should look like in Indonesia versus Malaysia versus the Philippines. Odoo core has no concept of a marketplace: sale.order has no channel, stock.quant has no per-channel allocation, and account.payment has no notion of a settlement statement that arrives two weeks after the sale with commission, shipping subsidy, campaign fees and a currency adjustment already deducted. Teams bridge the gap with CSV exports and a spreadsheet, and the spreadsheet quietly becomes the system of record — which is where the oversell and the unreconciled payout come from.

This pack puts the channel into the data model. We add a marketplace.channel model carrying credentials, currency, fee profile and fiscal position, and stamp every imported order with it, so sale.order gains marketplace_channel_id, an external reference and the raw channel payload for audit. Orders land through a scheduled ir.cron polling job or a webhook controller (whichever the channel supports), are de-duplicated on the external id with a database-level unique constraint, and map to your existing products through a marketplace.listing bridge — one Odoo product, many channel SKUs, so a bundle or a variant sold under three different listing codes still moves one product.product. Stock is not simply mirrored: a marketplace.stock.buffer model holds per-channel reserve rules (fixed units, percentage, or a compute reading forecasted quantity), and a @api.depends-driven compute publishes an adjusted availability figure per channel rather than your real free-to-use quantity, which is the single most effective defence against oversell during a 9.9 or 11.11 campaign.

The money side is where the build earns itself back. Settlement files and payout APIs are imported into a marketplace.settlement document with typed lines — commission, service fee, shipping subsidy, campaign contribution, adjustment, refund — and each line maps to an account through a configurable fee profile so posting produces a real journal entry rather than a lump-sum bank line. The settlement reconciles against the originating invoices and against the bank statement, and anything that does not match is left on an exception list with the order reference attached instead of being silently absorbed. Tax and invoicing follow the same rule: fiscal positions and tax mappings are driven per channel and per delivery region, and channel-specific document layouts are QWeb templates you can edit, not hard-coded HTML. Returns are modelled as their own flow, so a marketplace-initiated return creates the reverse picking and the credit note with the channel's own return id preserved on both.

Everything is a proper Odoo addon: a real __manifest__.py with declared dependencies on sale_management, stock and account, models under models/, access rights in ir.model.access.csv plus record rules so a country team sees only its own channels, list/form/kanban views in XML with OWL components only where a plain view genuinely cannot do the job, a settlement and reconciliation report in QWeb, and automated actions for the routine escalations. Credentials are stored per channel and never in source. The models are exposed over the standard XML-RPC/JSON-RPC API like any other, so your BI tool or a warehouse device can read them. We build against Community and note explicitly where an Enterprise-only feature (for example accounting bank-statement automation) changes the recommended flow, and we ship on whichever of Odoo 17.0, 18.0 or 19.0 you actually run.

This is a build-to-order product, not a download. You request a quotation, we run a scoping call, and we come back with a written scope naming the exact marketplaces, the settlement formats we will parse, the tax jurisdictions in play and the acceptance criteria. Typical delivery is 2-4 weeks from confirmed scope. We install on a staging copy of your database first, run UAT with your own historical orders and a real settlement file, and only then go to production with a documented rollback. You receive the full source in a git repository you own.

What you get

Installable addon source built and tested against your exact Odoo version (17.0, 18.0 or 19.0), Community or Enterprise

Installation and configuration on your staging environment, including channel credentials, listing mapping and fee profiles

Technical documentation: data model, model and field reference, cron and webhook wiring, extension points and upgrade notes

End-user guide plus a live training session for your operations and finance team, recorded for later joiners

UAT on staging using your own historical orders and at least one real settlement file, against written acceptance criteria

Production deployment with a documented rollback plan and a pre-deployment database backup

Post-go-live support window for defect fixes on the delivered scope

Handover of the complete git repository, with commit history, to an account you own

Who this is for

Regional e-commerce operations manager

Runs three to five marketplace storefronts across two or more Southeast-Asian countries and currently reconciles them in spreadsheets. Needs one order queue, one stock position and a defensible answer to 'why did we oversell on campaign day' without adding headcount per channel.

Finance lead or group controller

Cannot close the month because payouts arrive net of commission, subsidies and adjustments with no line-level trace back to invoices. Needs settlement documents that post real journal entries, reconcile against the bank, and leave a visible exception list rather than a plug figure.

Warehouse and inventory manager

Holds one physical stock pool serving several channels and is judged on both fill rate and cancellation rate. Needs per-channel reserve rules and controlled publishing of availability instead of mirroring free-to-use quantity everywhere at once.

Odoo functional consultant or in-house ERP owner

Owns the Odoo instance and will maintain this after handover. Needs a conventional addon — clear manifest, models, security CSV, record rules, inheritable QWeb — that upgrades cleanly and does not fork core behaviour.

How Southeast Asia Marketplace Pack Compares

Criterion	ECOSIRE	Custom Build	Competitor	Odoo Native
Marketplace coverage	Exactly the channels in your scope, each with its own adapter against a shared core	Whatever your team has time to build, usually one channel at a time	A fixed list the vendor chose; your channel may not be on it	None — Odoo core has no marketplace concept at all
Stock control across channels	Per-channel buffer rules (fixed, percentage or computed) with controlled publishing	Achievable, but the buffer logic is the part teams usually postpone	Typically mirrors free-to-use quantity to every channel identically	One `stock.quant` figure, no channel dimension
Payout and fee reconciliation	Typed settlement lines posted to mapped accounts, matched to invoices and bank, exceptions surfaced	Often the last phase built, and the first dropped when budget tightens	Usually order sync only; settlement handling is out of scope	A single bank line; fees absorbed manually or in a spreadsheet
Tax and invoice localisation	Per-channel and per-region fiscal positions with editable QWeb document layouts	Possible, but each jurisdiction is fresh analysis for your team	Generic layout; localisation left to you	Standard fiscal positions, applied manually per order
Source code ownership	Full source in a git repository you own, with commit history	You own it, and you own every future fix	Licensed or obfuscated code; you depend on the vendor's roadmap	Odoo core only; no custom layer exists
Upgrade path across Odoo versions	Built for your version; migrations available under a maintenance agreement	Migration cost lands on your team at every major release	Depends entirely on whether the vendor ports it in time	Core upgrades cleanly, but there is nothing here to upgrade
Security and data access	`ir.model.access.csv` plus record rules so a country team sees only its channels	As good as the developer's discipline on the day	Commonly a single flat access group covering all channels	Standard Odoo groups, no channel-level segregation
Time to a working system	2-4 weeks from confirmed scope, including staging UAT and rollback plan	Months, plus the internal opportunity cost of your ERP team	Fast to install, then slow to bend to how you actually operate	Immediate — and immediately manual

Frequently Asked Questions about Southeast Asia Marketplace Pack

How long does delivery take, and how does the build-to-order process work?

Typical delivery is 2-4 weeks from confirmed scope. This is not an existing download from apps.odoo.com — we build it for your database. You request a quotation, we run a scoping call to fix the exact marketplaces, settlement formats and tax jurisdictions, and we return a written scope with acceptance criteria and a fixed quote. Then build, staging install, UAT with your own data, and production with a rollback plan. Complex multi-country tax scope or an unusual settlement format can extend that; we say so before you commit, not afterwards.

Which marketplaces does it cover?

We build for the specific Shopee/Lazada-class marketplaces you actually sell on, named in your scope. The channel model, listing bridge, buffer engine and settlement framework are shared; the per-marketplace adapter is the part written for each channel. Adding a further marketplace later is an incremental adapter against the same core, not a rebuild.

Does it work on Odoo Community, or do I need Enterprise?

It runs on Community. We build against `sale_management`, `stock` and `account`, all of which are Community modules. Where an Enterprise feature changes the recommended flow — bank-statement import automation and the accounting reconciliation widget are the usual ones — we document the difference and design the Community path so nothing is blocked. Tell us which edition you run before scoping.

What happens to support and updates after go-live?

The quote includes a post-go-live support window for defects in the delivered scope. Beyond that we offer an optional maintenance agreement covering marketplace API changes, Odoo point-release compatibility and version migrations. You own the git repository outright, so you are never locked in — your own team or another partner can maintain it. Marketplace APIs do change; budget for that regardless of who maintains the code.

How do the stock buffers actually prevent overselling?

Odoo's free-to-use quantity is published to every channel simultaneously, so the same unit can be sold three times inside the sync interval. The pack computes a per-channel published availability instead: real quantity minus that channel's reserve, where the reserve is a fixed number, a percentage, or a compute reading forecasted quantity. Buffers are per channel and per product, so you can run a high-velocity campaign channel tight and hold a cushion elsewhere.

Will this modify or fork Odoo core?

No. It is a conventional addon with a real `__manifest__.py` declaring its dependencies. It extends core models through inheritance and adds its own, ships security in `ir.model.access.csv` with record rules, and uses inheritable QWeb templates for documents. Nothing in `odoo/addons` is patched, so standard upgrades apply normally.

Can we import our existing marketplace order history?

Yes, subject to what each marketplace's API will still return — most limit historical retrieval to a rolling window. We import what the API exposes and can load older data from your exports. Historical orders are marked as such so they do not trigger fulfilment or duplicate accounting entries. Scope the history range in the scoping call, because it affects both effort and the UAT dataset.