In D365FO, postal addresses are not only stored as individual fields but can also be formatted according to predefined rules. These rules are configured in D365FO through the Global Address Book to Address format setup form, where you can define how an address should be structured for a specific country or region.
Once an address format is defined, D365FO can compose a full postal address as a single formatted string based on this setup. When a Docentric Data Source Package (DDSP) file is generated, such a formatted address is written directly as a string value.
However, while the formatted address is stored as a single string in the DDSP file, it often contains line break characters that represent the logical separation of address lines. When rendering this value in a Docentric template, these line breaks are not automatically interpreted by XPath expressions. As a result, the address may appear as a single line unless additional handling is applied.
This forum post explains how to render a formatted address string with proper line feeds using XPath expressions, ensuring that the address appears in the document exactly as defined by the standard address format in D365FO.
The Challenge
The address was provided as a single field with encoded line break characters:
CustTable_Address = “Street Name 123
Business District
Main Road
City Area
Postal Code
Country”

→ presents a carriage return
→ presents a line feed
In the Docentric template, the customer wants to replace
and
with a new line using various XPath replace() expressions, such as:
replace(Customer/@customerTable_Address,'
',$lf)
replace(Customer/@customerTable_Address,'
',$cr)
However, none of these approaches produced the expected line breaks in the template.
Why This Happens
When the XML DDSP file is parsed, the XML parser automatically converts character entities into control characters:

is converted to a carriage return (char(13))
is converted to a line feed (char(10))
As a result, the XPath engine in Docentric doesn’t recognize the literal strings 
 or 
.
Instead, XPath works with the actual control characters already present in memory, which explains why string-based replacements do not work.
Solution1: Using char() functions
To correctly handle line breaks in the Docentric templates, the XPath expression must replace the actual control characters using char() functions and convert them into Docentric’s $lf placeholder, which represents a line feed in Word or PDF output.
The correct XPath expression is:
replace(replace(Customer/@customerTable_Address,char(13),$lf),char(10),$lf)
This ensures that both carriage return and line feed characters coming from the DDSP file are rendered as proper new lines in the final document, and the address will be shown on the template as:
Street Name 123
Business District
Main Road
City Area
Postal Code
Country
Solution2: Using string variables
Docentric provides built-in string variables for line breaks.
You can replace:
- carriage return (

) with string variable$cr; - line feed (

) with next string variables:$tab,$new-line,$lf.
Using these variables, the XPath expression can also be written in the following way:
replace(replace(Customer/@customerTable_Address,$cr,$lf),$tab,$lf)
Feel free to experiment with other combinations as well! 
Recommendation
From a best-practice perspective, it’s usually better to provide address components (Street, City, Country, etc.) as separate fields in the DDSP file. This allows you to place them directly using Field Tagging, avoiding complex XPath string manipulations in the template.