Jewelry store website development using 1C-Bitrix

Jewelry Store Website Development on 1C-Bitrix

A jewelry e-commerce store differs from typical e-commerce in one fundamental aspect: a significant portion of inventory is one-of-a-kind. Two rings with a 0.5 carat diamond may differ in color, clarity, and cut — thus differing in cost. The 1C-Bitrix platform with "Trade Catalog" module (sale + catalog) allows item-by-item accounting, but standard trade offer logic requires adaptation.

Jewelry Catalog — Information Block and Trade Offers

Catalog structure built on product information block with linked SKU information block (trade offers). Main block contains the model card; SKUs contain specific instances:

Main Information Block Properties (model):

• Product type — list: rings, earrings, pendants, bracelets, chains, brooches, necklaces.
• Collection — binding to collection information block elements.
• Metal — list with multiple selection: 585 gold, 750 gold, 950 platinum, 925 silver.
• Stone (gemstone) — list: diamond, emerald, sapphire, ruby, no stone.
• Style — list: classic, contemporary, vintage.
• Model description, care recommendations — HTML properties.

SKU Properties (specific instance):

• SKU — unique instance identifier. String property, required, with uniqueness check.
• Hallmark — number.
• Product weight (g) — number with centesimal precision.
• Size — number (for rings and bracelets).
• Stone characteristics — property group: carats, color (GIA scale), clarity, cut.
• Certificate — file (scan of gemological certificate).
• Instance photos — multiple "File" property.

This two-level structure allows displaying the model card with list of available instances. User selects not abstract "size 17," but specific piece with unique weight and stone characteristics.

Advanced Filtering

Jewelry catalog filtering is more complex than typical e-commerce due to parameter combinatorics. Implementation via bitrix:catalog.smart.filter with faceted index:

• Metal — checkboxes.
• Stone — checkboxes.
• Product type — checkboxes.
• Price range — slider (range slider).
• Size — slider or dropdown.
• Weight — slider.

Faceted index (b_catalog_smart_filter) recalculates on product updates from 1C. For 5000+ SKU catalog, facets are mandatory — without them, filtering degrades to seconds per query.

Visualization: Photos, Zoom, 360°

Jewelry requires quality visualization. At Bitrix level, this means:

• Main photo — "File" property in SKU. Loaded in high resolution (minimum 2000×2000 px). Resized via CFile::ResizeImageGet for preview (400×400), catalog (800×800), and zoom (original).
• Zoom — on detail page, library connected (drift or elevate-zoom) with original load on hover.
• 360° rotation — series of 24–36 frames shot on turntable. Stored as multiple "File" property in fixed order. On front — JS player cycling frames via drag/swipe.
• Video on model — YouTube/Vimeo URL in string property, embedded via iframe with lazy loading.

Ring Size Selection

Online tool for ring size determination. Two implementation options:

1. By existing ring — user applies ring to screen, scales circle until match. Requires screen diagonal calibration (determined via JS or manually entered).
2. By finger circumference — instructions + field for string length in mm, conversion to size by table.

Correspondence table stored in Highload block or in component config. Selection result saved in session and substituted in catalog filter.

Engraving and Customization

Additional services on checkout implemented via basket property mechanism in sale module:

• When adding product to basket, form displays: engraving text (up to 20 characters), font (selection from 3–5 variants), gift wrapping.
• Values saved as basket element properties (CSaleBasket::Update with PROPS array).
• On manager side — properties visible in order and transferred to print forms.

Integration with 1C: Item-by-Item Accounting

Standard exchange via CommerceML assumes product is model with variants (size, color). In jewelry business, each instance is unique. This requires exchange modification.

Deep-dive: Catalog with Item-by-Item Accounting and Unique SKUs

Standard Exchange Problem

In typical CommerceML exchange, trade offer identified by characteristic combination: "Ring, 585 gold, size 17" may exist in quantity 10. In jewelry accounting "Ring, 585 gold, size 17, weight 3.82 g, diamond 0.31 ct VS1 G" — this is one specific item with SKU R-585-1742. Cannot combine with another same-size ring because weight, stone, and cost differ.

Solution Architecture

Each instance exported from 1C as separate trade offer with unique XML_ID matching SKU. Stock always 0 or 1. Scheme:

Exchange Handler Modification

Standard handler /bitrix/admin/1c_exchange.php processes import correctly if 1C properly configures characteristic export as separate offers. Key settings:

• In 1C: nomenclature characteristic export enabled, each characteristic = unique Id.
• In Bitrix: catalog block settings, "Trade Offers" option enabled, type — "Each offer — separate element."
• SKU properties (weight, stone characteristics) mapped through exchange settings in "Property Matching" section.

If standard mapping insufficient, attach event handler OnSuccessCatalogImport1C, enriching SKUs after import: parse additional fields from XML and write to block properties.

Sold Instance Accounting

On order placement, SKU stock decreases to 0 items. Instance disappears from catalog (availability filter in component). Next 1C exchange synchronizes stock. Important — reservation: on basket addition, instance reserved for 30 minutes via catalog_store_barcode mechanism or custom OnSaleBasketItemAdd handler.

GIIS DMDK

Since 2024, jewelry items subject to mandatory GIIS DMDK marking. Each item assigned unique identification number (UIN). On site, this is additional SKU property displayed in product card and transferred in order documents. GIIS integration performed on 1C side; site receives ready UIN via exchange.

Technical Summary

• Catalog performance — faceted index mandatory, recalculation triggered by cron after each 1C exchange.
• Caching — component auto-caching with tags by block. SKU update from 1C automatically clears cache.
• Images — WebP conversion via OnBeforeResizeImage handler, originals stored for zoom.
• Mobile version — responsive layout accounting for 360° view switching to swipe gallery on mobile due to performance limits.

"One SKU = one instance" architecture requires careful exchange configuration with 1C, but ensures precise accounting and correct display of each item's unique characteristics in catalog.