Category Archives: General Ledger

Intercompany Sales Orders, Purchase Orders and Journals

Posted on by
Reply

As an appendix to my previous post about Intercompany Setup and Operation I thought I should complete the picture by describing some other stuff. This is about sending Intercompany Sales Orders, Purchase Orders and Intercompany General Journals

If you are using items or resources and supplying them from one company to another of your companies then this allows you to generate a sales order in one and automatically create the corresponding purchase in the other with no extra keying.

The process for Sales Orders and Purchase Orders is identical. I’ll talk about Sales Orders here but the two are interchangeable.

Assuming you’ve done the setup as described in the previous article, create a Sales Order as normal. The Customer in this case is the Customer you created for the Intercompany Partner you are transacting with.

I placed the order in the Cronus UK company. I am selling an ATHENS Desk to the Cronus EU Customer.

Instead of doing the usual and releasing the order, (1) go to Functions and (2) click on Send IC Sales Order. This will send the order to the Intercompany Outbox

and then on to the Intercompany Partner’s IC Inbox

The user at Cronus EU needs to accept the Inbox transaction (Functions/Accept). This moves the transaction to the Handled IC Inbox and, more importantly, creates a Purchase Order to match the Sales Order in the other company.

The sales and purchase orders can then be posted as normal as the stock is received and shipped and then invoiced.

Journals:

In the sending company prepare an Intercompany General Journal

Posting it will move it to the IC Outbox and send it to the IC Partners IC Inbox

As before, with the Sales Order, hit Function and then Accept. This opens the Complete IC Inbox Action popup. Fill this in and click OK.

Side note: You might find you need to set up a General Journal Template for IC General Journals as I’ve done here

Clicking OK Creates the Intercompany General Journal, which can then be posted.

And that’s it. A very quick romp through Intercompany Sales Orders and Journals. As before, set up is key.

What I am finding with clients with multiple companies is that an individual user will take responsibility for a single company. They may be very confident that they have performed the setup correctly but in reality, they have only done it in their company. This means they have only done half the job. Users at both ends of the transaction must cooperate for Intercompany to work properly.

Intercompany Setup and Operation

Posted on by

1         Introduction

The Intercompany functionality in Business Central allows for transactions to run smoothly between different companies on the same database without having to key documents on both ends of the transaction.

The user creates a sales invoice in company A (the Sending Company) and this – via various elements of set up – will create the equivalent purchase invoice in company B (the Receiving Company).

The guiding principle to be followed throughout is that for every element in company A, an equivalent element needs to exist in company B. I think of it like a plug and a socket. A three-pin plug will successfully connect to a three-pin socket but if you have two pin socket you will fail.

With that in mind let’s look at the elements involved in set up

2         Set up

2.1         Company Information

In the Company Information window, you will need to make sure that the IC Partner Code field is populated with a Code you will recognise when using it in other companies.

It’s a good idea to use the Display Name from your Companies table.

This will be the code you use when you set up this company as an Intercompany Partner in another company.

The IC Inbox can be set to Database. This allows for communication between companies in the same database. The other option is “File Location” which can be used for IC transactions between companies in different databases.

2.2         Customers and Vendors

For each Company you want to transact with you will need to set up a customer and/or a vendor depending on whether you will be “selling” or “buying” goods or services from your partners, or both.

Generally, in the Sending Company you will need a Customer who corresponds to the Receiving Company.

This example from CRONUS UK shows the customer representing CRONUS EU

In the Receiving Company a corresponding Vendor must be set up to represent the Sending Company. Here, in CRONUS EU you can see the vendor representing CRONUS UK

It is important to note that the IC Partner Code field in both is populated with the code you created in company information.

2.3        Intercompany Partners

The next step is to establish the link between the Sending and Receiving Companies. This is done in the Intercompany Partners table. The example is from CRONUS EU (as the Sending Company) for CRONUS UK (as the Receiving Company)

The fields are pretty self-explanatory, but I’ll go through them in order

  • Code: Intercompany Partner Code from the Receiving Company
  • Name: The name of the IC Partner
  • Currency Code: The Currency Code the transactions will be made in. If you leave this blank it will default to the Local Currency (LCY) set in the General ledger Setup. In this case it is EUR.
  • Inbox type: choice between email and Database. Database means that your IC partner is on the same NAV Database as you. 
  • Inbox Details: this will auto populate when the Code is filled in
  • Accept Transactions: This is for incoming transactions. When it is ticked an incoming Sales Invoice automatically creates a corresponding Purchase Invoice in the Receiving Company
  • Customer No.: The Customer No. created in the Sending Company to correspond to the Receiving Company
  • Receivables Account: the G/L Account No. of your Accounts Receivable (i.e. money you are owed by Customers)

