Migrate from Udyog ERP to Odoo ERP

Udyog ERP Customer master (billing address, GSTIN, PAN, contact details) maps to Odoo res.partner with partner_type=customer. We run GSTIN checksum validation against the public GSTN API during data cleaning because Udyog ERP does not perform live GSTIN validation at entry. Deactivated or invalid GSTINs are flagged before import. The customer's billing state code maps to res.partner state_id and country_id for GST intra-state/inter-state tax determination in Odoo. Phone and mobile fields map to phone and mobile on res.partner; email maps to email.

Udyog ERP Vendor master mirrors the customer structure with additional TDS deduction fields. We map vendors to res.partner with partner_type=supplier, preserving GSTIN and PAN for TDS certificate generation. TDS deduction rates stored in Udyog's vendor tax configuration map to Odoo res.partner TDS fields if the l10n_in_tds module is installed. Vendor bank details map to res.partner.bank for payment NEFT/RTGS routing. State code and GST registration type (regular, composition, SEZ) are preserved for GST reporting.

Udyog ERP Item master stores SKU, HSN code, unit of measure, opening stock, and valuation method (FIFO/weighted average). Items map to Odoo product.product with product_type=product (for stockable) or service. We map the valuation method to Odoo's inventory valuation setting (manual or automated) and the costing method to product.category fifo/standard/average. HSN codes map to l10n_in_hsn_code on product.template for GST rate determination. Opening stock balances map to stock.quant records created at the designated stock location during initial inventory setup.

Udyog ERP's Indian accounting chart includes statutory ledgers for GST input tax, GST output tax, TDS receivable, TDS payable, TCS receivable, and TCS payable. These map to Odoo's l10n_in (India localization) account.account records with the appropriate account_type (asset_current, liability_current, etc.) and l10n_in_gst_tag for GST reports. Standard account codes from Udyog ERP map to account.account code; account names map to name. We flag any India-specific tax accounts that may not have Odoo equivalents and document them as needing manual account creation before journal entry import begins.

Outstanding payable and receivable vouchers in Udyog ERP (voucher number, party name, amount, due date, GST tax component) map to Odoo account.move records with move_type=out_invoice (AR) or in_invoice (AP). The voucher-level detail preserves audit trail continuity. We map Udyog's voucher_date to account.move invoice_date, the party reference to ref, and the GST tax component to tax_line_id on the invoice lines. Due dates map to invoice_date_due. Reconciliation is preserved by creating account.move.line records that match the open amount against the corresponding customer or vendor partner account.

Posted journal vouchers with narration, date, and multi-legger debit/credit lines export in chronological sequence from Udyog ERP. We map each voucher to account.move with move_type=entry (general journal). The original voucher numbering from Udyog ERP is preserved in the move name or reference field for audit trail continuity. Narration text maps to account.move.line name (description on each line). Lines with debit amounts map to account.move.line debit; credit amounts to credit, with account_id resolved to the mapped account.account record. Date sequencing is enforced to maintain chronological integrity.

Multi-level BOMs with nested sub-assemblies, scrap percentages, operation sequences, and work centre assignments are stored as parent-child relationships in Udyog ERP. We run BOM explosion queries in SQL to flatten the full hierarchy to a single level and validate component quantities against production orders. The flattened BOM components map to mrp.bom.line records referencing product.product. Scrap percentage maps to the bom_line scrap field. Operation sequences map to mrp.routing.workcenter on the parent mrp.bom. Udyog ERP BOM versions (dated) are resolved to the active version at migration cutoff date. This is a high-scrutiny object due to nested BOM complexity.

Udyog ERP work orders reference a BOM, planned quantity, and actual production quantities with status flags (Pending, In Progress, Closed). Status flags map to Odoo mrp.workorder state (pending, ready, in_progress, done). We sequence work orders by creation date to preserve production scheduling continuity. Work centre assignments from Udyog map to mrp.workorder workcenter_id. Actual production quantities map to mrp.workorder time_ids (tracking time and production output). Work orders without a resolved BOM reference are held in a reconciliation queue until the BOM import is validated.

Production orders capture input material consumption and finished goods output with date-stamped transactions. We extract full consumption ledgers and flag any under-closed production orders that require admin review before closing in Odoo. mrp.production records are created with product_id referencing the finished goods product, product_qty from Udyog planned quantity, and bom_id resolved from the BOM mapping. Component stock moves (stock.move) are generated from the mrp.production record. We preserve the original production order reference in the origin field of mrp.production for audit continuity.

Udyog ERP employee records include designation, department, and bank details for payroll processing. Leave balances and attendance data are stored in the HRMS submodule. We map core employee fields (name, department, designation, bank account) to hr.employee and related hr.employee.base fields. Bank details map to hr.employee.bank_account_id for payroll NEFT. We do not migrate leave balance histories as a complete accrual ledger; we capture the current balance snapshot as a custom field on hr.employee for the customer's HR admin to reconcile against their Odoo HR configuration.

Udyog ERP project master and cost centres link to budget lines, revenue recognition schedules, and milestone billing. We extract project WIP balances and open task lists to reconstruct project status in Odoo. Project maps to project.project, cost centre budget lines map to budget.budget.line (if Odoo budget module is active), and milestones map to project.milestone. Open tasks map to project.task with stage and user assignment resolved. Revenue recognition schedules are documented as a separate inventory item for the customer's Odoo accountant to configure in Odoo Accounting.

India-specific GST filing data stored in Udyog ERP proprietary format linked to invoices does not export cleanly to Odoo's standard format. We extract invoice-level detail (invoice number, date, GSTIN, taxable value, GST rate, CGST/SGST/IGST amount, place of supply) from the underlying account.move records rather than the GSTR export format, and map them to Odoo account.move records that feed into the l10n_in_gstr report. GSTIN validation against the GSTN portal is performed during extraction. We note that the GSTR-1 and GSTR-3B filing summary data is reconstructed from migrated invoice lines, not carried over as a completed filing record.