Posted on

Incorporating GST [CU17] in NAV 2016

With Microsoft releasing GST -Indian localization for Dynamics NAV, Dynamics community is all excited and jumped to work on it and so did I. Of course, the first step was to upgrade the database with GST objects. This also lead me to think about what approach to follow such that it  be simple and  effective for all the different customers those looking for upgrading to GST. Some of the customers are in latest version of NAV, while there are customers who are also on older versions for which it is highly unlikely that Microsoft is going to release an update for GST.

Those who are starting with a fresh implementation, can directly download of CU 17 (build 48067) setup and install and are ready to go. For those who are way ahead in their implementation phase with an older version of NAV or have already gone Live, will have to go through an upgrade process with GST.

Upgrading GST means to merging the changes done to objects for GST to the existing objects. Changes to GST will impact most of the areas of the product for e.g. Masters, Business logic, Screens etc and in all these area there will also be custom codes that will make the merging a little challenging. The intention of this post was to cover how to approach merging of objects in Dynamics NAV. Below approaches can be taken up for upgrading to GST.

  • Merging all the custom code to GST changes
  • Merging all the GST changes to Custom implementation
  • Mix of approach 1 and 2

While deciding upon the approach, some of considerations that will influence decisions are the effort involved, availability of Resources, time required etc. For e.g. bringing all the customer changes to GST would mean to have different upgrade strategy to each customer, while bring the GST changes to different implementation will mean having a uniform approach for upgrading process. For making these decision points that needs to considered are

  • Type of Import option i.e. Merging feature supported by Dynamics NAV
  • Objects that have been impacted by GST changes

Type of Import options (Merging features available in Dynamics NAV)

While importing the objects to Dynamics NAV, following options are available:

  1. Create: The new object will be added to the database. This option is only valid if no such object already exists.
  2. Replace: The existing object will be replaced by the new object.
  3. Merge: Existing<-New: Only valid for tables. All fields in the existing table will remain and any additional fields from the new object will be added.
  4. Merge: New<-Existing: Only valid for tables. All fields in the new table will be imported and any additional fields in the existing table will be added to the new table.
  5. There are two more “Skip” and “Delete”

Steps involved in merging objects are –

Step 1: Import the GST objects to the existing Database, which will appear as a list in Import worksheet. All new tables will have “Create” option set in field “Action” as shown in below image –

Step 2: Patch also has changes to existing standard tables and in the Import worksheet they will appear with option “Replace” in field “Action”. All those standard tables that are not modified or customized can straight away be set to “Replace” as shown in below image

Step 3: Those standard Tables that are customized, set the “Action” field with option “Merge: Existing<-New”. For e.g. in case Vendor table is customized. Go to the Vendor table line in Import worksheet and in Action field, select option “Merge: Existing<-New” as shown in below image –

Merging using Action “Merge:Existing<-New”

While merging with option “Merge:Existing<-New”, system considered are Global variables, Local C/AL function including local variables and Table properties. Similarly from New table items considered are New fields, Field properties that are different and Trigger level code on field level including local variables.

Fields are merged based on the field number. The following scenarios are possible:

  1. The field is located in the old object, but not in the new. The field will remain as it was.
  2. The field is located in the new object, but not in the old. The field will be added.
  3. The field is located in both objects. If the properties are different in the new object, these new properties will be used.

Sample Walk-through of Vendor table Merge

Below are List of new fields added as part of GST changes to Vendor table.

Field No. Field Name
16600 GST Registration No.
16609 GST Vendor Type
16610 Associated Enterprises

Changes to Existing Field

Field No. Field Name
13717 State Code

‘State Code’ field has new C/AL included in Trigger as shown in below image –

Below are steps to import GST changes to Vendor Table –

Step 1: Create a .FOB of Table 23 GST changes and Import. On importing .FOB, an error may popup as shown in below image. This is due of code existing in Triggers of New fields as well as existing fields. To resolve the error, one of the approach would be to open the object in GST Build (48067) and comment all the C/AL code existing in Trigger related to GST changes and save and compile another .FOB

Step 2: Import .FOB with Option “Merge: Existing<-New”. Merging will create all the new fields and also the triggers in the new fields. It may not bring the C/AL trigger for field “State Code” and this will have to be manually merged.

