x++ list enumerator

In Dynamics 365 Finance & Operations, the if statement is the simplest way to express branching around warehouse flow—think “should we create pick work, backorder, or stop?” For a beginner, start with a single clear condition, then add an else path that communicates what happens when rules aren’t met. Keep variables typed and names meaningful so intent is obvious during investigations on a busy floor.

// Beginner: validate LP is present before continuing
WMSLicensePlateId lp = "LP123";
if (lp)
{
    info(strFmt("LP %1 received at staging.", lp));
}
else
{
    warning("Missing license plate; cannot stage.");
}

As you get comfortable, intermediate code often chains conditions and normalizes decision order: preconditions first (data present?), then domain rules (status, quantity), then side effects (make work, reserve). Short-circuit early to keep the “happy path” readable. In warehousing, it’s common to validate line state, physical availability, and cutoff windows before committing to work creation.

// Intermediate: gate picking on status + availability
if (salesLine && salesLine.RemainInventPhysical() > 0)
{
    if (WHSWorkCreateHelper::isLinePickable(salesLine))
    {
        info("Creating pick work…");
        // WHSWorkCreate::build(...);
    }
    else
    {
        warning("Line not pickable due to reservation or wave rules.");
    }
}
else
{
    warning("No physical qty or line missing.");
}

Advanced usage keeps logic expressive and testable. Prefer extracting complex boolean expressions into well-named helper methods (or value calculators), and centralize business flags so that toggles don’t leak everywhere. Guard irreversible actions (like WHSWorkCreate) with explicit if checks that read like policy, log the reason when you don’t proceed, and avoid nesting by returning early from small methods.

// Advanced: policy-style guards with clear reasons
if (!WarehousePolicy::isWithinCutoff(salesTable, systemDateGet()))
{
    info("Skipping work: after shipping cutoff.");
    return;
}

if (!InventoryPolicy::hasPickableQty(salesLine))
{
    info("Skipping work: no pickable qty under current reservations.");
    return;
}

// All guards passed — perform the action last
WHSWorkCreate::buildForSalesLine(salesLine);
info("Work created for LP and line.");

A few practical tips across all levels: (1) keep conditions small and named—readers should grasp why a branch fires; (2) place safeguards (null/empty checks) first to fail fast; (3) when a decision depends on time, status, and stock, separate those checks so operations can log precisely which rule blocked the flow; and (4) for UI or integration paths, prefer informative info()/warning() messages that help ops staff resolve issues without diving into code.

In D365FO X++, the ternary operator cond ? a : b shines when you’re choosing a value, not a workflow. It keeps assignments tight and readable when both outcomes are simple. For example, when labeling a carton on the packing station, you might select a short tag based on weight class in one line instead of three:

// Pick a label text, not a whole workflow
str label = (grossWeight > 31.5) ? "HEAVY" : "STD";

The classic if is better when you’re branching into actions, logging reasons, or doing more than a single expression. Warehouse rules often need guardrails, messages, and calls into WHS classes. That’s where a full if keeps intent crisp:

// Actionful branch with side effects
if (WHSWorkCreateHelper::isLinePickable(salesLine))
{
    info("Creating work…");
    // WHSWorkCreate::buildForSalesLine(salesLine);
}
else
{
    warning("Line not pickable under current reservations.");
}

Type clarity also nudges the choice. The ternary must return a single compatible type on both sides; mixed types or complex objects can get awkward and harder to read. If you find yourself casting or calling multiple methods just to make the ternary compile, switch to if and name the steps. Conversely, when you’re computing a small value that feeds another call—like deciding a mode string or a boolean flag—the ternary keeps momentum:

// Feed a small computed value into another call
boolean expedite = (isCutoffSoon && hasCarrierCapacity);
WHSWave::suggestBatchSize(expedite ? 200 : 80);

Readability is the tie-breaker. If the condition or outcomes need comments, logging, or more than one statement, if reads like policy and helps ops and devs trace behavior. If it’s a tiny, pure choice with no side effects—especially in value-building code—the ternary keeps your intent on one line and your method compact. In short: use if for decisions that do things; use ?: for decisions that produce values.