Migrate from Login ERP to Odoo ERP

Login ERP's hierarchical account structure with Turkish fiscal classification codes maps to Odoo's Chart of Accounts configuration. We extract account codes, names, parent references, account types (asset, liability, equity, income, expense), and Turkish tax agency mappings. During migration we create Odoo account.account records with the correct user_type_id, code prefix matching the source hierarchy, and any Turkish-specific tax tags stored in Login ERP's fiscal configuration tables. Currency defaults to TRY unless the destination Odoo instance is configured for multi-currency.

Login ERP customer records (company name, Vergi Kimlik No tax ID, address, contact details, payment terms) map to Odoo res.partner records with customer_rank set for CRM and sale order creation. Turkish tax ID (Vergi Kimlik No) migrates to res.partner's vat field. We inspect any custom extension tables the customer has added for additional address or contact fields and create matching custom fields on res.partner before import. Payment terms from Login ERP map to Odoo's account.payment.term records.

Vendor master data mirrors the customer structure with Turkish supplier tax IDs and bank account details. We map to Odoo res.partner records with supplier_rank set, preserving the Vergi Kimlik No in the vat field and bank account details in res.partner.bank records. Vendor categories from Login ERP become Odoo res.partner.category tags for segmentation.

Login ERP items carry unit of measure conversions, cost layers (FIFO/average), bill of materials for manufactured items, and multi-warehouse stock tracking. We map to Odoo product.template (with product_variant_count and attribute_line configuration for variants), product.product variants, and stock.quant for inventory quantities. Login ERP's cost method (FIFO vs average) maps to Odoo's product.cost_method. Multi-warehouse locations become Odoo stock.location records with a location_ids hierarchy.

Login ERP multi-level BOMs with component structures and routing/step labor definitions migrate to Odoo mrp.bom records with type=normal or type=kit. Parent-child integrity is preserved during extraction by sorting BOMs in dependency order (sub-assemblies first, top-level last). Odoo requires mrp.workcenter records for routing labor; we create workcenters from Login ERP's labor step definitions or flag for manual setup if the source data does not include routing information.

Outstanding invoices, credit memos, and payment records carry TRY amounts with exchange rate histories. We preserve original posting date, due date, and invoice number. Currency is set to TRY or the original transaction currency if multi-currency. Odoo requires the related partner_id (res.partner), account_id (mapped from Login ERP's receivable/payable account), and line_ids with debit/credit amounts. Open AP/AR are imported before payment records to satisfy the foreign-key relationship on matched records.

Journal entries, invoices, and receipts spanning the full fiscal history require date-windowed chunking by fiscal year. We scope a cutoff date during discovery, exclude voided or reversed entries flagged in Login ERP, and chunk by source journal (sales, purchase, general) to avoid overwhelming Odoo's External API. Each fiscal year's entries are imported as a separate batch with the correct period_id assigned. Turkish Lira amounts are imported at original value; currency conversion to EUR or destination currency is a configurable step if the Odoo instance uses a different base currency.

Login ERP HR module stores employee records with compensation, PTO balances, effective-dated job changes, and Turkish SGK and tax regulation fields. We map to Odoo hr.employee with basic fields (name, department_id, job_id, work_email). Login ERP payroll history tied to Turkish SGK regulations requires custom field mapping or manual reconciliation after migration because Odoo's standard HR module does not natively replicate Turkish SGK calculation logic. We flag payroll fields requiring a separate payroll module configuration or partner engagement.

Login ERP work orders with status completed or cancelled migrate as Odoo mrp.production records with state=done or state=cancel. Work orders with status in-progress or on-hold are excluded from migration because they carry open material allocations and labor postings that cannot be safely imported without creating phantom inventory transactions in Odoo. These in-flight orders are flagged in a separate inventory for manual re-entry post-go-live. Completed production orders migrate as historical records with the originating BoM and components preserved.

Login ERP QC inspection data links to purchase orders and production runs. The schema is customer-extended and not part of the standard module set. We inspect the actual table definition before committing to migration scope. If QC data is stored in a proprietary extension table, we export metadata (inspection ID, date, result, linked PO or production order reference) to a CSV and deliver it alongside the migration for the customer's admin to recreate as Odoo quality.alerts or a custom QC module. We do not attempt to import binary data from non-standard tables without a schema review.