Microsoft MB-820 Practice Test Questions

Explanation:
The goal is to automatically populate the Incident Date and Status fields when a new "Room Incident" record is created.

Instructions:

"Incident Date":=Workdate(); is the correct function to assign the current work date (which is often the session date) to a date field. Today() could also be acceptable, but WorkDate() is more aligned with business application context in Business Central. CurrentDateTime() is incorrect as it returns a DateTime value, which is not suitable for a pure Date field.

"Status":=Status:Open; is the correct way to assign an enum value. Using the enum's symbolic name (Status:Open) is the modern, readable, and recommended practice in AL. Using the underlying integer value ("Status":=1;) is fragile and should be avoided, as the integer mapping can change if the enum is modified.

Trigger:
The OnInsert trigger is the correct choice. This trigger fires automatically when a new record is first saved to the database. It is the standard and intended place for initializing default field values for a new record.
OnModify fires when an existing record is changed, which is too late.
OnRename fires when a record's primary key is changed, which is irrelevant for setting initial values.

Explanation:
Let's break down each required component for creating a robust and secure codeunit.

1. Access Property: Access = Internal
Internal restricts the use of this codeunit to the extension in which it is defined. It cannot be called from other extensions or from the base application. This is the secure, modern practice for encapsulating logic that is not intended to be a public API.

Why not Public? While Public would allow the codeunit to be called from anywhere, it is unnecessary for internal logic and violates the principle of encapsulation. It exposes the codeunit's interface, making future changes more difficult without breaking dependent code.

2. Permissions: Permissions = TableData "POS Information" = RIMD
RIMD grants the codeunit the necessary permissions to Read, Insert, Modify, and Delete records in the "POS Information" table. This full set of permissions is typical for a codeunit that manages data for an entity, as it will likely need to create, read, update, and delete records.

Why not rdx or RMDX?
rdx is syntactically incorrect and uses lowercase letters, which is not standard.
RMDX is also incorrect. The standard permission letters are R (Read), I (Insert), M (Modify), and D (Delete). The X is not a valid permission for table data; it is sometimes used in end-user permission sets to grant the "Execute" permission for objects like codeunits.

3. Procedure Signature: procedure readAPI(PosNo: Integer)
A parameterized procedure (PosNo: Integer) is the correct choice. It allows the caller to specify which POS terminal to read the API for, making the codeunit flexible and reusable. The logic inside the procedure would use this PosNo parameter to filter or identify the correct terminal.

Why not the others?
procedure readAPI() (no parameters) is too rigid. It implies the codeunit can only ever read from one, predefined POS terminal.

var procedure readAPI() is syntactically incorrect. The var keyword is used to define variable parameters, not the procedure itself.

Reference:

Microsoft Learn Documentation: Codeunit Object

This documentation details the properties and structure of a codeunit. It explains the Access property and the difference between Internal and Public scopes. It also covers how to define the Permissions property and the standard permission set letters (RIMD).

Explanation:
When defining fields in a Business Central table, it's crucial to select the most appropriate data type based on the nature of the data and how it will be used.

E. Code for the Non-Conformity Number field:
The Code data type is specifically designed for alphanumeric identifiers, such as document numbers, codes, and IDs. It automatically handles uppercase conversion and trimming of leading/trailing spaces, ensuring data consistency. It is the standard and correct choice for any numbered field that is an identifier (like "Non-Conformity Number").

Why not A (Integer)? An Integer is for whole numbers without any alphabetic characters. A "Number" field in a business context often includes prefixes or is part of a formatted number series (e.g., "NC-0001"), which an Integer cannot store.

Why not C (Char)? A Char (Text) field stores text as-is without automatic formatting. It is less rigid than Code and can lead to inconsistent data (e.g., "nc1", "NC1", " NC1 ").

D. Date for the Non-Conformity Date field:
The Date data type is the standard and correct choice for storing a calendar date without a specific time component. A "Non-Conformity Date" is a point in time on the calendar, making Date the logical fit.

Why not B (Date Time)?
A DateTime data type includes both a date and a time. Unless the specific time of the non-conformity is a business requirement, using DateTime is unnecessary and adds complexity. A simple Date is sufficient and more appropriate for this context.

Reference:

Microsoft Learn Documentation: Data Types

You can find the official documentation by searching for "AL Data Types" on the Microsoft Learn site. It explicitly describes the purpose of each type:

Code:
"Use this data type for a textual value that contains only alphanumeric characters and no space... The text is stored in uppercase and is padded with the number of spaces that is defined by the length of the variable."

Date:
"Use this data type to store a date ranging from January 1, 1753, to December 31, 9999."

DateTime:
"Use this data type to store any date and time ranging from January 1, 1753, 00:00:00.000 to December 31, 9999, 23:59:59.999."

Explanation:
For a configuration/setup table that stores global settings for a functionality (like non-conformity), the standard pattern is a Singleton table.

