Migrate from Expandable ERP to Odoo ERP

Expandable's Part Master is the central item master with revision history, lot/serial tracking parameters, and user-defined fields. We map Part records to Odoo product.product (stockable, consumable, or service variants) with the part number as the default code and the Expandable revision identifier preserved in a custom field product_revision__c. Part parameters (dimensions, materials, supplier lead times) migrate to product attributes and variant values, or to custom fields on product.template if no variant dimension applies. Multi-unit-of-measure settings from Expandable (each, lot, foot, etc.) map to Odoo's unit of measure category with conversion factors.

Expandable BOMs are versioned and linked to specific Part revisions, and sub-assemblies can nest five or more levels deep. We load BOMs in reverse-indent order so that sub-assemblies are created as products before their parent BOMs reference them. The Expandable BOM revision identifier maps to mrp.bom.code, the effective date maps to date_start, and the bom type (normal, phantom, kit) maps to Odoo's type field. BOM line positions preserve the component sequencing from Expandable. This sequencing is critical: if a parent BOM references a sub-assembly that does not yet exist in Odoo, the import fails the foreign-key constraint.

Expandable ECOs and ECMs track revision-controlled changes to parts and BOMs with effective dates and affected BOM levels. We extract ECO records with their effective dates and affected BOM levels, then apply BOM revisions in Odoo by creating new mrp.bom records linked to the same product.template with updated component lists. ECO-to-part revision chains must be preserved for regulated manufacturers that need to demonstrate which BOM was active on which production run. We flag ECOs that have not been released to production as draft BOMs in Odoo.

Expandable Sales Order headers (customer, order date, terms, ship-to) map to Odoo sale.order, and line items (part number, quantity, unit price, scheduled date) map to sale.order.line with the product_id resolved to the Odoo product.product created during the part migration. Open orders migrate as sale orders in the Quotation or Sales Order state; order history migrates as completed sale.order records for reporting continuity. Pricing tiers from Expandable migrate to Odoo pricelist rules attached to the customer.

Expandable PO headers (vendor, terms, requested date) map to Odoo purchase.order, and line items (part number, quantity, unit cost, receipt status) map to purchase.order.line with product_id resolved. Partial receipts from Expandable are reconstructed in Odoo as purchase.order.line records with the received quantity tracked against the ordered quantity. Multi-vendor purchase scenarios and blanket PO structures map to Odoo's blanket order model where the customer has licensed the purchase module add-on.

Expandable's Lot Master tracks on-hand quantities by location and lot number, and serial number traceability records are stored at the part level. We map lot records to Odoo stock.lot (with the product_id and lot name from Expandable) and on-hand quantities to stock.quant with location_id resolved from Expandable's warehouse and bin location fields. Serial number traceability for discrete manufacturing becomes lot_number and sn_ref fields on stock.move.line in Odoo, preserving the chain of custody for regulated environments.

Expandable integrates GL with all subledgers but does not generate financial statements natively; customers rely on Crystal Reports or third-party tools. We extract GL account balances and journal entry lines from Expandable's SQL database and map them to Odoo account.move records. The Expandable chart of accounts structure must be redesigned to fit Odoo's accounting architecture: Expandable account codes map to Odoo account.account records with appropriate account_type values (receivable, payable, asset, liability, equity, revenue, expense). We flag journal entries that reference inactive accounts and escalate to the customer's accountant before import. Historical balance sheet balances may be loaded as opening journal entries rather than individual transactions depending on the cutover scope.

Expandable Quality Events are linked to specific lots, parts, and suppliers and carry FDA-relevant compliance data including event severity, root cause classification, and corrective action status required for FDA 21 CFR Part 820 compliance. We extract event records and map them to Odoo quality.alert for non-conformances, quality.check for inspection points linked to the affected product and lot, and mrp.workorder if corrective actions involve production holds. Event-to-part relationships are preserved as quality.alert references to the migrated stock.lot. We do not flatten compliance metadata to plain text notes; structured fields carry the original severity, root cause, and corrective action status.

Expandable uses role-based Advanced Security with user-to-role mapping stored in its SQL database. These do not map directly to Odoo's group-based access control model. We export a user-to-role mapping table listing each Expandable user's email, name, and role name, then provide a role-mapping guide that maps each Expandable role to the nearest Odoo access group (Sales: User, Manager; Manufacturing: User, Manager; Inventory: User, Manager; Accounting: Billing, Accountant, Billing Admin). The customer's Odoo admin provisions users and assigns groups after reviewing the mapping guide. Active/inactive status from Expandable carries over as the user active flag in Odoo.

Expandable stores document references and link paths but does not have a native document management engine. Binary attachments do not migrate directly. We export all document link paths as a structured CSV keyed to the Expandable entity (Part, BOM, Sales Order, etc.) and advise the customer to configure Odoo's document management (either the native attachments model or a third-party DMS integration) post-migration. Document content stored in third-party tools (PLM systems, SharePoint, network drives) is outside migration scope.

Expandable customers frequently add user-defined fields to the Part Master and custom editor screens using QBE exports and SQL access. We inventory every distinct UDF found in QBE exports and map each to either an Odoo native product field (if semantically equivalent) or a custom ir.model.fields entry on product.template. UDFs that represent part parameters (material grade, finish type, tolerance class) map to Odoo product attribute values where applicable. We do not assume every Expandable UDF has an Odoo equivalent; unmapped UDFs are listed in the handoff document for the customer's Odoo admin to configure post-migration.

Some Expandable customers run third-party RMA and CAPA tools that share data via EDI or API. During discovery we identify whether these tools share data with Expandable and whether that data needs to be consolidated into Odoo's quality module. If RMA/CAPA data lives only in the standalone tool and shares no key with Expandable records, we treat it as a separate migration workstream and flag it in the handoff document. If customer numbers, lot numbers, or part numbers cross-reference between Expandable and the RMA tool, we extract and map those records as quality.alert entries keyed to the migrated product and lot.