Free Microsoft MB-800 Practice Exam with Questions & Answers

We are recording an incoming customer payment in the Cash Receipt Journal:

Account Type = Customer → Because we are applying the payment to a customer balance.

Account No. = 2030 → This is the customer account number provided.

Amount = $500 → Since it’s an incoming receipt (cash inflow), the value is positive. (A negative would represent refunds or outgoing payments.)

Bal. Account Type = Bank account → Payments received must be offset against a bank account, not a G/L account directly.

Bal. Account No. = 1010 → This is the specific bank account receiving the payment.

⚠️ Note: The G/L account 10100 mentioned in the scenario is the general ledger posting account associated with the bank account card (No. 1010). Users do not directly post against that G/L account in the journal; instead, the system automatically posts to it when you select the bank account.

This ensures proper double-entry posting:

Debit Bank (G/L 10100 via Bank Account 1010)

Credit Customer (Customer 2030).

Microsoft Learn References

Work with General Journals in Business Central

Apply Payments with the Cash Receipt Journal

Bank Accounts in Business Central

The requirement is: “You need to configure retail store customer cards to track revenue by market.”

In Business Central, to track revenue by customer market (Retail, Veterinarian, Breeder), you configure default dimensions on the Customer Card.

Assign the dimension code → Market

The business wants to analyze revenue by Market (Retail, Veterinarian, Breeder).

Therefore, the dimension code must be Market.

Assign the dimension value code → Retail

For this specific setup, the customer is a retail store, so the dimension value must be Retail.

Select a value posting → Same code

To ensure that every posting for this customer always carries the same dimension value, use Same Code.

Other options:

Blank = no default dimension.

No code = optional dimension.

Code mandatory = requires entry but allows flexibility in values.

Since we want strict tracking by a fixed market (Retail), Same code is correct.

This ensures that every transaction posted for the customer will always have Market = Retail, enabling accurate revenue tracking.

Microsoft Learn references:

Work with Dimensions

Set Up Default Dimensions

Dimension Value Posting Options

The Accounts Receivable (AR) team often needs to correct payment applications when cash is applied incorrectly. In Business Central, unapplied entries can be corrected in several ways:

From the Customer Card, under Navigate > Ledger Entries, users can select entries and use the Unapply Entries action.

From the Customer Ledger Entries page, users can directly select a posted application and choose Unapply Entries.

The Detailed Customer Ledger Entries page is used for analysis and shows how entries were applied, but the actual “Unapply” action is not typically performed here (it is read-only in terms of correction).

“Apply entries” can be done from Detailed Customer Ledger Entries, but unapplies are performed from Customer or Customer Ledger Entries.

Correct answers: A and C

The requirement is: “Customer pricing is determined by the customer market type (Retail, Veterinarian, Breeder). Each customer is associated with only one market type.”

A. Assign the Customer Price Group code on the customer card → Correct, because each customer must be tied to its market type via a Customer Price Group.

C. Create a Sales Price List by using the assign-to type of Customer Price Group → Correct, because pricing and discounts should be managed at the group level, not per individual customer, ensuring easier maintenance.

E. Create Customer Price Groups that allow line discounts → Correct, because discounts are offered by item, brand, or product category, and must flow to sales lines automatically.

Incorrect options:

B. Exclude line discounts → Opposite of requirements.

D. Create a Sales Price List for the customer → Not scalable; must be done by group, not individual customer.

Correct answers: A, C, E

In Business Central, the over-receipt functionality (receiving more than ordered) requires setup in two places:

Item Card (or SKU Card) → Define whether an item can be over-received and the % tolerance.

Over-Receipt Codes → Configure allowable over-receipt percentages and reasons in the Over-Receipt Code list.

The Vendor Card does not control over-receipt settings, and SKUs inherit from items unless specifically overridden.

In Business Central, the Payment Terms calculation uses the Document Date (not Posting Date or Order Date). The system takes the Document Date and applies the due date calculation formula defined in the Payment Terms.

Order Date is primarily for purchase/sales documents scheduling.

Posting Date drives G/L posting date.

Due Date is the result of the calculation, not the input.

In Dynamics 365 Business Central, the General Ledger Setup page controls how amounts are displayed and rounded.

Amount Decimal Places specifies how many decimal places will be displayed for all monetary amounts in local and foreign currencies.

A value of 3:3 means exactly 3 decimals will always be shown.

This directly matches the requirement: "Monetary amounts for local currency must always display three decimal places."

Unit-Amount Decimal Places controls the decimals for unit costs or prices on items, not for general monetary amounts.

Inv. Rounding Precision sets the rounding for invoice totals, not for displaying all local currency amounts.

Unit-Amount Rounding Precision applies to rounding of item unit costs/amounts.

Amount Rounding Precision determines how monetary amounts are rounded during posting (for example, rounding to 0.01 or 0.001), but does not control how they are displayed.

Therefore, the correct configuration is to set Amount Decimal Places = 3:3 in General Ledger Setup.

In Dynamics 365 Business Central, the General Journal Reconciliation feature allows reconciliation of ledger entries against G/L accounts (often bank, clearing, or control accounts).

To include a G/L account in the general journal reconciliation window:

You must enable the Reconciliation Account field on the G/L Account Card.

This setting flags the account as reconcilable, so it appears in the reconciliation process.

Why not the others?

B. Direct Posting field → Controls whether you can post directly to the account, not related to reconciliation.

C. Bank Account Posting Group → Links bank accounts to G/L accounts, but the reconciliation flag still must be set.

D. Create a new payment reconciliation journal → Used for bank statement reconciliation, not general ledger account reconciliation.

Microsoft Learn Reference

Reconcile General Ledger Accounts in Business Central

In Business Central, when you want to import master data (like customers, vendors, items, etc.) using configuration packages, you follow a structured sequence:

Create a configuration package – First, you define the configuration package and select the related tables to be imported.

Export an Excel template and populate the data – Once the package is created, you export the template to Excel. This gives you the correct structure (fields, columns) that match Business Central. Then you (or the customer) fill in the Excel file with the master data.

Import a populated Excel template into the package data – You then import the filled-in Excel file back into the configuration package in Business Central.

Apply the data – Finally, after validation, you apply the data so it is committed to the database tables of the new company.

Why not the others?

Export a configuration package is used to share configuration setups with another environment, not part of this workflow.

Import a populated Excel template into the sales header and lines is only for document data (transactions), not master data imports via configuration packages.