Design pattern: Singleton
A Singleton table is designed to hold only one configuration record for the entire company. This is the standard pattern for setup tables in Business Central (e.g., "Sales & Receivables Setup", "Inventory Setup"). It ensures there is only one set of configuration values.
Why not "Adapter"? An Adapter pattern is for integrating external systems, not for internal configuration.

Data type of the primary key field: Code
The primary key for a singleton table is typically a Code field with a fixed length (e.g., Code[10]). A common practice is to have a single, hard-coded value like 'SETUP' or 'GLOBAL' as the primary key for the one and only record. The Code data type is perfect for this kind of identifier.

Why not "Integer" or "BigInteger"? These are for numeric sequences, which are not needed for a singleton table's primary key.

Property to prevent users from adding records: InsertAllowed
Setting InsertAllowed = false; on the table object is the direct and correct way to prevent users from manually creating new records through the UI. This is crucial for a singleton table to maintain its single-record integrity. The configuration page should have logic to create the single record if it doesn't exist, typically in the OnOpenPage trigger.

Why not "InitValue"? This property sets a default value for a field when a new record is created, but it does not prevent the creation of new records.

Why not "UnBound"? This is a page control property, not a table property, and is unrelated to record insertion.

Reference:

Microsoft Learn Documentation: Table Properties
The InsertAllowed property is documented to "Specifies whether users can add records to the table by using the user interface."

Business Central Development Patterns:
The Singleton pattern for setup tables is a well-established standard in the Business Central application. You can observe this by examining base application tables like "Sales & Receivables Setup" or "Inventory Setup", which all use a Code primary key and are designed to hold a single record.

Explanation:
To create a comments field that supports multiple lines of text, you need to use the correct combination of data type and page field property.

Variable Declaration: NonConformityComments: Text; is correct. The Text data type is the standard choice for storing multi-line comments and large text blocks.

Page Field Property: ExtendedDatatype
This is the correct property name. The ExtendedDatatype property on a page field allows you to specify a specialized UI behavior for a Text or Code field.

Why not the others?
DataType is used to define the fundamental data type (like Integer, Decimal, Text) and is not needed here since the variable is already declared as Text.
ExtendDataType and RichDataType are not valid property names in AL.

Property Value: Multiline
Setting ExtendedDatatype = Multiline; is the correct value. This property tells the client to render the field as a multi-line text box, allowing users to enter text with line breaks. It is the standard way to handle comments or notes.

Why not the others?
LongContent, RichContent, and TextRichContent are not standard values for the ExtendedDatatype property.
Multiline = True; and NotBlank= True; are invalid syntax. Multiline and NotBlank are not standalone properties; Multiline is a value for ExtendedDatatype, and NotBlank is a separate field property used for validation.

Reference:

Microsoft Learn Documentation: Page Field Properties
The official documentation for the ExtendedDatatype property lists its possible values, which include Multiline. The documentation states that Multiline "Specifies that the field can contain multiple lines of text." This is the definitive property for creating a comments field.

Explanation:
The non-conformity entity represents a core business document that tracks issues or defects. In Business Central, such entities are best modeled using a document table pattern.

B. Document Table:
This is the correct choice for introducing the main non-conformity entities. A document table acts as the header for a business document, storing primary information like a document number, date, description, status, and general header-level data. It typically has a one-to-many relationship with a corresponding lines table, which holds the detailed items or issues. This pattern is used throughout Business Central for documents like Sales Orders, Purchase Orders, and Transfer Orders.

Let's examine why the other options are incorrect:

A. Document History Table:
This type of table is used for auditing and tracking changes to an existing document, not for creating the primary entity itself. It stores historical snapshots or change logs (e.g., "Posted Non-Conformity Header") after the main document has been processed. It is a secondary table, not the primary entity definition.

C. Supplemental Table:
A supplemental table is used to add extra fields to an existing table via a table extension. It is not used to define a new, standalone business entity from scratch. Its purpose is to extend, not introduce.

Reference:

Microsoft Learn Documentation: Table Overview
While there isn't a single page titled "Document Table Pattern," this design is a fundamental architectural standard in the Business Central base application. You can observe this pattern by examining standard tables like "Sales Header" (the document/header table) and "Sales Line" (the corresponding lines table). The header table introduces the entity, and the lines table stores the details.

Explanation:
Each page type in Business Central serves a specific purpose within the application's UI architecture.

Display relevant insights in the Housekeeping Role Center: HeadLinePart
A HeadlinePart page is specifically designed for role centers. It displays key performance indicators (KPIs), metrics, or insightful messages in a prominent banner at the top of the role center. Its purpose is to give users an immediate, high-level overview of their most important business data.

Display the additional information for the Room table: CardPart
A CardPart page is used to create a FactBox. FactBoxes are panels that appear on the right side of a card or list page, displaying related or additional information about the selected record. Creating a CardPart page for the Room table would allow you to show extra details (like maintenance history or current status) next to the Room card.