Step 3: Uncomment all the GST changes and recompile the object.

Step 4: After the Merge, it is always better to do a text compare and check what is missing and change it manually.

Objects Impacted by GST changes

Below is list of new table that are part of GST patch

Type No. Name
Table 1531 Workflow Step Argument Archive
Table 16400 GST Registration Nos.
Table 16401 GST Accounting Period
Table 16402 GST Accounting Sub Period
Table 16403 GST Claim Setoff
Table 16404 GST Group
Table 16405 GST Component
Table 16406 GST Posting Setup
Table 16407 GST Configuration
Table 16408 GST Setup
Table 16411 HSN/SAC
Table 16412 Detailed GST Entry Buffer
Table 16418 GST Ledger Entry
Table 16419 Detailed GST Ledger Entry
Table 16420 GST Posting Buffer
Table 16421 GST Calculation Buffer
Table 16422 Adv. GST Calculation Buffer
Table 16423 GST Application Buffer
Table 16424 GST Liability Line
Table 16425 Posted GST Liability Line
Table 16426 e-Commerce Merchant Id
Table 16429 GST Recon. Mapping
Table 16430 GST Reconciliation Lines
Table 16431 Periodic GSTR-2A Data
Table 16432 Posted GST Reconciliation
Table 16433 GST Reconciliation
Table 16434 GST Credit Adjustment Journal
Table 16435 Invoice Adjustment Journal
Table 16436 GST Payment Buffer

A Sample list of existing standard Tables that are modified as part of GST –

Type No. Name
Table 3 Payment Terms
Table 4 Currency
Table 5 Finance Charge Terms
Table 6 Customer Price Group
Table 8 Language
Table 9 Country/Region
Table 13 Salesperson/Purchaser
Table 14 Location
Table 15 G/L Account
Table 17 G/L Entry
Table 18 Customer
Table 21 Cust. Ledger Entry
Table 23 Vendor
Table 25 Vendor Ledger Entry
Table 27 Item
Table 32 Item Ledger Entry
Table 36 Sales Header

There is no fixed way or right way of merging objects from new releases, intention is to provide an overview of what is possible so that upgrades become very smooth affair. This is very critical as GST in India has to be implemented to most of the customers and within a given time frame. I believe this post will bridge that gap.

Posted on

Do we know all about Default Dimensions? How to make a dimension Code Mandatory for all the the accounts in Chart of Accounts


Simple. Open Chart of Account, Select all the accounts there, Click on Account > Dimensions > Dimensions-Multiple. Choose the dimensions you want to make mandatory for the accounts and mention ‘Code mandatory’ in ‘Value Posting’ field. That’s it.That’s the most common answer you will have if you ask somebody how to make a dimension mandatory across all the accounts in Chart of Account. This common answer is the most common mistake functional consultants make during implementation. Yes, the common answer is not at all right answer.The above described method of making a dimension mandatory is only valid to make a dimension mandatory for a set of accounts only. Not for entire all the accounts of Chart of accounts.

You may argue – Why not? I am selecting all the accounts from Chart of accounts and making a dimension mandatory for them. And it works.

But think again. Think about a situation where you are creating a new account in Chart of Account.
The dimension you made mandatory for rest of the accounts will not be readily become mandatory for this new account.
So you have to make that dimension mandatory for this new account manually following the same method. If you forget, it can be a disaster waiting for you.

Rather the right method of making a dimension mandatory across all the accounts is much simpler and full proof (foolproof as well). Use the ‘Account type default Dim.’ feature. Its available in the Dimension window itself.

Open the Financial Management > General Ledger > Setup > Dimension.
Select The Dimension you want to mandatory across all accounts
Click Dimension > Account Type Default Dim.
Mention the table no. behind the Chart of Account (That’s Table no. 15)
And mention that it’s ‘Code mandatory’ in the ‘Value Posting’ field.
And this will ensure that the particular dimension is mandatory for entire set of records of te table no. 15 (nothing but the Chart of Account). And in future, any new accounts created in charts of accounts will be automatically included in that mandatory list.
This is the way you can make a dimension mandatory for an entire type of account. For example, the customer account, Vendor Account, Item Master etc.
Reblog this post [with Zemanta]
Posted on

Dimension, Shortcut Dimension, Global Dimension – Confused?

