Par levels for models that meet various requirements

[dhammond3]

How do you set par levels for stockrooms that use different models that meet the requirements of a standard device? Our warehouse currently fulfills stock levels by Standard Laptop, Standard Monitor, etc... Which means we send First In-First Out. Does anyone use par levels with similar setup?

[Vikram Reddy]

Hello @dhammond3,

I'm assuming you're running out-of-the-box HAM stock rules here, not a custom aggregation script. If so, set your par levels at the generic Model level, not Model Category: give each standard, Standard Laptop, Standard Monitor, its own hardware model, and point catalog items at that model instead of a specific vendor SKU. A Stock Rule only accepts a Model and a Stockroom, Model Category isn't a supported option there, it's really just a reporting bucket that doesn't aggregate cleanly for threshold math. Receive whichever physical SKU you're actually stocking against that same Standard model so it counts toward on-hand quantity, and the Stock Rule Runner job handles the reorder or transfer once FIFO consumption drops you below par.

Thank you,
Vikram Karety
Octigo Solutions INC

[fknell]

Could you please elaborate further how this should work or how you implemented your proposal? 

Thanks!

[Vikram Reddy]

Hi @fknell,

The scenario behind my last post is this: you've got a Model Category like "Standard Laptop" with three or four vendor SKUs mapped into it (Dell, Lenovo, HP, whatever meets spec that quarter), and you want one par threshold to cover all of them combined instead of running a separate rule per SKU. Answering for that case, since that's the one that actually trips people up.

The core constraint is that alm_stock_rule only ever points at one row in cmdb_model. There's no field on the stock rule for Model Category, and even if there were, the model category value on the asset record itself is a slush bucket field, so you can't cleanly GlideAggregate against it the way you'd want to for threshold math. That's the wall everyone hits, and it lines up with what a ServiceNow employee laid out in an older community thread on this exact ask: model substitutes, not model category, is the workable path. Two ways around it, and honestly which one you pick depends on why you have multiple SKUs in the first place:

1. Scenario A, opportunistic sourcing. Procurement buys whichever approved laptop SKU is cheapest or in stock that week, but functionally they're interchangeable. Here I'd normalize at receiving: build one canonical model record ("Standard Laptop 15in") and have your receiving Transform Map or a before-insert business rule on alm_asset rewrite the model field to that canonical record regardless of which vendor SKU actually showed up on the PO. Now the native Stock Rule Runner job works with zero customization, because it's just counting against one model like it always does. The tradeoff: you lose the vendor-specific model on the asset itself, so if you need that for warranty lookups or depreciation schedules, stash the real SKU in a custom field (u_vendor_model or similar) before you overwrite the model reference.
2. Scenario B, models that genuinely need to stay distinct. Think mobile phones that get refreshed every year, or laptops where you still want separate depreciation and warranty tracking per SKU even though they satisfy the same spec. Here don't normalize, use cmdb_m2m_model_substitute (labeled Model Substitution in the CMDB) to link each SKU to a primary model. Then write a scheduled script that sums quantity across the primary model plus its substitutes and handles the reorder yourself, because the native Stock Rule Runner still only evaluates the exact model on the rule row, it will never walk the substitute relationship for you.

A rough version of that scheduled script, evaluated per stockroom per primary model, using GlideAggregate to do the counting:

var primaryModel = '<sys_id of primary model>';
var stockroom = '<sys_id of stockroom>';
var threshold = 10;

var models = [primaryModel];
var sub = new GlideRecord('cmdb_m2m_model_substitute');
sub.addQuery('model', primaryModel);
sub.query();
while (sub.next()) {
    models.push(sub.getValue('substitute'));
}

var ga = new GlideAggregate('alm_asset');
ga.addQuery('model', 'IN', models.join(','));
ga.addQuery('stockroom', stockroom);
ga.addAggregate('COUNT');
ga.query();

var onHand = 0;
if (ga.next()) {
    onHand = parseInt(ga.getAggregate('COUNT'), 10);
}

if (onHand < threshold) {
    // create your transfer order, PO, or stockroom manager task here
}

Before you build either path, a few things worth checking on your instance so you don't fight the platform:

• whether the resource_category field on cmdb_model_category already has an ACL locking it down, since that trips up people trying to script against it directly
• whether any cmdb_m2m_model_substitute records already exist for your models, some instances have these seeded from a data import and nobody remembers
• the Order Quantity field on your existing alm_stock_rule records, since Scenario B needs you to replicate that restock math yourself
• your stockroom hierarchy (parent stockroom relationships), because if Scenario B needs to aggregate across child stockrooms too, the query above has to walk that hierarchy as well

Scenario A is less code and more reliable long term, honestly, most shops go that route once they realize how thin the "distinct SKU" requirement actually is in practice. Scenario B is more accurate to reality but it's on you to maintain going forward, nothing native will pick up the slack.

Thank you,
Vikram Karety
Octigo Solutions INC

[fknell]

Hi @dhammond3,

Unfortunately, ServiceNow doesn't support functional or later model binding, meaning you can't create a standard laptop and map it to a set of equivalent SKUs from different vendors later in the process. 

Hope this helps!