Migrate from proALPHA ERP to Odoo ERP

proALPHA treats Customers and Vendors as distinct partner records with classification, address, and contact data. We split these into Odoo's Contact and Company (res.partner) model where contacts are people linked to company records. The proALPHA partner type field (KUNDTYP, LIEFERTYP) determines whether each record becomes a Customer flag, Vendor flag, or both on the res.partner record. Partner-specific classifications and credit limits migrate to custom fields on the partner record.

proALPHA Items carry product masters with multi-level BOMs, variant configurations, and operation routings. We decompose each Item into an Odoo Product template, variant records (if proALPHA variants exist), a top-level BoM record with component lines, and sub-Bom records for each BOM level. proALPHA routing operations map to Odoo Work Center records with cycle time and work order capacity. Variant configuration data from proALPHA's product configurator requires a separate mapping session with the customer's engineering team to define the dimension-to-variant mapping in Odoo.

proALPHA Work Orders contain operation sequences, work center assignments, scheduling constraints tied to APS, material allocations, and backflush records. We extract order status, material components with quantities, work center operations with cycle times, and backflush postings. In Odoo, these become Manufacturing Orders with BoM components resolved from the product mapping, work orders generated from the BoM routing, and qty_producing set to the order quantity. Orders in Closed or Cancelled status are imported as historical records with no further state transitions.

proALPHA maintains a structured COA with cost centers, department assignments, and posting keys that define debit/credit rules. We map each proALPHA account to an Odoo account.account record with the correct account type ( receivable, payable, liquidity, expense, revenue, etc.), and create corresponding account.journal records for the posting model. Cost center assignments from proALPHA map to Odoo analytic accounts, which are a separate dimension in Odoo's accounting. We validate that account codes are unique and that account types are consistent before import.

Historical journal entries from proALPHA's financial module migrate to Odoo account.move records in the Posted state for closed periods and in Draft for the current open period. Each journal entry line maps account, debit, credit, analytic account (from proALPHA cost center), and partner reference. We scope which fiscal years to migrate versus archive based on the customer's reporting retention requirements, and flag any journal entries with incompatible data types (non-numeric amounts, missing account references) for manual review before import.

proALPHA fixed asset records include acquisition cost, depreciation schedules, useful life in periods, depreciation method (linear, declining balance), and location assignments, all integrated into the financial module. We preserve the depreciation method and remaining useful life, create the Odoo asset record with corresponding account.move entries for each depreciation posting, and map asset category to Odoo's asset category model. Any assets with partially posted depreciation at cutover are flagged so that the first Odoo depreciation run picks up the correct remaining balance.

proALPHA's multi-site warehouse management holds stock quantities, bin locations, and lot/serial numbers across sites. We map each proALPHA warehouse to an Odoo stock.warehouse record and each bin or sub-location to a stock.location record within the warehouse's location tree. Stock quantities migrate as stock.quant records linked to the product, location, lot, and owner. Lot and serial numbers migrate to stock.production.lot and are linked to the quant records.

Open and recently closed sales orders from proALPHA migrate to Odoo sale.order records with order lines, taxes, payment terms, and delivery addresses. The proALPHA order status (Open, Completed, Cancelled) maps to Odoo's state field, and confirmed orders trigger the creation of related delivery orders (stock.picking) if the customer continues using Odoo's warehouse management. Historical orders beyond the cutoff window are flagged for archiving rather than active migration.

Open purchase orders migrate to Odoo purchase.order with vendor reference, order lines, expected delivery dates, and invoicing control. proALPHA's goods-receipt status maps to Odoo's picking-related state. Vendor-specific terms and conditions stored as text in proALPHA migrate to the purchase order's notes field.

Outstanding payables and receivables are extracted at a fixed cutover timestamp with payment terms, due dates, and partial allocations preserved. Open vendor bills become Odoo account.move records of type in_invoice (draft or posted depending on the original state), and open customer invoices become out_invoice records. Partial payments are modeled as related account.payment records linked to the original invoice. We freeze AP/AR data on the cutover date and migrate open items as of that date to avoid gaps in reporting continuity.

proALPHA's integrated document management stores binary files linked to business objects (Customers, Items, Work Orders). The document metadata (filename, mime type, link, object reference) is extracted from proALPHA's DMS tables. Binary files are extracted via a parallel file transfer operation to Odoo's filestore directory and registered as ir.attachment records with a res_model and res_id pointing to the migrated parent record. The customer validates attachment integrity after import and flags any orphaned references for manual repair.

proALPHA supports user-defined fields per module, but field names and data types are defined per-customer during implementation, resulting in no stable global schema. We document every custom field encountered during the discovery scan, infer the Odoo field type (Char, Integer, Float, Selection, Many2one) from the proALPHA data values, and create equivalent ir.model.fields records in Odoo before the main migration begins. Each custom field is mapped individually and validated against the source data to catch type mismatches early.