Itemprocessingparameters

Version: v1 (minor version 0) Scope: singleton per store Owning service: item-registry

Itemprocessingparameters is a singleton per store containing the four parameters that govern how Item Registry accepts and applies incoming backoffice item updates. It was created to move these configuration knobs out of Pricer Server's monolithic SystemParameter table and into a DTO-flow-compatible, versionable form that Item Registry can subscribe to. Each parameter maps directly to an existing Pricer Server system parameter (the original parameter names are noted below).

ID pattern

t/{tenantid}/s/{storeid}/itemprocessingparameters

Segment	Meaning
t/{tenantid}	Tenant scope
s/{storeid}	Store scope — each store can have independent processing behaviour
itemprocessingparameters	Fixed singleton name; exactly one record per store

Example: t/10001/s/S001/itemprocessingparameters

Schema

Field	Type	Default	Pricer Server parameter	Description
id	string	—	—	Full resource name following the ID pattern above
unknown_item_behavior	UnknownItemBehavior enum	INSTALL	UNKNOWN_ITEM_IN_UPDATE	Controls what happens when an update arrives for an item ID that does not yet exist in the store
sic_append	bool	true	SIC_APPEND	When true, incoming SICs on an update are appended to the existing SIC list. When false, the incoming SICs replace the list entirely.
sic_allow_moving_sic	bool	false	SIC_ALLOW_MOVING_SIC	When true, a SIC already owned by another item may be moved to the incoming item. When false, a SIC conflict causes the update to be rejected.
reject_update_on_unlinked	bool	false	REJECT_UPDATE_ON_UNLINKED	When true, item updates are rejected if the item has no active ESL link. When false, updates are accepted regardless of link status.

UnknownItemBehavior enum

Value	Meaning
UNKNOWN_ITEM_BEHAVIOR_UNSPECIFIED (0)	Proto3 zero value; receivers treat this as INSTALL
INSTALL (1)	The item is created when an update arrives for an unknown item ID. This is the default behavior.
IGNORE (2)	The update is silently discarded. No error is returned to the sender; the item is simply not created.
REJECT (3)	The update is rejected with an error. Useful when unknown item IDs should be treated as data quality issues.

Parameter semantics in detail

unknown_item_behavior

This is the most consequential parameter. Retailers with tightly controlled item master data typically use REJECT or IGNORE to prevent unknown items from polluting the store's item registry. Retailers onboarding a new store or running bulk data migrations typically use INSTALL (the default).

sic_append and sic_allow_moving_sic

These two parameters work together to govern SIC management. In a typical configuration (sic_append=true, sic_allow_moving_sic=false): - New SICs in an update are added to the existing list without clearing it. - If a SIC is already attached to a different item, the update is rejected.

With sic_allow_moving_sic=true, a SIC can be transferred from one item to another in a single update — useful in scenarios where product repackaging causes barcodes to change ownership.

reject_update_on_unlinked

When true, this acts as a guard for stores where item data should only be maintained while an ESL is actively linked. Unlinked items — items that have no label — are not updated, reducing unnecessary write traffic to the system.

Omitted parameters

The full parameter survey covered all ~180 parameters in Pricer Server's SystemParameter.java. Parameters deliberately omitted from this DTO include:

• PFI pipeline parameters (MESSAGE_FILE_PATH, DROP_FOLDER_*, PFI_*, etc.) — these concern the drop-folder file ingestion path, not online item updates. Suggested future DTO: pfiparameters.v1.proto.
• Communication and scheduling parameters — belong in service-specific configuration DTOs.

Consumed by

Service	Why
item-registry	Reads this singleton at item update processing time to decide whether to create, ignore, or reject unknown items, and how to reconcile incoming SICs

Related DTOs

• itemproperties — co-singleton at the same store scope; defines the property catalogue for the store
• storeitemvalues — the sic_append and sic_allow_moving_sic parameters directly affect the sics list written to each Storeitemvalues record