How to define ‘Bill To’ address in Dynamics 365 Finance and Operations. Advanced address settings that you may not know about
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.
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:
1) One address can have several ‘Purposes’. And vice versa, there can be several addresses with the same ‘Purpose’
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.
2) By default, system sets Business purpose to each new address. And one of the addresses should be always set as Primary.
3) In the customer card, on the Invoice and Delivery tab, there are Invoice Account and Invoice Address fields. Invoice account is used to identify the billing account for the Invoice, but the Invoice address parameter is not that obvious.
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)
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?
DeliveryPostalAddress is taken from the sales order header. In Sales order header, system picks it from the customer addresses setup. Where system takes default address with the Purpose = Delivery.
* If no such address is found, the Primary address is taken
InvoicePostalAddress is the key field for ‘Bill To’. Unfortunately, on a sales order, we cannot change it explicitly (and, typically, there is no need to change it order by order).
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:
1. If CustTable.InvoiceAddress = Invoice Account, then the system finds default address for CustInvoiceJour.InvoiceAccount with Purpose = Invoice. If such address is not found, then Primary address is taken from the Invoice Account.
2. If CustTable.InvoiceAddress = Order Account, then system finds default address for CustInvoiceJour.OrderAccount with Purpose = Invoice. If the address is not found, the Primary address is taken from the Order Account.
3. If CustInvoiceJour.InvoiceAccount does not have a Primary address, then the address from the Order Account is taken, regardless of the value of the CustTable.InvoiceAddress field.
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:
1) Each address has Effective period days. The system takes these dates into account when it searches for a valid address.
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.
2) In the Advanced address parameters, you can explicitly specify Delivery terms, Mode of delivery, Sales Tax group, Receipt calendar – which overrides default settings in the customer details, when this address is selected on Sales order.
3) On a customer facing document if you want to include phone number of a company’s employee, like sales representative or accountant, make sure that ‘work phone’ number is taken, instead of ‘personal phone’ number.
Purpose also exists for a contact information (like e-mails, phones, faxes). Try to use Purpose instead of taking Primary worker phone number in your custom code. Ignoring this nuance may require data update in production environment and employee dissatisfaction for making their personal sensitive data available in public.
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!