Migrate from Kafinea to Microsoft Dynamics 365 Business Central

Kafinea Customers map to D365 CustCustomerEntity or Customer records. Primary contact details, payment terms, and addresses migrate as CustParty and DirParty postal-address structures. Customer number from Kafinea becomes the D365 Customer Account number; if Kafinea uses alphanumeric identifiers, we map them to D365's numeric or alphanumeric account code format based on the customer's chosen number sequence configuration. Customer type (individual vs. organization) maps to the PartyType field in D365's party model.

Kafinea invoices (Classic, Progress, and Recurring types) map to D365 SalesInvoiceHeader and line records. Invoice-to-payment links are preserved through invoice number matching against the D365 CustSettlementJour or payment journal records. Tax codes and VAT treatment require manual review at the destination because Kafinea's French tax configuration may use codes that D365's country-specific tax setup does not auto-recognize — we flag any mismatched VAT groups for manual correction in the Tax configuration workspace before the first invoice posts. Credit note chains migrate as CreditNote records referencing the original invoice number.

Kafinea journal entries with multi-line debits and credits require sequencing by posting date during import. We sort all journal lines by posting date and then by entry sequence within each date to preserve the original ledger ordering. D365 requires a LedgerJournalTable header before any LedgerJournalTrans lines can be inserted. If Kafinea entries reference cost centers, we map them to D365 Financial Dimensions (configured in the Dimensions framework) — custom or non-standard account codes from Kafinea are flagged for manual account creation before journal migration begins.

Kafinea account codes and names map to D365 MainAccount with the same account type classification (Revenue, Expense, Asset, Liability). Currency assignments on Kafinea accounts require mapping to D365's ledger currency setup — if Kafinea supports per-account currency and D365 enforces a single ledger currency, we flag the multi-currency scenario for the customer's finance team to define a conversion approach. Cost center assignments from Kafinea map to Financial Dimensions that must be pre-configured in D365's Dimension framework.

Kafinea Sales Orders with tiered Price Book lines (quantity-based portions at different price levels) map to D365 SalesLine with price breakdown per line. D365's price disc and trade agreement model is different from Kafinea's tiered portion model — we flatten the tiers into individual price disc lines or preserve the tier structure as a note on the order line depending on the customer's preference for reporting. Product references migrate as item numbers matched against D365 InventTable or released products.

Kafinea CRM Contacts map to D365 DirParty of type Person with a linked Contact record. The Kafinea Contact-Company link maps to the Contact's AccountNum foreign key linking to the corresponding CustCustomer. Lifecycle stages from Kafinea CRM migrate as custom text fields because D365 does not have a native lifecycle stage model — we flag this for the customer's admin to configure as a picklist in the Contact form.

Kafinea CRM Companies map to D365 Customer records. The distinction between CRM Company and ERP Customer in Kafinea collapses in D365 where the same Customer record drives both the financial ledger and the CRM account. We consolidate the Kafinea Company and Customer records into a single D365 Customer entity, deduplicating by company name and domain where a Kafinea customer used both CRM Company and ERP Customer objects for the same entity.

Kafinea Service Contracts defining recurring billing terms and SLA levels map to D365 ProjContract (Project Operations) or Field Service Agreement. Contract start and end dates, billing frequency, and SLA tier migrate as contract line items. If the customer uses Field Service, we map the Kafinea contract to an Agreement record with service tasks and work order templates pre-linked for the customer's service team to configure post-migration.

Kafinea Interventions (time and task records logged against service contracts) map to D365 WorkOrder or ServiceOrder records. Duration, technician assignment, and contract reference migrate as work order lines and header fields. The linking relationship between Intervention and Service Contract requires the ProjContract or Agreement to be migrated first so that the parent contract ID can be resolved at import time.

Kafinea Timesheets linked to projects or users map to D365 ProjJournalTrans or TimeSheetLine depending on the destination module. Effective-dated absence records require sequential import to preserve accrual calculations. D365's approval workflow for timesheets is configured separately and does not migrate — we flag this for the customer's admin to set up in the Project Management and Accounting Parameters workspace.

Kafinea exposes customizable fields across most objects as key-value pairs or extended property sets. We map custom field names and data types (picklist, date, numeric, text) to D365 field equivalents using the same API naming convention. Picklist values require explicit mapping to D365 OptionSet values that must be pre-created in the destination. Custom fields on Kafinea objects that have no D365 equivalent are documented as custom fields on the nearest standard entity with a note for the customer to evaluate whether the data is still needed post-migration.

Documents stored in Kafinea EDM export as file references or direct binary downloads. We preserve the original folder structure and attach documents to the corresponding D365 records using the Document Handling framework or SharePoint integration if the customer has configured OneDrive/SharePoint as the document storage backend. PDF attachments from Kafinea invoices and service contracts attach to the matching D365 records as document attachments.