Bill-to vs. Sell-to Customer
This is an old but still relevant topic; on sales documents (quotes, orders, invoices, return orders, etc.) in Microsoft Dynamics NAV you have the option to specify a separate bill-to customer. The bill-to customer is obviously who gets the invoice and where the accounts receivables end up, while the sell-to customer is who you are selling to.
Having a separate bill-to for some customers is a quite common requirement. In addition to the sell-to and bill-to customer there is also a ship-to address that is used to specify where the shipment is going.
There are some things that you need to be aware of when implementing this, I have seen people struggling with this many times and I thought it would be worth blogging about it (even if it is nothing new).
Below are some of the things that you need to know.
We will use a sales order with customer 10000 as the sell-to customer and customer 20000 as the bill-to customer in the examples.
The dimensions inserted onto the sales document are from the bill-to customer. It is a very common mistake to define default dimensions on the sell-to customers and then expect them to be inserted onto the documents.
Let say we want to report sales by region and for this we define a REGION dimension with the values equal to the states in the US. We then set a default REGION dimension value on all customers according to what state they are in. In this case it is important to know that if a sell-to customer is in a different state compared to the bill-to customer, then the sales report will show values based on where it was invoiced to. Sometimes this is wanted, sometimes this is not wanted.
If this is not wanted, then a way around this could for example be to have the users enter the REGION dimension value on each order manually (by leaving the dimension value blank on the default dimension for the bill-to customer), or to do a modification to have Dynamics NAV to insert dimensions from the sell-to instead (or maybe even based on the ship-to).
Prices and Discounts
All prices and discounts are based on the bill-to customer. This in most cases makes sense, so when you setup your price lists and discounts don’t set them up against the sell-to it will have no affect. I have seen this in many places and this is another common mistake.
Item Ledger and Value Entries
The item ledger entries and value entries created during posting are a bit interesting. The item ledger entry gets the Source No. according to the sell-to customer while the value entry gets the Source No. according to the bill-to customer.
Historically this has changed from version to version as well. A bit strange, but I guess the way it is now in NAV 2013 makes sense (as long as you know it when running reports, filtering, etc.). It would have been nice to have both in both places.
Customer Ledger Entries
The customer ledger entries are obviously created against the bill-to customer, but it also contains the sell-to customer number in the Sell-to Customer No. field. Nice!
Analysis View Entries
The analysis view entries has the bill-to customer number as the Source No., this makes sense since the dimensions are based on the bill-to customer.
Most of the canned reports, like the Customer Top 10, Customer/Item Statistics, Customer – Order Summary, etc. are based on the bill-to customer. Although there are some exceptions, like the Item Sales by Customer, that are based on the sell-to customer.
Some of the reports are created using the flowfields in the customer table (which are mostly the bill-to customer), some of the reports are created based on the value entries (which is the bill-to customers) and some of the reports are created based on the item ledger entries (which is the sell-to customers). Therefor a bit of a mixture.
Of the above mentioned things the Prices and Dimensions are by far the most common source of discussions when implementing Dynamics NAV. A couple of times I have had to change it so that the dimensions and prices are based on the sell-to customer instead, this have turned out to be quite a small and doable change.