Migrate from ABRA Gen to Microsoft Dynamics 365 Business Central

ABRA Gen firmy records serve as both customer and vendor depending on business relationship type. We split firmy into D365 Accounts with Account Type = Customer for revenue-facing records and Account Type = Vendor for payable-facing records. Address, contact, and financial classification fields map to D365 Address, Contact, and the CustTable or VendTable extensions. Custom firmy extensions identified during schema discovery are mapped as custom fields on Account and flagged for customer review.

Customer master records from ABRA Gen's odberatele table map to D365 CustTable with billing address, payment terms, and customer group assignment preserved. We resolve the customer group code against the destination's customer group configuration before insert to avoid post-migration cleanup.

Vendor master records from ABRA Gen's dodavatele table map to D365 VendTable with vendor-specific payment terms, banking details, and discount structures preserved. Vendor group codes map to D365 vendor groups configured during destination setup.

ABRA Gen zakazky capture project-level financial tracking, billing, and cost allocation. We map zakazky to D365 Project management contracts or project records depending on the customer's usage pattern identified during discovery. Job codes preserve as Project ID or Agreement number. Nested hierarchy structures are flattened to a single project level with cost categories mapped to D365 project categories.

ABRA Gen sklady define warehouse locations with quantity and valuation. We map warehouse codes to D365 Warehouse sites and locations, preserving location-level detail where the customer uses bin management in ABRA Gen. Inventory valuation method mapping (FIFO, weighted average, standard cost) is applied per item and validated against the destination's costing configuration. Serialized and lot-controlled items are flagged for D365 tracking dimension setup before migration.

ABRA Gen vyrobky product master records include pricing, BOM structures, and unit-of-measure definitions. We map products to D365 Released Products with item number, description, item model group (controlling valuation method), and product type (Item vs Service). Multi-level BOMs in ABRA Gen may require flattening or restructuring; we document the BOM hierarchy during discovery and apply a flattening strategy in D365's BOM designer before load. Unit-of-measure sequences map to D365 unit-of-measure classes.

Czech accounting journal entries from ABRA Gen's ucetni table use a COA structure with specific account codes, tax codes, and document references. We map account codes to the D365 chart of accounts with financial dimension mapping for cost center, department, and project dimensions. Document-level detail and audit trails migrate for the retention-required periods. Posting dates outside the migration window are flagged for archive rather than live migration to prevent bloating the production D365 ledger.

ABRA Gen doklady store document headers with line items for sales invoices, purchase orders, and delivery notes. Open documents (not yet posted) migrate to D365 as draft orders; historical posted documents migrate as journal entries rather than live documents to preserve accounting integrity. Document numbering sequences map to D365 number sequences, with a gap-filling strategy for any numbering conflicts.

ABRA Gen employee records map to D365 Human Resources HcmWorker with employment status, department assignment, and contact data preserved. If D365 HR module is not in scope, we map to DirPerson and DirOrganizationPersonMapping for basic personnel records. Payroll data does not migrate as a standard scope item; this requires a separate payroll migration engagement.

ABRA Gen user accounts and permission sets map to D365 User records with security role assignments based on role discovery during database schema inspection. Inactive ABRA Gen accounts are flagged for deactivation at cutover rather than migrated as active users. Role mapping requires the customer to define the target security role for each ABRA Gen role identified during discovery.

Many ABRA Gen implementations include custom-developed modules or heavily customized standard modules identified during schema discovery. We inspect the live database schema against the standard ABRA Gen data dictionary, identify custom tables and fields, and document them in a written schema inventory. We do not migrate custom module code; the inventory document allows the customer's D365 admin or implementation partner to rebuild equivalent functionality in D365 using Power Apps, custom tables, or AL extensions in Visual Studio Code.

Closed fiscal years that exceed the Czech statutory retention period required in the destination system are exported as read-only CSV or SQL backup files rather than loaded into the live D365 ledger. This satisfies legal retention requirements under Czech and Slovak tax law (5-10 years depending on document type) without bloating the D365 production database. The archive is delivered alongside the migration with a metadata manifest identifying period, document type, and record count.