Field Transfers

Field transfers allow you to automatically copy field values between related tables. This page explains how field transfers work, which paths are supported, and how to troubleshoot them.

Understanding Field Transfers

In Business Central, data often flows between related tables:

Customer information copies to Sales Order header
Sales Order header copies to Posted Sales Invoice
Item information copies to Sales Line

Field transfers let you extend this pattern for your custom fields.

Field transfers are a built-in SOD feature

Copying a value from a header record to its lines, and onward to posted document lines, is something SOD does for you wherever a supported transfer path exists. It does not require event subscribers or custom AL code. If a path is listed under Supported Transfer Paths, configuring the transfer is all that is needed.

Field Transfers vs. Lookup Field Transfers vs. FlowFields

Three different features solve three different problems. Choosing the wrong one is the most common cause of "my field stays empty".

Feature	Where you configure it	What it does	Use it when
Field Transfer	Add Fields > select field > Field Transfers	Copies and stores the value on the target record when the record is created or the lookup is validated	The value must be frozen onto the transaction/posted record
Lookup Field Transfer	Field Settings page for a Lookup field	Pulls additional fields from the looked-up record at the moment the lookup is selected	You have a Lookup field (e.g. to Customer) and also want the Name, Address, etc.
FlowField (Lookup or Sum)	Field type FlowField, configured in Field Settings	Displays the current related value without storing it; always reflects live data	The value should follow the source (including when it is cleared), or you need an aggregate

If the Field Transfers page is empty for a given field, no standard transfer paths apply to that field's source table. That is not an error — see Field Not Available for Transfer.

Verify the table before you configure

Selecting the wrong table is a common mistake. Check the table number and name before configuring a transfer:

The Purchase Line table (39) is not the Purchase Header table (38). An Item field flows to the Purchase Line, not the Purchase Header.
Table 405 is the Change Log Entry table, not a purchase document table.
The "Capacity Journal" in Business Central is technically the Item Journal Line table. Transfers described as "Capacity Journal to Capacity Ledger Entry" are the Item Journal Line → Capacity Ledger Entry row below.

How Field Transfers Work

When you create a field transfer:

SOD identifies the source field (e.g., Custom Field on Customer)
SOD identifies the target table (e.g., Sales Header)
When a record is created/updated, the field value transfers automatically

Example:

You add "Preferred Shipping Method" field to Customer
You create a transfer to Sales Header
When creating a sales order for a customer, the shipping method copies automatically

Values are only populated going forward

A field transfer populates values into records created after the transfer is published. Existing records are never backfilled, and no transfer runs retroactively over historical documents. To see a transfer work, create a new target record and select the source record.

Supported Transfer Paths

Field transfers work on established Business Central relationships. The tables below list the source-to-target transfer paths that SOD ships with. This list is a fixed, curated set — it is not exhaustive, and Hougaard adds new paths over time (see Requesting a new Field Transfer).

Customer Transfers

Source	Target	Notes
Customer	Sales Header	Via Sell-to and Bill-to Customer No.
Customer	Gen. Journal Line
Customer	Job
Customer	Contact

Vendor Transfers

Source	Target	Notes
Vendor	Purchase Header	Via Buy-from and Pay-to Vendor No.
Vendor	Gen. Journal Line

Item Transfers

Source	Target	Notes
Item	Sales Line
Item	Purchase Line	Use this to surface Item data (e.g. Vendor Item No.) on purchase lines and report layouts
Item	Job Planning Line
Item	Assembly Header
Item	Assembly Line
Item	Production BOM Line
Item	Prod. Order Line
Item	BOM Component

Sales Document Transfers

