Itemproperties¶

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

Itemproperties is a singleton per store that exports the complete item property catalogue maintained by Pricer Server for that store. It serves two purposes. First, it mirrors the GET /itemproperties REST API response, making the property list available to DTO-flow consumers without polling HTTP. Second, it carries a dynamically generated protobuf FileDescriptorProto that encodes a typed StoreItem message for this specific store. Consumers holding this descriptor can deserialise binary item payloads without a compile-time schema — the field numbers in the generated message correspond directly to the numerical_id values of the property definitions.

ID pattern¶

t/{tenantid}/s/{storeid}/itemproperties

Segment	Meaning
`t/{tenantid}`	Tenant scope
`s/{storeid}`	Store scope — each store has its own property catalogue
`itemproperties`	Fixed singleton name; there is exactly one record per store

Example: t/10001/s/S001/itemproperties

Schema¶

Field	Type	Description
`id`	string	Full resource name following the ID pattern above
`properties`	repeated PropertyDefinition	All property definitions for this store. Sorted by `numerical_id` ascending for consistent serialisation.
`proto_descriptor`	google.protobuf.FileDescriptorProto	Dynamically generated protobuf schema for the typed `StoreItem` message for this store. Field numbers in the generated message equal the `numerical_id` values in `properties`. The `.proto` source text is not stored; it can be derived from this descriptor.

PropertyDefinition message¶

Field	Type	Description
`name`	string	Property name as used in item update payloads and rendering expressions. System-defined properties use camelCase (e.g. `itemId`, `itemName`). Custom properties preserve their original casing from the PFI definition.
`numerical_id`	int32	Unique property identifier assigned by Pricer Server. Also used directly as the protobuf field number in the dynamically generated `StoreItem` message. The mapping is stable across stores and server versions.
`type`	PropertyType enum	Value type of the property
`max_length`	int32	Maximum allowed string value length. `0` indicates no constraint (Pricer Server's `Integer.MAX_VALUE` is mapped to `0` on export).
`is_system_defined`	bool	`true` for properties built into Pricer Server; `false` for custom properties added for this store via PFI

PropertyType enum¶

Value	Meaning
`PROPERTY_TYPE_UNSPECIFIED` (0)	Unset
`STRING` (1)	Text value
`PRICE` (2)	Numeric price value
`DATETIME` (3)	Date/time value

System-defined properties¶

These properties are present in every store and have stable numerical_id values:

name	numerical_id	type
`itemId`	2	STRING
`department`	5	STRING
`itemGroup`	6	STRING
`itemName`	7	STRING
`price`	23	PRICE
`presentation`	121	STRING

Custom properties are allocated in ranges starting at 201. Known observed ranges: 201–245 (common custom fields such as Brand, MainBarcode, PLU), 299–361 (consolidated/central properties), 450–462 (promotion/discount price fields in Plus stores).

Intentionally excluded properties¶

lastUpdated (numerical_id 250) — the data platform provides this as metadata; it is not stored as part of the item's own property set.
validFrom (numerical_id 9500) — an input-only scheduling field on the item update PATCH API, not a stored item attribute. Consumers must not treat it as queryable item data.
sics — Store Item Codes are a first-class structural field in Storeitemvalues, not an entry in the property catalogue.

The proto descriptor¶

Pricer Server generates a StoreItem message at runtime for each store. The field numbers in the generated message equal the numerical_id values. A minimal example for a store with three properties might look like:

syntax = "proto3";
message StoreItem {
  string id         = 1;
  string itemId     = 2;
  string itemName   = 7;
  string price      = 23;
  string myCustomProp = 201;
}

Consumers that receive the proto_descriptor can register the message type at runtime with a dynamic message factory and deserialise StoreItem binary payloads without any code generation step.

Consumed by¶

Service	Why
`item-registry`	Reads the property catalogue to validate incoming item updates and to construct `Storeitemvalues` records
Studio rendering pipeline	Uses `properties` to understand which item fields are available in design expressions

storeitemvalues — the actual item key-value data; custom_properties keys correspond to name values in this catalogue
itemprocessingparameters — governs how item updates are accepted; co-singleton with Itemproperties at the same store scope