Migrate from COINCAP ERP to Odoo ERP

COINCAP ERP stores financial accounts within its finance module as a hierarchical account master. We extract the full account tree including parent-child relationships and map to Odoo's account.account model with the correct account_type (asset, liability, equity, revenue, expense). COINCAP's Indian GST tax code references (CGST Input, SGST Input, IGST Payable) become Odoo account.tax records with tax_group_id set to the appropriate Indian GST group. Account codes are preserved as Odoo code values for audit trail continuity.

All posting transactions in COINCAP—sales invoices, purchase receipts, payment vouchers, and contra entries—exist as vouchers in the finance module. We map these to Odoo's account.move (journal entry) records with move_type set to entry, out_invoice, in_invoice, out_refund, or in_refund as appropriate. Each voucher line becomes an account.move.line with matched account_id from the COINCAP account master mapping. Historical voucher numbering sequences are preserved in the Odoo move reference field for audit continuity.

COINCAP party masters (customers and vendors) live in the trading module with fields for contact details, payment terms, GST registration numbers, and PAN references. We map both to Odoo's res.partner, setting customer_rank or supplier_rank based on the COINCAP party type flag. GSTIN numbers migrate to the l10n_in_gstin field (with l10n_in_reseller_id for composite supply). Multiple COINCAP address lines are flattened to Odoo's street/street2/city/state_id/country_id structure using Indian state codes.

COINCAP inventory module stores item masters for raw materials, semi-finished goods, and finished products. We map item codes to Odoo product.product with type set to product (stockable), consumable, or service based on COINCAP item category. UOMs (units of measure) are mapped from COINCAP UOM definitions to Odoo's uom.uom with consistent uom_type and category. Pricing tiers from COINCAP become Odoo product.pricelist items applied at the partner or product category level.

Multi-level BOM hierarchies in COINCAP's production module map to Odoo's mrp.bom with nested bom_line records referencing child product.products. COINCAP's operation sequences (routing steps) map to Odoo workcenter lines on the BOM with cycle_time and time_cycle fields set from COINCAP operation duration data. We detect recursive BOM structures and resolve them into Odoo's flat bill-of-materials with component qty and allowance percentages preserved.

Outstanding customer receivables tracked in COINCAP's finance module become Odoo account.move records of type out_invoice with invoice_date and invoice_payment_term_id set from COINCAP payment terms. The partner outstanding balance is then reconciled against the open Odoo move using account.reconcile_model or manual reconciliation. Aged trial balance totals from COINCAP are compared against Odoo's aged receivable report during reconciliation to validate completeness.

Outstanding vendor payables in COINCAP's finance module map to Odoo account.move records of type in_invoice with vendor-specific invoice references preserved. COINCAP payment terms and due dates carry forward to Odoo's invoice_date and invoice_payment_term_id. Odoo vendor outstanding balances are reconciled against open moves using account.reconcile_model. Any partially paid COINCAP invoices become Odoo in_invoice records with residual amounts.

COINCAP inventory locations map to Odoo's stock.warehouse (the facility) and stock.location hierarchy (shelf/bin structure within each warehouse). Multi-warehouse COINCAP deployments create multiple Odoo stock.warehouse records with corresponding internal location types (view, internal, transit). COINCAP location codes are preserved in Odoo's shortcode field for inventory team reference.

COINCAP purchase orders migrate to Odoo purchase.order with state mapped from COINCAP status (draft, sent, confirmed, done). PO lines map to Odoo purchase.order.line with product_id resolved from the item master mapping and taxes_id from the GST tax group configuration. Odoo automatically generates stock.picking (receipts) when PO state reaches confirmed, which is the expected post-migration workflow.

COINCAP sales orders migrate to Odoo sale.order with state mapping (draft, sent, sale_order, done). SO lines map to Odoo sale.order.line with product_id resolved, taxes_id from the GST configuration, and discount values preserved from COINCAP price adjustment fields. Customer-specific pricing from COINCAP's party master becomes Odoo product.pricelist rules applied at the partner level.

COINCAP users and their module-access role assignments map to Odoo res.users and res.groups. COINCAP module-gating (which roles can access which functions) maps to Odoo access rights groups: Accounting / Inventory / Sales / Manufacturing / Administration. COINCAP usernames and emails migrate as Odoo login credentials. Session tokens and passwords cannot be extracted from COINCAP; Odoo users must reset passwords post-migration.

COINCAP deployments across its 11 industry verticals frequently include module-specific custom fields not present in the base product. We identify every active custom field during the schema audit phase, capture its COINCAP data type and value domain, and pre-create matching custom ir.model.fields in Odoo before the main migration window. Field values are imported as part of the parent object migration. This step requires COINCAP technical staff to enumerate custom field names and types, which we coordinate during the discovery phase.

COINCAP ERP may store scanned documents and file attachments linked to transactions, vouchers, or master records. There is no documented API endpoint for bulk attachment retrieval. We flag every transaction and master record with attachment dependencies during discovery and present the customer with three options: manual re-upload post-migration using Odoo's document management, a separate document-migration workstream coordinated with COINCAP vendor assistance, or acceptance that attachments will not migrate. This decision is documented in the migration scope before extraction begins.