Migrate from aACE to Odoo CRM

aACE Accounts are the primary customer and vendor record, holding billing and payment terms. We map Accounts to Odoo res.partner records with partner_type set to 'contact' for customers and 'invoice_address' for billing addresses. Each Account's location records migrate as separate res.partner addresses linked to the parent contact via type (delivery, invoice, contact). Account payment terms map to Odoo property_payment_term_id.

aACE supports multiple locations per Account, each with its own address and contact record. We split each aACE Location into a separate res.partner address record with type='delivery' or type='contact', linked to the parent res.partner via partner_share. The primary location becomes the default delivery address; additional locations become secondary delivery addresses on the same partner.

aACE Items are the inventory-part records holding SKU, description, unit cost, and pricing. They map to Odoo product.product (the storable product variant) with product.template as the template record. Item cost maps to standard_price on product.product; sales price maps to list_price on product.template. Odoo creates product.attribute.value records for any variant dimensions carried in the aACE Item.

aACE Sales Orders link a Customer Account to Line Items and spawn Invoices and Purchase Orders. We map sale.order with Order Lines linking to product.product via SKU resolution, Account mapped to res.partner, and the originating Sales Order reference preserved in the Odoo order's origin field. Order status (draft, sent, sale, done, cancel) maps from aACE order state values to Odoo state values directly.

aACE open invoices migrate to Odoo account.move with type='out_invoice'. We preserve the original invoice number, invoice date, due date, and open balance so the A/R team can pursue collections without re-entering data. Partial payments against the invoice create corresponding account.payment records linked to the invoice. Historical closed invoices migrate as read-only account.move records with state='posted'.

aACE Purchase Orders link to Items, Vendors, and the originating Sales Order. We map purchase.order with PO lines resolving Item to product.product, Vendor to res.partner (partner_type='supplier'), and any received quantities preserved as Odoo stock.move records. Partial receipts (partial_receipt_status = true in aACE) are preserved at migration time so the purchasing team can receive the remaining quantity against the same PO in Odoo.

aACE Projects hold the job header and link to Tasks, Time entries, and billing records. We map project.project with status (active, archived, on_hold) preserved. The project manager from aACE maps to Odoo user_id on the project. aACE Project billing information (if linked to an Account) maps to analytic account in Odoo for cost tracking.

aACE Tasks are the unit-of-work records linked to Projects and optionally to Accounts and Orders. We map project.task with status, assignee (mapped to Odoo user_id via Owner email resolution), due date, and any custom flag fields preserved. High-volume task exports use the FileMaker batched export pipeline to avoid overwhelming the cache table. Task priority maps to Odoo priority (0-5 scale).

Employee records in aACE hold role and department data. We map hr.employee with name, job_title (mapped from aACE role field), department (resolved to Odoo hr.department via name match), and active status. Historical payroll or compensation records are migrated as separate hr.contract records with Odoo wage and struct fields set to the compensation values.

aACE Distribution Lists are FileMaker portal-based address-book groupings. We migrate them as Odoo mailing.contact records grouped under a mailing.list, or alternatively as a res.partner category (tag) applied to the contact records depending on the customer's intended use. The list membership join table migrates as mailing.list.contact records.

aACE custom fields on Accounts, Orders, Items, and Projects have no metadata API for enumeration. During scoping we request the customer's FileMaker layout definitions and build the complete field list from them. Custom fields that map directly to an Odoo field type become Odoo ir.model.fields created via Odoo Studio. Custom fields without an Odoo equivalent are written as Char or Text fields in the relevant Odoo model, or as a JSON blob in a dedicated ir_attachment record for post-migration admin review.

FileMaker container fields store attachments, signatures, and scanned documents inside the aACE database. Export scripts do not reliably extract container binary data. We extract document filenames and container references and create ir.attachment records in Odoo pointing to the file location. Customers with compliance or audit requirements for document preservation are flagged for a separate FileMaker-native document export step after the primary data migration completes.