Following the general availability milestone for Microsoft Dynamics 365 Business Central, Dynamics ERP veterans and Microsoft MVPs AJ Ansari of InterDyn BMI, Rod O'Connor of BriWare Solutions, and Mark Polino of FastPath, joined MSDW editor Jason Gumpert to discuss the details and the reaction thus far . Reflecting on the end of NAV After the initial announcement of the new bran... read more Read the full text.

The Extension currently only contains the preliminary steps which enable a notification showing once you in a non-demo company have at least 50 CustLedger or 50 GLEntries or 50 Item Ledgers. Then you are prompted to allow it, and your choice is stored in a table. I guess the actual sharing is not made yet or is done directly from the DB ignoring AL. You can get the code using ForNAV Modern Object Explore, and please do. I'm sure you will also be surprised by the quality of the code :-)

Very nice, but I just tried installing it in a Business Central docker and it didn't work. It seems to be missing the ApplicationArea property. Please add #All to all page elements and actions.

I am creating a Report with two pages (difference No. but the same PIN) in the table (Account) . I differentiate the page with Reason exist code from table (Account 1), first page as Reason exist code = 13, Second page as Reason exist code= 5 but i set the property of the Report to Reason exist code=13. I want to get some fields from the Second page (Reason exist code = 5) and call it in my report. thanks

Hi Priggy, The payment journal is not a table in itself. The payment journal is just on of different pages for the general journal lines. And all general journal lines becomes general ledger entries when posted. Additionally all lines where the account type is customer get a corresponding (same entry no) customer ledger entry, where account type vendor creates a vendor ledger entry. Finally posting a general journal creates records in the G/L registry. As specifically to what is shown onthe posted payment journal details page, then I cannot say, as I don't know that page. Which version/localization are you using?

Hi all, I am sure that you are right now working on some build system for your Dynamics 365 Business Central App. May be you already solved how to get the vsix from container, how to unpack it to have alc.exe. How to run alc.exe which will "compile" the app from the sources (and you found out that there is /packagecachepath parameter in alc.exe). And now, you have put this into some scripts and you are running it from TFS build agent. Because alc.exe will put all output to standard output stream, you will see it in the TFS console, but if there is some error, it will fail just because alc.exe ends with return code <> 0. But you want to see the errors/warnings like if it another standard compile tool. No problem! You can use the TFS Logging command, which are GREAT tools to do something during the build by just outputting command to console. See https://github.com/Microsoft/vsts-tasks/blob/master/docs/authoring/commands.md . By "filtering" the output of ALC.exe you can easilly format the output as you wish. There is my function to format it: function Convert-ALCOutputToTFS { foreach ($_ in $input) { switch -regex ($_) { "^warning (\w{2}\d{4}):(.*('.*').*|.*)$" { if (Test-Path $Matches[3]) { Write-Host "##vso[task.logissue type=warning;sourcepath=$($Matches[3]);code=$($Matches[1]);]$($Matches[2])" } else { Write-Host "##vso[task.logissue type=warning;code=$($Matches[1]);]$($Matches[2])" } } "^(.*)\((\d+),(\d+)\): error (\w{2}\d{4}): (.*)$" #Objects\codeunit\Cod50130.NRMGetInfoCommand.al(62,30): error AL0118: The name '"Parent Object"' does not exist in the current context { Write-Host "##vso[task.logissue type=error;sourcepath=$($Matches[1]);linenumber=$($Matches[2]);columnnumber=$($Matches[3]);code=$($Matches[4]);]$($Matches[5])" } "^(.*)\((\d+),(\d+)\): warning (\w{2}\d{4}): (.*)$" #Prepared for unified warning format #Objects\codeunit\Cod50130.NRMGetInfoCommand.al(62,30): warning AL0118: The name '"Parent Object"' does not exist in the current context { Write-Host "##vso[task.logissue type=warning;sourcepath=$($Matches[1]);linenumber=$($Matches[2]);columnnumber=$($Matches[3]);code=$($Matches[4]);]$($Matches[5])" } default { Write-Host $_ } } } } You can use it like this: & $ALC --% /project:.\ /packagecachepath:.\.alpackages | Convert-ALCOutputToTFS And your build will have the errors and warnings like from other languages! Feel free to use other logging commands to e.g. attach files, log details, set variables, change build name, add tags to the build etc. Thanks the ALC.EXE I was able to create Branch policy in TFS allowing to merge Pull Request only when the result is successfully compiled. Whole compilation takes around 2-4 minutes, depending on how fast the container is started (when downloading image, it takes more).

