How to define ‘Bill To’ address in Dynamics 365 Finance and Operations. Advanced address settings that you may not know about
Define ‘Bill To’ address
Most D365 FO projects have a typical requirement: Company’s customer, with a network of several branches/warehouses, where orders are delivered to (‘Ship To’ address), has one HQ/Office address, where invoices should be sent (‘Bill To’).
Although the requirement is quite common, its implementation in D365 is not as trivial as it seems at the first glance.
Let’s focus on a standard logic to display both ‘Ship to’ and ‘Bill To’ addresses in printed documents or send both addresses during EDI integration.
Unfortunately, I saw several implementations, where standard logic was either completely ignored or not fully understood by a client, which causes extra development efforts or unexpected system behavior.
We will explore standard logic in this blog post.
As you may know, behind each Customer in D365 F&O, there is a Party record, which may have several addresses. And, respectively, it is necessary to somehow make the system know how to select the right one unambiguously.
Pic. 1 – Party details
In addition to the ‘Primary’ attribute, each address also has so-called ‘Purpose’ attribute. There are several standard ones: Delivery, Business, Invoice, Remit to.
You can add new value to the list that fits your requirement best.
(Path: Organization administration > Global Address Book > Address and contact information purpose)
So, back to our requirement, there are several ways to implement it and some useful hints:
To identify default address between the two with the same purpose, for a particular customer, there is a hidden menu under More options> Set default, where you can choose, which address is the ‘default’ for every Purpose.
Pic. 2 – Default purpose
Pic. 3 – Invoice and delivery parameters
Depending on financial accounting requirements, we can represent customer subsidiaries and delivery points with either different addresses or different customers.
HQ might be set as Invoice account on customer’s card (subsidiary) and, consequentially, on the sales order.
But I don’t recommend splitting customer data just for the sake of address display.
(In most cases finance team will stop you from doing so, even before you start thinking about it =)
Let’s move on and take look at the example:
When sales invoice is posted, a new record is generated in the CustInvoiceJour table, representing an invoice (header) details.
(Accounts Receivable > Inquiries and reports > Invoices > Invoice Journal)
Pic. 4 – Invoice journal
In addition to Order Account and Invoice Account (which is the same in most cases), this table also has DeliveryPostalAddress and InvoicePostalAddress fields (hidden on the form by default).
We can treat them as our desired ‘‘Ship To’’ and ‘‘Bill To’’!
But the devil is in the details. Where are these addresses taken from?
InvoicePostalAddress inheritance logic is as follows:
First, for a selected Order account from the Invoice journal (CustInvoiceJour.OrderAccount), the value of the InvoiceAddress field in Customer details is checked:
When you create a new customer in the system, CustTable.InvoiceAddress equals to Invoice Account by default.
So, in conclusion, the logic described above is recommended for a requirement with a different ‘Bill To’ and ‘Ship To’ addresses.
For a custom SSRS document or EDI integration, try to take ‘Ship To’ (DliveryPostalAddress) and ‘Bill To’ (InvoicePostalAddress) directly from the Invoice journal, instead of retrieving it from sales header or customer details.
It will solve all ambiguities when you want to reprint it later in case the master data had been changed.
In addition, there are some advanced address parameters that may also be considered:
By default, an address does not have an expiration date. But this can be set in the Address form, via More options> Advanced under General tab, for all addresses, except Primary one.
Pic. 5 – Address effective dates
For example, there was a situation on a project, when the system printed out blank ‘Bill To’ address, although user has set it right at the data migration phase. But the address was expired, and system considered it inactive.
Moreover, expired addresses are not displayed on the customer’s details directly, which leads to misunderstanding among users.
I hope this information will be useful for you, in case when Primary address is not enough)
Have a good time using Dynamics 365 and implement it wisely! We are ready to support you!
Article was prepared by:
