Community News

I’ve been working with Business Central Telemetry a lot the last coulple of months, having to deal with deadlocks and such. And while doing so, quite some new ideas came to mind that I’d like to investigate by means of Telemetry. But first, a disclaimer I’m absolutly not an expert. Probably there are better ways …

This tweet reminded me of a small but beautiful trick to get a reliable xRec in all the Modify trigger events. The problem When events were introduced in C/AL code, one of the most discussed was the OnAfterModify event. Back ...

Just a small heads-up that made us scratch our heads for a while.. . In the new version of Business Central (2023 Release Wave 1 – aka v22), the PowerShell CmdLet “Get-NAVAppInfo” now gives one more dependency in the “dependencies” collection. Or as pictures say more than a thousand words: V21 and below: But from …

In chapter 6 of , on pages 109 and 110, the data model and business logic changes for the Lookup Value business case are listed and discussed.

One way or another these changes are covered by most of the test examples worked on in the book. Accept for the two following business rules that were out scoped as too elaborative for the already packed authoring plan; and were setup up as issues on the GitHub repo for the book.

• When restoring an archived sales document, the Lookup Value Code field should be
  restored from Sales Header Archive to Sales Header.
  See .
• When copying a sales document using the Copy Document feature, the Lookup Value Code field should be inherited from source Sales Header to target Sales Header.
  See .

Now, with some extra hands available – see below – these could get implemented finally. With this post I am going to tackle the first item. The next addendum, #06, will cover the second one.

What was missing?

Although the Sales Archive subfeature did already emerge in the business logic in the first edition of the book, it was incomplete as , one of the reviewers of the second edition, justly reported. It did only cover the archiving part, not the restoring part. I decided to add it to the test plan breakdown exercise in chapter 6 of the second edition, and at the same time park it as an issue on GitHub (see the already mentioned ).

It was a great business case to get to learn some basic Business Central functionality and design and code test scenarios for the new apprentice, , that joined 4PS a couple of months ago.

How was it fixed?

Jules planned, designed and coded the following 7 scenarios:

