Migrate from Digit to Odoo ERP

DIGIT Citizens map to Odoo res.partner records. The DIGIT citizen_id becomes the partner's reference field. Citizen name, mobile, email, address, and household data map to Odoo partner fields. We create a custom field digit_citizen_id__c and a tag per DIGIT module (PT, TL, PGR, FSM) to preserve the cross-module association chain. Citizen-specific fields without Odoo equivalents (e.g., voter_id, ration_card) migrate as Char or Text custom fields on res.partner.

DIGIT PT property records (assessments, boundary data, owner associations, payment history) map to a custom Odoo model (e.g., asset.property) created during schema setup. We preserve the property identifier, boundary coordinates, assessment value, owner citizen_id link, and PT demand register payment status. If the Odoo deployment uses the Odoo Real Estate module (available in Community), property records map to that module's schema instead.

DIGIT TL trade licence records map to a res.partner with a commercial activity tag plus a custom licence model capturing licence_number, category, application_status, issue_date, and expiry_date. Citizen-to-business linkage is preserved by referencing the same partner record that was created from the DIGIT Citizen entity.

DIGIT PGR complaints migrate to Odoo Helpdesk tickets. The complaint number, description, workflow state (open, assigned, resolved, closed), department assignment, citizen_id link, and action timeline migrate as ticket fields, stage values, and mail.message records respectively. We preserve the timeline ordering by setting ticket create_date to the original DIGIT complaint timestamp.

DIGIT FSM sanitation, drainage, and desludging service requests map to Odoo Project tasks (or the Odoo FSM app if installed). FSM request identifier, service type, routing, field worker assignment, asset association, and completion records migrate with workflow state mapped to Odoo task stage. Citizen_id linkage is preserved via the partner reference on the parent task.

DIGIT HRMS employee records map to Odoo hr.employee. Employee name, designation, department, mobile, email, and leave balance migrate. Role-permission mappings are deployment-specific and flagged for manual validation in Odoo's Access Rights configuration post-migration because Odoo's security model (record rules, groups) differs structurally from DIGIT's role-based module access.

DIGIT PT demand registers (billing demands with demand_amount, collected_amount, pending_amount, and status flags) transform into Odoo Account Move records. Each demand with partial payment state becomes an invoice with the paid amount recorded as a partial payment via a payment utility. Multiple demand periods for the same property aggregate into separate invoice entries linked to the property's partner owner.

DIGIT FSM invoices migrate as Odoo Account Move records with the FSM service request identifier preserved in the invoice reference field. Payment state (paid, partial, outstanding) transfers using Odoo's reconcile mechanism. The customer citizen reference links the invoice to the res.partner record created from the original DIGIT Citizen.

DIGIT deployment-specific localisation files (JSON/CSV containing region labels, boundary definitions, business rules, and module configurations) are extracted and mapped to Odoo's po file translation format. We validate that applied locales match the source system's regional settings and flag any DIGIT-specific business rules that have no Odoo configuration equivalent for manual review.

Because DIGIT Citizens appear across PT, TL, PGR, and FSM modules, we tag each migrated res.partner with Odoo tags (PT Citizen, TL Licence Holder, PGR Complainant, FSM Service Recipient) to preserve the cross-module view. This allows Odoo users to filter partners by their service history without requiring a custom cross-module report.