Report from two pages with different No. but with the same PIN as field in the table.

In my last post I wrote about how global NAV implementations used to be done . About the two different implementation models either a Template Core or One-Database Core. It took a bit longer to get this next “chapter” ready. Especially since a lot of the information has only been made available over the last week. Business Central was released this Monday, April 2nd. Localization's as Extension's The game changer was the release of NAV 2018 / Business Central. Extensions first came available in NAV 2017 and where are both very difficult to do and had a lot of limitation’s. With NAV 2018 and Extension version 2 they are much less time-consuming to do. Developing them using the “new” AL language in Visual Studio Code a very good and modern experience. And most of the previous limitations are gone. More importantly Microsoft have started to ship their localization's as extensions, with Denmark being the first country. I wrote in the post, that Microsoft has been “suffering” just as much as everybody else,by the way they previously have been handling localization's. Their (long term) goal is to have one version to maintain, their World-Wide (W1) version. Localization's will then be Extensions applied to a W1 version, including languages and everything. The Danish localization for NAV 2018/Business Central still have a different base, but its C/AL source code is much closer to W1 than it was before. Translations of the C/AL objects are still made directly in the source code and there may also be more direct changes, which have not yet been converted to extensions. Just as many of the now obsolete local fields still are to be found in the database. Localized reports like invoice etc. are also still changed in the code and not in an Extension. Denmark did not have very complex changes to begin with. So that may be the reason that Microsoft started here. In Denmark the OIOUBL e-Invoicing was the change which had the most changes. In the December 2017 release of NAV 2018, it was still in the C/AL source code, but now from the April release this is also an Extension. But most other countries have a lot more localization changes. The US-sales tax functionality for example. That’s going to be a very big Extension. Personally, then I would hope that Microsoft, would put it into W1 to replace the “sales tax” functionality here. The US sales tax module is great, a bit complex to setup, but flexible enough to have a lot of usage outside of the US. Italy, Spain, India, Russia etc. all have very complex local legal requirements, with a lot of changes to support this in NAV. It is going to be a work in progress, such as it might be with many NAV implementations, that I think will take several releases. Not only Microsoft are going this way now. The same message comes from partners, who have developed the localizations for so-called 3rd party countries. The countries where Microsoft does not have their own localizations. I.e. the localizations done by Pacific Business Consulting (www.pcb.co.jp) for Japan, Hong Kong, China, Vietnam and Thailand are either already shipped close to be released as Extension’s. And I’m sure the message is the same from the other localization partners. The new world-wide version Previously the W1 version was not a version you could actually buy from Microsoft. It was “just” the foundation for the localizations and not supposed to be used by customers. Many global NAV implementations are already based on this version. But it was always a trade-off, because using a local version also meant saying no to a lot of features available in the local versions. In the Summer of 2018, Microsoft has announced the release of a new W1 version. The difference is going to be that more of the features, which today is available in some localizations, will become global functionality. That could make perfect sense for a lot of features, which can be used by many countries. I hope that Microsoft would consider moving the US sales tax, as I wrote above. Right now Microsoft has made no announcements in regards to what is going to be moved to the W1 version. What does all this mean for international NAV implementations? The short answer: Almost everything is getting much easier. Not just for global implementations, but for every NAV implementation. When localizations are Extensions, then it really doesn’t matter, if we have individual installations/databases per country, or just a world-wide version with tenants with localization extensions per country. In all countries with an official NAV localization (Microsoft or 3rd party), then localization issues become non-issues. You really only have to care about countries not supported. And here it’s very likely that their special requirement exists in one of the other countries. We will be able to focus on the implementation process and actual business requirements, rather than localization issues, which really adds no value to the companies. And what about Dynamics 365 Business Central? Business Central is really all everybody talks about these days. And for large international companies that’s also good news. Microsoft’s previous Dynamics 365 ERP offerings did not only have ridicules long names but was also divided into in Business and Enterprise editions. Business edition had a user max of 250 users and was marketed towards small and mid-size companies and based on NAV (only a subset of features). Dynamics AX got re-branded to Dynamics 365 for Operations, Enterprise Edition (available both on-premise and in the cloud). Now the two editions are gone, instead we have Dynamics 365 for Finance and Operations and Dynamics 365 Business Central. With BC down being a “full NAV”, and no longer a user maximum, then NAV again becomes a valid choice for international companies. Dynamics 365 Business Central is now a NAV platform hosted on Azure by Microsoft. A setup where the customer besides high-end hosting with a +99.9 up-time and build-in/ootb integration's to most of the Office 365/Dynamics 365 Ecosystem, also get a full NAV. If a customer doesn’t want to go full-in on the cloud, then NAV on-premise licenses is still available until the fall. I have written a bit more about licensing further down in this post. Only the web client in the cloud! In Business Central the web client has also been improved. The differences to the Windows client becomes less and less. Keyboard shortcuts and personalization has been added. Even if neither of these features are a near what they are in the Windows client, then it’s a start. I’m sure that most current NAV Windows client users will not find the web client good enough, if they use NAV more than 3-4 hours a day, depending on what they use it for of course. But that’s the topic for another blog post. The fact that the Windows client is not available, will for sure mean that a lot of existing companies is not going to jump up on BC/SaaS for a couple or more releases. But let’s see how fast the product team works. I’m quite optimistic myself. For new companies without previous versions of NAV, here I’m sure that most would opt for a cloud-based Dynamics 365 Business Central right away. Free objects in the cloud A further advantage of Business Central to an on-premise NAV, is that objects are free. Yes you heard right. In Navision and NAV we always have paid for the extra object we have used for customizations. A large international NAV project with a complex business model, count extra objects in the 1000’s. The extra cost just for objects is considerable, especially if you need to buy the same ranges to licenses in many countries. Definitely one of the old reasons for selecting the one-database core over the template core which is no longer there. Which model is the best today? The first question you need to ask is if your core business functionality can be done using Extensions or if your requirements can only be solved change the standard NAV code with C/AL and C/Side? If what you need can be done as Extensions, then all options are open. You may choose on-premise or cloud, one database or multiple installations. If you need to change the C/AL, then you may have to choose the on-premise solution, NAV now and BC after the fall 2018. If your company is large enough eventually your base-core functionality could be done as an “Embedded App”, in which case the cloud is still an option. The new template core model If all your core functionality and business requirements can be done as Extensions, then the template core in the cloud is obvious. Low cost to get started, you just need to add your Core Extensions. Each time you need a new country, then you start a new tenant. You install your Core Extensions, start setup, migrate data and train users. Microsoft takes care of infrastructure, hosting and monthly upgrades if in the cloud. No cloud - if you need C/AL That is not possible if C/AL changes are needed. The best option is then that you create a hybrid, where you keep the absolute minimum changes in C/AL and move everything else to Extensions. That would typical mean required events/hooks, stuff with DotNet (may later be possible in Extensions on-premise) in C/AL. Even if C/AL is still possible on-premise and no announcement in that direction has been made, then I would guess that Microsoft would drop it at one point after maximum 2-3 releases. By then I would also expect us to be able to do much more with VSCode and Extensions. Each time you have a new country, then you will need a new license, a new database and a new server. And the localized version. Then you need to merge your (hopefully small) C/AL core into the country version. If there are no remaining code changes between the localized version and the W1, then no more will be required if based on same build. More or less the same as today, just a lot easier. The new One Database Core Model If your all core customization's cannot be done as Extensions, then the one-database core is obvious. On-premise you should create a hybrid, for the same reasons as described above. When all localizations are available as Extensions, then it will require a multi-tenant setup based on the W1 “no-localization” version and as a minimum one tenant per country. On these country tenants, you would the install the Extensions from the official or 3rd. party localization package. Handling a One-Database Core is still not going to be trivial. Just as the One-Database Core model was never supported by Microsoft in Dynamics NAV, then I doubt that it’s going to be supported by Microsoft in Business Central. At least not for the first couple of years. That means there is no guarantee that the individual localization extensions may not be conflicting, even if they are not installed at the same time. Luckily the source code is also available for the Microsoft Extensions, so you may need to create your own versions of them. Embedded Global Core Apps As with the template core, if you have any C/AL changes, then the Cloud option is not possible. At least as the rule of thumb. Microsoft also has Dynamics 365 branded vertical solutions or Embedded Aps. This is a way partners to have their own vertical solutions hosted by Microsoft. It made for the ISV’s who sells the same solution to potentially a lot of customers. To be used for Embedded Core Apps, then it would require that the corporations either themselves sign-up to become a (non-selling) partner. Or that they work together with a partner to who manages it for them. Notice: I have at time of writing this post, not been able to get this option confirmed by Microsoft. But if had a large enough number of users to interest Microsoft, then I’m sure that there is a way. Many of these companies may “only” have a couple of thousand full users in NAV/BC. But if implemented as D365, then it could easily bring in a lot of their new Team Users. Same as PowerBI and PowerApp, plus a connected D365 Sales suddenly becomes a lot more interesting. 1000 full BC users could easily bring in 1000+ team users in such a large organization. Don’t think it’s going to be possible for a small company with 4-5 countries and just a few 100 users. Licensing When we talk on-premise/perpetual licensing, then nothing has changed yet. You still need a license for all the new objects you add to your solution. Even table and page extension objects need to be licensed. When we talk Template-Core, then as before you need a license per database on-premise (minimum with starter pack, eventually with extended pack), plus a license per concurrent users. In the cloud you pay for named users, either essential, premium or team. You may therefor need more licenses in the cloud. But in the cloud there is no database license and no object fees. The One-Database Core may still be a license cost saver, when we talk very large on-premise installations. In the cloud the license cost of a one-database core would be about the same. You pay for number of named users. The One-Database Core License Challenge Previously the two ways to get local functionality into a One-Database core was either to build yourself, or to try to implement the local objects and changes you needed. Whereas the copy-paste solution by copying the local objects sounded easy then was not that easy. Neither from a coding or licensing perspective. The only way i.e. to get a Danish localization to work in a US version, were to renumber all the objects and fields to the open number range (50000 to 99999) as all local features where in a locked country object number range, only available if you had a license with the same country code. Where it technically is (hopefully) not going to be too challenging to get a Microsoft localization extension from one country, to work in a different country (or W1) database. I guess that’s really Microsoft’s own goal here? Practically then it may not be as easy as it sounds. Unless Microsoft removes the current block from running the local objects from one country number range in a different country license. Right now, Microsoft also ships the source code to the localization extensions, to make it possible to change the local functionality. On less Microsoft comes up with a way to allow customers to add access to other country locations into their license, then it would still be required to the rename/renumber source and hope that the Extension again builds again. An alternative would be to have an individual license for each country tenant. So let’s hope that Microsoft will be looking into this. The Fall 2018 Release Currently no announcements have been made towards changing the availability of on-premise/perpetual licenses for Dynamics NAV. I wouldn’t be surprised if big changes will happen here, when we come to the Fall 2018. After the fall 2018 release NAV and Business Central will be the same system. Unless Microsoft makes a period with both, then all new licenses will be Dynamics 365 Business Central licenses, even on-premise (but that has not been Microsoft’s practice since NAV 2009). What that otherwise means in terms of pricing or licensing has still not announced. My own guess would be that it would mean a goodbye to Navision’s age old concurrent user principle. Even on-premise. They already have named users everywhere else, including the on-premise version of Dynamics 365 for Finance and Operations (the old Dynamics AX/Axapta). If they should have an incentive for customers to use more of the remaining Dynamics 365 ecosystem, then that would be included in the price. I would also hope that they will have the same object licensing on-premise. No extra cost for extra objects. Migrating existing customizations to Extensions will very often require more objects, than they did in C/AL. Not only because what better option to get clean-code, than when migrating to Extensions, and clean code requires more objects, especially codeunits. And if you have added 20 fields to a table, then they may not going all be part of the same extension. Good practice is always to make your extensions as small as practical, and then eventually have dependent extensions. But I have heard nothing about this so far, not even under NDA. That’s typically not the stuff they discuss with us MVP’s before releasing it, even if they are listen to our advises. Navision vs Axapta – Business Central or Finance and Operations? Before Microsoft came into the picture, before Navision Software and Damgaard merged, Navision and Axapta were two competitors, competing for basically the same markets. Since both became Microsoft products AX were positioned against the lower end of the SAP enterprise market. NAV were for companies up to a maximum of 250 users. Personally, I have been in projects where the companies were strongly under pressure to move from NAV to AX for years. And Microsoft did have a lot of good reasons for this. Not only did they need as many good references for AX as possible in the “enterprise segment”, but AX simply does have a lot more build-in “enterprise functionality” than NAV. That has not changed, except a lot of that functionality today is available for NAV from ISV’s, and more importantly Microsoft has (almost) solved their localization and upgrade issues. The same perfect choice With Dynamics 365 Business Central and Dynamics NAV 2018, then nobody should be afraid of implementing it globally in many different companies. It’s still the same perfect choice for the growing successful companies as Navision was 30 years ago. Microsoft and BC are not quite there yet for all companies. That doesn’t mean you should wait, no matter if you are an existing global NAV customer, or you just consider using NAV in all your companies. In my next post about global NAV implementations, I will come with some personal tips and tricks about how to get started or prepare your NAV project for going international. And about some of the many different questions you have to consider first. Plus a little about how to organize your project teams.