Source	Target	Notes
Sales Header	Sales Line
Sales Header	Sales Invoice Header
Sales Header	Sales Cr.Memo Header
Sales Header	Sales Shipment Header
Sales Header	Sales Header Archive
Sales Header	Gen. Journal Line
Sales Header	Item Journal Line
Sales Header	Warehouse Shipment Header
Sales Header	Warehouse Request
Sales Header	Warehouse Activity Header
Sales Header	Assembly Header
Sales Header	Purchase Header	Drop Shipment and Special Order
Sales Header	Sales Header	From Blanket Order / Make Order — requires a version newer than 12.0.0.586
Sales Line	Sales Invoice Line	Not triggered when posting a prepayment invoice — see Limitations
Sales Line	Sales Cr.Memo Line
Sales Line	Sales Shipment Line
Sales Line	Sales Line Archive
Sales Line	Item Journal Line	Route Sales Line values to Item Ledger Entry through here
Sales Line	Assembly Header
Sales Line	Requisition Line
Sales Line	Purchase Line	Drop Shipment
Sales Line	Production Order
Sales Line	Warehouse Shipment Line

Purchase Document Transfers

Source	Target	Notes
Purchase Header	Purchase Line	Configure here — not on the posted tables — to get values onto posted lines
Purchase Header	Purch. Inv. Header	Direct order-to-invoice; does not apply in the Get Receipt Lines workflow
Purchase Header	Purch. Cr. Memo Hdr.
Purchase Header	Purch. Rcpt. Header
Purchase Header	Purchase Header Archive
Purchase Header	Gen. Journal Line
Purchase Header	Item Journal Line
Purchase Header	Purchase Header	From Blanket Order
Purchase Line	Purch. Inv. Line
Purchase Line	Purch. Cr. Memo Line
Purchase Line	Purch. Rcpt. Line
Purchase Line	Purchase Line Archive
Purchase Line	Item Journal Line

General Journal and Ledger Entry Transfers

Source	Target	Notes
G/L Account	Gen. Journal Line
Gen. Journal Line	G/L Entry
Gen. Journal Line	Cust. Ledger Entry
Gen. Journal Line	Vendor Ledger Entry
Gen. Journal Line	Bank Account Ledger Entry
Gen. Journal Line	Employee Ledger Entry
Gen. Journal Line	Maintenance Ledger Entry
Gen. Journal Line	Job Journal Line	Use this for Project/Job G/L Journals — the target is Job Journal Line, not Project Ledger Entry. Added after version 12.0.0.626
Cust. Ledger Entry	Gen. Journal Line
Vendor Ledger Entry	Gen. Journal Line
Employee Ledger Entry	Gen. Journal Line

If you are looking for a transfer to the "Project Ledger Entry", configure it against Job Journal Line — the value flows onward on posting, so it becomes available for filtering and reporting on project costs.

Item Journal and Inventory Transfers

Source	Target	Notes
Item Journal Line	Item Ledger Entry
Item Journal Line	Value Entry
Item Journal Line	Capacity Ledger Entry	The "Capacity Journal" is the Item Journal Line table
Item Ledger Entry	Item Journal Line	Via Apply-To field; custom field transfer on Applies-to Entry validation requires a recent SOD version
Item Category	Item
Item Variant	Sales Line
Item Variant	Purchase Line
Phys. Invt. Order Line	Item Journal Line
Standard Text	Sales Line
Standard Text	Purchase Line
Sales Price	Sales Line
Price List Line	Sales Line
Item Substitution	Item Substitution

To get a Sales Line value onto an Item Ledger Entry, route it through the Item Journal Line (Sales Line → Item Journal Line, then Item Journal Line → Item Ledger Entry). A direct Sales Line to Item Ledger Entry transfer, or a FlowField from Item, is not the correct approach.

Transfer Order Transfers

Source	Target	Notes
Transfer Header	Transfer Receipt Header
Transfer Header	Transfer Shipment Header
Transfer Header	Transfer Line	Chain from here to the posted line tables
Transfer Line	Transfer Shipment Line	Requires SOD 12.0.0.568 or later
Transfer Line	Transfer Receipt Line	Requires SOD 12.0.0.568 or later
Purch. Rcpt. Line	Transfer Line	Via Prepare > Get Receipt Lines on a Transfer Order. Available in versions higher than 12.0.0.578

