MB-330 common mistakes
MB-330 · Understand the traps and how to avoid them.
When a scenario says a product is sold in several colors and sizes, the candidate creates and releases one separate product per combination instead of building a product master with variants.
Case scenarios describe variant-heavy products, and translating each combination into its own product feels concrete and safe under time pressure; the later questions about shared attributes, dimension-based pricing, or variant-level on-hand then no longer match the answer options.
What to do instead
Create a product master, activate only the dimensions the scenario needs (for example Color and Size) in a product dimension group, add one variant per combination, then release the master once per legal entity. Each variant becomes a released product variant that shares the item number and base data, which is what the exam's variant questions assume.
Places dimensions in the wrong dimension group, for example putting Location or Batch on the product dimension group to create variants, or expecting Site and Warehouse to generate variants.
All three group types appear on the same released product and look interchangeable, so the candidate assigns dimensions by name rather than by function.
What to do instead
Memorize the three roles: product dimension group drives variant generation (Color, Size, Style, Configuration); storage dimension group defines where stock physically sits (Site, Warehouse, Location, Pallet); tracking dimension group defines how stock is traced (Batch, Serial, Owner). Only dimensions active on the product dimension group create variants, and Location must be active in the storage dimension group before warehouse work can run.
Uses inventory close and inventory recalculation interchangeably, for example recommending inventory close to correct the cost of one item, or running close for the same period repeatedly without reversing it first.
Both are periodic costing jobs found under the same area and both visibly change cost amounts, so the functional difference blurs when the question is worded around 'fixing the cost'.
What to do instead
Recalculation recomputes on-hand cost amounts and can be run whenever needed; inventory close settles issues against receipts for a period, posts the resulting adjustments, and must be reversed before it can be run again for that period. Choose close for period-end settlement and recalculation for correcting cost amounts mid-period.
Answers consignment scenarios as though consignment stock were owned stock, assuming it can be reserved against a sales order or that receiving it already creates the vendor liability.
Consignment inventory physically sits in the company's warehouse, so on-hand and availability screens look familiar; only the Owner tracking dimension and the consumption journal change what is owned and when the liability appears.
What to do instead
Model consignment with the Owner tracking dimension so vendor-owned quantity sits on-hand but is not financially owned and cannot be reserved. The financial transaction and vendor liability are created when the consumption journal is posted, which transfers ownership from the vendor to the legal entity.
Builds or selects the wrong category hierarchy, for example creating a product category hierarchy to drive purchasing policy rules and category access restrictions, or a procurement category hierarchy to drive retail attributes and channel listings.
Both are multi-level category hierarchies with similar maintenance forms, and the words 'category' appear throughout both the procurement and the product information areas.
What to do instead
Choose by purpose: the procurement category hierarchy governs buy-side rules such as purchasing policy rules, category access policies, requisitions, and vendor rebates. The product (retail) category hierarchy governs sell-side behavior such as attributes, assortments, and channel listings. Confirm which hierarchy is assigned as the procurement category hierarchy in Procurement and sourcing parameters before answering policy questions.
Configures only one side of an intercompany relationship and then expects a sales order in one legal entity to automatically generate the matching purchase order in the other legal entity.
Intercompany is really a reciprocal customer/vendor pairing, and it is easy to create one record, skip the intercompany flag, or miss the partner mapping on the second entity.
What to do instead
Create the reciprocal pair explicitly: in legal entity A a customer flagged as intercompany that points to B's vendor account, and in legal entity B a vendor flagged as intercompany that points to A's customer account. Orders only flow when the intercompany flag is set and the trade partner resolves to the configured account, so verify both directions before predicting order flow.
Designs location directives, work templates, and waves for a warehouse that is not actually enabled for warehouse management processes, then expects work to be generated.
The scenario states that warehouse management processes are used, so the candidate jumps straight to directives and templates and skips the enabling switches that sit on the warehouse and the storage dimension group.
What to do instead
Verify the prerequisites in order: Location active in the item's storage dimension group, Use warehouse management processes selected on the warehouse, the item released to that warehouse, and Location at the bottom of the reservation hierarchy. Only then will location directives and work templates produce work.
Confuses the roles of the wave template, work template, work class, and location directive, for example expecting a wave template to choose the picking location or attaching the location directive to the shipment instead of to a work template line.
All four artefacts appear on the outbound flow and all are configured with queries and sequences, so the candidate merges them into one mental model.
What to do instead
Separate the chain: the wave template decides which shipment lines are waved and which work template is used; the work template defines the work order type and the pick/put line sequence with a location directive attached to each line; the location directive query selects the actual location; work classes group the work for mobile device execution. Mobile menu items then determine what the operator can do.
Selects a coverage code from memory instead of from the demand pattern, for example Min/max for an item that must be replenished by an exact quantity per requirement, or leaving items on Manual coverage and still expecting master planning to generate planned orders.
The coverage codes have similar-sounding names and all are described as 'creating orders', so the distinguishing behavior is not recalled under exam pressure.
What to do instead
Match the code to behavior: Manual produces no planned orders, Requirement orders exactly for each requirement, Period consolidates all demand in a period into one order, and Min/max replenishes to the maximum when on-hand falls below the minimum. Check coverage group defaults versus item coverage overrides before predicting what the plan will output.
Treats static and dynamic master plans as interchangeable, for example expecting a static plan to include demand entered after the last run without a regeneration.
Both plans are started from the same form and both produce planned orders, while the difference lies in whether the run uses a stored snapshot of master data.
What to do instead
State the difference explicitly: a static plan runs against a snapshot of master data and must be regenerated to see changes, while a dynamic plan uses current data and reflects changes on the next run, which makes it the usual choice for operational planning. Also confirm which planning engine is enabled (Planning Optimization versus the deprecated built-in MRP), because not every legacy behavior is supported in Planning Optimization.