Migrate from eFacto ERP to Odoo ERP

eFacto stores the COA as a flat SQL table with account codes, names, and inactive flags. We extract all active accounts and map them to Odoo's account.account model, preserving the source account code as Odoo's code field. Inactive eFacto accounts are exported with their disable_date so the customer can decide whether to archive or import them. Odoo's internal_type (view, other, receivable, payable, liquidity) is assigned based on the account's usage in eFacto's G/L posting history. Indian GST reporting accounts are tagged with Odoo's tax_tag_ids for GST returns.

eFacto customer records include billing/shipping addresses, GSTIN/VAT IDs, payment terms, and credit limits. We map each customer to Odoo res.partner with customer_rank set for deduplication by phone and email. GSTIN is stored in Odoo's vat field for Indian compliance. If eFacto stores multiple contacts per customer, the primary contact migrates as partner and additional contacts as Odoo child contacts (res.partner with type=contact). Credit limits become Odoo's credit_limit field on the partner record.

Vendor records in eFacto include PAN/TIN registration, banking details for NEFT/RTGS, and purchase terms. These map to Odoo res.partner with supplier_rank set. PAN number migrates to the partner's ref field. Banking details (account number, IFSC code, bank name) migrate to Odoo's res.partner.bank records linked to the supplier partner. Payment terms from eFacto (Net 30, Net 60, etc.) map to Odoo's account.payment.term records that the administrator links to each supplier partner post-migration.

eFacto items carry SKU (hs_sku equivalent), description, unit of measure, standard cost, and selling price. We map to Odoo product.product (the storable product variant) and product.template. The source SKU becomes Odoo's default_code. If eFacto stores variant attributes (size, color) as separate fields, we split these into Odoo's product.attribute and product.attribute.value schema and create Odoo variants. BOM structures for manufactured items map to Odoo mrp.bom with the appropriate bom_line and bom_type (kit vs manufacture). UOMs from eFacto map to Odoo's uom.uom by matching the UOM name and category.

Open vendor bills from eFacto migrate to Odoo account.move with type=in_invoice. Each bill's partner_id, invoice_date, invoice_line_ids (product, quantity, price_unit, tax_ids), and payment_terms are preserved. Partial payments already applied in eFacto are carried forward as Odoo account.payment records linked to the invoice via the reconcile field. The migration_as_of_date determines which bills are considered open versus closed at cutover. Bills with status=draft in eFacto import as Odoo draft invoices; posted bills import as posted moves.

Open customer invoices from eFacto migrate to Odoo account.move with type=out_invoice. GST amounts are mapped to the appropriate tax lines using the GST rate derived from the item's HSN code and the customer's GSTIN state. Partial receipts applied in eFacto become Odoo account.payment records. Credit notes (eFacto credit memos) import as Odoo account.move with type=out_refund. The customer reconciles the migrated open AR in Odoo against actual bank statements during the cutover period.

Open sales orders in eFacto migrate to Odoo sale.order with full line-item detail. Each order's customer_id, order_date, order_line_ids (product, quantity, price_unit, discount, taxes), and incoterms are preserved. Cancelled or fully fulfilled orders are archived and not imported. If eFacto stores custom fields on the sales order header, these migrate to Odoo sale.order custom fields created via Odoo Studio before migration. Pricelist assignments from eFacto map to Odoo's product.pricelist records.

Open purchase orders migrate to Odoo purchase.order with vendor_id, order_date, and order_line_ids preserved. eFacto PO approval status maps to Odoo's picking_policy and invoice_status fields. If eFacto tracks incoming shipments against a PO, these link to Odoo stock.picking records created from the purchase.order's procurement group. Partial receipts are carried forward as stock move quantities rather than being reset.

eFacto POS receipts are stored in a separate transaction log from the accounting ledger, so we build a mapping table linking each eFacto receipt number to the corresponding Odoo pos.order and account.bank.statement.line created during migration. Daily POS session aggregates from eFacto map to Odoo pos.session, which creates its own journal entries for cash reconciliation. Tender types (cash, card, UPI) from eFacto map to Odoo's pos.payment.method records. Shift and cashier IDs from eFacto link to Odoo pos.session's user_id. If the destination POS configures auto-reconciliation to a cash account, Odoo handles this natively going forward.

Current stock quantities are extracted per eFacto warehouse and per batch/lot if applicable. We map each warehouse in eFacto to an Odoo stock.location (type=internal) within the Odoo warehouse structure. Batch/lot numbers from eFacto migrate to Odoo's stock.lot model linked to the product and quant. The stock_as_of_date is set on each stock.quant to indicate the snapshot date; historical valuation entries are not migrated, as Odoo recalculates stock valuation from the general ledger and incoming moves post-migration. If eFacto stores minimum stock rules, these map to Odoo's stock.rule (procurement rules) for reconfiguration by the warehouse manager.

eFacto employee master records include designation, department, PAN, and bank account details for payroll. These map to Odoo hr.employee with department_id linking to Odoo's hr.department tree. PAN number migrates to the employee's identification_id field. Bank details migrate to Odoo's hr.employee.bank_account model. Salary structures, payroll history, and TDS configuration do not migrate because Odoo's payroll module handles these differently; we export the pay structure summary for the customer's HR administrator to re-enter in Odoo Payroll.

Custom SSRS reports built on eFacto's stored procedures export as RDL XML and parameter definition files. These cannot be imported into Odoo because SSRS and Odoo Reporting use different engines. We deliver the exported RDL files, a description of each report's underlying SQL logic, and a mapping of report parameters to Odoo's equivalent data fields. The customer's Odoo administrator or a reporting consultant rebuilds equivalent reports using Odoo Studio, Pentaho, or a BI tool connected to Odoo's database. This is a manual rebuild task outside the data migration scope.