MB-310 common mistakes
MB-310 · Understand the traps and how to avoid them.
Building dimension entry requirements entirely with account structures when the rule is conditional on another dimension value (for example, requiring Department B only when Cost Center = 100), then discovering journals accept combinations that should be rejected.
Candidates treat account structures as a general validation engine. An account structure can only constrain a main account range and each dimension's allowed value list independently; it cannot express cross-dimension logic, so every combination in the allowed lists passes validation during the case study review.
What to do instead
Keep the account structure for main-account ranges and per-dimension allowed values, then add an advanced rule structure for the conditional requirement (select the dimensions involved, define the criteria on the driving dimension value, assign the rule to the published account structure), and prove it by posting an intentionally invalid journal entry during the test phase.
Trying to set default financial dimensions on customer, vendor, site, warehouse, or item records and finding the dimension lookup empty, then concluding the dimension or the ledger setup is broken.
A dimension exists on the chart of accounts and posts fine in journals, but the default-dimension fields on master records are driven by a separate per-legal-entity list that the candidate never populated.
What to do instead
For each dimension, open the financial dimension's 'Financial dimension configuration for integrating applications' FastTab and add a line for every legal entity and master record type that needs defaults (customer, vendor, site, warehouse, item, etc.), then go back and set the default values on the master records.
Configuring credit limits and expecting sales orders to be blocked automatically, only to find orders confirm and ship; or releasing a credit hold once and wondering why the customer's later orders are still affected.
The credit limit value alone does nothing. A credit limit check point must be selected (for example at sales order confirmation or picking/packing), credit management must be enabled in the Accounts receivable parameters, and holds must be explicitly released for each order - the system clears a hold only when the account falls back under the limit or a user releases it.
What to do instead
Plan the check points with the business first, set each credit limit check point accordingly, define credit limit and temporary credit limit on the customer, then test both paths: an order that exceeds the limit and is held, and the manual release of that specific order after payment or limit increase.
Posting customer payments through a payment journal or the settle-transactions screen without opening 'Settle transactions', so the invoice remains open and then appears in aging, collection letters, and credit limit calculations.
Posting a payment and settling it are two separate acts. If the settlement form is skipped, the ledger is correct but the subledger still shows the invoice as open, so the candidate sees wrong aging and assumes the payment terms or posting profile is wrong.
What to do instead
Always drive the payment from the invoice context and open 'Settle transactions' (or use 'Mark invoice as paid' only when the invoice was already posted as paid), then confirm with the customer open transactions list and an aging report that the balance is zero before moving on.
Setting up a three-way match requirement and then testing with invoices that refuse to match, and responding by disabling matching instead of fixing the configuration.
Invoice matching is governed from two directions: the vendor group's invoice matching validation level and the item model group / category's product receipt and matching policy requirements. Turning off matching makes the demo pass but abandons the control the requirement asked for.
What to do instead
Set the matching level on the vendor group (invoice totals, two-way, three-way as required), set the matching policy on the item model group or procurement category, ensure a product receipt exists for three-way, and test with one matched and one deliberately mismatched invoice to confirm the tolerance/approval path.
Recording everything through vendor invoice journals even where the scenario mentions approval workflow, prepayments, or encumbrance, and then being unable to show where the invoice waits for approval or how the prepayment links to the final invoice.
The invoice journal posts immediately and bypasses the pending-vendor-invoice workflow. Candidates pick it because it is the fastest path to a voucher, then hit a requirement that only the pending or register-and-approval route supports.
What to do instead
Route to the right artifact deliberately: pending vendor invoices when workflow or matching is needed, the invoice register plus approval journal when segregation of duties is required, and the invoice journal only for non-PO, non-workflow items. For prepayments, use the prepayment journal voucher and apply it against the final invoice.
Tuning an active budget control configuration (adding a dimension, changing over-budget permissions, changing the budget model) and then leaving the form, believing budget checking is still live.
Any edit to a budget control configuration puts the whole configuration back into Draft status. Budget checking silently stops enforcing anything, so subsequent purchase requisitions and orders post without the expected warning or error.
What to do instead
After every change, click Activate on the budget control configuration and confirm the status reads Active for that legal entity, then re-test one over-budget transaction and one transfer to prove the enforcement is back.
Turning on budget control but seeing 'no budget funds available' for transactions the client insists are budgeted, and responding by removing dimensions from budget control.
Budget funds available is computed only for the budget model, budget types, and dimensions defined in the 'Budget funds available' definition, and only for budget register entries posted with that model and the matching dimension values. Removing dimensions makes the check pass but destroys granularity.
What to do instead
Reconcile the definition to the budget register entries: confirm the budget model selected in the configuration matches the model on the posted entries, that the entries' budget type is included, and that the dimension values used on the transaction exist in the budget. Then re-test with an exact matching combination before widening the definition.
Configuring a purchase order so the receipt should create a fixed asset, then finding no asset record after posting, and manually creating the asset to recover the demo.
Fixed asset acquisition from procurement is gated by settings on both sides: the Fixed assets parameters switch for acquiring assets from purchasing, and the item group's fixed asset posting/receipt configuration. Without both, a normal product receipt simply hits an inventory or expense account.
What to do instead
Enable acquisition from purchasing in Fixed assets parameters, set the item group to create the fixed asset on product receipt or invoice as the scenario requires, link the fixed asset group on the PO line, then verify the asset exists before posting the vendor invoice and check the resulting acquisition transaction.
Disposing of or transferring an asset and reporting the gain/loss or net book value, without first running and posting depreciation through the disposal date.
Disposal uses the net book value at the moment it posts. If depreciation for the current period was never proposed and posted, the book value is overstated, producing a wrong gain/loss figure and a subsequent reconciliation break that is hard to trace back.
What to do instead
Run the depreciation proposal, review it, post the depreciation journal for the period containing the disposal date, then dispose and validate the net book value and gain/loss against the depreciation profile and convention (half-year, mid-month, full month) chosen for that book.