Author Archives: Mark Brummel

WARNING – The Data Upgrade Elephant

Last Thursday I was at the QBShare event in Veghel, Holland. I’ve been attending these events ever since I joined ForNAV a few years back and since the audience is a bit different from my normal events (CEO vs. Developers) it took me a while to get to know people.

No matter who you talk to at these events, all that they have on their minds is moving their IP to Business Central and most are in the middle of that project, some with my help.

This is all great and it’s cool to see peoples growing entousiasm but at this event I raised a question that for me is very obvious but to my surprise it was not for others.

The reason for my question was this slide in the presentation from William van Voorthuijsen.

Once partners are ready putting their IP on AppSource the next step is onboarding customers. Naturally you will start with customers who are as current as possible.

These customers will want to migrate data, including transactions, to Business Central and in order to do that they first have to migrate their OnPrem NAV to BC15 with a more-of-less matching schema.

WHAAT???

I hope that after following my blog nobody believes in the no-more-upgrade fairytales but this is a new chapter in this marketing bubble.

Right now, a customer on NAV2015 for example must first pay the partner for an upgrade OnPrem and every 6 months they wait the upgrade will get more expensive.

Remember that at the point of writing this blog, there is no direct upgrade path like we had in the old days where a customer could upgrade from Navision 2.01 to Navision 4SP3 without any issues. A friend of mine who does all of my upgrades even has his own tools that handles one-step datamigration from Navision 2.x to NAV2018 or Business Central Wave I.

The upgrade from Wave I to Wave II is tedious at best since C/Side is retired. Now everything has to be done in PowerShell and Microsoft even started promoting doing stuff directly on the SQL Database in order to speed up the process.

My recommendation to QBS, but also to Microsoft is to somehow make this process more affordable and guarantee that even if a customer wants to upgrade 5 years from now there is still a mechanism that allows doing that.

I expect that in the next years the SQL Schema of Business Central will undergo many changes which is expensive fort he technology that Microsoft uses fort he upgrade.

The good news is that Microsoft employs the smartest people in the world and they seem to have a subscription to my blog. Let’s see where this ends. I’ve already heard some rumours that this problem is under the attention of the teams and I hope this article helps leadership prioritise this issue.

There is an elephand in the room so big, that nobody seems to see it.

#BCALHelp

It’s the week of NAVTechDays, the biggest Business Central Community event of the year and I thought it would be good to spend a few moments on the state of our community.

Business Central is taking off. According to Microsoft there are more than 4000 paying tenants and the average number of users per tentant is 10+ which is the sweetspot where Navision used to be strong.

I can also see it in my daily work, especially at ForNAV, where almost all of the support cases and pre-sales activities now involve onboarding new Business Central Partners. Especially from North America the uptake from Great Plains partners is great and it’s nice to see the entousiasm.

I’ve said it before and I’ll say it again. Business Central is by far the best ERP in the cloud and with no doubt the most flexible and easy to enhance. If you just forget for a moment that it used to be Navision and forget about the failed marketing it’s so easy to fall in love with the product once again.

Microsoft is much more quiet or less noisy. Working hard on improving the product and realising the vast amount of changes nessesairy to put dots on I’s and crosses on T’s.

The people who are new to the product need help getting started and Twitter is a nice medium to shout out for help.

For that reason Microsoft started the hashtag #BCALHelp and encourages the community to subscibe to the hastag and help their peers.

I think being the underdog, quietly working on being the best without bragging has been a position that was always good for Navision and it’s good for Business Central. Our customers are small entrepeneurs working hard and not as sensible for loud marketing as the big fortune 500.

Let’s be humble and be the best in our game. Take it slow and steady and make the best with what we have.

I’m sure that with that, NAVTechDays will soon be BCTechDays with the same pride and dignity as before serving the same great communities of Navision and Great Plains combined.

See you all in Antwerp!

Working with dates in AL vs. C/AL

It’s friday afternoon and I’m goofing around a bit with the ForNAV AL Converter. I ran into something I want to share.

AL seems to be more strickt in hardcoded dates than C/AL.

Example

Constant value '99993112D' is outside the range for a Date. The syntax for defining Date format is yyyymmddD, where D is a mandatory letter. For example, 20180325D, read as the 25th of March, 2018.

This should be 99991231D but C/Side exports it using your regional settings.

Fortunately we can fix this in C/Side by changing the code to

DMY2DATE(31,12,9999)

I only have to replace 42 instances for the project/partner I’m currently working on. Thank god it’s friday afternoon. 😉