A custom field on a Transfer Line only survives posting to the posted transfer line when a line-to-line field transfer exists. A FlowField lookup from the posted line back to the transfer line is not the correct method.

Assembly Transfers

Source	Target	Notes
Assembly Header	Posted Assembly Header
Assembly Line	Posted Assembly Line	Not yet available. Accepted as a feature request; planned for a future update with no ETA

Until the Assembly Line path ships, choosing Field Transfers on a custom field on the Assembly Line table shows nothing to select for the Posted Assembly Line target.

Service Document Transfers

Source	Target	Notes
Service Header	Service Invoice Header
Service Header	Service Cr.Memo Header
Service Header	Service Shipment Header

Warehouse Transfers

Source	Target	Notes
Warehouse Request	Warehouse Receipt Header	Only populated when a new Get Source Document action is run
Warehouse Shipment Header	Posted Whse. Shipment Header
Warehouse Shipment Line	Warehouse Activity Line	Copies a custom field onto pick lines. Added in a recent update — not present in older versions
Warehouse Activity Header	Warehouse Activity Line
Warehouse Activity Header	Registered Whse. Activity Hdr.
Warehouse Activity Header	Posted Invt. Pick Header
Warehouse Receipt Header	Posted Whse. Receipt Header
Warehouse Receipt Line	Posted Whse. Receipt Line

Reminder Transfers

Source	Target	Notes
Reminder Header	Issued Reminder Header
Reminder Line	Issued Reminder Line

Requisition and Planning Transfers

Source	Target	Notes
Requisition Line	Purchase Header
Requisition Line	Purchase Line

Item Tracking Transfers

Source	Target	Notes
Whse. Item Tracking Line	Reservation Entry
Inventory Profile	Reservation Entry
Item Ledger Entry	Reservation Entry
Item Tracking Setup	Reservation Entry
Tracking Specification	Reservation Entry
Warehouse Activity Line	Reservation Entry
Warehouse Entry	Reservation Entry
Item Ledger Entry	Inventory Profile
Reservation Entry	Inventory Profile
Reservation Entry	Item Tracking Setup
Entry Summary	Tracking Specification
Item Ledger Entry	Tracking Specification
Item Tracking Setup	Tracking Specification
Reservation Entry	Tracking Specification
Warehouse Activity Line	Tracking Specification
Whse. Item Tracking Line	Tracking Specification
Entry Summary	Whse. Item Tracking Line
Item Ledger Entry	Whse. Item Tracking Line
Posted Whse. Receipt Line	Whse. Item Tracking Line
Whse. Item Entry Relation	Whse. Item Tracking Line
Reservation Entry	Whse. Item Tracking Line
Warehouse Activity Line	Whse. Item Tracking Line
Warehouse Entry	Whse. Item Tracking Line
Whse. Item Tracking Line	Whse. Item Tracking Line
Tracking Specification	Serial No. Information
Tracking Specification	Lot No. Information

Edit Posted Document Transfers

These self-referencing transfers are what make custom fields editable on posted documents:

Source	Target
Sales Shipment Header	Sales Shipment Header
Sales Invoice Header	Sales Invoice Header
Sales Cr.Memo Header	Sales Cr.Memo Header
Purch. Inv. Header	Purch. Inv. Header
Return Shipment Header	Return Shipment Header
Return Receipt Header	Return Receipt Header
Service Invoice Header	Service Invoice Header

Why a table transfers to itself

The posted-document update pages (for example Posted Sales Inv. - Update, page 1355) work through this mechanism behind the scenes. The self-referencing transfer is what wires the update page so that an edit is written back to the posted header record.

Without the self-referencing transfer, the field appears on the update page but edits are not saved.