In the Receiving Company the matching record looks like this.

  • Vendor No.: the Vendor No. created in the Receiving Company to correspond to the sending Company.
  • Payables Account: the G/L Account No. of your Accounts Payable (i.e. the money you owe to Vendors)

2.4         Intercompany Chart of Accounts

It’s a good idea to set this up whilst you’re doing everything else. It’s a chart of accounts agreed between all IC partners, so you can make it quite simple if you need to. The G/L Account No’s passed to the Receiving Company by the transaction from the Sending Company are mapped using the “Map-to G/L Acc. No.” field in the Receiving Company’s Intercompany Chart of Accounts.

However, there maybe occasions on which you don’t want a like-for-like mapping. Imagine you have sold services in one company to another. In the sending company this would be an Income GL whereas in the receiving company it would be an Expense. This is dealt with in the main Chart of accounts. Each account has a field called “Default IC Partner G/L Account”.

Imagine you are selling advertising services to your partner company. You would raise a Sales Invoice for GL Acct 10100 Income, Services but your partner will want the Purchase Invoice charged to an expense GL. In the example below I’ve mapped it to 30200 Advertising Expense. When the transaction is passed to the Partner it will appear with the Default Partner G/L Account 30200. No editing of the PI is required and no extra keying.

2.5.1        Set Up Dimensions and Intercompany Dimensions

Dimensions for Outgoing Transactions: In the sending company go to the Dimensions page. There needs to be mapping at both the Dimension level AND the Dimension Value level. You can see here that AREA and DEPARTMENT are mapped but BUSINESSGROUP and CUSTOMERGROUP is not.

Fortunately, there is an easy solution to this. In the Actions tab on the ribbon at the top of the page is a button: “Map to IC Dim. with Same Code”. Click this button and it will map at the Dimension and Dimension Value level by duplicating the entries in the Dimension Values and creating them as IC Dim Values. Obviously, you will need to ensure that these correspond with identical values in the Receiving company’s IC Dimensions

Intercompany Dimensions for Incoming Transactions: The same functions exist here but with one extra: “Copy From Dimensions”. This function creates IC Dimensions for the Dimensions already existing in the Receiving Company. Again, make sure that the Dimensions and Dimension Values have matches in the Sending Company.

3         Process

3.1         Sending Company

In the Sending Company a Sales Invoice is raised to the Customer corresponding to the Receiving Company (as set up in the Intercompany Partner table)

Once it has passed through the approvals process it can be posted.

This passes the invoice to the Intercompany Outbox and, providing the setup is all correct it it processed directly and will appear in the Sending Company in the Handled Intercompany Outbox Transactions

3.2         Receiving Company

In the Receiving Company, again assuming set up is correct, the transaction is passed via the Intercompany Inbox to the Handled Intercompany Inbox Transactions

If the Auto. Accept Transactions box is ticked on the Intercompany Partner then a PI will automatically be created with no further keying on the part of the users in the Receiving Company

This can now be posted and the IC transaction is complete.

4         Troubleshooting

I hope you can see that this is relatively simple to set up as long as you keep the pairing principle in mind at all times. In my experience pretty much all troubleshooting will boil down to this. When I was setting this up in my sandbox I fully expected to pass the first transaction through smoothly. But I’d forgotten to map the IC Chart of accounts AND one of the IC Dimensions in the receiving company.

Fortunately BC will pop up the usual gnomic error messages that should guide you to where the missing or mismatched pieces of the puzzle are.

Hope that’s helpful. Happy IC transacting!

Deferral templates and how they work..

Posted on by
Reply

Deferral templates and how they work…

I was talking to a client the other day, all full of confidence, and she asked me a question about Deferral Templates that caught me out.

What she wanted to know was how deferrals work in NAV/BC if the invoice is posted in the middle of the month. Is there an element of pro rata or does the deferred amount just get posted back into the beginning of the month on a date earlier than the original invoice. 

