Inconsistent field names across TransferFields

Properties
PC0021 Warning Design Code Fix Ignore Obsolete

TransferFields copies field values between records by matching field IDs, not field names — see PC0020 for how the matching works and when type mismatches are detected.

When two tables share a field ID but use different field names, the values are transferred regardless. This does not cause a runtime error, but it often indicates accidental field coupling: the same field ID was reused for a different purpose on each side, and TransferFields silently copies a value into a field where it does not belong.

Review the field definitions and either align the names or assign different field IDs.

Example

Both tables define field ID 2, but with different names. TransferFields copies the discount amount into the invoice amount field:

table 50100 "Sales Document"
{
    fields
    {
        field(1; "No."; Code[20]) { }
        field(2; "Discount Amount"; Decimal) { }
    }
}

table 50101 "Posted Sales Document"
{
    fields
    {
        field(1; "No."; Code[20]) { }
        field(2; "Invoice Amount"; Decimal) { }
    }

    procedure Post(SalesDoc: Record "Sales Document")
    begin
        Rec.TransferFields(SalesDoc); // Inconsistent field names across TransferFields [PC0021]
    end;
}

If the coupling is intentional, align the field names:

table 50100 "Sales Document"
{
    fields
    {
        field(1; "No."; Code[20]) { }
        field(2; Amount; Decimal) { }
    }
}

table 50101 "Posted Sales Document"
{
    fields
    {
        field(1; "No."; Code[20]) { }
        field(2; Amount; Decimal) { }
    }

    procedure Post(SalesDoc: Record "Sales Document")
    begin
        Rec.TransferFields(SalesDoc);
    end;
}

If the fields serve different purposes, assign a different field ID to prevent unintended data transfer:

table 50100 "Sales Document"
{
    fields
    {
        field(1; "No."; Code[20]) { }
        field(2; "Discount Amount"; Decimal) { }
    }
}

table 50101 "Posted Sales Document"
{
    fields
    {
        field(1; "No."; Code[20]) { }
        field(3; "Invoice Amount"; Decimal) { }
    }

    procedure Post(SalesDoc: Record "Sales Document")
    begin
        Rec.TransferFields(SalesDoc);
    end;
}

Mandatory affixes

When mandatoryPrefix, mandatorySuffix, or mandatoryAffixes are configured in AppSourceCop.json, field names on your own table extensions must carry an affix — forcing them to differ from a paired base-table field. This rule strips those affixes before comparing names, so a compliant extension field does not trigger a false positive. The AppSourceCop analyzer itself does not need to be activated — the configuration file is used solely to retrieve affixes.

tableextension 50100 "ABC Sales Document" extends "Sales Document"
{
    fields
    {
        field(50100; "ABC Discount Amount"; Decimal) { }
    }
}

tableextension 50101 "ABC Posted Sales Document" extends "Posted Sales Document"
{
    fields
    {
        field(50100; "ABC Discount Amount"; Decimal) { }
    }
}

With "mandatoryPrefix": "ABC " configured, the names are compared without the affix and no diagnostic is reported.

Affix stripping applies only to fields declared on table extensions in your own app. Fields on your own tables are not stripped: there the affix belongs on the table object, not on each field.

See also

  • PC0020 — Incompatible field types across TransferFields