Hi Imran & Erik, i've found the cause. It's because the payment term table have a record that isn't supposed to be there. I don't know how the customer insert them in the first place, but it's all sorted out now. Thank you for your help.
↧
Forum Post: RE: NAV 2009 R2 - Error while restoring database
↧
Forum Post: NAV 2018 - Decimal separator problem in native report
Hi everyone, I need help & insight on this case. A friend of mine from different company asked me why the report 1302 (proforma invoice) having no decimal separator. For example 1000000.00 Then i created a cronus demo database in my desktop and test the report default from cronus, it shows decimal separator like 1,000,000.00 Then I checked his object designer and find out that he has unmodified report which hasn't been modified, still original from development. However when i imported r1302 from his object designer to my cronus database and ran it, it shows no decimal separator. What's the cause of this ? How can two native report different in term of decimal separator ? I'm not a consultant and not very good at modern dynamics nav, however if you can give me insight and suggest a solution on this case i really appreciate it.
↧
↧
Forum Post: NAV 2018 - Release & Reopen Sales order authority assignment
Hi everyone, Is is possible to assign permission to specific user for release/reopen sales order ? Any help and insight are appreciated.
↧
Forum Post: RE: Backup Business Central (Cloud) Data
Thank so much [quote user="Erik P. Ernst"][/quote] I suggest that you find a real partner, they would know. You are right
↧
Forum Post: RE: Backup Business Central (Cloud) Data
Thanks Mohana
↧
↧
Forum Post: RE: Dynamics NAV Certification
Thanks for the info,hope MSFT will bring the exam soon.
↧
Forum Post: RE: Dynamics NAV Certification
I don't think the exams for NAV since 2015 and the Focus now on another app like CRM and for Finance and Operation and they will retire more exams in Jun 2019.
↧
Forum Post: Group by Month in Report
I have tried in many ways but i couldn't get exact output how to group a records by months in Report kindly help me guys thanks in advance
↧
Forum Post: RE: Group by Month in Report
You really need to supply more information than that is you wish to get a answer you can use to something. What version of NAV are you using? What kind of report are you using? What data do you have?
↧
↧
Blog Post: Microsoft Dynamics 365 Business Central – 2019 Spring Release is released!
You might remember my blog from yesterday … . I didn’t know when it would be released. Well, it wasn’t available yesterday, but today, I got the comment on my blog from Daniel Göhler that it was available – so I refreshed my container again, and indeed! I used this Docker image: mcr.microsoft.com/businesscentral/onprem:be (I assume you can use your own country-tag, or none for W1) But I also got these links from … : … Daniel Göhler: https://mbs.microsoft.com/partnersource/global/support/bconpremdownload ... Steven Renders: https://www.microsoft.com/en-US/download/details.aspx?id=58106 I just got this release schedule from my colleague – seems they are somewhat early ;-): https://dynamics.microsoft.com/en-us/business-applications/release/#release-calendar Enough resources I guess. Go grab your copy and upgrade!
↧
Forum Post: RE: NAV 2018 - Release & Reopen Sales order authority assignment
You will have to make a customization. In the user setup table create a boolean field and then based off the this field you can control the release and reopen of Sales order.
↧
Forum Post: RE: NAV 2018 - Decimal separator problem in native report
If nothing changes in the system except the report object - then the difference must be somewhere in the object. Are these objects from the same / different versions of NAV? Do you have access to the report designer? If you do, you can check formatting properties in the Visual Studio or SQL Server Report Builder. Standard version of the report 1302 seems to display numbers without any formatting: Is this property the same or different in two verions?
↧
Forum Post: RE: NAV 2018 - Release & Reopen Sales order authority assignment
That's a kind of a question where the answer is "yes and no". No - because there is no user role you can directly assign to allow releasing orders. But on the other hand - "yes", because it's possible to do it without customizing the code. Option one - manage access to the codeunit 414 which performs release / reopen action. You can create your own role allowing execution of this particular codeunit. The downside of it is that you can't use the BASIC role as the actual basis for your setup, since it allows to run all codeunits, and restricts access based on tables. This way, you'll have to create your own basic role that will give execution permission to all necessary codeunits, except 414, and 414 will reside in its own separate role. Option two - probably, a simpler one: create a user profile with customized ribbon for pages 42 and 9305 - just remove the buttons from the ribbon. Here, you can read how to edit a user profile: https://docs.microsoft.com/en-us/dynamics-nav-app/admin-configure-user-interface
↧
↧
Blog Post: Why C/Side will last another decade… at least…
The move by Microsoft from C/Side to Visual Studio Code is a bit like Brexit. At first everybody thinks it is a great idea, until they realise the consequences. And then there is no way back. Why? Please let me explain… With C/Side we have issues, everybody knows that and these issues have to be solved. Issues like integration with source code management and other issues like… well… hmmmm. Visual Studio Code is the new kid on the block and it’s cool, it’s the most popular source code editor of this moment. However when you combine it with AL code it’s not always an improvement. Microsoft claims partners have been demanding a more modern coding experience but let’s compare it to PowerBI. Does PowerBI have source code management? PowerBI has a native designer just like C/Side and PowerBI is very popular. The reason C/Side is going away has nothing to do with partners demanding anything. It has become very hard to maintain C/Side and it’s preventing Microsoft from moving to the cloud. It’s impossible to compete with the Microsoft Marketing machine. No matter how much feedback the product team is getting they make their own decisions. I spend my time 50% in C/Side and 50% in Visual Studio Code. I know all the VSCode shortcuts, snippets etc. but going back to C/Side just makes me happy every time I switch. Programming anything in Business Central involves mostly defining Meta Data. As programmers we write surprisingly little code. Visual Studio Code is horrible at defining Meta Data. Most other programming languages use templates for this. Have you actually tried to create a report in Visual Studio Code? OMG… please don’t. It seems like the Business Central teams are not yet at a point where we can easily juggle with Meta Data. We cannot yet create a listpage & cardpage for a table which would be an easy example of this. Extensions In our community Visual Studio Code is synonym for Extensions. This is just wrong. With relatively little effort Microsoft could have made Extensions work in C/Side. It would have meant adding Table Extensions and Page Extensions as object type. Not much more than that. Many partners, actually the vast majority, have issues moving to Extensions. Not because the concept is wrong, but because the base code is not designed to be extended. The Business Central code base is from the late 1980’s and is not object oriented in any way. Not even close. The solution that Microsoft is now proposing is that we can make raw source code modifications in Visual Studio Code. This is horrible! Visual Studio Code is not optimised for this. Not even closely. C/Side is. It looks like we are getting into a worst of all options kind of scenario where nobody wins. At NAVTechDays Microsoft announced that they would rewrite the Business Central code and break it up into extensions. I have not seen any progress on this, not any session at Directions ASIA, no blogs, nothing. Complete silence. Get comfortable on the Spring release It looks like the Spring release of Business Central will be the golden release to get comfortable on. Just like NAV 2009R2 was. We can use the best of both worlds. C/Side for the majority of the work and Visual Studio Code where possible and where it adds value like using JavaScript Add-In’s or making UI changes to the core UI. As a community we need to make Microsoft understand that this release must be maintained for at least five years, or possibly ten until Business Central is completely rewritten and object oriented. Until then, for most partners it’s simply not worth the effort. They will burn money and resources getting only disappointing results.
↧
Forum Post: Business central API: How to get the general ledger entries of a posted sale invoice ?
Hello, How can we get the general ledger entries of a posted sale invoice via the API of business central ? We tried with the following request ..../api.businesscentral.dynamics.com/v1.0/api/beta/companies(id)/generalLedgerEntries?$top=100&$filter=(documentNumber eq '1910022') and (documentType eq 'Invoice') but FILTER on documentNumber is not 100% correct because i assume documentNumber 1910022 could concern also a posted purchase invoice or even other thing. Thank in advance for your help. Regards. Guy
↧
Forum Post: G/L budget table Blocked Field
Hi Expert, In G/L Budget Name (table 95) having field Blocked, What is the used of blocked field. As I have searched at code level I didn't found any logic behind the standard field Blocked. If anyone knows? Regards, Shweta.
↧
Forum Post: RE: Business central API: How to get the general ledger entries of a posted sale invoice ?
Hi, You can, for example, refer to the Navigate function to see how this kind of filtering is handled in standard NAV / BC. If you open a posted invoice click Navigate and drill down to G/L entries, you can see that there are two filter applied on the record: Document No. and Posting Date. In fact, these are the only two parameters that are passed to the Navigate page. Usual practice assumes that numbers to posted documents should be assigned in a way that rules out intersections. Different document types should always have different numbers. But, if you have doubts in the correctness of filtering, you can set additional filter on the "Source Code" field - for sales it will be 'SALES'.
↧
↧
Blog Post: “In the future, on-premises will follow the cloud rules”
My intentional plan was to share a small blog about the Fall release of Business Central . Well – it turned out I had more to say than I imagined beforehand ;-). I would like to focus on one point, where I’m not going to make myself really popular, as I notice quite a lot that people kind of disagree with me quite a lot :-). But that’s ok .. I don’t mind different opinions, as long I’m allowed to express mine ;-). Please take everything that follows as my opinion, and my opinion only. Fall 2019 release In Fall (probably October), we’ll have yet another major release of our beloved product Business Central. And Microsoft already shared their focus points in this slide: Two points are totally not a surprise, I guess, as I announced that already : The fall release will not contain C/SIDE or C/AL ! The fall release will not contain the Windows Client ! What I would like to do, is actually focus on the last bit. Extensions ! There is going to be a strong focus for you to be able to do what you want, completely with Extensions. And even more, that last sentence: “In the future, on-premises will follow the cloud rules” What does that mean? I understand this sentence can be understood in a lot of ways. And I wasn’t at Directions ASIA , so I wasn’t able to get the context of this – so I’m just going to make my own assumptions (disclaimer ;-)). Just look at this twitter-thread from AJ and this one from Tobias . It kind of expresses some things that I will explain going forward – but at least, might give you an idea on how other people think about it as well. Basically, I have a few assumptions that I’m going to assume is going to be the right assumptions. Assumptions² if you will .. : Microsoft wants all of us in the cloud (I think that’s an easy one) With Extensions only, not customizations. In order to do that, it needs to bring us as close as possible to be able to be as flexible as possible to do what we do today – with Extensions. I think that’s a very fair focus. Therefor – we should apply the same paradigms onprem, as we would for being “cloud ready”. Customizations are not “cloud ready”. So at some point (not in Fall), customizations are NOT going to be possible anymore – even on premise. Again, just my assumptions. Customizations We all like customizations, right? Well, to be honest, no. Some say it was the one thing that made NAV what it is today. Others say it implemented simplicity. I say: the simplicity to change the base app has kind of poisoned us. Sure, it’s easy on short term. But why-o-why are so many customers still running on old versions? In anything I do with C/AL, NAV, … , I have had a strong focus of “upgradability”. Implementing with Hooks. Adopting Events. Adopting Extensions V1 .. all just to be able to upgrade. That’s my history. And a lot of my contributions were focused on that as well. Just take these blogposts into account: How I upgraded to Microsoft Dynamics NAV 2017 The Hooks Pattern Hooks or events? Merge version lists To Hybrid or Not To Hybrid I can tell you one thing: customizations do not facilitate upgrades in any decent way . From the moment you start customizing, you start creating upgrade-challenges. That’s the simple truth. One might not care, but we’re talking “cloud ready” here … and software with upgrade-challenges is all but “cloud ready”. For a long time, Extensions has been the focus to solve that challenge. The feedback from some in the market though is a bit hesitant: “I can’t do everything with extensions” “I don’t have the events I need” “I can’t add document types” “I can’t …” And you are all right, most probably. But in many (I won’t say all) occasions, those people make one crucial mistake. You try to do what you have been doing. That’s not how evolution works. With (r)evolution comes change. With change comes adaptability. You need to adapt. You need to change. And in terms of products, software (and yes, also customer customizations), that means: refactoring and reimplementation . Don’t act like the software you wrote 10 years ago, is still valid today. Cars are re-invented ever so long – but software needs to live forever? I don’t think so… Our focus The focus in our company has been extensions for a long time. For sure, we are not able to do that for everything – and for sure, we are still doing customizations. More than I want to admit. Simply by the fact: our latest product release is still C/AL today. But … there is a focus: No hybrid . What is hybrid? Why not? Well, I blogged about that here . So it’s either full C/AL or full AL. When we need to use our product today, it’s full C/AL. If not, it’s full AL. Luckily, we have quite some cases we can go the AL directions ;-). We are rebuilding (from scratch) our product this year. No migration , but a complete rewrite. Because in my opinion, it’s the only thing that really makes sense for us. When it’s AL, it’s Extensions only . So funky weird hybrid, no customized BaseApp (which wouldn’t be possible today anyway). When we go AL (for product or customers), we only apply cloud-ready architecture. That’s our focus today .. so not in the future, but today. Our product is the only reason why we implement C/AL today. I’m not ashamed it not being converted yet. It’s a big-ass product, and we want to take the opportunity to rethink everything carefully. “Hurry” never ended up in decent software anyway ;-)). When the product is finished, the only reason we will be on C/AL in our company would be legacy customers, while all new customers will be full AL. Let’s dive in the above points a little bit more. Rebuilding, no migration Well, I know there is a txt2al tool, and there are very valid cases to use it. You won’t hear any bad word about it from my mouth. It’s just – looking at our situation – having +1000 hooks (not events) (while in extensions, I don’t want to use hooks anymore), new design patterns to be applied with extensions, … and a lot more reasons, we decided to do a rewrite with the big advantage we won’t have any legacy-stuff to solve. We will focus on one thing though – that’s trying to make sure we can upgrade data. The good thing on this approach is that we can completely revise all functionality in terms of begin “cloud-ready”, like: Remove all our .Net Interop Remove all our file-based integrations (or any kind of file-based automation) Focus on Service-based architecture (all funky stuff, provide (web) services for that – think “Azure Functions”) … Extensions only Besides our product, we are currently into a 2-year development challenge for a customer, with heavily modified NAV, many integrations, .Net, file-based automation, .. and so on. An atypical heavy customized project. This project is being turned into a (set of) extension(s). I have no intention whatsoever to turn back to customizations, just because I think that my customers need to get what they expect: a way to upgrade, a way to be future-proof. This project brings challenges for sure – but we’re getting there. I have full confidence we will be able to redo this heavy customized customer as a cloud-ready extension. Cloud-ready architecture I already kind of explained what I mean with “cloud ready” architecture. Basically, it comes down to being able to run it in the cloud. In essence, we need to apply the cloud-rules. And in terms of “rules” in AL development, we think of “compiler” and “code analysers”, right? Well, what we have been applying for all our extension-projects, is very simple this: In app.json: target = extension So the compiler won’t enable anything that would not be able to run in the cloud as an extension, like .Net. In settings.json : enable code analyzer “PerTenantExtension” , so also my code is analysed as such. Makes sense? May be not for you, but after 9 months of development, +800 objects, it still does for us :-). Thanks to this, we have found multiple unexpected parts that we needed to refactor. “Working with files ” and “working with .Net” being the most obvious ones. BaseApp in AL Big news – Microsoft was able to convert their C/AL to AL! It has been in the news for quite some time, but now you have it – next release (Fall 2019), this is the only way Microsoft will distribute its codebase. And that’s a major thing. Even more – you will be able to do customizations. Taking into account that in the future, we will NOT be able to do customizations, me personally, I don’t give one flying rats ass (sorry for my French). Cool for Microsoft to have a good conversion tool – but I won’t use it – may be to convert a set of objects (like reports) to copy, but I promise you now: I will never convert our product to AL. Just because – in my opinion – there is only one way forward. And that’s Extensions . If you would go down the route to migrate your product/customers/… to AL, just imagine. How do you manage: Support: People are going to have to support those customers/products/databases Now they have C/AL or Extensions Then there is a 3rd scenario – a mix of default code (that you probably want to upgrade at some point), products and customizations in one codebase. In a new technology. Imagine 300 customers, some have pure C/AL, some hybrid, some baseapp+customizations, some pure Extensions. Good luck with that! Maintenance / Upgradability: Congrats, you are on the new version But you haven’t progressed one singled bit. Upgrades is still a pain Maintenance is still a pain No way you will be able to easily migrate to the cloud … I’m a bit intentionally negative here – but I think you know what I mean when I say that I will never go down the route of customizing the BaseApp (as AL). Today, full C/AL or full AL Extensions. No other way for me. The only thing we need to do is make sure our product is finished (as Extensions) by the next release. “Don’tNet” One of the things to be “cloud ready” is to not use .Net. I get feedback from people that sometimes there is just no other way. And probably they are right. But in many (if not most) cases, you can avoid .Net. Vjeko and me did a session on NAVTechDays last year, were one of the topics was exactly that. I can strongly advise to watch that section here: So, there you have it – probably some of you think it’s time to unfollow me, unsubscribe from this blog, … . I strongly hope I didn’t offend anyone – this was merely an attempt to justify my opinion on things. Nothing more. I will never judge anyone for going down a route that I wouldn’t go to. Probably it would just mean that you are more organized (or more courageous) than me ;-).
↧
Forum Post: RE: Business central API: How to get the general ledger entries of a posted sale invoice ?
Thank you for your help, In the API documentation i don't see the field "Source code" , did i miss something ? You are right by saying that "Different document types should always have different numbers" but i made a test and Business Central allow intersections in the numbering so filtering on document number is not 100% correct. For example when you have a posted sale invoice with the same number as a posted purchase invoice and you open the posted sale invoice and click Navigate you receive the message "This combination of document number and posting date has been used more than once" and when you drill down to G/L entries you see the G/L entries of the 2 invoices (see screenshots below).
↧
Forum Post: RE: Business central API: How to get the general ledger entries of a posted sale invoice ?
You are right, that's my mistake - I was sure that source code is published in the standard API for G/L entries. Then there is no way to refine filtering except publishing your own API, as, for example, Dmitry Katson explains in his blog post: https://community.dynamics.com/nav/b/katsonsnavblog/archive/2018/10/10/how-to-create-custom-apis-for-business-central-even-from-macos In a custom API, you can show all the field you need. As for document numbers, you're absolutely correct - recommendation to configure number series in a way to prevent accidental overlapping is no more than a recommendation or a best practice. This is not a requirement imposed by the system core, and your example perfectly illustrates it. So, your solution would be to publish a custom API or a web service and appy an additional filter on the sorce code. But even that is not 100% reliable, because source code setup can change in time, and old entries posted with an obsolete source code will be lost in that case. Still the best way is try to prevent posting documents of different types with the same number.
↧