Configure the first installation: StandardDialog
A StandardDialog page is a modal pop-up window used for user interaction, such as collecting input or confirming an action. It is the correct type for a setup or configuration wizard that runs upon first installation, as it can prompt the user for necessary initial settings before the main application is used. A NavigatePage is for building navigational menus (like the Departments page), not for configuration dialogs.

Reference:

Microsoft Learn Documentation: Page Types
The official documentation defines the usage for each page type. For HeadlinePart, it states it is "used to create a headline for a Role Center." For CardPart, it is "used to display a page in a FactBox." For StandardDialog, it is "used to create a dialog." This aligns perfectly with the requirements described.

Explanation:
The goal is to create a lookup relationship for the "Receipt No." field that filters the available purchase receipts based on a vendor number stored in the Non-conformity table.

Property: TableRelation
This is the correct property to define a lookup relationship to another table. It allows users to select a valid value from the related table.

Value: "Purch. Rcpt. Header"."No."
This specifies the target table and field for the relationship. The "Receipt No." should relate to the "No." field in the "Purch. Rcpt. Header" table, which is the standard table for posted purchase receipts.

Clause: where ("Buy-from Vendor No." = field ("Vendor No."))
This where clause adds a critical filter to the lookup. It ensures that the drop-down list for the "Receipt No." field only shows purchase receipts where the "Buy-from Vendor No." in the receipt header matches the "Vendor No." stored in the current record of the Non-conformity table. This creates a context-aware and valid selection for the user.
The syntax = field ("Vendor No.") is used to reference a field in the current record (the source table).

Why the other options are incorrect:
Other Properties: CalcFormula, FieldRelation, and Relationship are used for different purposes (FlowFields, field mapping, and defining table relationships) and are not the correct property for creating a simple lookup.

Other Clauses: = const uses a fixed value, = filter applies a static filter, and = lookup is not valid syntax for a where clause. The = field() operator is the correct way to dynamically filter based on another field in the current record.

Reference:

Microsoft Learn Documentation: TableRelation Property
The official documentation explains how to use the TableRelation property, including the syntax for using a where clause to filter the related table entries based on a field in the current record.

Explanation:
The endpoint for a Business Central API page follows a specific, structured format. The components are defined by properties in the API page object itself.

The standard format is:
https://api.businesscentral.dynamics.com/v2.0///api////companies()/

Let's break down the correct choices based on this structure:

API Publisher (): alpine
This is a namespace, typically your publisher name or a unique identifier for your organization (e.g., microsoft). "alpine" is the placeholder/publisher name used in this context.

API Group (): integration
This is a logical grouping for your APIs. "integration" is a common and appropriate name for a set of APIs designed to integrate with external systems like a Property Management System (PMS).

API Version (): v2.0
This specifies the version of your API. Using a version like v2.0 is standard practice to allow for future updates without breaking existing integrations.

Entity Name (): rooms
This is the name of the specific API entity. Since the API page is named "RoomsAPI", the natural and expected entity name in the endpoint would be rooms.

Reference:

Microsoft Learn Documentation: API Page Type
The official documentation details how to create API pages and how the APIPublisher, APIGroup, and APIVersion properties defined on the page object directly construct the OData endpoint URL. The entity name is derived from the EntityName property, which defaults to the page name without the "API" suffix.

Explanation:
This code follows the standard pattern for handling BLOB data (like images) using a TempBlob codeunit in Business Central. The process involves writing data to an OutStream and then reading it from an InStream for download.

First blank: CreateOutStream
The Temp Blob. Create Out Stream method creates an Out Stream object linked to the temporary BLOB storage. This stream is used to write or export data into the Temp Blob. The code Incident. Image .Export Stream( Incident Out Stream) writes the image data from the database field into this Out Stream.

Second blank: Create In Stream
After the data is written to the Temp Blob via the Out Stream, you need to read it back out for downloading. The Temp Blob. Create In Stream method creates an In Stream object linked to the same Temp Blob content. This stream is used to read the data that was previously written.

Third blank: IncidentInStream
The DownloadFromStream function requires an InStream as its first parameter because it needs to read data from the stream to create the file for the user to download. IncidentInStream is the InStream variable that now contains the image data we prepared, making it the correct argument to pass.

Why the other options are incorrect:
CreateStream is not a standard method for the TempBlob codeunit.
CreateInStream is incorrect for the first blank because you first need an OutStream to receive the exported image data.
WriteOutStream and ReadInStream are not valid methods.
IncidentOutStream is incorrect for the third blank because DownloadFromStream requires an InStream to read from, not an OutStream to write to.

Reference:

Microsoft Learn Documentation: TempBlob Codeunit
The official documentation for the "Temp Blob" codeunit lists the CreateOutStream and CreateInStream methods. The pattern of using an OutStream to export data into a TempBlob and then an InStream to retrieve it is a standard practice for handling BLOBs in AL. The DownloadFromStream function's signature explicitly requires an InStream parameter.