Category: Dynamics

This article is part of the In Microsoft Dynamics 365 Business Central (Purchasing), how do I… series and of the wider In Microsoft Dynamics 365 Business Central, how do I… series which I am posting as I familiarise myself with Microsoft Dynamics 365 Business Central.

when entering a purchase invoice, you need to match the values entered into Business Central with those on the invoice received from the supplier. In most cases, they will be the same, so you can simply enter the transaction, but at times there will be a difference in values, most commonly in the VAT figure where the suppliers system is rounding differently to Business Central.

Fortunately, you can override the VAT calculation and change the vat amount on the invoice.

If we take the below example, where £22,018.40 of tax has been calculated, and need to reduce the VAT by a penny for a rounding difference:

Continue reading “In Microsoft Dynamics 365 Business Central (Purchasing), how do I… Override VAT on a Purchase Invoice”

This article is part of the In Microsoft Dynamics 365 Business Central (Purchasing), how do I… series and of the wider In Microsoft Dynamics 365 Business Central, how do I… series which I am posting as I familiarise myself with Microsoft Dynamics 365 Business Central.

When dealing with purchase invoices there are a few date fields on the record and I have fielded a few queries from users to clarify exactly what they are and how they should be set.

The Document Date is the date on the suppliers invoice; you should always set this field correctly when entering a purchase invoice and is used to calculate the Due Date.

Oddly, there is both an Invoice Receipt Date and an Invoice Received Date field, which appear to be intended for the same purpose; recording the date you received the invoice from the supplier.

Posting Date is the date the transaction will be posted to the general ledger; usually set to the same value as the document date, you may need to change this when entering invoices after month end when the invoice is dated before month end; this allows you to enter the invoice with the correct Document Date, but keep the financial postings in the current month.

The Due Date is the date by which the invoice should, according to the payment terms, be paid.

The VAT Date is the date upon which VAT is payable.

This article is part of the In Microsoft Dynamics 365 Business Central (Administration), how do I… series and of the wider In Microsoft Dynamics 365 Business Central, how do I… series which I am posting as I familiarise myself with Microsoft Dynamics 365 Business Central.

There is four main types of data in Business Central; master data, transactions before posting, transactions after posting and ledger entries.

I was surprised to learn that all of this data, excepting the ledger entries, can, by default, be deleted.

Just in case you’re not aware, the flow of a transaction, such as a sales invoice, would be from the transactions before posting tables (such as Sales Header (36) / Sales Line (37)) to the transactions after posting tables (such as Sales Invoice Header (112) / Sales Invoice Line (113)) when the transaction was posted. At the same time, entries will be created in the ledger entries table (such as Cust. Ledger Entry (21)).

So when a transaction is deleted, which can be done through the relevant list page, it is only deleted from the transaction before/after posting tables, but will still remain on the ledgers.

There are a couple of caveats to deleting master data. You cannot delete the master data if there are unposted transactions or if there are ledger entries in an open financial year.

When you delete a master re cord, the ledger entries in closed years remain behind, but are in effect “orphaned” records which relate to a record which no longer exists. This means you need to be careful how you create reports; for example, no inner joins between the transaction and master record tables, as this would exclude transactions not in the master record table.

As I said at the start of the post, the data can by default be deleted, as the permissions sets which Business Central ship with allow for deletion. The way to prevent users from deleting master records or posted transactions is to create and assign custom permission sets which prevent data being deleted.

This article is part of the In Microsoft Dynamics 365 Business Central (Financial), how do I… series and of the wider In Microsoft Dynamics 365 Business Central, how do I… series which I am posting as I familiarise myself with Microsoft Dynamics 365 Business Central.

Entering general journals in Business Central is quite easy to do, but there is a little setup required before you begin. When entering general journals they must be entered as part of a batch, and behind the batch is a template; these two things do not exist except as a many to one relationship from the template to the batch.

The general journal template provides a standardised format for entering transactions and allows default settings, such as account types, numbers, number series, posting number series, reason codes and more to be defined. There will be one template for each of the different areas of the system, such as assets, cash receipts, payments, purchases and so on.

