Migrate from WennSoft to Odoo CRM

WennSoft customers map to Odoo res.partner records. A Customer record with multiple Locations becomes the parent res.partner with each Location added as a child contact (address type = 'contact') so Odoo's address model handles multi-location correctly. Primary contact person within the location becomes the contact's name fields. Phone, email, and notes carry over directly.

Service Calls are the core WennSoft object and map to Odoo project.task records. Each Service Call becomes a task linked to a project record representing the customer location. Call status (Open, Dispatched, In Progress, Complete, On Hold) maps to custom task stage IDs configured in Odoo before migration. Original dispatch timestamps, problem type, and call type are stored in custom fields on the task.

Odoo has no native customer-linked equipment model that mirrors WennSoft's Equipment Manager. We recommend creating a custom field_service.equipment model inheriting from stock.production.lot with fields for customer_id, location_id, serial_number, equipment_type, problem_type, and last_service_date. Equipment history is stored as task records linked to the equipment. If Odoo's maintenance module is installed, equipment records are also registered there for preventive maintenance scheduling.

WennSoft employee records map to Odoo res.users (for system login) paired with hr.employee (for HR and timesheet context). Email, name, and department carry over directly. Technician skill certifications and dispatch-enabled flags map to hr.employee fields and tags. Active/inactive status on the WennSoft employee record controls the res.users active flag.

WennSoft TimeTrack entries migrate as Odoo account.analytic.line records linked to the project (work order) and the hr.employee (technician). Billable flag, labor type, and billing rate carry over as custom fields — Odoo timesheet lines do not natively support WennSoft's per-call-type billing rate lookup, so we store the rate as a computed field on the analytic line. Timesheet entries are created via Odoo's hr_timesheet module.

WennSoft Job Cost lines (labor, materials, subcontractors) map to Odoo analytic lines with the appropriate product category. Cost codes map to Odoo's analytic account structure — each Job in WennSoft becomes an analytic account in Odoo, and the cost lines become child analytic lines under it. Actual cost and budgeted cost are stored as amount and planned_amount respectively on the analytic line.

WennSoft's Unbilled Costs report lists all labor and material costs on unposted service calls. Odoo has no native unbilled cost register equivalent — we preserve the unbilled total and per-call cost breakdown as custom fields on the project.task and as analytic line records with a flag unbilled=True. This lets your Odoo admin generate an unbilled cost report in a spreadsheet without a native equivalent.

WennSoft's Extended Pricing Matrix sets billing amounts by call type, problem type, and equipment type per contract. Odoo product pricelists handle volume-based and rule-based pricing but not the multi-axis cost-plus matrix. We map the matrix to a combination of product.pricelist.item records and custom fields on the service call task. Each pricing rule references the product (labor type or service part) and the pricelist scoped to the customer or contract.

WennSoft documents attached to service calls, equipment records, and customers migrate to Odoo ir.attachment records linked to the corresponding task, equipment model, or partner. The original filename, mimetype, and binary content are preserved. Inline images in notes are rehosted in Odoo's filestore under the project's directory.

WennSoft's Signature platform supports custom triggers and workflow rules tied to call status changes, technician assignments, and billing events. These run inside the Dynamics GP extension layer and have no Odoo equivalent. We export all trigger definitions and logic as a human-readable rebuild guide mapped to Odoo Studio actions, server actions, and action rules so your Odoo admin can reconstruct the automation logic post-migration.