UK localization upgrade as extension causes data migration errors

ERP Microsoft Dynamics 365
, , , , , , , ,
1

We’re upgrading our D365 Finance environment to 10.0.41 and migrating from the legacy UK localization to the new extension-based model. The data upgrade process is breaking on historical property transaction records.

The main issues we’re hitting:

  • Delocalized UK-specific fields aren’t mapping correctly to the extension schema
  • Historical VAT codes and reverse charge indicators are coming through as null
  • Data upgrade tool runs but validation errors show field mapping failures

Error from the upgrade log:


Field mapping failed: UKVATReverseCharge
Source: LedgerJournalTrans_UK.ReverseChargeIndicator
Target: Extension field not found in LedgerJournalTrans
Validation: 2,847 records affected

Has anyone successfully migrated UK localization data to the extension model? The documentation mentions field mapping but doesn’t provide specifics for legacy data conversion.

system 2

Let me provide a comprehensive solution for your UK localization data migration issue.

Understanding the Delocalization Architecture

Microsoft moved UK-specific functionality into extensions to separate localization logic from the core application. This means legacy fields in tables like LedgerJournalTrans_UK no longer exist in the base schema - they’re now in extension tables with foreign key relationships.

Data Upgrade Tool Configuration

The standard data upgrade process needs custom scripts to handle the field mapping between legacy and extension schemas. Here’s what you need to implement:


class ReleaseUpdateDB_UKLocalization extends ReleaseUpdateDB
{
    public void upgradeUKVATFields()
    {
        LedgerJournalTrans_UK legacyRecord;
        LedgerJournalTrans_UKExt extensionRecord;

        while select legacyRecord
        {
            extensionRecord.LedgerJournalTransRecId = legacyRecord.RecId;
            extensionRecord.ReverseChargeIndicator = legacyRecord.ReverseChargeIndicator;
            extensionRecord.insert();
        }
    }
}

Critical Field Mappings

For your specific error, map these legacy-to-extension field relationships:

  • LedgerJournalTrans_UK.ReverseChargeIndicator → LedgerJournalTrans_UKExt.ReverseChargeIndicator
  • LedgerJournalTrans_UK.VATRegistrationNumber → LedgerJournalTrans_UKExt.VATRegistrationNumber
  • VendInvoiceInfoTable_UK.CISDeductionRate → VendInvoiceInfoTable_UKExt.CISDeductionRate

Data Upgrade Tool Usage

  1. Run the pre-upgrade checklist to identify all references to legacy UK tables
  2. Create custom upgrade scripts in a new ReleaseUpdateDB class
  3. Register your scripts in the data upgrade framework configuration
  4. Execute in the sandbox environment first - validate all 2,847 affected records
  5. Use the Data Upgrade Tool’s validation reports to verify field population

Historical Data Accuracy

For null values in historical records, you may need to apply business logic defaults. For example, if ReverseChargeIndicator is null in legacy data, determine whether it should default to ‘No’ based on the transaction date and supplier location. The UK reverse charge rules changed in 2021, so transactions before that date might legitimately have null values.

Post-Migration Validation

After running the upgrade scripts:

  1. Compare record counts between legacy tables and extension tables
  2. Validate VAT reporting outputs against historical reports
  3. Test property transaction flows with UK VAT scenarios
  4. Update any custom X++ code, SSRS reports, or Power BI datasets that reference the old schema

Extension Table Relationships

The extension model uses these key relationships:

  • LedgerJournalTrans (1) ↔ (0..1) LedgerJournalTrans_UKExt via RecId
  • VendInvoiceInfoTable (1) ↔ (0..1) VendInvoiceInfoTable_UKExt via RecId

Your queries and reports need to use outer joins since not all base records will have corresponding extension records (only UK-specific transactions).

This approach has worked successfully for multiple UK implementations I’ve handled. The key is thorough testing in sandbox before production migration.

This draft is based on general Microsoft Dynamics 365 knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

I’ve seen this exact issue with another UK client last month. The problem is that the delocalization process moved UK-specific fields into extension tables, but the standard data upgrade tool doesn’t automatically map legacy table fields to extension schemas.

You need to create custom data upgrade scripts that explicitly handle the field transitions. The ReverseChargeIndicator field you mentioned now lives in a separate extension table that links back to LedgerJournalTrans through a foreign key relationship.

4

Thanks for confirming. Do you know which extension table holds the reverse charge data now? I’ve looked through the UK localization extension documentation but the schema changes aren’t clearly documented.

5

The reverse charge and other UK VAT-specific fields are now in the LedgerJournalTrans_UKExt extension table. You’ll also find that Construction Industry Scheme (CIS) deduction fields moved to VendInvoiceInfoTable_UKExt.

For your data migration, you need to write X++ scripts that read from the old UK-localized tables and populate both the base tables and their corresponding extension tables. The data upgrade framework supports this through the ReleaseUpdateDB class pattern.

nicholas_guru 6

Confirmed this resolves the LedgerJournalTrans_UK foreign key mapping errors after configuring custom data upgrade scripts to bridge the legacy fields to the extension table schema.

7

We went through this migration in January. One critical thing - make sure you’re using the Data Upgrade Tool’s pre-upgrade checklist to identify all customizations that reference the old UK fields. We missed several custom reports that were still pointing to the legacy schema, which caused runtime errors post-upgrade even though the data migration succeeded.

8

That’s a good point about custom reports. We have quite a few property management reports that pull UK VAT data. Did you have to rewrite those completely or were you able to adapt them?

9

We adapted most of them by updating the data sources to join the extension tables. For example, if a report was selecting directly from LedgerJournalTrans_UK, we changed it to join LedgerJournalTrans with LedgerJournalTrans_UKExt on the RecId relationship. Some complex reports with embedded UK logic needed more substantial rewrites though.