Important limitation: this only works for your own custom fields. It does not work for Microsoft standard fields — attempting it produces an error. For example, the standard External Document No. field (field 100 on table 112) cannot be made updatable on page 1355 this way. Posted data is not meant to be editable, and allowing edits to standard posted fields could break Business Central, so this is outside SOD's scope.

Fixed Asset Transfers

Source	Target	Notes
Fixed Asset	Maintenance Ledger Entry
FA Depreciation Book	Maintenance Ledger Entry
FA Journal Line	Maintenance Ledger Entry
FA Ledger Entry	Maintenance Ledger Entry	Supported from SOD version 650
G/L Entry	Maintenance Ledger Entry	Supported from SOD version 650

Other Transfers

Source	Target	Notes
Ship-to Address	Sales Header
Contact	Customer
Activity Step	To-do
Time Sheet Line	Time Sheet Line
Production Order	Production Order	Copy to new status (Planned → Released). Requires SOD 12.0.0.597 or later

Creating a Field Transfer

Step 1: Create the Source Field

First, create your custom field on the source table:

Go to Tasks > Create new fields
Add a field to the source table (e.g., Customer)
Configure field type and properties

Step 2: Access Field Transfers

From Add Fields page, select your source field
Click Field Transfers in the action bar
The Field Transfers page opens

Step 3: Configure the Transfer

Click New to add a transfer
Select the target table
The target field is created automatically with matching properties
Optionally adjust target field settings

You do not need to create a matching field on the target table first. SOD creates it for you. If nothing can be selected, the path is unsupported — not missing a target field.

Step 4: Publish

Publish your extension to activate the transfer.

Field Numbers Must Match Across Tables

This is the single most common cause of field transfer errors, so it deserves its own section.

When "the same" logical field exists on several related tables, Business Central expects that field to have the same Field No. on each table. Business Central also performs its own automatic transfers between related tables (the TransferFields() mechanism), and it matches fields by Field No., not by name. If two unrelated custom fields on two related tables happen to share a number, BC will try to transfer between them, and if the types differ you get an error.

SOD tries to assign numbers so this does not happen, but a sequence of field creations and deletions can still produce a collision or a mismatch.

Symptoms of out-of-sync field numbers

A type-mismatch error at publish time, at data entry, when posting, or even when deleting a document, in this form:

  Field: FieldName1 <-- FieldName2
  Table: Customer <-- Contact
  Type: Date <-- Text

The error names two fields that have nothing to do with each other, and no transfer was ever configured between those tables.
An error that a value cannot be copied because the target field is not large enough, e.g. Type: Code10 <-- Text50 between Sales Line (37) and Sales Shipment Line (111).
Transfers that used to work suddenly write into the wrong target field, although the generated AL source still looks correct.
One field in a chain works (e.g. Demand Order No.) while another fails (e.g. Demand Line No.) even though both are Integer everywhere.

How to fix it

Open the New Fields list (the Add Fields page).
Use personalization to add the Field No. column — it is not shown by default.
Find the fields named in the error and compare their numbers across the tables involved.
Give "the same" logical field the same Field No. on every table in the chain, and make sure no two unrelated fields share a number across related tables. Numbers may be swapped around freely; the only hard rule is that no two fields within one table may share a number.
Stay inside your assigned number series — see Object Numbering.
Publish again.

Fixing one pair can reveal the next one. Repeat the comparison until no unintended shared numbers remain between the related tables.

This applies to chains as well: if you transfer a field along Requisition Line (246) → Purchase Line (39) → Purch. Rcpt. Line (121), the field must carry the same number in all three tables.

About existing data: correcting a field number to align it across tables is the supported fix. If the field already holds data, follow the usual precautions before republishing — see Force Mode.

Using BC's own TransferFields(): Business Central's automatic transfer between tables still works for SOD-created fields, provided the field number is identical on both tables. Note this is not a pattern Microsoft recommends, and Microsoft is moving away from TransferFields() in many areas — a configured SOD field transfer is the more predictable choice.

Field Transfer Settings