People often gets confused about the terms used to describe dimensions. – Dimension, Shortcut Dimension, Global Dimension – are they same or what? Why we need so many different dimensions?

To understand the concept you need to go back to history of Navision and also need to understand the basic concept of Dimension. Let me try to elaborate it.

Dimension: Dimensions are nothing but parameter for your analysis of data. In other words, they are additional information attached to your transactions and you can analyse / summarize your transactions on the basis of those parameters. Say, you want to analyse your fuel expenses on the basis of Car no. So you need to define a dimension called ‘Car’ and put all the car nos in the dimension value list.

Similarly, if you need to analyse telephone expenses on the basis of Telephone nos or travel expenses on the basis of employee nos then, you will define Telephone and Employee Dimensions and list down the dimension values for those dimensions. So at the end you can have a list of dimensions & their values as below:

— Car — 1001 — WB 300356

— 1002 — UP5005333

— 1003 — DEL678932

— Tel — 98444320 — Ashish Banerjee
— 87909098 — Snehanshu Mandal
— Emp — 1001 — Snehanshu Mandal
— 1002 — Vinay Iyer
— 1003 — Shridhar Varasala

You can define the dimension in Navision from ‘Financial Management > General Ledger > Setup > Dimensions > Dimension’. And then define the respective dimension values.

This way you can define any no of dimensions and attach any no of dimension values while entering any transaction in the system.

Now that’s was Dimension. So what is global dimension? Lets go back few years down to Navision history.

There was time when Navision didn’t have the facility to attach unlimited no of dimensions to transactions. Instead it had only 2 fixed dimensions with each transactions – Department & Project. And to attach these 2 dimension with each transactions, Navision had created these 2 fields in all the transaction tables (e.g in 81 – Gen. Journal Line, 36 – Sales Header, 37 – Sales Lines, 38 – Purchase Header, 39 – Purchase Header and so on). See the figure below.

 Now you can’t just keep on adding new fields in each transaction table to achieve unlimited no of dimension attachment feature. So Navision started storing dimension information attached to different transactions in 2 separate tables (Journal Line Dimension – for storing dimensions attached to all journal transactions, Document Dimension – for storing dimensions attached to all document type of transactions). So Navision came up with a different method of storing dimension values attached with transactions.
What happened to the 2 fields present in all transaction tables? To reuse these 2 fields, Navision came up with a concept called ‘Global Dimensions’. So 2 dimensions from your dimension master can be defined as Global Dimension and their values can directly be attached with any transaction (in those 2 fields present globally – They automatically take the caption of global dimension defined and displayed accordingly to users – using ‘CaptionClass’ property). Just because they are present in all the transaction tables, these dimensions make it easier to take out reporting based on these 2 dimension and helps you in easy data entry. Ideally they are the most commonly used dimensions across in Navision Company.
So global dimensions are nothing but ordinary dimensions. Only thing they are globally present in the system and helps in data entry (dimension attachment) and reporting on most commonly used dimensions in a company.
But if you are going to attach more than 2 global dimensions in transactions, then the very attachment of dimension process is slightly lengthy. I mean you need to click on the transaction line > click on button ‘Line’ > Dimensions > Select the dimension code and dimension value.
Can we make it little easier for data entry where more than 2 global dimensions you need to attach to transaction? Off course we can. Use the concept ‘Shortcut Dimensions’
Shortcut Dimensions: There can be 8 dimensions displayed directly on any tabular transaction form (Journal lines or Purchase Lines, Sales Lines etc) just to facilitate the data entry. Remember, these dimension will not be present directly in the table but only displayed in the form. They are shortcuts to 8 different dimensions. So that you don’t need to go for the lengthy dimension attachment process. That’s why the name came ‘Shortcut Dimension’. And the 2 global dimensions automatically gets assigned as first 2 shortcut dimensions. (Check out the General ledger setup).
See the screen above (General Journal) and you will find there are 8 dimensions present (coloured columns). These are 8 shortcut dimensions. First 2 are global dimensions (directly present in the Gen. Journal Line table – the transaction table used here) coloured green are automatically became first 2 shortcut dimensions. Rest 6 columns are just displayed in the form only to facilitate the data entry (not present in the Gen. Journal Line table). If you enter some values in those columns, system will insert the relevant dimension and dimension values in the journal line dimension table for the transaction. If you enter values in first 2 shortcut dimensions, they will be inserted in the global fields present in the current transaction tables as well as the journal line dimension table.
That’s the funda of Dimension, Global Dimension and Shortcut Dimension. Hope i am able to clear the idea a little bit. If you want to discuss it further, do send me your comments or simply fire a mail to me (snehanshu.mandal@gmail.com).
See you in next post.
Posted on

