Migrate from Impact ERP to Microsoft Dynamics 365 Business Central

Impact ERP's hierarchical COA (Indonesian-tax-variant with account codes, group assignments, and account type flags) maps to D365 Finance and Supply Chain Management Main Account with MainAccountCategory and Financial Dimension structures. Indonesian COA groups (aset, liabilities, ekuitas, pendapatan, beban) map to MainAccountCategory. We extract the full COA tree from Impact ERP's export, normalize account codes to D365's alphanumeric format, and preserve the parent-child hierarchy in a separate DimensionAttributeLevelOr above structure. COA must load before all other objects to satisfy account validation rules on journal lines.

Impact ERP Item masters (SKU, description, unit of measure, cost method, valuation) map to D365 Released Products with Product number = Impact ERP item code. The inventory valuation method (FIFO, moving average, standard) migrates to the costing version on the Product. Unit of measure and UoM schedule map from Impact ERP's UoM table to D365 Unit of Measure Groups. Item must load before BOM, Routing, Open AP/AR, and any inventory transaction history.

Impact ERP BOMs attached to Item masters require extraction from separate BOM header and BOM line tables in the export. We map BOM to D365 Engineering -> Bill of Materials with BOM lines referencing the migrated Product numbers. BOM version and status (draft, active) are preserved. D365 BOMs support multi-level explosion; single-level Impact ERP BOMs are migrated as-is and validated for phantom assembly flag by the customer's engineering team post-migration.

Impact ERP routing operations attached to manufacturing items map to D365 Route and Route Operations. Operation number, work center, setup time, run time, and priority migrate to Route lines. Work Center in D365 must be provisioned first (from Impact ERP's cost center data), so routing migration follows work center setup. We flag any routing operations with machine or labor resources that cannot be mapped to D365 Resource Groups.

Impact ERP Customer records (billing address, NPWP tax ID, payment terms, credit limit) map to D365 Customer V3 entity with Customer group, Payment terms, and Credit limit preserved. The NPWP field migrates to TaxRegistrationNumber with TaxRegistrationType set to NPWP. Shipping addresses beyond the primary address require mapping to D365's additional delivery address structure or custom fields depending on the customer's address count. Customer must load before Open AR and sales order history.

Impact ERP Vendor masters (NPWP, bank account details, payment terms, lead-time fields) map to D365 Vendor V3 with Vendor group, Payment terms, and Tax Registration Number. Effective-dated vendor changes are preserved by loading the current active record and flagging prior records as historical in a custom vendor_effective_dates__c table for audit. Bank account details for payment runs map to Vendor Bank Account entity. Vendor must load before Open AP and purchase history.

Open AP invoices from Impact ERP (invoice number, due date, amount in IDR, vendor reference) map to D365 Vendor Invoice Journal lines. We create one journal batch per AP aging bucket to preserve the open item structure. Customers choose between carrying open items as unresolved balances (posted to a suspense account pending reconciliation) or re-invoicing. D365 requires a valid Vendor account and posting profile before AP can post; these are validated during the vendor migration phase. Exchange rate handling for any USD or SGD vendor invoices requires pre-configuration of the exchange rate type.

Open AR invoices from Impact ERP (invoice number, due date, amount in IDR, customer reference) map to D365 Customer Invoice Journal. We create one journal batch per AR aging bucket. D365 requires a valid Customer account and posting profile. Any AR records with a currency other than the D365 primary currency (IDR) require exchange rate setup on the ledger. We flag fully-paid historical AR for optional carry-forward versus balance-only migration based on the customer's reporting requirements.

Past invoices, purchase orders, receipts, and payment records migrate as General Journal lines or subledger journal entries depending on the D365 posting profile configuration. We extract transactions in date-range chunks (rolling 12-month windows) to avoid timeout during export from Impact ERP. Each chunk maps to D365 LedgerJournalTable + LedgerJournalTrans with the account, offset account, amount (in IDR), and posting date preserved. Journal batch numbers from Impact ERP become the D365 journal number prefix for traceability.

Impact ERP GL journal entries (header with journal number, date, description; line items with account code, debit, credit, department) map to D365 General Journal. Header description becomes the Journal name. Line-level department codes map to D365 Financial Dimensions if the customer has configured a Department dimension, otherwise they migrate as memo fields. We validate that debit and credit totals balance per journal before inserting into D365; unbalanced entries are flagged to the customer's finance team for correction before re-submission.

Impact ERP user accounts (username, role assignments, department assignments) map to D365 User entities via Azure AD. We extract role assignments and map them to D365 Security Roles. Department assignments map to D365 Legal Entity or Operating Unit depending on the D365 configuration. Impact ERP password hashes are not migratable; we provision new D365 accounts and the customer's IT admin distributes credentials. Users without a matching Azure AD account enter a reconciliation queue.

If Impact ERP carries fixed asset records (asset number, acquisition date, cost, accumulated depreciation, depreciation method), we map these to D365 Fixed Assets. Acquisition cost in IDR migrates to Fixed Asset value model with the original cost, depreciation start date, and depreciation method (straight-line or declining). Depreciation books are created per the customer's local tax reporting requirements (Indonesian PPh and PPT requirements). Fixed asset migration follows COA migration so that the FA account references are valid.

Impact ERP custom fields added during implementation have no standardized schema. We identify all custom field definitions via exported metadata, map them to D365 custom fields on the equivalent entity (using the Extensions model in D365 Finance and Supply Chain Management) or to a custom table if no standard entity exists. All custom field data is validated for data type compatibility before insert. Custom objects that reference standard entities (Customer, Vendor, Item) require the parent record to load first to satisfy the lookup constraint.