Source Field

The original field that provides the value.

Target Table

The table that receives the transferred value.

Target Field

Usually created automatically with the same properties as the source. You can customize:

Field name (if different naming needed)
Caption
Other properties as needed

Transfer Timing

Transfers occur when:

A new record is created in the target table
The lookup field (Customer No., Item No., etc.) is populated
The validate trigger runs on the lookup field
A process that builds the target record runs (e.g. Get Source Document on a Warehouse Receipt, Get Receipt Lines on a Transfer Order)

Some paths only fire at a specific moment. A Warehouse Request to Warehouse Receipt Header transfer, for example, only runs while a new Get Source Document action executes — opening an existing receipt will never populate it.

Limitations

One-Way Transfer

Field transfers are one-way only:

Source → Target
Changes in target do not flow back to source

Supported Relationships Only

Transfers only work on relationships Business Central already supports. You cannot create arbitrary transfers between unrelated tables. If Business Central does not carry the data from A to B, SOD cannot add the transfer — even on request.

Examples of paths that cannot be provided for this reason:

Purchase Line → Maintenance Ledger Entry and Purchase Line → G/L Entry. Standard BC only flows the header's Posting Description (field 22) to G/L and Maintenance Ledger Entries; the line-level Description (field 11) never reaches them.
Capacity Ledger Entry (5832) Run time (field 12) → Production Orders page (5405). Business Central offers no mechanism for this transfer, so SOD cannot expose it.

Same Data Type

Source and target fields must be compatible types. You cannot transfer a Text field to an Integer field.

Existing Data

Field transfers only work for new transactions. Existing records are not automatically updated, and there is no backfill.

BLOB Fields Are Not Supported

BLOB fields cannot be used as the source or target of a field transfer. Behind the scenes BLOBs are not really treated as fields and need special plumbing that transfers do not implement.

Transferring a BLOB to a Text field fails at deployment ("cannot transfer BLOB to TEXT").
A BLOB-to-BLOB transfer that is configured anyway does not display the source content — the target field on the card page shows only a plus (+) sign.

This includes comment and notes fields that are stored as BLOB.

Clearing the Lookup Does Not Clear the Target

Transfers only copy when a new value is selected on the lookup field. Blanking a lookup is not treated as selecting a value, so no transfer runs and previously transferred values stay on the record. This is expected behaviour, not a defect. If you need the value to follow the lookup at all times — including when it is cleared — use a FlowField of subtype Lookup instead.

Third-Party App Tables

SOD cannot create field transfers involving tables that belong to third-party apps. Both the source and the target table must be standard tables (or your own SOD tables). For example, "MPS Order" and "Low-Level Code" fields that originate from a third-party app on a Requisition Line cannot be transferred to a Prod. Order Line.

Target Header Tables Written by a Standard Process

A field transfer cannot be added into a header table that the underlying standard process already writes. For example, Purch. Rcpt. Header (120) → Purchase Header (38) during Get Receipt Lines is not possible, because the Get Receipt Lines process itself modifies the Purchase Header.

In the Get Receipt Lines workflow you can still use line-level and header-to-line transfers. A direct Purchase Header → Purch. Inv. Header transfer works when invoicing straight from the order, but does not apply when invoicing via Get Receipt Lines, since the order header is not referenced there.

Prepayment Invoices

Sales Line → Sales Invoice Line transfers do not run when posting a prepayment invoice. Prepayment posting routes lines through a buffer that aggregates them, which removes the one-to-one link the transfer depends on. This is a current product limitation and cannot be enabled through setup. Normal invoice posting is unaffected.

Posted Tables Are Too Late

Configuring a transfer from a posted header to a posted line does not work — posting has already happened. Set the transfer up on the pre-posting pair instead (see Getting a value onto posted lines).

No Calculations or Business Logic

Field transfers copy stored values along supported relationships. They do not calculate, aggregate, or implement business rules. Scenarios such as deriving a cost from a rate and a variable quantity, or pushing computed values onto ledger entries, are business logic and require AL development — see Graduating from SOD.