What is No. Series Relationship?

I got surprised when i discovered that so many people working in Navision for quite some time doesn’t understand No. series Relationship feature.
So what is No. Series Relationship?

Say you want to generate different invoice nos based on to where (geography) you are selling your service / material. So your domestic sales can have invoice nos which is different from invoice nos of export sales.

Now to implement the above feature, you need to use at least 2 no. series for invoice numbering? But in Sales & Receivables Setup’s Numbering tab, you have provision of mentioning only one no. series for Sales Invoice nos. how to resolve this?

You can go for some customisation or simply use the No. series relationship.

No. Series Relationship is a feature in Navision which helps you to group multiple no. series together and use it for one document no. Take an example of a sales Invoice. This feature will make 2 (or more) no. series related to each other and both can be used for the sales invoice nos.
Lets do it in Navision.
Create 2 no. series S-INV and S-INV EXP. First one for the domestic Sales & Second one for Export Sales.

Now relate the second no. series (S-INV EXP) with the first one with no. series relationship. To do that, select the seclect the S-INV in no. series window and click on the menu button series -> Relationships. Select the second no. series (P-INV EXP) in this window. Close it.
Your relationship between the 2 no. series is done. Now to use these no. series for sales invoice nos, you need assign it to sales & Receivables Setup.

Open Sales & Receivables Setup and go to the numbering tab. Choose the first no. series (P-INV) in the Invoice Nos.
Now you are ready to use both the no. series to generate the Sales Invoice nos. To test it –
Open the sales Invoice Window (Sales & Marketting -> Order Processing -> Invoices) and press F3 to create a new Sales Invoice. Don’t tab away from the no. field. Now click on the assist edit button (the 3 dot button) next to No. field and you will find system is suggesting both the no. series to you. Select any one series (depending on what type of Sales invoice – Domestic / Export you are creating) and a new no. document no will be generated.
So, you have the option of using 2 no. series (or more) for one single document no. You can extend this functionality further by automating the selection of no. series own the basis of USER ID.
Experiment on it. See you in next post.
Posted on

Do you want to keep a flow field editable on a form or in a table?

Let’s try it.

Say we will make ‘Balance (LCY)’ field in Customer card editable and test it. In Customer card, the textbox control is already editable and it is inheriting the ‘Editable = No’ property of the field from the customer tables.

Let’s make the ‘Balance (LCY)’ field editable in Customer table.

Select the field > Properties > Editable > Yes

Once this is done, the textbox displaying ‘Balance (LCY)’ in Customer card will become editable and you can put new amount in this field.

Right now, the calculated amount (coming from Detailed Cust. Ledger Entry) is shown as 73,810.00.

Let’s modify it to 80000.00 (an increase of 6,190.00)

So what will happen now. Your customer card is showing a value of 80000.00 whereas your detailed customer ledger entry table have entries of amount 73,810.00 only. is your data customer entries become inconsistent?

Not really. Navision never allows inconsistent data in flow fields. The system will simply will lookout some way to make the data consistent. It simply insert a new entry in ‘Detailed cust. ledger entry’ to adjust the inconsistent data.

Here, look at the detailed cust. ledger entry and you can see a new entry having an amount of 6,190.00. This new entry makes the total 80000.00 (now consistent)

Pretty dangerous! What do you think? To avoid this, you need to keep your flow field always ineditable.

But having seen the above incidence, can you think about any scenario, where this particular feature / rather drawback can be very useful?

Let me know if you find something interesting.

Posted on

Have you ever put a number in the G/L Journal Batch Name?

This time Mr. Parasuram Reddy is right :).

If you include a number in the journal batch name, the name will change by one number with every posting. Say your batch name is Snehanshu01. This will change by one number after every posting, to Snehanshu02, Snehanshu03, and so on.

