This is the second and final instalment covering the Customer Card fields in Business Central. This post will focus on the ‘Payments’, ‘Shipping’ and ‘Statistics’ tabs. Make sure you check out our first post covering Customer Card fields.
Payments
The Payments tab contains fields relating to prepayment, payment terms, reminders and cash flow.
Prepayment %
The Prepayment % field allows you to specify the percentage the customer must pay prior to them receiving goods. This covers all types of orders including service orders. This is something more commonly utilised in situations where the customer’s credit score isn’t optimal, or perhaps there isn’t a pre-existing relationship.
Application Method
The Application Method field allows you to specify whether you wish to apply payments to entries manually or automatically.
By setting the value to Manual, you will always apply entries manually, using a journal. For example, the Cash Receipt Journal. So for any payments a customer makes, you specify which records the payments are associated with.
If you set the value to Apply to Oldest, it will apply any payments to the oldest entries, assuming there are some. Note, this will only work if the Work Date is ahead of the posting dates of those entries. This typically wouldn’t be an issue as it’s abnormal to post into the future, however as I am on a Sandbox environment, my Work Date doesn’t update on a daily basis. Therefore, whilst my entries were in the past, my Work Date was even further behind! This meant when I checked which entries the payment was made against, it was blank. However, upon amending my Work Date and creating a new payment, it applied it correctly:
To check which entry a payment has been made against, on the Customer Ledger Entries page, click ‘Entry’ and ‘Applied Entries’ on a record with a Document Type of Payment.
Partner Type
The Partner Type field allows users to specify whether direct debit payments are collected from an individual or a company. Generally this will be left as ‘Company’ but there may be instances where direct debits are paid by an individual instead.
Payment Terms Code
The Payment Terms Code is the way in which you configure when incoming payments are due in. To create payment terms, go to the page of the same name. Simply create a new record and input the relevant Due Date Calculation value. For example, 30D. You can also set a Discount Date Calculation value, which determines a period within the Due Date Calculation value in which customers will receive a discount. If you’d like more detail, please read our guide on payment terms in Business Central.
Payment Method Code
This field allows you to default how the customer typically pays you. The Payment Methods page as you can see, allows you to set a Balance Account Type and No. for each method you create:
One example of where you might use Payment Methods values would be on a Payment Journal record. There, you can use the ‘Suggest Vendor Payments’ action and filter your results by payment method. In this instance, you might want to pay all of your vendors who have a Payment Method value of BACS in one go.
Reminder Terms Code
The Reminder Terms Code allows you to configure payment reminders for customers. Against each Reminder Terms record, you can establish levels. These levels have Beginning and Ending Texts associated with them. These make up messages for the customer, informing them of their overdue payments. Each level has a defined period of time before it escalates to the next level. Interest and additional fees can be set against each reminder level.
So by establishing a Reminder Terms Code against a customer, you are establishing which set of levels, fees and messages you want the customer to receive when they don’t pay on time.
If you’re unsure about anything in this area, we recommend reading our guide on Reminders in Business Central.
Fin. Charge Terms Code
The Finance Charge Terms Code field allows users to specify any additional fees or interest applied to customers. You can also define a grace period for the record, a period where the customers will not incur any additional fees.
Cash Flow Payment Terms Code
This field allows you to specify a payment terms record. Whilst you might set a Payment Terms value against a customer of 30D, you might also be aware they don’t often pay on time. So when it comes to forecasting, it’s often unlikely to be accurate. So the Cash Flow Payment Terms Code factors in when you believe they will pay. To specify that you wish to use the Cash Flow Payment Terms on your forecasts, instead of the Payment Terms Code, enable the Consider CF Payment Terms field on the Cash Flow Forecast Card:
For my example, I will show this disabled and enabled. On a Cash Flow Worksheet, which you can use to forecast when money will go in and out of the business, the Suggest Worksheet Lines action will apply the Cash Flow Payment Terms value to the Cash Flow Date field. This more gives you a better picture of when you will be paid.
By specifying the different Source Types to Include and clicking ‘OK’, you will generate a cash flow forecast.
For my example, I created and posted a sales invoice on the 20th April 2023. Against the Customer Card for Alpine Ski House, there’s a 30D Payment Terms Code value and a Cash Flow Payment Terms value of 1Y (just to highlight the difference!). In the image below, you will see the Cash Flow Date is 20/05/23. This is because I didn’t enable Consider CF Payment Terms.
However, when I enable Consider CF Payment Terms and regenerate the Worksheet lines, you will see the Cash Flow Date changes to 20/04/23. This matches the Cash Flow Payment Terms of 1Y I set against the Customer Card:
Print Statements
The Print Statements field allows you to specify whether you wish to include the customer in question on any statement reports. For example, if you routinely run a report for customer statements, you can filter out which customers you wish to include on there. Perhaps you might enable this field for customers you no longer do business with. By default, this field is enabled.
Last Statement No.
The Last Statement No. field simply specifies the document number of the last printed statement for the customer.
Block Payment Tolerance
A payment tolerance is where you accept a lesser payment than what’s set out in an invoice. Enabling this field will prevent the customer from having a payment tolerance. Feel free to read our guide on payment tolerances in Business Central.
Preferred Bank Account
The Preferred Bank Account field specifies the bank account that will process refunds for the customer and be used to collect direct debit payments.
Shipping
The Shipping tab’s fields revolve around movement of goods.
Ship-to Code
The Ship-to Code allows users to specify where it is you wish to ship goods to. By default, the system will use the address values set in the Address & Contact tab. In instances where the customer has multiple sites, you can create and input these addresses in this code. On a sales order, you can amend the Ship-to address where necessary.
Location Code
The Location Code on a Customer Card specifies the default location goods will be processed from. On a sales document, the Location Code value will automatically pull through this value from the Customer Card. Of course this is only a default. You can amend the value on sales records. However, where you only ship goods to a customer from a singular place, it can be useful to set.
Combine Shipments
Enabling this field will allow you to ship goods from multiple sales orders in one shipment, as opposed to one for each.
Reserve
This field allows you to determine whether stock will ever be reserved for this customer.
We will produce a more detailed guide on reserving stock and reservation entries in Business Central.
Shipping Advice
The Shipping Advice allows users to specify whether or not a customer accepts partial shipment of goods. If this is set to ‘Complete’, you will not be able to partially ship goods to the customer. You will if the field is set to ‘Partial’.
To partially ship an order, amend the Qty. to Ship value on an outbound order. As you can see, the Quantity on my order is 10, however I am only shipping four at this time.
When I initially tested this, I encountered an error. Having created a Sales Order record and subsequently amending the Shipping Advice value on the Customer Card to ‘Complete’, I could still send partial shipments. However I realised that’s because I hadn’t changed the value on the Customer Card prior to creating the order. The system takes the value from the Card before applying it to the order.
On the order, in the Shipping and Billing tab, there’s a Shipping Advice field. In my example, this was set to Partial. As you’d expect, as I had posted part of the shipment, the system gave an error when I tried to amend this value.
The ability to amend this value on an order-by-order basis is valuable. Whilst you can say by default, this customer won’t accept partial shipments, there may be unique circumstances in which they do. This functionality caters for that requirement.
Code
The Code field indicates the transfer of ownership for saleable goods. Values include:
- Cost and Freight
- Free on Board
- Delivered Duty Paid
Agent
An Agent is a Code reflecting who is responsible for shipping. For example, DHL or Fedex. As you will see in the following fields, you can set up corresponding delivery time values against these records.
Agent Service
Following on from the Agent, these are the services they provide. Here, we can input ‘next day delivery’ for example, or ‘standard delivery’. Against each of these, we define the values that they correspond with. For ‘next day delivery’, you’d expect this to be one day. For standard, this might be three or four days.
Shipping Time
When you input the Agent and Agent Service against a Customer, this field should automatically populate. Whilst it’s unlikely you’d amend the configuration on the Item Card, if on a Sales Order you know that your ‘standard delivery’ won’t be able to reach them in the number of days it has as default, you can amend the Shipping Time on the Line which won’t affect the default value each time you apply the code. On this particular sales order, it will have a one-off value; this saves creating a new Agent Service each time you know an order delivery time won’t match a predefined record.
Base Calendar Code
The Base Calendar Code allows you to define a calendar for the customer, specifying when they are working. A typical example would be inputting a five day week. To set up a calendar, click into the field and ‘new’. Define a Code and Name for the record. Next, click ‘Actions’, ‘Functions’ and ‘Maintain Base Calendar Changes’. Here, you can specify which days of the week, and times a customer works. You can specify for each individual day, whether or not they are working. For more specific days when a customer is off, you can input individual dates and specify that they are non-working. To determine whether these follow a pattern, you can amend the Recurring System field. In the image below, you can see a typical example of a base calendar:
As you can see, I’ve stated that Christmas Day is always a non-working day, as are Saturdays and Sundays each week. Additionally, the 20th July is a non-working day. However, this is a one-off and so doesn’t have a Recurring System value. The system will use this data and assume all the days I’ve not specified are working days. This will affect things like delivery and receipt date calculations in the system.
Customised Calendar
Users can modify standard Base Calendar records for specific records. So in essence, you can use a base calendar as a template. To do so, you must set a Base Calendar Code against the Customer record. By drilling into the value in the Customised Calendar, you will see the base calendar’s calendar setup. If you click the pencil icon at the top to edit, you will be able to modify the record simply for this particular record. You can then either use the check-boxes to identify particular days that differ from the base calendar. Alternatively, for recurring changes, click ‘Actions’, ‘Maintained Customised Calendar Changes’.
To see your calendars, type in Base Calendars. For any of the records, click ‘Related’, ‘Base Calendar’ and ‘Where-Used List’. Here you will see which records use the standard base calendar and the customised one.
Statistics
Finally, the Statistics tab at the bottom contains lots of useful information surrounding the commercial performance of the customer. Any of the blue values, you can drill into.
It’s worth noting, for additional metrics, you can open the FactBox on the right-hand side of the page. To do so, click the ‘i’ action. As you can see in the below screenshot, you can click into tiles and directly navigate to corresponding records against the customer:
Concluding remarks
Thanks for reading! Hopefully you’ve learnt something from this and the previous part on the Customer Card in Business Central.
If you have any comments or questions, we’d love to hear them. Please get in contact with us! If you have any areas of the system you’d like to see posts on, don’t hesitate to let us know.
To keep up to date with when we post, follow us on LinkedIn.