You receive the message “The Posting Date is not within your range of allowed posting dates” when trying to post a Purchase Invoice in Business Central.
According to the user setup the “Posting Date” of the document I’m posting is within the allowed posting range so why won’t the system allow me to post it?
Background – Value Entries
To provide a little more detail I’m trying to post a Purchase Invoice that I’ve matched to a Posted Purchase Receipt and I’ve increased the Unit Cost on the Purchase Invoice as the price has changed since the goods were received. I’ve also sold the items on a Sales Invoice before I’ve tried posting the Purchase Invoice.
Therefore, if we look at the value entries of this item prior to attempting to post the Purchase Invoice they are as follows
We have a value entry for the Posted Purchase Receipt showing a date of 12/05/2017 and a “Cost Amount (Expected)” of £10.00 (this the amount I used when posting the Purchase Receipt)
We also have a value entry for the Sales Invoice showing a Posting date of 25/05/2017 and a “Cost Amount (Expected)” of £10.00.
Details of the Purchase Invoice
The Purchase Invoice I’m posting is dated 01/06/2017 and I’ve amended the Unit Cost from the original £10.00 that pulled through from the Posted Purchase Receipt to £12.00
Now when I try and post this transaction, I receive the message
Therefore, just to confirm the Posting Date of the Purchase Invoice is within my allowed posting dates below is a screen shot of the User Setup window showing my Allow Posting Dates
The dates are also within the General Ledger allowed posting dates as shown below
Therefore, at first glance its not apparent why the system isn’t allowing me to post this document? The Purchase Invoice posting date is 01/06/17 and this is within my range of allowed posting dates?
The Issue – Automatic Cost Adjustment and Adjust Cost Item Entries
When posting the Purchase Invoice, the system has detected that the cost has changed from the Posted Purchase Receipt, and as this has been sold on a Sales Invoice, the cost of goods sold need adjusting.
The system therefore tries to post an adjustment using the Posting Date of the entry its adjusting (in this case the Sale Entry on the 25/05/17), which is in May, and as this falls outside of my posting range I receive the error “The Posting Date is not within your range of allowed Posting Dates”.
** Please note there is a complex method for selecting the Posting Date if the Posting Date of the entry being adjusted also fell outside of the “Allowed Posting Dates” of the General Ledger and also if “Inventory Periods” are being used. More information on this can be found in this Microsoft document https://docs.microsoft.com/en-us/previous-versions/dynamicsnav-2016/dn948192(v=nav.90)
** Its also worth noting I’m getting this message when posting the Purchase Invoice because the option “Automatic Cost Adjustment” is set to “Always” in Inventory Setup. This means the system checks for cost adjustments when you post the transaction. If this wasn’t set to “Always”, then depending on its setting its possible the document would post however when the “Adjust Cost Item Entries” batch job was subsequently run the error would occur.
See below for my Inventory Setup
Solution
There are two possible solutions to my issue here. The first is to change my “Allowed Posting Dates” in the “User Setup” to 25/05/2017 through to 30/06/2017. This will then include the posting date of the entry that will be adjusted.
Alternatively, I could change the “Allowed Posting Dates” in the General Ledger Setup to 01/06/2017 through to 30/06/2017. Then, as per the article I linked to, the system would use the date of 01/06/2017 for the adjustment entries, (i.e. the first open date in the General Ledger Setup) which does fall in my allowed periods to post to.
Therefore I’ll change my “Allowed Posting Dates” in the User Setup as per below
And now when I post the Purchase Invoice this is succecssful
If I now view the Value Entries you can see the adjustment entry created with a Posting Date of 25/05/17.
Conclusion
Although this is a simple example it shows why you may encounter this error when it seems the postings date configuration on the User Setup should allow a document to post.
I recently had an issue where a user was stuck in a batch in the Bank Management module. You can usually run the “Clear Activity” option to resolve the issue however on this occasion it didn’t work. I found I had to manually delete a row in an SQL table to clear the lock and allow the user access to the batch.
The exact issue they received is as follows:
With this error message the first thing to try is to clear activity and although this didn’t work on this occasion I’ll detail the steps below.
Ensure there are no users in Dynamics GP and click “Yes” to the message below. (rather than asking everyone to log out I usually just ensure there’s nobody doing any Bank Management activities)
After doing this you will be prompted with the message below confirming activity is cleared
However I found I still couldn’t access the batch. On investigation there is still some activity for the batch in the CBEU1020 table which needed clearing. I therefore ran the SQL query below in the company database to delete the row. (replace TWO18 with the name of your company database)
Within Dynamics NAV \ Business Central you can switch Expected Cost Posting to G/L both ON and OFF via the option below in Inventory Setup.
In this post I’ve been playing with this feature to see how things work and how the various postings differ to Dynamics GP. I also take a look at how the Value Entries in Inventory play a pivotal role in this. I end by taking a closer look at the SQL tables involved and how things fit together.
Expected Costs in Dynamics GP
When you receive goods via a Shipment transaction in Dynamics GP a Purchase Accrual is automatically created to a General Ledger accrual account to record the expected cost in the General Ledger. This account is generally taken from the Creditor Card as per below:
Dynamics GP – Creditor Account Maintenance
The
opposite debit entry is taken from the Inventory Item card as per below:
Dynamics GP – Item Account Maintenance
Let’s add a Purchase Order Shipment transaction in Dynamics GP and see this in action:
Dynamics GP – Receiving Transaction Entry
As you can
see from the screen shot above, I’m receiving one Inventory item, and this has
created an accrual distribution crediting the 000-2111-00 accrued purchases
account I specified on the creditor card. The balancing debit side is to the
Inventory code that we specified on the Inventory Item card.
Now let’s
see what happens when we invoice the Shipment:
Dynamics GP – Purchase Invoice Entry
Just as expected the accrual is reversed via a Debit entry to the 000-2111-00 accrued purchases account and the accounts payable is credited. Therefore, the balance in the accrual account is now nil.
There’s no way to disable this behaviour in Dynamics GP. When you post a “Shipment” for some Inventory Items General Ledger entries are always created. (however you can prevent the entries posting through to the General Ledger via the Posting Setup)
Expected Costs in Dynamics NAV \ Business Central
Before we look at Expected Costing in Dynamics NAV \ Business Central we first have to take a step back and look at the various inventory entries that are created when you post inventory transactions.
When you post an inventory transaction in Dynamics NAV \ Business Central the system creates a minimum of two inventory entries: an Item Ledger Entry and a Value Entry. The Item Ledger Entry records the change in quantity and the Value Entry records the change in inventory values. For the purposes of this post we just need to know that when posting Purchase receipts Value Entries are created for Expected Costs, and when you post Purchase Invoices, Value Entries are created for Actual Costs, and Expected Costs are reversed.
Expected Cost Posting to G/L – Switched ON
Unlike Dynamics GP you can switch ON and OFF accrual postings in Dynamics NAV \ Business Central via the Expected Cost Posting to G/L option in Inventory Setup. When you switch Expected Cost Posting to G/L ON interim accounts are used to post the accrual and inventory entries for Purchase receipt transactions.
The equivalent Dynamics GP accrued purchases account is called Invt. Accrual Acc. (Interim) and is specified in the General Posting Setup window and is selected based on the Posting Groups used on the Item and Creditor. (see my previous post for more details on the posting groups). I’ve highlighted this below
Dynamics NAV \ Business Central – General Posting Setup
The Inventory code for the debit side of the transaction is taken from the Inventory Posting Group and again is based on the combination of posting groups used. I’ve highlighted this below
Dynamics NAV \ Business Central – Inventory Posting Setup
The key difference here is Dynamics GP doesn’t use an interim Inventory account whereas Dynamics NAV \ Business Central does.
In my Cronus demo data, the option Expected Cost Posting to G/L is currently switched ON so let’s see how this works when I create a Purchase Order for an Inventory item and receive it.
Here’s my Purchase Order and after clicking Post I’m going to choose receive so I receive the items into the Inventory:
When I view the item I can see this has created the following Value Entry (Number 454) which shows the Cost Amount (Expected) and Expected Cost Posted to G/L both populated.
If I highlight the Value Entry and click Navigate > General Ledger I can see the G/L Entries associated with the Value Entry
As expected,
we can see the 5510 Accrual account is being credited and the debit entry is
posting to the 2111 “Interim” Inventory code.
Now let’s invoice the purchase order and take a look at the G/L entries. First I click Post and select Invoice on the Purchase Order. (Incidentally if I were to select Receive and Invoice the system recognises I’ve already received the items. It doesn’t receive them again)
This has created the a new Value Entry (Number 455) . There’s a few things to note here. Firstly the Cost Amount (Expected) and the Expected Cost to G/L have been reversed. Secondly the Cost Amount (Actual) and Cost Posted to G/L have been populated.
Again if I highlight the Value Entry and choose Navigate > General Ledger we can the G/L Entries associated with this Value Entry.
As you can see the original entries created via the Purchase Receipt have been reversed by posting a debit to the 5510 Inventory accrual account and a credit to the 2111 Interim Inventory account. The system has then posted new entries to the 2210 Resale items inventory account (debit) and the direct cost applied account (credit). (for more info on the direct cost applied account see my previous post).
So that’s it. Although there are a few extra distributions to Dynamics GP everything makes sense. Its also apparent that the Value Entries have a direct relation to the G/L entries that are created.
Expected Costing to G/L – Switched OFF
Now let’s see what happens when we post a Purchase Receipt with the Expected Cost Posting to G/L switched OFF. First I switch the option OFF and then create and post the Purchase Receipt
This has created the following Value Entries (Number 456)
The key thing to note here is that although the Cost Amount (Expected) is populated the Expected Cost Posted to G/L isn’t. This means no G/L Entries have been created. To prove this click Navigate > General Ledger to view any G/L Entries
Let’s now invoice the Purchase Order and see what happens:
This has created the following Value Entry
This Value Entry records the Cost Amount (Expected) being reversed and the Cost Amount (Actual) and Cost Posted to G/L are also populated. Therefore we get the following G/L Entries
As expected no expected cost postings have been created or reversed for this transaction.
Bonus – G/L Item Ledger Relation and Post Value to G/L SQL tables
An unexpected bonus of writing this post was the chance to geek out on some of the Dynamics NAV tables. Unlike Dynamics GP, I don’t have much of a grasp of the SQL tables in Dynamics NAV however while going through the various scenario’s I was curious about how a couple of things worked which encouraged me to dig a little deeper.
The first thing was how I was able to drill down on the G/L Entries from the Value Entries screen? This meant there must be a direct or indirect relationship between the tables.
After some digging I found the link was via the G_L – Item Ledger Relation table. Therefore writing the SQL query below enabled me to join the G/L Entries and Value Entries table to see all the details for Value Entry Number 455
The next thing I was curious about was what would happen if the Expected Cost Posting to G/L was switched from OFF to ON when there were lots of Purchase Receipts that hadn’t yet been invoiced?
I found the answer to this question lay in the two prompts you receive when you switch Expected Cost Posting to G/L from OFF to ON (or ON to OFF). Below are the two messages you get when toggling the setting
Dynamics NAV \ Business Central – Inventory Setup
As per the first message it seems when you switch the option Expected Cost Posting to G/L ON the system determines if the Actual Costs for the Purchase Receipt have been posted and if not a record is written for that Value Entry to the Post Value Entry to G_L SQL table. This has a link back to the Value Entry so the system knows to create the Expected Cost interim postings for this Value Entry.
To show this in action, I switched the Expected Cost Posting to G/L option OFF and queried the SQL table:
SQL Query on Post Value Entry to GL Table
As per the image above the SQL table is currently blank.
I then created
a Purchase Order and received it as per below:
Dynamics NAV \ Business Central – Purchase Order
After posting this I queried the Post Value Entry to G/L SQL table again to see if any new rows had been added and the table was still blank
SQL Query on Post Value Entry to GL Table
I then checked the Value Entry for my receipt and as per the screen shot below the Cost Amount (Expected) is populated but the Expected Cost Posted to G/L is blank. As this is only the Purchase Receipt the Cost Posted to G/L is also zero.
Dynamics NAV \ Business Central – Value Entries
I then went back to Inventory Setup and switched Expected Cost Posting to G/L back ON and clicked YES to the prompt and now when I check the Post Value Entry to G/L table its populated as per below
SQL Query on Post Value Entry to GL Table
After toggling the Expected Cost Posting to G/L option to ON the system has determined that this Value Entry has no G/L Entries for the Expected Costs and has inserted a record into the Post Value Entry to G_L table with a direct link back to the Value Entry that was created when I posted my receipt.
Now if I run the Post Inventory Cost to G/L batch job as instructed in the second message G/L entries are created for the purchase receipt, the SQL table is cleared, and the Value Entry is updated. See below:
The report output
of the “Post Inventory Cost to G/L” shows entries have been created:
Dynamics NAV \ Business Central – Post Inventory Cost to G/L
Below are the expected cost General Ledger entries created to the interim accounts. (in my previous example these were created immediately because I had Post Expected Costs to G/L switched ON)
Dynamics NAV \ Business Central – General Ledger Entries
And finally the Expected Cost Posted to G/L field on the Value Entry has been updated to show the General Ledger entries have been created and posted.
Dynamics NAV \ Business Central – Value Entries
If I now check the Post Value Entry to G_L table in SQL I can see its been cleared.
Incidentally if I were to switch OFF Expected Cost Posting to G/L before running the Post Inventory Cost to G/L batch job the SQL row is removed from the Post Value Entry to G_L table.
Conclusion
In conclusion I find the way Dynamics GP deals with expected costs to be a much more conventional and simple approach however there’s no doubting that Dynamics NAV \ Business Central gives more flexibility.
Although I don’t know much about the inner workings of Dynamics NAV \ Business Central it also seems to me that G/L Entries are created based on the Value Entries.
In another post I hope to look at how Expected Costs work with Sales Shipments and Sales Invoices.
All ERP systems aim to make data entry simple, fast and accurate. One way to achieve this is to default as much data as possible when the user is entering transactions, including the General Ledger distributions. In this post I aim to show how Dynamics NAV \ Business Central defaults the General Ledger codes when entering a Sales Invoice using inventory Items. Also, as I come from a Dynamics GP background, I’ll start off by providing a quick overview of how Dynamics GP achieves this, to offer a comparison between the two Dynamics systems.
The Dynamics GP way
In Dynamics
GP you enter default General Ledger codes on entities like customers, vendors,
items, fixed assets and then the “catch all” which is the Posting Accounts Setup window.
Once this has been configured the General Ledger codes default automatically onto the transaction. For example, when creating a Sales Invoice for an inventory item usually the control account would default from the customer card and the revenue code would default from the inventory item (you can change this but usually it would be setup this way). At this point the user can potentially edit and change the General Ledger codes on the transaction prior to posting thus overriding the system defaults. Being able to edit the General Ledger codes inside the transaction gives the user more flexibility however it can also introduce mistakes or errors. An example would be someone changing the control account, which would likely cause a reconciliation issue at month end.
Dynamics GP – Default SOP Distributions can be edited as per above
The Dynamics NAV \ Business Central way
From a Dynamics GP perspective things change quite dramatically when you look at how Dynamics NAV \ Business Central defaults the General Ledger codes. Instead of assigning specific General Ledger codes on customers, vendors, items, fixed assets, you assign Posting Groups to each of these entities. It’s the posting groups that have the General Ledger codes assigned and based on the combination of the posting groups used, general ledger postings are automatically performed when the transaction is posted. This means unlike Dynamics GP you can’t edit or change the default General Ledger codes prior to posting which gives less flexibility but there’s also less chance of mistakes being made.
So how do Dynamics NAV \ Business Central posting groups work?
There are two main types of posting groups – Specific and General.
Specific posting groups are used to default the control accounts. For example, I’ve assigned the specific Customer Posting Group “DOMESTIC” to the customer below:
Business Central – Customer Card
If we open the Customer Posting Group window and look at the setup, we can see when I post a transaction for this customer the General Ledger code 40400 will be used for the receivables control account.
Business Central – Customer Posting Groups
Moving on
to the General Posting Groups things
become a little more complex.
General
posting groups can be split into two further groups – Business and Product. You
assign “Business” posting groups to customers and vendors and “Product”
postings groups to Items.
The
combination of the General Business
Posting group from the customer and the General
Product Posting Group from the item determines the General Ledger codes
that will be used. This is something that is best explained via an image, so
I’ve included a screen shot below of the General
Posting Setup window from my demo version of Business Central.
Business Central – General Posting Setup
As you can see the posting groups form a matrix and the combination of “Business” (labelled Gen. Bus. Posting Group in the window) and “Product” (labelled Gen. Prod. Posting Group in the window) determines the General Ledger codes used when you post a transaction.
Therefore,
based on the General Posting Setup
above, if a customer has been assigned a Gen.
Bus Posting Group of DOMESTIC as per below:
Business Central – Customer Card
And the
item they are buying has been assigned a Gen.
Prod Posting Group of RETAIL as per below:
Business Central – Item Card
Then based on the General Posting Setup matrix defined in the General Posting Setup window the General Ledger sales account that will be used when the transaction is posted is 10200.
Defaulting the VAT Codes – VAT Posting Groups
A similar concept
is used when Business Central is determining the VAT percentage and VAT General
Ledger codes to be used. The matrix is defined in the VAT Posting Setup window as per below:
Business Central – VAT Posting Setup
So, in this
example if the VAT Bus. Posting Group
on the customer was “DOMESTIC” and the VAT
Prod. Posting Group used on the Item is “STANDARD” the VAT percentage used
would be 20 and the General Ledger code used would be 56100.
So there you have it. A very quick overview of how Dynamics NAV \ Business Central uses Posting Groups to create the General Ledger distributions when posting a Sales Invoice with inventory items.
Coming from a Dynamics GP background I initially found the exchange rate setup in Dynamics 365 Business Central a little confusing. In Dynamics GP you set an exchange rate, and then configure whether you wish the system to divide or multiple the foreign currency amount by that rate, to get the local currency amount, and that’s it.
However, in Dynamics 365 Business Central things are a little different. In this post I’ll walk through the key fields in the Currency Exchange Rates page to explain how you can set Exchange Rates in Dynamics 365 Business Central.
** This post only goes through setting Exchange Rates for Documents. It doesn’t touch on the Exchange Adjustment side of things.
Currency Setup
To access the “Currency Exchange Rate” page you must first go to the “Currencies” page, highlight the currency in question, and then drill down on the “Exchange Rate”. Alternatively from the “Currencies” page you can highlight the currency and click “Process > Exch. Rates” as per below.
This should then open the “Currency Exchange Rates” window which is shown below:
As I mentioned previously this window looks a little confusing to me? It appears there’s more than one place to enter a rate for the same currency? There’s also no option to specify if you wish to divide or multiply the currency at a given rate? (which is something I’m used to). So where do you enter the rate exactly?
Making sense of it all
I’ve found the key fields in this window are the “Exchange Rate Amount” and the “Relational Exch. Rate Amount”.
The “Exchange Rate Amount” is the rate to use for the “Currency Code” selected on the line, and the “Relational Exch. Rate Amount” relates to the rate to use for the “Relational Currency Code”. (generally its left blank so its the local currency – see further below for an example where this isn’t the case)
This can be further explained in the image below
Therefore using the Currency Exchange Rates window shown above, as we have 1.0 in the Relational Exch. Rate Amount (GBP) and 1.3 in the Exchange Rate Amount (EUR) this means 1.3 Euros is equal to 1 GBP. (The “Exchange Rate Amount” is acting as the exchange rate)
Hence entering a transaction for €200.00 would equate to £153.85 (i.e. 200 / 1.3 = 153.85)
I could also flip this by entering 1.0 in the “Exchange Rate Amount” and 0.76923 in the “Relational Exch. Rate Amount” as per below:
This now means the “Relational Exch. Rate Amount” is acting as the Exchange Rate.
In this example €1 (Exchange Rate Amount) is equal to £0.76923 (Relational Exch. Rate Amount). Therefore entering a transaction for €200.00 would also equate to £153.85 (i.e. 200 * 0.76923)
Both would work exactly the same its just a slightly different configuration.
** I would tend to use the divide method as the rates make more sense in this scenario.
Bonus – Adding a Relational Currency Code
I’ve never come across a situation where the “Relational Currency Code” is anything other than blank (i.e. the local currency) however now we know how the relationships work let’s test this out.
I’ve therefore changed the Currency Exchange Rates page for EUR to include USD as the Relational Currency Code as per below
And the USD rate is below:
Therefore if I were to raise a €200 Invoice the GBP will be calculated as follows:
Step 1 Euros to USD :- €200 / 1.3 = $153.8462
Step 2 USD to GBP :- $153.8462 / 1.39 = £110.68
To confirm I added an Invoice in Business Central and below is the statistics page confirming our calculations
Conclusion
Although confusing at first (at least to me) understanding how the Exchange Rates are picked up and used is fairly straight forward. Its also flexible offering various options for how to calculate exchange rates.
A few weeks ago I assisted with a General Ledger year end for a GP user with a very large number of journals and consequently a very large SQL database.
Usually a year end is a fairly straight forward routine, however as this user has such a large database, along with additional SQL bits and pieces for disaster recovery and bespoke reporting, it required a little more thought to ensure things went as smoothly as possible.
In this post I thought I’d share the steps I took to hopefully assist anyone else facing a similar situation in the future.
Here goes…..
1) Do the basics first.
By basics I mean following Microsoft’s general Year End prerequisites which can be found here.
I find the most important steps are ensuring you have a good backup and also ensuring the general ledger codes have the correct posting type as this can be a pain to correct post year end.
2) Ensure you have enough disk space for the SQL Data and SQL Log files.
This usually isn’t a consideration when running the Year End however given the size of the data its something that needs planning when dealing with GL tables in the 100’s of GBs.
Microsoft’s official guidance on disk space is included in the Year End documentation that I’ve linked to above however I’ve copied the section on disk space below:
During the year-end closing routine, all the records that will be moved are put in a temporary table before they are moved to the GL30000 table. You must have free disk space that is equal to the size of the GL20000 table to perform the routine.
To find the current size of the GL20000 you can use the sp_spaceused system stored procedure i.e.
However I’d also add that when dealing with large data volumes you also need to plan for extraordinary SQL transaction log growth as well.
For example the SQL transaction log grew to 240GB when I did this particular year end. This is because various statements including the INSERT statements into GL30000 are completed in one SQL transaction. Therefore no matter what the SQL recovery model is of your database, the log file is going to grow while the process completes. This is standard behaviour so SQL can roll the whole transaction back should any issue occur.
3) Remove any Database Mirroring or Availability Groups.
In my scenario the user has database mirroring for disaster recovery. I could have left this on however this would result in a lot of transaction log being sent over the wire while the Year End ran potentially doubling the length time it takes. I always see the amount of time something takes, as the size of the window of opportunity for something to go wrong. The quicker I could get the Year End process to go, the less chance I had of something going wrong. On the down side it does mean I had additional configuration to complete post year end, but I was fine with this.
4) Remove any custom indexes
If you have any additional custom indexes on GL20000 and GL30000 its best to remove them. Again its not a problem if you don’t remove them, however it can slow things down and also increase the amount of transaction log that SQL will produce. This is because if you are DELETEing and INSERTing data into tables the indexes also have to be updated. Therefore the less indexes you have the better. This requires additional space and also additional log to record the operations.
**Don’t remove any of the standard indexes though.
5) Stop the SQL Agent.
Maintenance tasks like reindex routines sometimes use the SQL agent to run. As I suspected the Year End will run for a very long time, I stopped the SQL agent to prevent this from happening. Its always best to check that critical operations won’t be affected by this though. If so just disable any SQL jobs that run maintenance on the Dynamics databases.
6) Temporarily revoke permissions for any Reporting Logins.
Ideally I’d like to set the database to single user mode while the Year End ran however as I wanted to monitor the process I didn’t want to restrict this too much. I therefore disable logins that I knew were used for reporting in case anyone sets off a large report in the middle of the year end.
7) Ensure SQL log growth on the database is set sensibly.
As I mentioned above the SQL transaction log is going to grow during this operation regardless of the recovery model. Therefore go to the properties of the SQL database and ensure the growth is set correctly, and its set in MB’s rather than a percent. I set it to grow 10GB increments for this particular year end process.
8) Use SQL monitoring scripts
I like to nosy under the hood when running most things but I especially want a sneak peak on the General Ledger Year End. My tool of choice for this is Adam Machanic’s awesome free monitoring tool sp_whoisative. This is a free script you can use to monitor activity in SQL. Using this I can pretty much see at what point the Year End was up to. i.e. INSERTing the data to GL30000 etc.
**If you didn’t know about this free script, and this is all you take away from this blog I’d be happy :). Its a really cool free tool you can use when troubleshooting all sorts of things in SQL i.e. blocking etc.
I also want to monitor my database and log growth as the process is running. If I monitor this I can predict when the log will run out of space and need to grow. I then check the disk space to ensure the growth will happen smoothly. To do this I use this script
SELECT DB_NAME() AS DbName,
name AS FileName,
size/128.0 AS CurrentSizeMB,
size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT)/128.0 AS FreeSpaceMB
FROM sys.database_files;
9) Be patient 🙂
One of the most important things is to be patient as this routine can last hours on a large data set. Its also important to never cancel the operation by manually closing GP down even if it says “Not Responding”. If it doubt you can run the sp_whoisactive stored procedure and check what’s happening on the server.
10) Once complete
After a huge sigh of relief I performed an additional backup and then started recreating the indexes, setting up the mirroring and restarting the SQL agent. I also shrank the SQL transaction log back down to a reasonable size.
Conclusion
I hope you find the information in this post useful. Although you may not need to follow all the points I outlined, I think the most important are disk space for the SQL transaction log, monitoring and lots of patience 🙂
Ever wondered why you have options to post to Vendors in a Sales Journal and Customers in a Purchase Journal? What do Documents and Journals have in common? How are Ledger entries and GL register created?
In this post I’ll explain more about Financial Journals and Documents and hopefully unlock some of their secrets along the way.
**Please note there are other journals such as Item Journals for inventory management which I wont cover in this post)
Journals
Journals are scattered throughout Dynamics 365 Business Central and can be used to record a whole manner of transactions. The most commonly used financial journals would be General Journals, Sales Journals, Purchase Journals, Cash Receipt Journals and Payment Journals.
Interestingly, under the hood all the journals are pretty much the same. All the journal pages are based on the Gen. Journal Line (81) table and all journals use the same Gen. Journal posting routine (codeunit) to create the relevant Ledger Entries and G/L Register.
As you can see from the image below although the General Journal and Sales Journal use different pages they are based on the same table.
The difference between the journals only really exists on their Pages and the actions and options available on those Pages.
For example the Payment Journal page has an action to run the “Suggested Payment Routine”, which is relevant to paying suppliers, and the other journals also have different actions. However, as they are all technically the same, nothing stops me creating a Payables Payment transaction in a Sales Journal and getting the correct Ledger Entries.
For instance, as you can see below although I’m in a Sales Journal I can still choose an Account Type of “Vendor”.
When you post the journal the relevant Ledger Entries and G/L Register are created and the journal lines are removed. (some exceptions exist like for recurring journals).
Therefore, taking all this into consideration, we could technically just use the “General Journal” page to record all of our financial transactions in Business Central, whether they be Sales or Purchase entries. We can also use one journal to record a whole host of different types of transaction. (as I show in this post)
Documents – Overview
When we refer to documents in Dynamics 365 Business Central we are referring to things like Sales Invoices and Purchase Invoices. (there are of course others such as Sales Orders, Sales Shipments, Purchase Orders, and Purchase Receipts)
They will have a Header and Lines, with the Header typically containing information on the Customer or Supplier and various dates, and the lines containing information or what you are selling or buying, for example items or GL codes.
When you post an Invoice, postings routines are ran to create the Ledger Entries and G/L Registers and new Posted Documents are created and the unposted document is removed. (you can archive Sales Orders using the archiving options in Setup)
For example if I were to Post a Sales Order via the “Ship and Invoice” option a Posted Sales Shipment and Posted Sales Invoice would be created along with financial Ledger Entries such as General Ledger and Customer Ledger Entries.
Documents – Posting
So what do Documents and Journals have in common? What makes them technically the same when it comes to the creation of the Ledger Entries and GL Registers?
As mentioned above when you post a Document the system runs posting routines to create the relevant ledger entries and it turns out these are the exact same posting routines that run when you are posting a journal (whether that be a General Journal, Payment Journal etc).
The posting routine responsible for this is “Codeunit 12, Gen. Jnl.-Post Line”. This is responsible for creating all the Financial Ledger Entries and G/L Register regardless of whether you are posting a journal or a document.
Therefore when you post a document its converted into journal lines, the lines then validated, and finally its posted in the same way as a journal.
Conclusion
The Gen. Journal Line table and Gen. Jnl.-Post Line codeunit do feel like the heart of Dynamics 365 Business Central. (certainly the financial heart)
I hope this article helped explain some of the concepts around journals that I found confusing when I started out with Business Central.