[SCENARIO #0100] Restore archived sales order with lookup value to sales order with changed lookup value.
[SCENARIO #0101] Restore archived sales order with empty lookup value to sales order with lookup value.
[SCENARIO #0102] Restore archived sales order with lookup value to sales order with empty lookup value
[SCENARIO #0103] Restore archived sales quote with lookup value to sales quote with empty lookup value
[SCENARIO #0104] Restore archived sales invoice with lookup value to sales invoice with empty lookup value
[SCENARIO #0105] Restore archived blanket order with lookup value to blanket order with empty lookup value
[SCENARIO #0106] Restore archived return order with lookup value to return order with empty lookup value
[SCENARIO #0107] Restore archived credit memo with lookup value to credit memo with empty lookup value

As like any testing with test automation choices have to be made on what scenarios are meaningful to implement/execute. The above 8 scenarios are a meaningful (enough) subset of all possible scenarios. It covers:

Scenarios #100, #101 and #102 cover the three basic scenarios for an archived sales order

1. Restore overwrites a changed lookup value
2. Restore empties a lookup value
3. Restore populates an empty lookup value

Note that we could argue about a fourth basic scenario: Restore empties an empty lookup value.

Scenarios #103, #104, #105, #106 and #107

Each of them covering the first basic scenario for each of the other sales document types.

The test designs have been added to the as shown in the screenshot below.

The scenarios have been coded in a new test codeunit as part of the final version of the Lookup Value extension (having separate app and test app).

Note that, like in , the new tests have been assigned ids starting at 0100 for the reason mentioned there:

I often do use higher numbers for scenarios that are added later to make clear that the collection of scenarios is never complete. Scenarios keep on being added later due to better understanding, reported omissions, etc.

Note

As both test codeunits use identical helper functions there is clearly a need for refactoring. I decided, however, not to do this as it would introduce too many changes to the existing code and make repo too much different from what was released with the book.

A BIG thanx to …

… , a very talented apprentice at 4PS, for the design and coding all the test scenarios; what a great job you did.

… , for his reviews, feedback and input on this topic.

It’s almost time for the Business Central Launch Event 2023 Wave 1 : https://aka.ms/BCLE The Business Central Launch Event will  take place from March 29-31, 2023. During the three days, you’ll be able to participate in a  live opening session...

As I explain in with test example 8 in chapter 8, the testability framework – or actually the test toolkit – does not provide for layout testing, only dataset testing.

Those who bought both the 1^st and 2^nd edition of my book might have noticed that the verification part of this report test example changed.

1^st Edition

The verification code part of the 1^st edition was like the following:

local procedure VerifyCustomerWithLookupValueOnCustomerListReport(
    No: Code[20]; LookupValueCode: Code[10])
var
    Row: array[2] of Integer;
begin
    Row[1] := LibraryReportDataset.FindRow(
        'Customer_No_', No);
    Row[2] := LibraryReportDataset.FindRow(
        'Customer_Lookup_Value_Code', LookupValueCode);
    Assert.AreEqual(
        13, Row[2] - Row[1],
        'Delta between columns Customer_No_ and Customer_Lookup_Value_Code')
end;

Where the FindRow(ElementName: Text, ElementValue: Variant) method, from Library - Report Dataset (131007), returns the row number for the combination of ElementName and ElementValue. In our case the combination of column Customer_No_ or column Customer_Lookup_Value_Code and its respective value No or LookupValueCode. Apparently the row number of column Customer_No_ yielded another value than that of column Customer_Lookup_Value_Code as you can see from the AreEqual check where the delta between the row numbers is expected to be 13. This indeed was true on BC14, the version the 1^st edition was based on, although you might have expected that the row number should be exactly the same as No and LookupValueCode belong to the same customer record.

2^nd Edition

When using this code on B19, the version the 2^nd edition was based on, the verification did not work as FindRow returned always 0, as I reported to MS. So, it seemed I could not use FindRow method anymore and decided to make use of the AssertElementWithValueExists method from Library - Report Dataset (131007) as per the following code:

local procedure VerifyCustomerWithLookupValueOnCustomerListReport(
    No: Code[20]; LookupValueCode: Code[10])
begin
    LibraryReportDataset.AssertElementWithValueExists(
        'Customer_No_', No);
    LibraryReportDataset.AssertElementWithValueExists(
        'Customer_Lookup_Value_Code', LookupValueCode);
end;

I was not very happy, but didn’t have much time to ponder over this. Later, however, a number of attendees to my online course rightfully pointed out that this new verification code was not 100% robust. Why? Well, the checks on the columns Customer_No_ and Customer_Lookup_Value_Code could both be passing even though these two columns reside in the dataset at unrelated rows. I had to get back and study the issue once more which I did this week. I also added an issue for it to the GitHub of my book: .

I tested both solutions on their related version, i.e. BC14 and BC19, again and saw both passing. While debugging the 2^nd edition version I, however, noted that FindRow did not return a 0. It actually returned the same raw number for a related set of columns Customer_No_ and Customer_Lookup_Value_Code resulting in a delta of 0. This meant that I could revert the 2^nd edition version of VerifyCustomerWithLookupValueOnCustomerListReport to the 1^st edition version only changing the expected delta from 13 to 0 as per the below:

local procedure VerifyCustomerWithLookupValueOnCustomerListReport(
    No: Code[20]; LookupValueCode: Code[10])
var
    Row: array[2] of Integer;
begin
    Row[1] := LibraryReportDataset.FindRow(
        'Customer_No_', No);
    Row[2] := LibraryReportDataset.FindRow(
        'Customer_Lookup_Value_Code', LookupValueCode);
    Assert.AreEqual(
        0, Row[2] - Row[1],
        'Delta between row for columns Customer_No_ and Customer_Lookup_Value_Code')
end;

I have updated all version related branches on the GitHub repo. you might notice that I left the two original lines of code as comments.

Case closed.

It’s always nice having to prep a webinar about “what’s new in Business Central”. It makes you being very busy with what’s next, and forces you to dive into it :-). Not always easy though, because – even today – there isn’t too much documentation online yet (it’s not fully released either, so .. quite …

A few months ago someone asked if if it was possible, using Power Automate, to get documents from Business Central, for example in pdf format and them email them or save them somewhere. At that time I did a few tests and discovered it was simply not...

A short heads-up! Time is running out, and if you want to be part of it, you’ll have to act fast! Days of Knowledge 2023 is a series of conferences organized by DirectionsEMEA (aka “Directions4Partners“). The conferences are focused on education, sharing knowledge and “upgrading” Business Central professionals across the industry. Each event consists of …

Business Central 22 Preview is available! Try it now on Docker or in your Cloud tenant… and share feedback\impressions please.