Say «counting» to two different EWM people and you may not be talking about the same thing. One will think of cycle counting — the periodic physical-inventory sweep that keeps book stock honest, unrelated to quality, running on both architectures. The other will think of the quality measure that fires the moment a delivery hits goods receipt, checking whether the quantity you actually received matches what the system expects. This post is about the second one.
And even once you are talking about the right «counting,» there is a second layer of the same confusion waiting underneath: two mechanisms that look identical to the person doing the counting, built on completely different architecture.
What Counting Actually Checks
Counting, as a quality measure, exists to ensure consistency between the quantity entered in the system and the quantity actually there — it is a check on how much arrived, not on its condition. It is one of the inspection object types the Quality Inspection Engine supports: IOT2, Counting Inbound Delivery.
That single fact already limits where this post applies. IOT2 is one of the three object types — alongside IOT1 and IOT6 — that SAP Note 2861813 retired from embedded EWM. If you are running embedded, this specific mechanism structurally is not on your system; counting as a formal quality process, the way this post describes it, is a decentralized-EWM story.
Two Mechanisms, One Job, Different Footprint
Decentralized EWM offers two ways to run a count, and from the floor they can look like the same task with a different label.
Implicit counting rides entirely inside the warehouse task that was going to happen anyway. There is no separate document, no work center, no extra routing step. If the quantity is off, the person confirming the task confirms it with a difference and enters an exception code that says why — wrong quantity delivered, something damaged during putaway, whatever fits. That is the entire mechanism.
Explicit counting is the heavier of the two. It requires a work center — it does not matter whether that work center runs the classic work center transaction or a mobile RF device, both are valid front ends — and a real inspection document generated against an inspection rule, the same rule-and-document machinery Post 1 covered for every other IOT. Process-oriented storage control is what actually gets the stock physically to that work center in the first place; without it, nothing routes there on its own.
What Happens When the Numbers Do Not Match
Both mechanisms end at the same fork: a difference gets entered, and an exception code says what kind. The exception code is not just a label for a report — it is what the system reads to decide the follow-up. The single most common outcome is a correction that runs backward through the documents that already exist: the inbound delivery in EWM gets updated to the corrected quantity, that correction propagates to the inbound delivery in the ERP system, and if a goods receipt was already posted against the wrong number, that posting gets corrected too.
The exception code is doing double duty
It is simultaneously the reason code a supervisor reads later («wrong quantity delivered,» «damaged in putaway») and the trigger for what the system does next. Get the exception code catalog wrong — too coarse, or missing the case your warehouse actually hits — and you either lose the audit trail or lose the automatic correction. It is worth treating as seriously as an inspection rule, even though implicit counting skips the inspection rule machinery entirely.
The Exception Code Framework Behind Implicit Counting
Exception codes are not specific to counting — they are a general RF and warehouse-task mechanism, and counting is simply one of the places that uses it. On an RF screen, the exception code field sits in the same spot on every screen that supports it, usually the lower-right corner. Some exception codes need nothing further from the user — a full handling unit, for instance, needs no extra input beyond the code itself. Others, a missing-quantity difference among them, open a follow-up screen asking for the actual quantity found.
Two BAdIs sit behind the scenes if the standard behavior needs adjusting. /SCWM/EX_EXCP_EXC_FLT (Filter Exception Codes), called from /SCWM/CL_EXCEPTION_APPL‘s GET_EXCEPTION_CODE method, lets you remove exception codes the system would otherwise offer — useful if your warehouse has codes defined that should not apply to a particular transaction or role. /SCWM/EX_EXCP_EXC_FLT_FOLLOUP does the same filtering one step later, on the follow-up actions an exception code would normally trigger.
Hands-On: Setting Up Both Mechanisms
The tolerance question comes first, before either mechanism does anything: how big does a difference have to be before it counts as one at all? SCM Extended Warehouse Management → Extended Warehouse Management → Cross-Process Settings → Quality Management → Quality Management for Decentralized EWM → Inspection Planning → Counting defines the quantity and value intervals that decide it. This setting applies underneath both mechanisms — it is not something implicit and explicit counting each configure separately.
For implicit counting:
1. Cross-Process Settings → Exception Handling → Maintain Business Context for Exception Codes. Create or reuse a business context for the warehouse task confirmation step where counting differences can occur.
2. Same menu → Define Exception Codes. Create the code for your warehouse — a short one, since whoever enters it will be doing so mid-confirmation, under an RF scan gun or at a desktop screen — with a description that will still make sense in a report six months later.
3. Maintain Process Parameters for the code, mapping it to the internal process it should trigger. This is the step that decides whether entering the code actually corrects the inbound delivery automatically or merely records the difference for someone to act on later.
For explicit counting: the sequence is the same generate-activate pattern Post 1 walked through for IOT4, run against IOT2 instead — Define and Activate Warehouse-Dependent IOTs with 2 in the Insp. Obj. Type field, generate a version, activate it, then build the inspection rule via /SCWM/QRSETUP. The one difference worth watching: without process-oriented storage control actually configured to route to a counting work center, the rule can be perfectly valid and still send nothing anywhere. Confirm the routing before you trust the rule.
RF — Explicit Counting
Explicit counting is one of the few mechanisms in this series that genuinely does not care which front end reaches the work center: the classic work center transaction and a mobile RF device are both first-class options, not a desktop process with an RF afterthought bolted on. Implicit counting, by contrast, has no separate RF story at all — it simply happens wherever the warehouse task confirmation already runs, RF included by default, because there is no separate mechanism to add RF support to.
What Comes Next
Counting answers «how much arrived.» It says nothing about whether what arrived is any good — that is a completely separate question, and it is where the next post starts. Two processes that both call themselves sampling, both hang off IOT4, and behave nothing alike the moment a result comes back bad: one can stop a delivery cold with a hard error, the other cannot block anything no matter how bad the result is.
Part of the Quality Management series
Previous ←
The Engine Embedded EWM Doesn’t Use
Next →
One Can Stop the Truck, the Other Cannot (coming soon)
Deja un comentario