Mapping Codeunit 10201 “Transfer Custom Fields” to Events (NA Only)

By Steve Krisjanovs

Below is a list of all COD10201 external functions and where I believe their event equivalents live in. There were three functions in the list below that had me stumped so a second set of eyes would be helpful.

I do still believe that BC’s out of the box COD10201 should still have been modified by MS to indicate that all of these external functions are dead.

The problem I encountered, was because nothing has changed with this codeunit from NAV to BC (the codeunit exists, but all objects that used to call this codeunit no longer do that in BC), the NAV merge tools merged/upgraded our legacy modified cod10201 without any issues since it couldn’t find any conflicts. This could have been an avoidable scenario e.g. if the BC functions in this codeunit threw a runtime error at the beginning of each function call (e.g. “Depricated! Use {event pub object type} {event pub object ID}.{event pub name}”) our merge tools would have caught the conflict and I could have investigated much sooner in my merge/upgrade efforts.

  • [External] GenJnlLineTOGenLedgEntry(VAR GenJnlLine : Record “Gen. Journal Line”;VAR GenLedgEntry : Record “G/L Entry”)
    • maps to COD12.OnAfterInitGLEntry
  • [External] GenJnlLineTOTaxEntry(VAR GenJnlLine : Record “Gen. Journal Line”;VAR TaxEntry : Record “VAT Entry”)
    • maps to COD12.OnBeforeInsertVATEntry
  • [External] GenJnlLineTOCustLedgEntry(VAR GenJnlLine : Record “Gen. Journal Line”;VAR CustLedgEntry : Record “Cust. Ledger Entry”)
    • maps to COD12.OnAfterInitCustLedgEntry
  • [External] GenJnlLineTOVendLedgEntry(VAR GenJnlLine : Record “Gen. Journal Line”;VAR VendLedgEntry : Record “Vendor Ledger Entry”)
    • maps to COD12.OnAfterInitVendLedgEntry
  • [External] GenJnlLineTOBankAccLedgEntry(VAR GenJnlLine : Record “Gen. Journal Line”;VAR BankAccLedgEntry : Record “Bank Account Ledger Entry”)
    • maps to COD12.OnPostBankAccOnBeforeBankAccLedgEntryInsert
  • [External] BankAccLedgEntryTOChkLedgEntry(VAR BankAccLedgEntry : Record “Bank Account Ledger Entry”;VAR CheckLedgEntry : Record “Check Ledger Entry”)
    • maps to COD12.OnPostBankAccOnBeforeCheckLedgEntryInsert
  • [External] VendLedgEntryTOCVLedgEntryBuf(VAR VendLedgEntry : Record “Vendor Ledger Entry”;VAR CVLedgEntryBuf : Record “CV Ledger Entry Buffer”)
    • maps to TAB382.OnAfterCopyFromVendLedgerEntry
  • [External] CVLedgEntryBufTOVendLedgEntry(VAR CVLedgEntryBuf : Record “CV Ledger Entry Buffer”;VAR VendLedgEntry : Record “Vendor Ledger Entry”)
    • maps to TAB25.OnAfterCopyVendLedgerEntryFromCVLedgEntryBuffer
  • [External] CustLedgEntryTOCVLedgEntryBuf(VAR CustLedgEntry : Record “Cust. Ledger Entry”;VAR CVLedgEntryBuf : Record “CV Ledger Entry Buffer”)
    • maps to TAB21.OnAfterCopyCustLedgerEntryFromCVLedgEntryBuffer
  • [External] CVLedgEntryBufTOCustLedgEntry(VAR CVLedgEntryBuf : Record “CV Ledger Entry Buffer”;VAR CustLedgEntry : Record “Cust. Ledger Entry”)
    • couldn’t identify a suitable event mapping
  • [External] ItemJnlLineTOItemLedgEntry(VAR ItemJnlLine : Record “Item Journal Line”;VAR ItemLedgEntry : Record “Item Ledger Entry”)
    • COD22.OnAfterInitItemLedgEntry
  • [External] ItemJnlLineTOPhysInvtLedgEntry(VAR ItemJnlLine : Record “Item Journal Line”;VAR PhysInvtLedgEntry : Record “Phys. Inventory Ledger Entry”)
    • maps to COD22.OnBeforeInsertPhysInvtLedgEntry
  • [External] ItemJnlLineTOValueEntry(VAR ItemJnlLine : Record “Item Journal Line”;VAR ValueEntry : Record “Value Entry”)
    • maps to COD22.OnAfterInitValueEntry
  • [External] JobJnlLineTOResJnlLine(VAR JobJnlLine : Record “Job Journal Line”;VAR ResJnlLine : Record “Res. Journal Line”)
    • maps to TAB207.OnAfterCopyResJnlLineFromJobJnlLine
  • [External] JobJnlLineTOItemJnlLine(VAR JobJnlLine : Record “Job Journal Line”;VAR ItemJnlLine : Record “Item Journal Line”)
    • maps to TAB83.OnAfterCopyItemJnlLineFromJobJnlLine
  • [External] JobJnlLineTOGenJnlLine(VAR JobJnlLine : Record “Job Journal Line”;VAR GenJnlLine : Record “Gen. Journal Line”)
    • couldn’t identify a suitable event mapping
  • [External] JobJnlLineTOJobLedgEntry(VAR JobJnlLine : Record “Job Journal Line”;VAR JobLedgEntry : Record “Job Ledger Entry”)
    • legacy NAV called from this from COD1012.CreateJobLedgEntry(…) but there doesn’t appears to be any suitable event pub in BC
  • [External] ResJnlLineTOResLedgEntry(VAR ResJnlLine : Record “Res. Journal Line”;VAR ResLedgEntry : Record “Res. Ledger Entry”)
    • maps to COD212.OnBeforeResLedgEntryInsert