Likewise, to display an aggregated value (for example reserved quantity from Reservation Entry), build a Sum FlowField on the table that needs it rather than chaining transfers. Values that come through a transfer chain as 0 are a strong hint that a FlowField is the right tool.

Reports

A field transfer puts a value into a table. It does not add anything to a report layout. For the value to be available to a report, the target table must be one of the report's data items — either transfer the value into a data item table, or use a Lookup FlowField on one.

Common Scenarios

Customer Preference on Orders

Scenario: Track customer delivery preferences on sales orders.

Setup:

Create "Delivery Instructions" field on Customer
Create transfer to Sales Header
When order is created, instructions copy automatically

Item Attributes on Lines

Scenario: Show item certifications on sales lines.

Setup:

Create "Certification Code" field on Item
Create transfer to Sales Line
Certification shows on every line for that item

Item Information on Purchase Lines

Scenario: Show a field from the Item (e.g. Vendor Item No.) on each purchase order line, for example so it can be placed on a custom report layout.

Setup:

Create the custom field on the Item table
Create a transfer Item → Purchase Line
Publish. When the Item is selected on a purchase line, the value copies automatically
Add the field to the report dataset and layout

Pair this with placing the field on the Purchase Order lines subpage using AddAfter with a line field as the anchor.

Vendor Notes on Purchases

Scenario: Show vendor notes when creating purchase orders.

Setup:

Create "Purchasing Notes" field on Vendor
Create transfer to Purchase Header
Notes display when creating PO for vendor

Chaining Header → Line → Posted Line

Scenario: Carry a custom field from a document header down to its lines and onward to the posted lines.

Configure one transfer per hop — each transfer is independent:

Transfer Header → Transfer Line
Transfer Line → Transfer Shipment Line
Transfer Line → Transfer Receipt Line

The same pattern applies to sales and purchase documents. Build the chain hop by hop along supported paths.

Getting a value onto posted lines

Scenario: A header value (e.g. Vendor Shipment No.) must be visible on posted receipt lines so users can identify lines when applying item charges such as freight.

Correct: configure Purchase Header → Purchase Line. On posting, the value flows to the Purch. Rcpt. Line automatically.
Incorrect: configuring Purch. Rcpt. Header → Purch. Rcpt. Line. Those tables hold already-posted data, so the transfer is too late to run.

Populating Transfer Order Lines from Posted Receipts

Scenario: Goods are received at one location on a purchase order, then moved to another location with a Transfer Order whose lines are created with Prepare > Get Receipt Lines.

Setup:

Create the custom field (e.g. a PO No. reference)
Create a transfer Purch. Rcpt. Line → Transfer Line
When the Transfer Order lines are generated via Get Receipt Lines, the values copy automatically

The data comes from the Posted Purchase Receipt Lines, not from Item Ledger Entries. A FlowField on the Transfer Line filtering on Entry No. can pull a single value as an alternative, but the field transfer is the better choice when several fields are needed.

Carrying a Field from the Item Card to Warehouse Pick Lines

Scenario: A "Pack/Size" field maintained on the Item must be visible to warehouse staff on pick lines.

Configure one transfer per hop along the chain:

Item → Sales Line
Sales Line → Warehouse Shipment Line
Warehouse Shipment Line → Warehouse Activity Line (pick lines)

The final hop requires a recent SOD version — see the Warehouse Transfers table.

Making a Custom Field Editable on a Posted Document

Scenario: Users must be able to correct a custom field on a Posted Sales Invoice.

Setup:

Create the custom field on the posted header table (Sales Invoice Header)
Place it on the posted-document update page (Posted Sales Inv. - Update)
Create a field transfer from the table to itself (Sales Invoice Header → Sales Invoice Header)
Publish

Without step 3 the field is visible but edits do not persist. Only custom fields can be handled this way — Microsoft standard fields cannot.