Thanks Erik. Actually I am trying to create a new field(Name) in G\L entry.If i am posting a payment Journal, that field(Name field) will get update depends on my Payment Journal 'Account type'(Customer or Vendor). I am using Microsoft Dynamics Nav 2009 R2.(Nav version 6.0 R2) Guide me. Thanks, Priggy.

I wrote a blog post about that a couple of years ago, look there , or have if you tried to use search. There are already 100's of post answering the same question.

It is impossible to tell you how to do the development here - you have to either study the development material, watch the online partner training or participate in a training course. You are referring to a form (Payment Journal) and you should really talk about a table called Gen. Journal Line, know about Transferfields and codeunit 11 and 12. It is very important that you understand the most basic way og modifying the standard system - if not you will end up doing the same code a multiple no. of times. Regards Palle

Thank you so much for your valuable advice Palle.

I do agree with you most of your saying but what about all of the drawbacks ?? Just to mention a few: 1) Advanced filtering does not exist? 2) No way of doing a backup/restore - (so having testdatabases etc is impossible) 3) Missing the shortcut-keys in many of the places 4) Total lack of object overview of the objects 5) The missing source code of extensions The list is way longer than this. Don't be totally blind to all the negative sides. Yes there at loads of cool stuff application wise, development snippets, vscode as editor.. Becoming a Dyn/NAV developer is going to be complicated. All the gui-development-help with eg. shift F4 is gone. Finding properties, controls etc are going to be a total nightmare and the learning curve is not good. The future will end op in "core developers" not knowing anything about accounting, because of the complexity of devleopment - and that is scarying... Palle A

