Configuration

Stock Count itself has very little to configure: which items a count lists follows from the count's type, its filters and the stock, not from settings. What is configurable is when counting staff are warned about a deviation, and whether Stock Count should generate counts of suspicious items on its own. Beyond that, a count depends on settings owned by other services.

Deviation thresholds

Three settings decide when a counted quantity is far enough from the expected quantity to deserve a second look. Each is its own Customer Controlled Configuration (CCC) kind holding a single property.

Setting	CCC kind and property	Warns when
Max quantity deviation	stc.max-quantity-deviation.v1 maxQuantityDeviation — integer ≥ 0, nullable	the counted total differs from the expected quantity by more than this many units, up or down
Max quantity deviation in percentage	stc.max-quantity-deviation-in-percentage.v1 maxQuantityDeviationInPercentage — integer ≥ 0, nullable	the difference is more than this percentage of the expected quantity
Max cost value deviation	stc.max-cost-value-deviation.v1 maxCostValueDeviation — integer ≥ 0, nullable	the difference, valued at the item's cost, is more than this amount

• Unset means no warning of that kind, and so does 0. With none of the three set, nothing is flagged.
• They are independent: an item can exceed one and not the others, and each exceeded threshold is reported separately.
• The comparison uses the item's counted total across all locations against the expected quantity, so counting the first of several locations can trigger a warning that disappears once the rest are counted.

Scope. Set per tenant, per business-unit group or per store in CCC. Stock Count applies the effective value for each store, so a store can be stricter than its region.

Where the thresholds show up:

• While counting. Registering a quantity returns the thresholds it exceeds, and the app warns the counter straight away.
• In the deviation review. Before a category is marked as done, and before the count is submitted, the app lists the items outside the thresholds for review.
• In the reports. The item reports can leave out every item within the thresholds (doExcludeWithinThreshold=true) — see The API.

A threshold is a warning, never a block. A count with deviations above every threshold can still be submitted, and its quantities are applied as counted.

Counting suspicious items

One CCC kind, stc.suspicious-stock-count-generator.v1, switches on suspicious-item counts for a store and decides how often they come. Like the thresholds, it is set per tenant, group or store and applied per store.

Property	Type	Default when unset	Meaning
doGenerateStockCountForSuspiciousItems	boolean	false	Switch the generated counts on
weekdayToBeGenerated	Monday … Sunday	Monday	The weekday a count is generated on
intervalInWeeks	integer	2	Generate at most once every this many weeks
minNumberOfWeeksSinceLastCount	integer	6	Leave out items counted within this many weeks
slowSalesFactorThreshold	number between 0 and 1	0.1	How sharply sales must have slowed: 0.1 flags an item that sold less than 10 % of its usual pace over the last three days
nameOfStockCountGenerated	string	Suspicious	The name the generated count is given

A count is generated only when the report finds something: a store with no suspicious items, or where every suspicious item was counted recently, gets no count that week.

Settings in other services that a count depends on

Setting	Owned by	Why it matters to a count
Do enable PosLog processing	STP	Must be on for STP to apply counts. Despite the name it gates every feed from Hii Retail services into stock, counts included.
Stp.StockHandlingType on the item	PnP item	An item STP does not stock-handle never has stock information, so it is never listed, and a counted quantity for it does not change any stock.
The store's assortment	PnP	The candidates for a full count
Saved searches	PnP	The candidates for a cycle count
The item's purchase price	PnP	Values a deviation when STP has no cost for the item yet
Store status and type	Business Unit Management	Only active physical stores receive recurring counts

What each setting affects

Symptom	Check first
Submitted counts do not change the stock	STP's Do enable PosLog processing for the tenant — and whether the count was a test count, which is never published
A full count lists nothing, or stays on Preparing items…	Whether STP holds stock for the store at all — see Stock ownership
An item is missing from a count	Why is an item not in my count?
No suspicious-item count appears	doGenerateStockCountForSuspiciousItems is off for the store, today is not its weekdayToBeGenerated, the interval has not passed, or nothing was flagged
Staff are never warned about deviations	None of the three thresholds is set for the store, or they are set to 0
A recurring definition generates nothing for one store	The previous count it generated there is still open, or the store is not an active physical store — see Recurring counts

Read next

• The API — the endpoints, including the reports that use the thresholds
• Types of count — what decides the item list