Displaying Live Customer Values on a Sales Order

Scenario: Show Credit Limit or Balance Due from the Customer on a Sales Order.

Use a FlowField on the Sales Header, not a field transfer — these values must reflect current data rather than a snapshot taken at order creation.

Credit Limit: a Lookup FlowField
Balance Due: a Sum FlowField over Detailed Cust. Ledg. Entry

Archiving an Option Field

Scenario: A custom Option field on the Sales Header should be preserved in the Sales Header Archive.

Create a field transfer to the archive table. SOD creates a matching Option field on the archive table and links the two. A FlowField is not the right tool for this — the value must be stored on the archived record.

Multiple Transfers

A single source field can transfer to multiple targets:

Customer.Custom Field → Sales Header
Customer.Custom Field → Service Header
Customer.Custom Field → Sales Quote

Each transfer is independent.

Testing Field Transfers

After publishing:

Open the source record (e.g., Customer)
Enter a value in your custom field
Save the record
Create a new target record (e.g., Sales Order)
Select the source record
Verify the value transferred

Always test with a newly created record. Existing records will not show transferred values.

Troubleshooting

Value Not Transferring

Check:

Is the extension published?
Is the transfer configured correctly?
Is this a new record (not existing)? Transfers never backfill.
Is the lookup field being validated?
For process-driven paths, did you run the process again (e.g. a new Get Source Document / Get Receipt Lines)? Viewing an existing document will not trigger anything.
Do the field numbers match across the tables involved? See Field Numbers Must Match Across Tables.

Field Shows on the Page but Is Always Empty

Symptom: The field is visible, including on brand-new records, and the same setup works in sandbox but not in production.

Checks and causes:

A newly created field is blank by definition. Creating a field does not populate it — a transfer, lookup, or FlowField must fill it. Re-creating a column that previously showed a related record's name (e.g. Vendor Name on G/L Entries) needs lookup logic, not just a field.
If the customization was rebuilt by hand in production instead of deploying the sandbox-tested app, parts of the configuration (such as the transfer) are easily missed. Deploy the app file from sandbox via Extension Management instead of recreating the setup in production.
Remember that transfers do not backfill existing records.

Wrong Value Appearing

Check:

Is the source field populated?
Is the correct source record selected?
Are there multiple transfers causing conflicts?
Do the field numbers of the custom field match between the source and target tables? A mismatch causes the transfer to resolve to a different (wrong) target field, producing type or size errors at posting time. See Field Numbers Must Match Across Tables.

Type Mismatch Error Between Unrelated Fields

Symptom: An error such as Field: A <-- B / Table: Customer <-- Contact / Type: Date <-- Text appears during data entry, posting, deletion, or publishing — between two fields that have nothing to do with each other, with no transfer configured between those tables.

Cause: Business Central's own automated transfer between related tables matched two SOD fields that share a Field No.

Fix: Give one of them a different, unused Field No. and republish. See Field Numbers Must Match Across Tables.

Posting Fails After Adding a Transfer

Symptom: A custom field on Sales Header transfers to Sales Line, Sales Invoice, Sales Cr.Memo, Sales Shipment and Sales Header Archive; posting an order now fails.

Cause: Business Central expects "the same" field to carry the same Field No. on each of those tables. When numbers differ — for example two custom fields whose numbers are effectively swapped across tables — posting can fail even though the fields are unrelated in business terms.

Fix: Align the field numbers across the tables and republish.

Transferred Value Not Cleared When Lookup Emptied

Symptom: The transferred value stays on the target record after the source lookup field is emptied.

Cause: Transfers run only when a new value is selected; clearing to blank transfers nothing.

Alternative: Use a FlowField of subtype Lookup so the displayed value always follows the current lookup value, including when it is cleared. See Field Settings (FlowField Configuration → Calculation Type: Lookup) and Field Types.

Target Field Shows a Plus (+) Sign