In Navision it is possible to set up several journal batches under each journal template. That is, the same window can be used to display several different journals, each with its own name. This particular functionality is provided to facilitate / manage the batch names / registering each posting with unique Journal batch naming. This is particularly useful if every user of Navision is having his or her own journal.

Before Posting:

After Posting:
Posted on

Do you know what Happens if you assign same no. series to both unposted as well as posted document?

Let us simulate the same scenario.
I have created a new no. series named ‘Test’ with a starting document no. ‘TEXT0001’ and assigned it to both ‘Unposted Sales Invoice’ as well as the ‘Posted Sales Invoice’ in sales & Receivables Setup window.
Afterwards, we have created 2 unposted sales invoices with the document no ‘TEST0001’ and ‘TEST0002’ (generated by the no. series Test).
The first sales invoice has the external document no ‘ABC’ and the second one has ‘ABC1’ as external document no.
Now what will happen if I post these documents? One of the comments in this discussion says that it will create a document no after the last no created by the no. series. So the first posted document will be ‘TEST0003’? What do you think? Let me post the invoices.
To make it more interesting, I have posted the second document (‘TEST0002’) first and the first document (‘TEST001’) second. Here is the screen shots of the posted documents. You can identify the documents with their respective external document no.

This is the first document posted second identified by the external document no ‘ABC’.
This is the second document posted first identified by the external document no ‘ABC1’.
You got the answers?
In this scenario, the posted documents are taking the same document no assigned in their unposted state. And as no new no is generated by the no. series, the posting process does not update the ‘Last no used’ field of the no. series line.
Have you tried this ever? Try it and I believe you will also find application of this functionality in real life implementation scenario also.
Best of luck
Posted on

Do things differently

To start our discussion, let’s take a simple topic –

Few months back, in one of Orkut forum somebody had posted a problem as follows:

‘I have to pick out a digit from a code field. E.g. Code is ‘50123AD786′ n I have to select 7th character from this field How can this be done…’

You all know it’s simple and the common way to achieve this is:

Copystr([ur code variable],[position, say 7 for 7th position],[length, here for u its 1])

We have designed a new form here. Taken a new global variable called ‘Name’ of data type Text and inserted a text box to display the variable.

We also have written a single line code as per the above syntax to display the 7th character of the ‘Name’ in a message box.

Now, can we do it in not so common way?

Yes, we can if we know that a text string in Navision is nothing but an array of characters (literally). So here ‘Name’ variable is nothing but an array of its length and we can fetch out the 7th character of it by simply referring it as Name[7]. To validate it, let us change the code in the ‘OnPush’ trigger of the Button as below:

Message (FORMAT (Name [7]));

Why we needed a FORMAT command? Just because the message box can only display text not character.

Here I entered ‘Snehanshu Mandal’ in the text box and clicked on the button ‘Click me’. It’s displaying the 7th character of my name ‘s’.

Don’t you think it’s interesting?
Posted on

How can we make working on Navision a FUN?

Hi friends! How are you doing?

Last month, I completed 6 ½ years working in Navision and was stumped by one of my junior’s question – Don’t you get bored while working with Navision after so many years? Big question.

People are getting bored very fast nowadays. But why? You get bored when –

1. Work is monotonous
2. Work can be monotonous when you know everything and there is nothing new left to learn
3. ‘Hey, I am doing the same form designing, report designing and data port designing’

Besides the above points, you will find plenty of reasons of why people are getting bored in Navision.

I think the answer lies in the approach you have towards Navision. Whether we are trying to solve a problem too technically or we are having a holistic approach to solve a problem? Again to have a holistic approach towards a problem, you need to be little experienced on Navision or you have a fair idea about Navision functional things. So the whole issue is little paradoxical.
Whatever may be the reason, here we are not to discuss the problem. Rather we are here to try & make working on Navision a little more enjoyable. And to make it enjoyable, the best thing is to do something new in Navision every day. Mind it, you can do something new only when you do not know everything but you know something of Navision to start with.

I am not here to teach you something new in Navision rather together we will search new things in Navision. Every day, we will discuss about one topic and if you feel interested, you are welcome to suggest me the future topic or contribute a new discussion. You are welcome to send the problem you are having in your implementation and together we will try to evolve most reasonable solution of it. When so many brains will work on the problem, definitely we will be able to achieve most suitable solution for the problem
So let’s wish ourselves happy learning of Navision.