ERP migration
Field-level mapping, validation, and rollback between reybex and Odoo ERP. We move data and schema; workflows are rebuilt natively in Odoo ERP.
reybex
Source
Odoo ERP
Destination
Compatibility
9 of 11
objects map 1:1 between reybex and Odoo ERP.
Complexity
BStandard
Timeline
4-8 weeks
Overview
reybex bundles ERP, WMS, and financial accounting behind an API-first architecture targeting German SMEs in ecommerce, wholesale, and manufacturing. Odoo ERP is a Belgian open-source platform with a free Community edition and a paid Enterprise subscription, offering 50+ integrated modules from CRM through manufacturing. The structural differences between these platforms center on how Articles (SKUs with variant matrices) map to Odoo product variants, how GoBD-compliant invoice metadata translates to Odoo accounting records, and whether reybex EDI transaction sets can be preserved at all. We perform schema discovery against reybex's undocumented frontend-style API endpoints before writing any mapping, extract financial records with their TSE signature and tax code fields explicitly preserved, and schedule inventory snapshots during low-activity windows to avoid discrepancies from in-flight orders. Workflows, automations, and EDI partner mappings are not migrated; we deliver written inventories for the customer's admin to rebuild.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a reybex object lands in Odoo ERP, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
reybex
Customer
Odoo ERP
res.partner
1:1reybex Customer records (name, address, contact fields) map 1:1 to Odoo res.partner with address type differentiation (invoice address vs delivery address via partner_address fields). Country-specific address structures are preserved through street, street2, city, state_id, zip, and country_id fields. VAT number from reybex maps to res.partner.vat for EU tax validation.
reybex
Article
Odoo ERP
product.product + product.template
1:manyreybex Articles (SKUs with variant matrices for attributes like size and color) must be split into Odoo's two-object product model. The article header becomes product.template; each variant combination becomes a separate product.product record linked via product.template.attribute_line_ids. Multi-language article names and descriptions from reybex map to product.template.name and description fields with the relevant language context. Variant-specific pricing, barcodes, and stock quantities attach to product.product records.
reybex
Sales Order
Odoo ERP
sale.order + sale.order.line
1:1reybex Sales Order headers map to sale.order with partner_id resolved from the Customer mapping, currency_id set from the order's currency, and order state translated from reybex status. Line items map to sale.order.line with product_id resolved to the product.product variant, price_unit and discount preserved, and taxes mapped from reybex tax codes to Odoo account.tax records. Order references, delivery addresses, and incoterms transfer as order-level fields.
reybex
Purchase Order
Odoo ERP
purchase.order + purchase.order.line
1:1reybex Purchase Orders map to purchase.order with partner_id resolved from the reybex vendor (stored as a Customer with vendor type in reybex). Lines map to purchase.order.line with product_id and price_unit from reybex. PO approval workflows do not migrate; the Odoo purchase configuration defaults to draft state on creation and the customer's admin sets up approval rules post-migration. Vendor-specific payment terms from reybex map to account.payment.term.
reybex
Inventory / Stock Levels
Odoo ERP
stock.quant + stock.location
1:1reybex real-time stock quantities per warehouse location map to Odoo stock.quant records tied to stock.location records. We create location records matching reybex warehouse names, then create quant records with product_id, location_id, quantity, and lot_id (for lot/batch-tracked stock). Bin-level or serialized stock requires custom field mapping; we detect serialized articles during schema discovery and create stock.production.lot records before quant import. Stock moves and the reybex reorder-point configuration are not migrated; Odoo's Odoo stock module provides its own reorder point configuration post-migration.
reybex
Invoice
Odoo ERP
account.move
1:1reybex invoices carry GoBD-compliant metadata (TSE signatures, document numbers, tax code assignments) that must be explicitly mapped to Odoo account.move fields. We map reybex invoice date to account.move.invoice_date, invoice number to name/ref, and tax codes to account.tax records with the correct tax_group_id. The reybex TSE signature and document number are stored in custom fields on account.move (tse_signature__c, gobd_document_number__c) to preserve audit trail integrity. Multi-currency invoices require currency_id mapping from reybex currency codes to Odoo res.currency. Cancelled or voided invoices in reybex map to Odoo state= cancel with the original move preserved for audit.
reybex
Banking / Cash Transactions
Odoo ERP
account.bank.statement + account.move.line
1:1reybex POS cash register transactions and bank statement lines map to Odoo account.bank.statement (for statement lines) and account.move.line (for journal entries). TSE-signed receipts carry legal weight; we preserve TSE data in a custom field on account.move.line. The reybex cash register (TSE-integrated GoBD cash register) output is exported as a structured reference document; Odoo POS module provides its own cash control configuration for post-migration setup.
reybex
Project
Odoo ERP
project.project
1:1reybex Project records with tasks, time entries, and budgets map to Odoo project.project and project.task. Task dependencies and milestone hierarchies from reybex are flattened during export and reconstructed as project.task dependencies in Odoo. Budget figures map to the Odoo project financial fields or to a project budgetary line object if the customer licenses the Odoo Project Enterprise features. Milestone date tracking from reybex becomes task deadline fields in Odoo.
reybex
Manufacturing / Production Order
Odoo ERP
mrp.production + mrp.bom
1:1reybex BOMs (bills of materials) and production routings map to Odoo mrp.bom and mrp.routing objects. Finished-goods outputs map to mrp.production records with product_id, product_qty, and bom_id resolved. Material consumption lines map to mrp.bom.line records with the component product and quantity. Machine capacity planning data from reybex does not transfer natively; Odoo's work center and cycle-time configuration on mrp.routing provides the equivalent planning model but must be rebuilt by the customer's manufacturing team. Production order status (draft, confirmed, in progress, done) translates to Odoo state and state字段.
reybex
CRM Activities
Odoo ERP
mail.message + mail.activity
1:1reybex CRM activities (calls, emails, meetings, notes) tied to Customer records map to Odoo mail.message records (for the timeline) and mail.activity records (for task-like follow-ups). Activity types map from reybex category to Odoo activity_type_id; timestamps preserve via date field. Custom activity fields detected during schema discovery are mapped to mail.message custom field columns. Activities without a matching Odoo partner (Customer) are linked to a general company partner record during import.
reybex
Custom Fields
Odoo ERP
Custom Fields
lossyCustom fields defined on reybex Articles and Customers are detected during the pre-migration schema discovery visit (required because reybex does not publish API documentation). We generate a mapping matrix of every custom field definition including its data type, and pre-create matching fields on the corresponding Odoo model before data import begins. Field types are translated: reybex text fields become char or text, numeric fields become float or integer, date fields become date, and multi-select fields become char with delimiter or selection fields in Odoo.
| reybex | Odoo ERP | Compatibility | |
|---|---|---|---|
| Customer | res.partner1:1 | Fully supported | |
| Article | product.product + product.template1:many | Fully supported | |
| Sales Order | sale.order + sale.order.line1:1 | Fully supported | |
| Purchase Order | purchase.order + purchase.order.line1:1 | Fully supported | |
| Inventory / Stock Levels | stock.quant + stock.location1:1 | Mapping required | |
| Invoice | account.move1:1 | Fully supported | |
| Banking / Cash Transactions | account.bank.statement + account.move.line1:1 | Mapping required | |
| Project | project.project1:1 | Fully supported | |
| Manufacturing / Production Order | mrp.production + mrp.bom1:1 | Fully supported | |
| CRM Activities | mail.message + mail.activity1:1 | Fully supported | |
| Custom Fields | Custom Fieldslossy | Mapping required |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
reybex gotchas
No public API documentation for schema discovery
EDI transaction sets are not transferable
GoBD compliance metadata must be explicitly preserved
Inventory snapshots require coordination with active orders
No documented bulk export or batch API
Odoo ERP gotchas
No rollback for CSV imports
External ID conflicts on re-import
Many2many field encoding in CSV imports
Large export timeouts require batching
Version schema drift between Odoo releases
Pair-specific challenges
Migration approach
Schema discovery and reybex audit
We receive tenant credentials and perform a pre-migration audit visit using reybex's frontend-style API endpoints. We enumerate every object (Customer, Article, Sales Order, Invoice, etc.), detect all custom field definitions, measure record counts per object, and identify EDI partner configurations and GoBD compliance records. This step produces the data inventory that drives the full mapping matrix. Because reybex does not publish API documentation, this discovery visit is mandatory and cannot be skipped; it typically adds five to ten business days to the project schedule.
Destination Odoo environment setup and schema provisioning
We set up the destination Odoo environment (customer-provisioned Odoo Online, on-premise, or Odoo.sh instance) and provision the required modules: Sales, Purchase, Inventory, Accounting, Project, and Manufacturing as applicable. We pre-create all custom fields detected during schema discovery on the corresponding Odoo models, configure chart of accounts aligned to the reybex account structure, and set up warehouse locations matching reybex warehouse definitions. If the customer uses Odoo Community edition, we configure the accounting module with German localization (chart of accounts, tax codes, and GoBD-relevant fields) during this step.
GoBD compliance field configuration and tax code mapping
We configure custom fields on account.move and account.move.line to store the reybex TSE signature, document number, and tax code assignments. We map reybex account numbers to Odoo account.account records, ensuring that the financial chart of accounts is aligned before any invoice data is loaded. Any reybex invoice with missing TSE data is flagged and routed to the customer's admin for manual verification before the financial migration phase begins. This step is sequenced before the main invoice import to prevent compliance gaps from propagating into production.
Sandbox migration and reconciliation
We run a full migration into the Odoo sandbox environment using production-like data volume. The customer's team reconciles record counts (Customers in, Articles in with variant breakdown, Orders in, Invoices in, Stock quants in, Projects in), spot-checks thirty to fifty records across each object against the reybex source, and validates that GoBD fields are populated on a random sample of financial records. Any mapping corrections happen in sandbox before production migration begins. This step also reveals whether custom fields discovered during schema discovery require additional type conversions.
Production migration in dependency order
We run production migration in record-dependency order: res.partner (Customers and Vendors), product.template and product.product (Articles with variants unpacked), stock.location and stock.quant (Inventory snapshot), account.account and account.tax (Chart and tax configuration already done but validated), account.move (Invoices with GoBD fields), sale.order and sale.order.line (Sales Orders), purchase.order and purchase.order.line (Purchase Orders), project.project and project.task (Projects), mrp.bom and mrp.production (Manufacturing), and mail.message and mail.activity (CRM Activities). Each phase emits a row-count reconciliation report; migration pauses if any phase exceeds a two percent record rejection rate until the cause is diagnosed and resolved.
Cutover, validation, and EDI handoff
We freeze reybex writes during cutover, run a final delta migration of any records modified during the migration window, then enable Odoo as the system of record. We deliver the EDI partner mapping reference document, the GoBD compliance mapping document, and a written inventory of any reybex workflows or automations requiring rebuild in Odoo. We support a five-business-day hypercare window where we resolve post-go-live reconciliation issues raised by the customer's team. We do not rebuild reybex automations as Odoo server actions or automated activities inside the migration scope; that work is a separate engagement for the customer's Odoo partner.
Platform deep dives
reybex
Source
Strengths
Weaknesses
Odoo ERP
Destination
Strengths
Weaknesses
Complexity grading
Standard ERP migration. 2 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across reybex and Odoo ERP.
Object compatibility
2 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
reybex: Not publicly documented.
Data volume sensitivity
reybex exposes a bulk API — large-volume migrations stream efficiently.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during reybex to Odoo ERP migration scoping. Not seeing yours? Book a call.
Walk through your reybex to Odoo ERP migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave reybex
Other ways to arrive at Odoo ERP
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.