Analyze (the lack of) Partial Records with Business Central Telemetry
How to get a reliable xRec
Get-NAVAppInfo gives different results in v22
Addendum #05 – Include Lookup Value in Restore Archived Sales Document feature
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 Codefield should be
restored from S
ales Header Archiveto
- When copying a sales document using the
Copy Documentfeature, the
Lookup Value Codefield should be inherited from source
Sales Headerto target
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
- Restore overwrites a changed lookup value
- Restore empties a lookup value
- 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.
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.
Join the Business Central Launch Event, 2023 Wave 1
Addendum #04 – Verifying the Report Dataset
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 1st and 2nd edition of my book might have noticed that the verification part of this report test example changed.
The verification code part of the 1st edition was like the following:
local procedure VerifyCustomerWithLookupValueOnCustomerListReport( No: Code; LookupValueCode: Code) var Row: array of Integer; begin Row := LibraryReportDataset.FindRow( 'Customer_No_', No); Row := LibraryReportDataset.FindRow( 'Customer_Lookup_Value_Code', LookupValueCode); Assert.AreEqual( 13, Row - Row, 'Delta between columns Customer_No_ and Customer_Lookup_Value_Code') end;
FindRow(ElementName: Text, ElementValue: Variant) method, from
Library - Report Dataset (131007), returns the row number for the combination of
ElementValue. In our case the combination of column
Customer_No_ or column
Customer_Lookup_Value_Code and its respective value
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 1st edition was based on, although you might have expected that the row number should be exactly the same as
LookupValueCode belong to the same customer record.
When using this code on B19, the version the 2nd 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; LookupValueCode: Code) 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_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 2nd 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_Lookup_Value_Code resulting in a delta of 0. This meant that I could revert the 2nd edition version of
VerifyCustomerWithLookupValueOnCustomerListReport to the 1st edition version only changing the expected delta from 13 to 0 as per the below:
local procedure VerifyCustomerWithLookupValueOnCustomerListReport( No: Code; LookupValueCode: Code) var Row: array of Integer; begin Row := LibraryReportDataset.FindRow( 'Customer_No_', No); Row := LibraryReportDataset.FindRow( 'Customer_Lookup_Value_Code', LookupValueCode); Assert.AreEqual( 0, Row - Row, '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.
Dynamics 365 Business Central in 2023 release wave 1
How Do I: Get Business Central (Pdf) Documents in Power Automate?
“Days of Knowledge” coming up!
Business Central 22 (2023 Wave1) Preview and BC Launch Event