A DEFAULT batch is created with the template and inherits the default settings, but it is recommended that users create personalised batches for the different types of transactions which will be entered in a specific area.

For example, if we look at the general journals entered directly onto the general ledger, there would usually be a batch for adjustments, one for payroll journals, one for year-end adjustments, one for corrections and so on. To avoid users entering journals into the same batch and having conflicts with others, I would always recommend including the users initials in the batches created.

For example, I might have the following batches within my GENERAL template:

• IG-PAYROLL
• IG-MONTH-END
• IG-YEAR-END

A batch can contain multiple individual journals with different posting dates, references and so on, but each journal must balance before it can be posted.

This article is part of the In Microsoft Dynamics 365 Business Central (Administration), how do I… series and of the wider In Microsoft Dynamics 365 Business Central, how do I… series which I am posting as I familiarise myself with Microsoft Dynamics 365 Business Central.

Number series are maintained in the No. Series Lines (457) table; it’s important to remember that the number series page and table are not aware if a number series is a posted one or not, as this is managed in the setup or batch pages.

There is no limit to the number of number series which can be created, and some people create number series for specific batch types such as year-end, adjustment or payroll journals.

To create a new number series, search for the No. Series page; to create a new number series, move to the bottom of the list (in theory you can click the new button and insert where the cursor is, but, long term, this can cause problems).

In this example, I am adding a number series to use for payroll journals (and have applied a filter to the list to hide the other number series). I have entered the Code, Description[/b] and have marked the Default Nos. checkbox so numbers will default onto the transaction (in almost all cases you will want this checkbox marked; the only scenario I’ve found so far where we wouldn’t want this is when users will manually supply the item number when creating new items; a number series needs to be assigned in Inventory Setup (461) to avoid errors).

Decide if gaps are allowed in the numbers and mark the Allow Gaps in Nos checkbox accordingly; typically I set number series to allow gaps unless they are being used as posted number series.

Continue reading “In Microsoft Dynamics 365 Business Central (Administration), how do I… Maintain Number Series”

This article is part of the In Microsoft Dynamics 365 Business Central (Administration), how do I… series and of the wider In Microsoft Dynamics 365 Business Central, how do I… series which I am posting as I familiarise myself with Microsoft Dynamics 365 Business Central.

All master records and transactions in Business Central require a unique identifier; hte number series is how Business Central handles this.

There is the page where you create and maintain the number series, which actually provides a fair bit of control. For example, you can choose if the number series allows users to override the default numbering with their own number, if gaps are allowed in the numbering or if any number defaults as all.

Elsewhere is Business Central, you can configure which number series is used for which master record or transaction type.

In addition, when you configure the number series to be used, you can also specify the posted number series, which is available for most, but not all, transaction types.

The number series is assigned as the record or transaction is created; when a transaction is posted it will be assigned a number from the posted number series. This allows for different numbering ranges to be used for open and posted transactions, giving a separation between documents at different status and also a clear audit trail.

I was onsite doing a small system review for a client recently. One of the issues they mentioned was that they were reaching the limit of the number of rows that could be entered in sales orders, comments and other areas of the system.

I didn’t think there was a practical limit to the number of rows you could add, so was a bit surprised. I asked them to show me an example and they used the sales order window.

The issue was sort of a Business Central issue, but not the one they thought it was. When you enter a word order line into Business Central the data is stored in the Sales Line (37) table, with one column being the Line No.

The first row in this field is set to 10,000 and a second line would be 20,000. If you insert a line where the cursor is, then the row number will be mid-way between the line above and below. for example if I have a two line order and insert a new line, it’s Line No. will be a 15,000.

Eventually, the system runs out of space to enter new lines half way between the lines. They always encountered this issue, as they’d leave the cursor on the first line and click the New Line button.

If you always put the cursor at the bottom of the lines then a new number will be created 10,000 higher than the previous:

This numbering is common to all record types with lines, including comments as well as sales transactions.