My mind went blank. It’s a few years since I’d set up a deferral template and, whilst I knew that I knew, I simply couldn’t remember. 

I immediately fessed up and told her I’d go and brush up and get back to her (never try to bluff. It’s always best to confess and come back when you’ve found out the answer). so I did and I thought I’d share the result.

I did this in NAV 2019 but it’s pretty much unchanged in BC.

Deferral will take the amount of an invoice or journal and spread it across the current and following periods according to a set of rules. The rules are set in a Deferral Template. The Template looks like this:

It’s good practice to name your template in such a way as you don’t get mixed up. This one is for deferral across six months in a straight line and is using a sales G/L for the Deferral Account.

Deferral %: This determines the amount of the invoice that will be deferred. Here we’re deferring all of it. But if you were to set this to 80, it would post 20% of the invoice value directly and the defer the rest over the following months

Calc. Method and Start Date: These two fields tell NAV how you want to calculate the deferral. Specifically:

Straight Line: Defers by dividing the amount to be deferred by the number of periods specified depending upon the Start Date. Here, we’re using Posting Date so it will make seven deferral postings. The first and last are pro rata and the middle five will be equal and posted on the first day of the period. The last, pro rata’d posting will also be dated at the start of the final period.

It will do a similar Pro rata calc if you choose End Of Period as the start date in that it will calculate the amount left to the end of the period, defer that first, then five equal payments followed by a final pro rata payment to make up the remaining sum. Whereas Beginning of period and Beginning of Next Period will do exactly what they say they will.

Equal Per Period: This is pretty self-explanatory. The amount to be deferred is split equally by period but again it pro rata’s if the posting date is in the middle of the period

Days Per Period: Will divide up the deferral by the number of days and allocate the amount according to the number of days in each accounting period. So if you are using calendar months it will calculate a different amount for February and March. Similarly if you use a 5-4-4 pattern to each quarter it will calculate a higher amount in the five week period.

No. of Periods: This is simply the number of periods over which you wish to calculate the deferral. Bear in mind that, as shown above, some combinations of Calc Method and Start Date will pro rata the first and last months of the deferral giving you an extra month.

Period Desc: This allows for you to provide a dynamic posting description for your deferral entries as seen in the G/L entries above. The text in the template here is “Sales Deferred for %4 %6”.

  • %4 returns the Month name of the period in which the entry is posted
  • %6 returns the fiscal year of the posting date

Other codes are

  • %1 = Day number
  • %2 = Week number
  • %5 = Accounting period name (from the account period table)

Year End: Or…How to Close the Year and Close Income Statement

Posted on by
6

The process of Closing the Income Statement in Navision or Business Central (or Year End as most of us normal mortals call it) creates a journal which debits all the income and credits all the expenses in the P&L and creates a balancing entry in the Balance Sheet, usually the GL for P&L Brought Forward.

Year End can be run as many times as you like which enables you to run it both at your actual Year End and after posting adjustments following an audit. The screenshots here are all taken from NAV 2019 but the commands, menus and principles are all the same in Business Central.

Go to “Accounting Periods” and highlight the last month of the financial year you wish to close

  1. Click “Close Year”

  2. This locks the month end dates so that they cannot be altered

  1. Now go to “General Journals” and create a new template as shown

  2. In Chart of Accounts click on “Close Income Statement” and fill in the pop up as shown
  3. In the “Document No” field fill in a doc no that will distinguish your year end postings from your other General Ledger postings.
  4. In the “Retained Earnings Acc” field, click the dropdown and chose the General Ledger (GL) code you want to save your retained earnings to (usually P&L Brought Fwd)
  5. Under “Posting Description” number the field so that you can distinguish between journals if you need to run it more than once
  6. Populate the “Dimensions” field with your default dimensions again, to allow for ease of navigation later. It’s important to remember to do this as failure to do so can lead to reporting problems down the line.
  7. Click “OK” and this will create the journal.
  8. Check the journal and post.

The journal has now been posted and is dated with the year end date prefixed with a C

This denotes a date – in the example shown – between 24:00 on 29/10/17 and 00:00 on 30/10/17 and can be used in filters

Steps 1 – 4 only need to be performed once each year. If you come to do a second year end (say after audit adjustments have been posted) then you can start at step 5.

Note: it’s useful to make a note of the last G/L Entry number so you can easily identify entries that have been posted back into the year after this process has been run.