Add a field to Gen. Journal Line table and add the same field to G/L entry table. In Codeunit 12 search for GLentry.init, right below this line add the code glentry. := , this will post to the G/L entry.

Hi Palle, As I said the web client is not good enough for existing power users. Some of the most used shortcuts are missing. But as I wrote, I'm working about a blog post specifically about the web client. The backup/restore issue when we talk cloud only, it's kind-of like when they removed the FBK option in NAV 2013 R2, when they introduced tenants. And I'm sure that they are working very hard to solve this issue. As to the source code of Extensions, then all the source code for Microsoft's Extensions is on the DVD and on Docker. If you refer to source code for Extensions, that you buy from 3rd party ISV's, then that's more or less business as usual. I have always tried to go way around any add-ons which contained locked objects. And I will continue to do. It's important for the way we work with NAV. As to overview over the objects (I guess you mean in the extensions), then I've already seen a post or two on that. Think that peikba has one on his blog. I think we will have less need for NAV developers in the future. At least if customers are starting to use Extensions from AppSource. So I expect that there generally will be less customization's (both if we talk C/AL and AL). But as you and I know, then it does take a bit longer to add a field to a page and a table, using AL, than it takes in C/SIDE. And while I'm sure that we will also have the more "geeky" NAV developers, then we see more consultants, who can do "prototypes" with the Designer, tweak it up a bit on VSCode to get the customers acceptance, before handing it over to a hard-core developer to make all ends meet. Knowledge about accounting and how businesses work is imperative for being a good all round NAV consultant and developer. And still it is not news that some partners hire developers who didn't know accounting or business. I have met lots of NAV developers who really don't know what debit and credit is. Some of them learn, most of them moves on to other more exiting jobs outside of the NAV world. I'm not scared. Neither personally, nor on behalf of Navision. I'm rather optimistic in fact. Which is not the same as I find that everything in this release is great, nor that I would recommend anyone to upgrade/move to Business Central. But neither is Microsoft. Right now there is no upgrade option from NAV to BC. Don't think we will know it all until the fall release. /Erik

I saw some of the extensions after NAV 2018 came out. I hope what we saw on the DVD was not the actual objects. They almost looked like they just copied the code from C/AL and Txt2AL. You can also get the code directly from the extension. Just unzip it with WinRar.

In this week's Microsoft Dynamics partner news roundup: TRIMIT and Awara IT partner to automate and optimize business for companies with Microsoft Dynamics Insight Works welcomes Sri Lanka's Amicis Holdings to partner program family Velosio introduces partner enablement programs for Microsoft Dynamics 365 Business Central Queue Associates announces new sales director TRIMIT and Awara IT partner to automate and optimize business for companies with Microsoft Dynamics... Read the full text.

I am so Sorry but still the Question is not clear to me. Can you please clarify it a level more?

WHAT? I'm right with RWN there. Try to read your question your self. It makes no sense what so ever...

Thank you mohana Yoiur link worked out for me. Warm Regards, Bharath K