MB-335 common mistakes
MB-335 · Understand the traps and how to avoid them.
Treating product masters, released products, and product variants as interchangeable when setting up a new item, and trying to configure dimension groups on a product master that will never be released.
The exam tests the distinction between shared product definitions and company-specific released products, and candidates often learn the UI flow by clicking through one entity type and then apply those steps to another. The terminology overlap (product, product master, released product, variant) makes it easy to assume one object covers all cases.
What to do instead
Build a mental decision table before answering: a product master exists only to carry variants and is created with a product dimension group that includes the variant dimension; a released product is the company-scoped record that carries storage and tracking dimensions, item model group, and site/warehouse defaults. Practise creating a distinct product, a product master with variants, and a released product from each, and note which fields appear at which step.
Configuring a product variant by manually creating dimension combinations instead of using the variant suggestions, then failing to notice that a variant is missing or duplicated when the configuration is applied to an order.
Manual creation feels faster for small examples, but the exam scenario usually involves a dimension group where not all combinations are valid. Candidates then answer questions about which variants exist without checking the suggestion criteria, and they miss that unused or blocked variants behave differently at order entry.
What to do instead
Use the variant suggestions form driven by the product dimension group, then review the generated list for completeness before releasing. When a question describes a missing variant at order entry, check the product dimension group, the released variant status, and whether the variant was blocked rather than assuming a pricing or trade agreement problem.
Building a product configuration model with constraint expressions that reference the wrong component or use the wrong operator, so the model validates in the designer but fails at configuration time on a sales line.
The expression language is terse and the designer's validation is not the same as runtime evaluation against a specific set of user selections. Candidates memorise syntax for 'implies' and 'requires' but not the scoping rules for referencing attributes across subcomponents.
What to do instead
For each constraint, identify the fully qualified path to every attribute it touches and confirm the constraint is attached at the level where all referenced attributes are in scope. Test by running the model through the configuration UI with several selection combinations, including ones that should be blocked, and confirm the error appears where expected.
Setting up a bill of materials with the wrong BOM version, site, or effective dates, and then answering questions as if the BOM will be picked up for a production order at a different site.
BOM selection depends on a combination of item, site, date, and version activation, and candidates often configure only the lines and forget the header-level selection criteria. The exam deliberately places the production order at a site other than the one where the BOM was created.
What to do instead
Always check four things on a BOM header before reasoning about explosion: the site, the active version and its from/to dates, the BOM status, and whether the item's default order settings point to that BOM. If the scenario states a different site, the answer usually involves a separate BOM or a site-specific version, not a fallback to the original.
Confusing routes and operations, or attaching an operation to a route without the correct resource requirements, then expecting capacity reservations to appear on the production order.
Routes reference operations, operations reference resource requirements, and resources carry capacity. Candidates who skip the resource requirement step build a route that looks complete in the designer but produces no capacity load, and they misread questions about scheduling as route errors.
What to do instead
Trace the chain explicitly: route header and route version, route lines with operation numbers and times, operation relations, resource requirements with quantity and resource type, and resources with capacity. When a question mentions missing capacity reservations, check the resource requirement and the resource's capacity settings before checking the route itself.
Choosing the wrong production type (standard, process, or lean) for a scenario, particularly answering 'lean' for a repetitive discrete item or 'standard' for a kanban-driven flow.
The three production methodologies overlap in the UI and all can produce an item, so candidates pick based on the product rather than the process characteristics described in the scenario. Signals like takt time, supermarket replenishment, and fixed-quantity kanban are the actual discriminators.
What to do instead
Map scenario keywords to methodology before reading the options: kanban, supermarket, and pull-based replenishment point to lean; formula and batch attributes with co-products or by-products point to process; discrete routing with operations and BOM explosion points to standard. Write the keyword mapping down and drill it against short scenarios.
Configuring production control parameters such as the production order status defaults, automatic BOM consumption, and automatic route card posting without understanding how they interact with the production lifecycle states.
These parameters are spread across production control parameters, item model groups, and item-level defaults, and the same behaviour can be set in more than one place. Candidates change one setting and expect the effect, not realising an item model group setting overrides or supplements it.
What to do instead
Learn the precedence order: production control parameters set the default, item model groups can override consumption and posting behaviour per item group, and item-level settings override again where available. For each parameter in a question, state which level is being changed and whether a higher-precedence level would override it.
Mixing up estimated, scheduled, released, started, and reported-as-finished states, and answering questions about what can be edited or posted at each state as if the order were still estimated.
The lifecycle has several transitions and some actions are only valid in specific states, but candidates often work from a single walkthrough where they created and immediately estimated an order. Questions that place the order in a later state then break their assumptions.
What to do instead
Draw the state diagram and annotate what each transition does: estimate calculates and reserves, schedule applies job or operation scheduling, release makes warehouse work available, start creates picking and journal entries, report as finished posts receipts. For any question, first identify the current state, then check which action is legal from that state.
Setting up a costing sheet or inventory valuation without aligning cost groups between the item, the cost group on the BOM line or route operation, and the costing sheet nodes, so indirect costs never appear.
Indirect cost calculation requires the cost group to be present at three points, and the costing sheet is a separate configuration from the BOM or route. Candidates configure the sheet and assume it applies, without checking that line-level cost groups exist and match.
What to do instead
Verify the chain for each indirect cost: cost group on the item or category, cost group on the BOM line or route operation, cost group node in the costing sheet, and the calculation formula with its basis and rate. Test with a single production order and inspect the cost breakdown to confirm the indirect cost line appears.
Treating intercompany or master planning setup as independent of the production configuration, and answering supply chain questions without checking that planned orders respect the BOM, route, and lead time settings already configured.
The additional SCM features domain pulls in master planning, intercompany, and inventory dimensions, and candidates study it as a separate topic. In reality the exam scenarios cross domains, and a planned production order depends on the coverage settings, the BOM and route versions, and the item's lead time.
What to do instead
When a question involves planned orders, check coverage group and coverage settings, the item's default order type and lead time, the active BOM and route versions for the planned site and date, and the planning parameters for the master plan. For intercompany scenarios, also confirm the intercompany customer/vendor relationship and the price and cost setup on both sides.