Symptom: After deploying a transfer into a BLOB field, the target field on the card page shows a + instead of content.

Cause: BLOB fields are not supported by field transfers.

Resolution: There is no supported way to transfer a BLOB. Do not configure transfers for BLOB fields, including comment/notes fields stored as BLOB.

Custom Field Disappears After Posting

Symptom: A custom field on a document line (e.g. a Decimal field on a Transfer Line) is not visible on the posted document line.

Cause: The value does not reach the posted line table unless a line-to-line transfer exists for that path.

Resolution: Configure the appropriate Sales Line / Purchase Line / Transfer Line to posted-line transfer. For transfer lines specifically this requires SOD 12.0.0.568 or later. Do not use a FlowField lookup on the posted line for this.

Edits on a Posted-Document Update Page Do Not Save

Symptom: The custom field appears on the update page (e.g. Posted Sales Inv. - Update) but editing it does not change the posted record.

Cause/Fix: The self-referencing field transfer is missing. Create a transfer from the posted header table to itself — see Edit Posted Document Transfers.

Field Not Available for Transfer

Check:

Is the source table supported for transfers?
Is the target table in a supported relationship?
Has the source field been published?

If the Field Transfers page offers nothing to select, the source-to-target path is not one of SOD's built-in mappings. This is not a setup error, and it is not caused by a missing field on the target table — SOD creates the target field for you when a path exists. Clicking + New on an unsupported path may add a blank line that will not let you enter target table information; this is expected, because table selection is restricted to supported paths.

Two examples of paths that are not shipped by default: Item (27) → a Bin Content table (7302), and Assembly Line (901) → Posted Assembly Line (911).

The remedy is to request the path — see below. Before doing so, consider whether a Lookup FlowField would serve you better: a transfer copies and stores the value when the record is created, whereas a Lookup FlowField displays the current related value on demand without storing it.

Transferred Field Not Found When Adding Existing Fields

Symptom: After configuring a transfer, the field cannot be found when using "Add existing fields to pages and reports".

Check: The transferred field is created on the exact target table named in the transfer. An Item → Purchase Line transfer creates the field on Purchase Line — not on Purchase Header, and not on another table with a similar name. Confirm the table number as well as the name.

Best Practices

Plan Your Transfers

Before creating fields:

Map out where data needs to flow
Identify all target tables
Plan field naming for consistency
Decide up front which numbers "the same" field will use on every table in the chain

Consistent Naming

Use consistent field names across transfers:

Customer.Delivery Preference
Sales Header.Delivery Preference
Same name helps users understand the relationship

Keep an Eye on Field Numbers

Field-number drift becomes more likely as more fields are added to tables that participate in transfers. When you add further fields to such tables, re-check the numbers.

Document Your Transfers

Keep track of:

Which fields have transfers
Source and target tables
Business purpose of each transfer

Test Thoroughly

After publishing:

Test each transfer path
Verify with real-world scenarios
Confirm values transfer correctly

Requesting a new Field Transfer

You can request Hougaard.com to create new field transfers. Please log a support ticket on https://support.hougaard.com if there's a field transfer missing. Be sure to describe the use-case and the from and to tables.

What to expect:

The supported paths are a curated list. If your source→target combination is not listed, a request is the correct route.
Accepted requests are implemented and ship in a later SOD update. After updating SOD, the new path appears in the Field Transfers configuration. Recent examples: Transfer Line to posted transfer lines (12.0.0.568), Purch. Rcpt. Line → Transfer Line (higher than 12.0.0.578), Maintenance Ledger Entry sources (version 650).
There is no fixed release cadence and an ETA is usually not given when a request is accepted. Watch the app version release notes to confirm a requested path has shipped.
A request can only be granted where Business Central itself carries the data between the two tables. If no underlying relationship exists, the transfer cannot be built at any version — see Supported Relationships Only.
Requests that involve calculations, derived values, or business rules are not field transfers and will need AL development.