Oracle RMS Item Images & Extended Attributes
Oracle RMS is not just a transaction engine — it also holds the descriptive metadata that makes an item complete: images for digital channels and internal systems, physical dimensions for logistics and warehouse slotting, ticketing attributes for label printing, and the extension model that lets retailers add their own custom columns and tables without touching the core schema.
Item Images and Extended Attributes — Overview
The core ITEM_MASTER table and its satellite tables — ITEM_DESC, ITEM_SUPPLIER, ITEM_LOC — capture what an item is, where it comes from, and where it goes. But a complete item record in a modern retail environment also needs images for e-commerce and digital channels, physical dimension data for warehouse management and logistics, printing attributes for shelf labels and price tickets, and whatever additional retailer-specific attributes the business requires.
Oracle RMS provides dedicated tables for images and dimensions, a ticketing attribute structure for label printing, and a formally documented extension model for anything beyond that. Understanding all four layers is essential for developers building integrations that need a complete item data picture — particularly those feeding Product Information Management (PIM) systems, e-commerce platforms, or warehouse management systems.
Oracle RMS stores image references, not image data
A critical design point: the ITEM_IMAGE table stores URLs or file
paths that point to where images are hosted — it does not store binary image
data inside the database. Oracle RMS is not an image repository. The actual
image files live in a file system, a CDN, or a dedicated Digital Asset
Management (DAM) system. RMS holds the reference that tells downstream
systems where to find each image.
The ITEM_IMAGE Table
ITEM_IMAGE stores image references for items. The composite primary key is ITEM + IMAGE_TYPE, allowing multiple images per item — each serving a different display purpose.
| Column | Type | Description |
|---|---|---|
ITEMPKFK | VARCHAR2(25) | FK → ITEM_MASTER.ITEM. Always VARCHAR2 — never cast to NUMBER. |
IMAGE_TYPEPK | VARCHAR2(6) | Identifies the purpose of this image. Retailer-configured values — see IMAGE_TYPE section below. |
IMAGE_ADDR | VARCHAR2(400) | The URL or file path to the image. This is the reference that downstream systems consume. Not binary data. |
IMAGE_DESC | VARCHAR2(120) | Optional descriptive label for the image (e.g. 'Front view on white', 'Lifestyle shot'). |
IMAGE_INDATE | DATE | Date the image was associated with the item. Audit field. |
IMAGE_TYPE — Multiple Images Per Item
The IMAGE_TYPE column controls what kind of image a given row represents. Values are retailer-configured but follow common conventions across Oracle Retail implementations. Each type corresponds to a different use case in the downstream systems that consume item images.
| Column | Type | Description |
|---|---|---|
A | Primary / Front | The main product image — front view on a clean or white background. This is the image used in most e-commerce product listings, internal reporting tools, and storefront displays. |
B | Alternate / Back | Secondary image — back view, alternate angle, or variant close-up. Used in multi-image product pages. |
C | Swatch / Detail | Colour swatch or fabric/material close-up. Critical for fashion and homeware items where the customer needs to see texture or exact colour. |
D | Lifestyle | Contextual or in-use photography — the item being worn, used, or displayed in a real setting. Used for marketing and digital editorial. |
E | Dimensional / Technical | Technical or dimensional drawing. Used in homeware, furniture, and electronics where precise measurements are displayed visually. |
F | Barcode / Label | An image of the product label or barcode. Used in some receiving workflows and compliance documentation. |
IMAGE_TYPE values are instance-specific — always look them up
The IMAGE_TYPE codes above are conventions, not hard-coded standards.
In any given Oracle RMS implementation, the valid values and their meanings
are configured in the CODE_DETAIL table under the code type
'IMTP' (or similar). Always query CODE_DETAIL for the actual
IMAGE_TYPE values in your specific instance rather than assuming the codes
above are present. Never hardcode image type values in integration scripts.
Image Storage Patterns — URLs, Paths and DAM Integration
Because ITEM_IMAGE.IMAGE_ADDR is a plain VARCHAR2(400), it can hold any string — a relative file path, an absolute URL, a CDN endpoint, or a DAM system identifier. The pattern used has major implications for integration consumers.
IMAGE_ADDR is a reference — if the image moves, the reference breaks
Oracle RMS has no mechanism to validate that the URL or path in
IMAGE_ADDR actually resolves to a live image. If the CDN is
restructured, if a file is renamed, or if the hosting provider changes, the
references in ITEM_IMAGE become broken links. Integrations that feed
image URLs to e-commerce platforms or storefront systems should include a
validation step that checks image reachability — not just that the
ITEM_IMAGE row exists.
ITEM_SUPP_COUNTRY_DIM — Physical Dimensions
The ITEM_SUPP_COUNTRY_DIM table stores the physical measurement attributes of an item as specified by a particular supplier from a particular country of origin. Physical dimensions in Oracle RMS are modelled at the item-supplier-country level because the same item sourced from factories in different countries may have slightly different packaging dimensions or weights.
This table is consumed by warehouse management systems (WMS) for bin slotting, carton sizing, and pallet build calculations, and by logistics systems for freight cost estimation.
The composite primary key includes DIM_OBJECT — the level at which the dimension applies. This allows storing dimensions for the individual selling unit, the inner pack, and the outer case on the same item-supplier-country combination.
| Column | Type | Description |
|---|---|---|
ITEMPKFK | VARCHAR2(25) | FK → ITEM_MASTER.ITEM. |
SUPPLIERPKFK | NUMBER(10) | FK → SUPS.SUPPLIER. |
ORIGIN_COUNTRY_IDPK | VARCHAR2(3) | FK → ITEM_SUPP_COUNTRY. Country of origin. |
DIM_OBJECTPK | VARCHAR2(6) | The packaging level: 'EA' = each (selling unit), 'IN' = inner pack, 'CA' = outer case/carton. |
WEIGHT | NUMBER(12,4) | Item weight in WEIGHT_UOM units for this DIM_OBJECT level. |
WEIGHT_UOM | VARCHAR2(4) | Unit of measure for weight — KG, LB, etc. |
LENGTH | NUMBER(12,4) | Physical length in LWHDIM_UOM units. |
WIDTH | NUMBER(12,4) | Physical width in LWHDIM_UOM units. |
HEIGHT | NUMBER(12,4) | Physical height in LWHDIM_UOM units. |
LWHDIM_UOM | VARCHAR2(4) | Unit of measure for length/width/height — CM, IN, MM, etc. |
LIQUID_VOLUME | NUMBER(12,4) | Liquid capacity for containers. Used for bottles, pouches, etc. |
LIQUID_VOLUME_UOM | VARCHAR2(4) | Unit of measure for liquid volume — ML, FL (fluid oz), etc. |
DIM_OBJECT lets you store dimensions at three packaging levels
A single item from a single supplier sourced from a single country can have
three ITEM_SUPP_COUNTRY_DIM rows — one for the individual selling unit
(DIM_OBJECT = 'EA'), one for the inner pack ('IN'), and one
for the outer case ('CA'). WMS systems typically need all three to
correctly calculate pallet builds: the case weight for freight, the inner pack
dimensions for shelf slotting, and the each dimensions for individual product
display.
Ticketing Attributes — ITEM_TICKET
Oracle RMS has a dedicated ticketing module that drives shelf label and price ticket printing. The ITEM_TICKET table holds the ticket printing configuration for each item — how many tickets to print, when to print them, and in what format.
| Column | Type | Description |
|---|---|---|
ITEMPKFK | VARCHAR2(25) | FK → ITEM_MASTER.ITEM. |
TICKET_TYPE_IDPK | NUMBER(10) | FK → TICKET_TYPE. Defines the label format, size, and content template used for this item. |
TICKETS_PER_ITEM | NUMBER(3) | Number of tickets printed per unit when a price ticket print job is triggered (e.g. on receipt or price change). |
AUTO_TICKET_IND | VARCHAR2(1) | Y = tickets are automatically printed when certain events occur (receipt, price change). N = manual print only. |
The TICKET_TYPE table defines the actual label template — barcode format (EAN-13, QR, etc.), printed fields (price, description, size, colour), label dimensions, and the printer type it targets. In RMS printing workflows, the ITEM_TICKET row links the item to its label template, and the print batch reads both to generate the correct output for the correct printer.
The Oracle Retail Extension Model
Retailers often need to capture attributes that are not in any Oracle RMS standard table — a proprietary sustainability score, a loyalty exclusion flag, an internal audit field, or a B2B-specific pricing tier. The temptation is to add custom columns directly to ITEM_MASTER or create a completely independent table with no relation to the RMS framework.
Oracle Retail formally documents an extension model — a specific pattern for adding custom attributes that does not break future upgrades and is supported by Oracle's patching and migration tools.
Adding Custom Columns — The Safe Approach
Oracle Retail ships a set of pre-defined extension tables alongside the core schema. These tables are empty by design — they exist purely to receive custom columns added by the retailer or implementation partner. The most relevant for item data is ITEM_MASTER_EXT.
ITEM_MASTER_EXT has the same primary key as ITEM_MASTER — the ITEM column. Oracle Retail guarantees it will not be modified by upgrade patches. When a retailer needs a custom item attribute, the correct pattern is:
- Add the custom column to
ITEM_MASTER_EXTviaALTER TABLE - Create a corresponding row in
ITEM_MASTER_EXTwhen each new item is created - Access the custom attribute by joining
ITEM_MASTERtoITEM_MASTER_EXTon theITEMcolumn - Expose the attribute through a custom view or API wrapper as needed
| Column | Type | Description |
|---|---|---|
ITEMPKFK | VARCHAR2(25) | FK → ITEM_MASTER.ITEM. The only column present before customisation. |
[custom columns] | Any Oracle type | Custom columns added by the retailer. Examples: SUSTAINABILITY_SCORE NUMBER(3), B2B_EXCL_IND VARCHAR2(1), LOYALTY_CATEGORY VARCHAR2(20). |
Create ITEM_MASTER_EXT rows in the same transaction as ITEM_MASTER
If custom attributes in ITEM_MASTER_EXT are required for all items,
the row must be created as part of the item creation transaction — not in a
separate step. Items created before the extension table row is inserted will
be missing their extension record. A LEFT JOIN from ITEM_MASTER to
ITEM_MASTER_EXT will return NULL for their custom columns, which
downstream systems may interpret as data errors rather than missing records.
Custom Extension Tables — The Preferred Approach
For larger sets of custom attributes, or for custom attributes that have their own relationships (e.g. an item can have multiple custom records, or the custom data joins to other reference tables), the better approach is a completely new custom table that references ITEM_MASTER via a foreign key.
This pattern is used when the custom attributes are complex enough to warrant their own table — multi-row relationships, their own PK beyond just ITEM, or their own status and lifecycle.
Example — a custom sustainability attributes table:
The XXRC_ prefix (where RC is the retailer's initials) is the Oracle Retail convention for custom objects — it prevents naming conflicts with any future Oracle-delivered table, view, or package that might use the same name.
RC:Storefront consumes structured item data — images, categories, custom attributes — from RC:OMS in real time. The same disciplined product data model that Oracle RMS uses for enterprise retail powers clean, image-rich, SEO-ready product pages on RC:Storefront. Self-hosted, zero transaction fees.
See RC:Storefront →Key Tables — Quick Reference
Practical SQL Examples
1. All images for an item with type descriptions
2. Items missing a primary image — e-commerce readiness check
3. Physical dimensions for an item across all sourcing countries
4. Items missing case dimensions — WMS integration readiness check
5. Full item data export — master, images, dimensions and custom attributes
Common Gotchas for Developers
Important Gotchas
- !
Hardcoding IMAGE_TYPE values like 'A' or 'B' in integration scripts. The
IMAGE_TYPEcodes are retailer-configured values inCODE_DETAIL. One implementation uses'A'for the primary image; another uses'PRIMARY'; another uses'F'. Scripts that hardcode these values will silently return no rows in any environment that uses different codes. Always look up the valid codes fromCODE_DETAIL WHERE code_type = 'IMTP'and parameterise them. - !
Treating a non-NULL IMAGE_ADDR as a valid, reachable image.
ITEM_IMAGE.IMAGE_ADDRis a free-text field. A row can exist with a value inIMAGE_ADDRthat is a broken URL, a path to a file that was deleted, or a placeholder string entered during data migration. The presence of a row inITEM_IMAGEdoes not guarantee the image is live. Always validate image reachability in integration pipelines that feed e-commerce or customer-facing systems. - !
Adding custom columns directly to ITEM_MASTER instead of ITEM_MASTER_EXT. This is the most damaging implementation mistake in Oracle Retail projects. Custom columns on core tables survive until the next Oracle patch is applied. Any patch that modifies the column structure of
ITEM_MASTERwill conflict with custom columns and fail. Oracle Support will not assist with upgrade issues on modified core tables. Custom attributes always go intoITEM_MASTER_EXTor a customXXRC_*table. - !
Not creating ITEM_MASTER_EXT rows when items are created. If the extension table pattern is in use, every new item must have a corresponding row in
ITEM_MASTER_EXT. Item creation scripts or staging batch processes that do not include this INSERT will leave items without extension records. Queries that INNER JOIN toITEM_MASTER_EXTwill silently exclude those items from all results. - !
Querying ITEM_SUPP_COUNTRY_DIM without filtering on DIM_OBJECT.
A single item can have up to three
ITEM_SUPP_COUNTRY_DIMrows per supplier-country combination — one for eachDIM_OBJECT(EA, IN, CA). Querying without aDIM_OBJECTfilter returns up to three rows per item. Any query that selects dimension values into scalar variables will throwTOO_MANY_ROWS. Always filter by the specificDIM_OBJECTyou need for your use case. - !
Using ITEM_IMAGE for full-resolution binary storage via LONG RAW or BLOB workarounds.
Some older implementations attempted to store binary image data in the database using workaround columns on custom extension tables. This makes the RMS database grow very large, slows down all operations on those tables, and creates backup and recovery challenges. Oracle Retail's design intent is clear:
ITEM_IMAGEstores references, not data. Binary image storage belongs in a dedicated file system, object store, or DAM system.
Key Takeaways
Key Takeaways
- ITEM_IMAGE stores URL or path references to images — not binary data. The IMAGE_TYPE column (PK with ITEM) identifies the image's purpose. Valid IMAGE_TYPE values are in CODE_DETAIL — never hardcode them.
- ITEM_SUPP_COUNTRY_DIM stores physical dimensions at three packaging levels: each (EA), inner pack (IN), and outer case (CA) — per item, per supplier, per country of origin. Always filter on DIM_OBJECT or you get up to three rows per item.
- ITEM_TICKET links items to their label printing templates. AUTO_TICKET_IND = 'Y' triggers automatic print jobs on configurable events such as receipt or price change.
- Custom item attributes must never be added to ITEM_MASTER directly — patches will conflict. Use ITEM_MASTER_EXT for simple column additions (Oracle-sanctioned extension table) or a custom XXRC_ table with a FK to ITEM_MASTER for complex structures.
- The XXRC_ prefix is the Oracle Retail naming convention for custom objects. It prevents naming conflicts with any future Oracle-delivered table, view, or package.
- A non-NULL IMAGE_ADDR is not proof of a live image. Integration pipelines feeding customer-facing systems should validate image reachability, not just the presence of a row in ITEM_IMAGE.