AppSource; Prefix, Suffix & Intellisense

This article was triggered by a discussion on Yammer yesterday that I felt went a bit sideways.

Business Central is a first class cloud citizen and it beats born in the cloud solutions easily but fact remains that it’s based on Navision, an ERP solution with a 30-some year legacy.

Part of that legacy is a requirement for unique names in the objects, also in the cloud.

Microsoft is working hard to remove this requirement hence it’s a temporary fix but the result is that every app on AppSource needs a three letter prefix or suffix.

You can register your TLA with Microsoft and when this is done nobody else can use it.

With Per-Tenant extensions you don’t need prefixing and I would actually recommend against it since there may be a fair change you’ll use one that is used by one of the apps.

At ForNAV I am primary responsible for the App we have on AppSource and we Prefix everything with ForNAV, hence we reserved “FOR” as a prefix.

I am probably a little autistic and I like stuff that looks clean, so my C/Side looks like this:

Had I suffixed everything it would have been so ugly to look at.

What about Intellisense?

If you watch my YouTube video’s or if you attended one of my classes you’ll have heard me say I recommend suffixing so this sticks into peoples heads.

However this is on a totally different topic. This recommendation is for people who are so stubborn that they want to cling on to Hungarian notation. This will affect Intellisense.

With an AppSource solution I would recommend (and use this myself) to leave our your Registered TLA of your variables all together.

Here is an example:

As a sidenote, Intellisense in Visual Studio Code works smarter than just the first characters, it would actually do a smart search and also suggest results that contain the characters even with small typos. It’s one of the things that make VSCode better than C/Side. (One of the few things though 😊).

Tip #64 | Show License Information in Business Central

With the retirement of C/Side we have a challenge we did not have before regarding the license.

We used to be able to see the license information from C/Side, upload the license and quickly create a new page that displays permissions.

With Business Central this is no longer possible and we now need PowerShell to upload a license.

On my GitHub you can find a repo you can clone to display the license information.

Challenge

I would also like to be able to change the license from this page. I hope one of my readers can put this in and do a pull request.

It will require DotNET but that’s fine, this extension is targeted for OnPrem anyway.

Enjoy!

Tip #63 | Export Warnings & Errors from Visual Studio Code

If I get asked the same question twice I am already tempted to blog about it. This one exceeds this number and is long overdue.

It looks like the whole world is now converting from C/AL to AL and running into challenges with that.

Right now I am analysing several databases and one thing you need after elliminating low hanging fruit and removing errors that crash the compiler is to find common errors and count them.

An Excel Pivot Table is perfect for that.

Normally Visual Studio Code is not nice in exporting errors and warnings. You can try to copy/paste them but the work to clean up is hard.

With the magic AL runner by Tobias Fenster it is prepared for you. You can download it here.

You can copy and paste this into Excel and use Data -> Text to Columns to use the | as a separator.

The only thing that you’ll miss is the object ID and type. You can add these with adding two columns using the formula like

=LEFT(C5;FIND(“.”;C5)-1)

After that you’ll spend several hours. or often days in C/Side fixing errors you could have fixed a long long time ago.

Enjoy!